Add LibreSign tools for Nextcloud Context Agent #9053

Goal

Expose carefully scoped LibreSign operations to Nextcloud Context Agent so an authorized user can ask for help with signing workflows while LibreSign remains the authority for policy, validation and execution.

AI is a tool for invoking implemented LibreSign capabilities. It is not intended to reproduce or replace the whole LibreSign interface or business logic.

Candidate capabilities

Only expose operations that already exist as reliable LibreSign services/workflows.

Future candidates may include:

• inspect signing-request status;
• find requests/documents the actor can access;
• prepare a request;
• add or change recipients through normal domain rules;
• set signing order through normal domain rules;
• send a request;
• send reminders;
• cancel a request.

The final set must be decided from implemented product capabilities and risk, not from what the model can theoretically call.

Platform availability

Revalidate the public Nextcloud Context Agent/Task Processing contracts when this blocked epic becomes actionable.

Current Nextcloud sources expose Context Agent task types, but their availability is version-dependent. Do not assume Context Agent exists on every Nextcloud version supported by LibreSign.

If the required public contract is unavailable on an otherwise supported Nextcloud version, the feature must be capability-gated or the minimum-version decision must be made explicitly at release/product level.

Authority model

Every tool invocation must pass through normal LibreSign:

• actor identity;
• effective policy;
• document/request access;
• workflow state;
• input validation;
• audit behavior.

The model never grants permission.

For consequential actions, especially sending, notifying, changing participants or cancelling, use least agency and require explicit confirmation where appropriate.

Security

• Do not give the model generic database, filesystem or unrestricted HTTP access.
• Expose narrow purpose-built tools.
• Validate every argument server-side.
• Treat tool-selection/model output as untrusted.
• Prevent confused-deputy behavior and cross-user access.
• Keep idempotency/retry behavior safe for external actions.
• Audit consequential operations through the same mechanisms as equivalent manual actions.

UX and prototyping

Study official Nextcloud Context Agent/tool interaction patterns before defining confirmation and result surfaces.

Prototype:

• proposed versus executed action states;
• clear confirmation for consequential operations;
• error and partial-failure recovery;
• how users return to the relevant LibreSign request/document;
• how the UI communicates which action will occur before execution.

Do not create a second full LibreSign UI inside chat.

Documentation

Document:

• available LibreSign agent tools;
• required policies/permissions;
• which actions require confirmation;
• important limitations;
• audit/security behavior relevant to administrators;
• examples that teach use without implying the agent has broader authority than LibreSign.

Planning gate

This is intentionally a later-stage epic.

Do not fully decompose it until the AI foundation and Context Chat/content-access work have established stable identity, policy, ACL and tool-integration contracts.

Before creating implementation issues, review current Nextcloud Context Agent APIs and the set of LibreSign operations that are already safe and reusable as application services.

Non-goals

• giving the LLM direct database access;
• bypassing existing LibreSign services;
• making the agent autonomous over signing workflows;
• exposing every LibreSign operation just because a tool interface exists;
• reimplementing LibreSign screens in chat.

Done when

• Only reviewed, purpose-built LibreSign tools are exposed.
• Every tool enforces normal policy/access/domain validation.
• Consequential actions use appropriate confirmation and audit.
• Agent/tool flows are covered by authorization and adversarial tests.
• UX has been prototyped/reviewed for proposed/executed actions and failures.
• Administrator/user documentation describes tools, permissions and limits.

Decomposition gate

This epic is intentionally blocked by prerequisite work tracked through GitHub's native dependency relationships.

Do not create a full implementation backlog for this epic while its blockers are open.

When all blockers are complete, review this epic against the actual Context Chat identity, ACL, policy, content and tool-integration contracts. Update the goal, scope, architecture, UX assumptions, security requirements, testing strategy and documentation requirements where needed. Only then create focused implementation sub-issues.

The current description preserves product intent and research; it is not authorization to implement around unfinished prerequisite contracts.