Integrate LibreSign with Nextcloud Task Processing #9056

Goal

Implement the reusable LibreSign backend integration with the public Nextcloud Task Processing APIs using the capability contract defined by the AI foundation.

Scope

Create the backend service boundary responsible for:

• discovering available task types for the relevant user/context;
• mapping Nextcloud task types to LibreSign semantic AI capabilities;
• scheduling/running supported tasks;
• retrieving results;
• handling failures/cancellation;
• exposing only the capability information needed by LibreSign consumers;
• keeping provider-specific details out of product code unless exposed for neutral informational purposes.

Use the supported Nextcloud public APIs. Do not detect AI support by checking whether a particular provider or Assistant app is installed.

Capability surface

Frontend/application consumers should work with semantic LibreSign capabilities rather than raw provider names.

The representation should be able to distinguish individual features; avoid one global aiEnabled flag that hides whether summary, chat, generation or another operation is actually available.

Do not expose capabilities that do not yet have a LibreSign consumer.

Task ownership and actor context

Use the actor/context rules established by the foundation contract.

Task ownership, result retrieval and authorization must prevent one actor from seeing or operating another actor's tasks.

Public/external signer handling must follow the agreed policy/actor contract rather than a frontend shortcut.

Security

• Minimize data sent to Task Processing.
• Do not include provider credentials in LibreSign.
• Validate task output at the consuming LibreSign boundary.
• Fail closed when capability/authorization state cannot be resolved safely.
• Do not convert technical capability into permission.
• Preserve cancellation/error semantics without exposing internal provider details unnecessarily.

Tests

Use the deterministic Task Processing test provider to cover:

• capability available and unavailable;
• feature-specific capability mapping;
• successful synchronous/asynchronous flow as applicable;
• controlled failure;
• cancellation;
• actor/task ownership;
• invalid output path;
• policy denial remains authoritative even when technical capability exists.

Documentation

Developer-facing architecture documentation should explain the reusable Task Processing boundary only where it is needed for maintainers. End-user/provider setup belongs to product documentation tasks, not implementation notes.

Done when

• LibreSign uses public Nextcloud Task Processing APIs through a reusable backend boundary.
• Semantic LibreSign capabilities are exposed without provider coupling.
• Task lifecycle/error handling follows the agreed contract.
• Actor/task ownership is enforced.
• Deterministic integration tests cover capability and failure paths.
• No provider/model configuration stack is introduced in LibreSign.