Generalize MCP Apps cards over authoritative tool results and evidence

[yyjeqhc]

Timing

Post-0.3.8 product theme. Finish the remaining small capability work first; this issue is about presenting the mature substrate rather than adding another execution model.

Problem

WebCodex already exposes rich structured state across Projects, Jobs, validation/evidence, Git, Artifacts, and Computer Use, but most of that state is consumed as ordinary MCP tool results. The existing MCP App path proves the host integration mechanics, but the coding/runtime surface does not yet have a coherent card layer.

The next UI layer should make durable execution and evidence visible without creating a second source of truth.

Core invariant

A card is a projection of authoritative WebCodex state/result/evidence. It must never create workflow truth, authority, or effect state.

Examples:

• a card may render running, reconnecting, reconciled, outcome_unknown, or terminal Job state, but visual state cannot change the Job;
• a validation card may summarize recorded parser evidence, but cannot turn a failed/unknown validation into success;
• a Computer card may render the latest bounded observation, but cannot imply an effect succeeded when the authoritative result is unknown.

Direction

Build one reusable MCP App/card presentation layer rather than one independent app implementation per tool.

A reasonable first set of card families:

• Project/bootstrap card: project/Runner identity, instructions, capabilities, relevant session context;
• File/edit card: bounded read metadata, guarded edit/patch result, changed paths;
• Git card: status/diff summary and bounded hunks;
• Validation card: structured test/check counts, evidence, duration and failures;
• Job card: queued/running/reconnecting/reconciled/completed/lost/outcome-unknown state, bounded logs and duration;
• Artifact card: metadata, image/file preview and ResourceLink-backed delivery;
• Computer card: evolve the current snapshot presentation path rather than duplicating it.

Prefer a shared app resource that dispatches by a small presentation envelope/category. Keep model-facing structuredContent contracts independent from UI-only presentation metadata.

Presentation envelope

Define a bounded UI metadata envelope sufficient for rendering without copying large or sensitive result bodies into _meta.

It should identify at least:

• card kind/version;
• authoritative object/result identity when one exists;
• display-safe state/summary;
• bounded file/count/duration metadata;
• safe follow-up actions or resource references where supported.

Do not place secrets, raw credentials, unbounded logs, screenshot bodies, full large diffs, or other sensitive payloads in presentation metadata.

Durable-state UX

Cards should explicitly represent production states that ordinary text output tends to hide, for example:

• waiting for capacity;
• Runner temporarily unavailable while the Job remains alive;
• Job reconciled after Runner restart;
• upstream/provider cooldown;
• outcome_unknown with an observation/reconciliation next step;
• terminal completion after a long-running request has outlived the initiating model turn.

This should be designed to compose naturally with detached execution (#88) and later terminal-Job continuation work.

Acceptance criteria

• At least three non-Computer tool/result families render through one shared MCP App resource and presentation envelope.
• Text/structured fallback remains complete when the host does not support MCP Apps.
• UI rendering does not alter authoritative Job/Execution/session/evidence state.
• Large logs/diffs/artifacts stay behind existing bounded/resource delivery mechanisms rather than being copied into card metadata.
• Sensitive values are absent from app metadata and host-visible diagnostics.
• Unknown/reconnecting/reconciled states have explicit visual semantics and do not collapse into generic success/failure.
• Existing model-facing schemas do not need to grow presentation-only fields.
• Focused host integration tests cover tool metadata, result metadata, fallback behavior, and at least one durable Job state transition.

Non-goals

• redesigning the execution/Job state machine;
• changing authority or permission decisions from UI state;
• building a generic frontend framework unrelated to MCP Apps;
• expanding the tool surface merely to support cards;
• automatic inference/model continuation in this issue.