Add end-to-end coverage for LibreSign AI integrations #9060

Goal

Add layered end-to-end and integration coverage that proves LibreSign AI features work through the real Nextcloud integration path without making ordinary CI depend on paid APIs or unstable generated prose.

This issue is part of the AI foundation epic.

Test layers

Use three complementary layers.

1. Deterministic pull-request coverage

Use the LibreSign deterministic Task Processing provider/test double for fast, exact and reproducible behavior.

Cover representative end-to-end flows such as:

• capability unavailable;
• capability available and policy allowed;
• capability available and policy denied;
• successful task/result;
• failure and retry/recovery behavior;
• invalid/hostile output;
• relevant cancellation/asynchronous behavior;
• frontend visibility/action state follows backend capability and policy.

This layer should be suitable for normal pull-request CI.

2. Provider integration contract

Where feasible, exercise LibreSign through an official Nextcloud provider integration against a deterministic local compatible endpoint/test backend.

The purpose is to cover:

LibreSign -> OCP Task Processing -> provider integration -> provider protocol -> Task Processing result

without paid/network-dependent model calls.

Only add this layer if it materially covers behavior that the deterministic provider cannot.

3. Real local-AI smoke coverage

Use a small number of real local-provider smoke tests where this adds confidence.

Follow the patterns used by Nextcloud AI applications such as llm2:

https://github.com/nextcloud/llm2

Use CPU execution/model caching where practical and avoid making generated wording an assertion.

Real-model tests should check stable invariants such as:

• task completes successfully;
• expected output shape is present;
• file/document input reaches the supported task path;
• structured output can be parsed/validated;
• security/policy invariants remain enforced.

Initially this layer may run on relevant paths, main/nightly or a dedicated workflow if its runtime is not appropriate for every pull request.

Context Chat precedent

For future retrieval work, follow the ACL/lifecycle style of the official Context Chat integration tests:

https://github.com/nextcloud/context_chat

That includes proving content is unavailable without access and removed from retrieval after access/delete changes.

Do not implement future Context Chat tests in this foundation issue before that feature exists.

Flake/cost policy

• No paid API requirement for required CI.
• No assertion on exact natural-language output from a real model.
• Pin/cache model/test infrastructure where appropriate.
• Keep real-model smoke scenarios few and contract-focused.
• A provider outage must not make normal pull-request CI nondeterministic.

Security scenarios

Ensure the layered test architecture can exercise:

• prompt-injection-like document content;
• malformed structured output;
• unsafe generated markup where a feature consumes markup;
• cross-user task/result access;
• policy denial;
• provider absence/failure.

Feature-specific adversarial cases remain the responsibility of the feature's implementation issues.

Done when

• Normal PR CI has deterministic end-to-end coverage of the shared AI path.
• The Task Processing boundary is exercised beyond unit mocks.
• Provider integration is covered where it adds unique value.
• A focused real local-AI smoke path exists where feasible and justified.
• Required CI does not depend on paid external AI.
• Tests assert stable contracts rather than exact real-model prose.
• Security/authorization failure paths are represented in the test architecture.