test: prove the supported operator workflow through an independent MCP client #848

Queue position -- 2026-10-05

Start a small executable baseline after #843 and the first #849/#850 shared projection. Add agreement/workstream reconstruction and revision-bound outcomes to the fixture journey. Expand with #846 and later client capabilities as they land; it is a continuing acceptance matrix, not a requirement to finish every platform feature before shipping the dashboard.

Goal

An independent client can carry out the complete supported operator workflow without LiveView, internal Elixir calls, or undocumented knowledge.

Use a tiny client/conformance harness as a concrete consumer of the existing single-operator API. This is the acceptance test for the five backend gaps filed alongside this issue, not a new desktop application.

Acceptance journey

1. Authenticate, initialize, discover capabilities and reconstruct current state.
2. Select/create a configured agent, submit a prompt with a durable identity, simulate losing the response, and retry/reconcile without duplicate execution.
3. Observe queued/executing/progress states and distinguish request acceptance from eventual completion.
4. Answer a question and resolve supported approval decisions, including workflow launch/budget attention. Exercise stale and duplicate decisions and unauthorized callers.
5. Retrieve the full answer/report and supported attachment/output references with documented result shapes.
6. Disconnect/reconnect and restart the isolated server, reauthenticate as needed, recover history via documented pagination/cursors and correlate the original message.
7. Exercise supported queue/stopping controls and show unavailable/unknown guarantees truthfully. A pause is not evidence of physical subprocess settlement.

Contract consistency work

For the operations this journey actually uses, document/version machine-readable result and error shapes, pagination boundaries, asynchronous state meaning, stale-state behavior and safe retry/reconciliation rules. Add declared output schemas where supported and useful. Cover both MCP tool errors and JSON-RPC errors; HTTP 200 is not an operation-success signal.

Do not require every historical tool to be redesigned before the first proof. Start with current capabilities, record exact gaps, and add cases as the related issues land. Unsupported capability handling can pass its own test but must not be reported as delivery of that capability.

Proof boundaries

Use an isolated server/database and deterministic provider fixtures for repeatable CI. Record tested versions and evidence. A native-provider smoke is separate, bounded work requiring applicable authorization; no new paid runs are authorized here.

Do not use the running fleet, weaken approvals, change #554/#555, or revive #836. Verify denied MCP calls while keeping authorization distinct from execution confinement. The current observe-mode repository grant behavior is a documented limit, not an arbitrary-agent sandbox.

Existing client contract, lib/custode/cli/client.ex and docs/mcp/authorization.md provide the baseline. No UI, new transport stack or generic platform rewrite is included.

Related client-contract work

• fix: separate full conversational answers from interval reports #843: separate full conversational answers from interval reports
• feat: expose independent conversation identity and lifecycle per agent #844: expose independent conversation identity and lifecycle per agent
• feat: expose resumable conversation and execution updates to clients #845: expose resumable conversation and execution updates to clients
• feat: expose image attachments and remaining operator actions to MCP clients #846: expose image attachments and remaining operator actions to MCP clients
• feat: complete provider-neutral delegation and explicit work controls #847: complete provider-neutral delegation and explicit work controls