Failure workbench: inspect an obstructed edit and retry with a fresh basis #333

Product outcome

A failed or obstructed document-edit command becomes an inspectable work item: what was requested, the basis it used, the last evidenced outcome, and whether any effect is known to have occurred. The user can revise the request and explicitly try again against a newly observed basis.

The failed attempt stays in history. Retrying creates a new attempt linked to it; it does not rewrite failure into success. Document drafts and invalid source text are legitimate content, not failed preservation states.

First independently mergeable scope

One inspect → revise → retry interaction for a supported basis-bound Jim document-edit command. Derive the attempt view from retained command and settlement evidence. Reuse the ordinary authored intent/admission path for retry, with a fresh basis and identity. Keep the original request and result inspectable after restart.

Acceptance

• Inspection distinguishes refused/no effect, admitted effect, pending/unknown outcome, and unavailable evidence using the existing typed outcomes.
• Missing receipt evidence is never interpreted as proof that nothing happened. An ambiguous attempt must be resolved through its existing correlation/idempotence contract before offering a potentially duplicating retry.
• Editing retry parameters leaves the original attempt unchanged; submission explicitly identifies the new basis and links the new attempt to the old one.
• If the document changes after retry preparation, normal admission validation yields an honest stale-basis result. The UI does not silently replace the basis or ranges.
• Dismissing an item changes its presentation only; it does not delete history or abandon an in-flight command without an explicit supported action.
• At least one real obstructed edit can be inspected, revised, successfully resubmitted, and explained after restart. A second case covers unknown/pending outcome without duplicate application.
• Human and machine output agree on attempt linkage, basis, outcome, and evidence availability. Tests run in guarded Docker through the actual runtime boundary.

Prerequisites and ownership

Proposed prerequisite: #201 for the supported typed settlement outcomes used by the interaction. #171 owns command lifecycle presentation; reuse its evidence model where it exists, but a timeline visualization is not a correctness prerequisite. #177 owns obstruction vocabulary and #86 owns idempotent delivery/recovery; this issue must not invent competing taxonomies or delivery machinery.

This issue owns the repair interaction and immutable retry linkage, not the base diagnostics. If existing retained evidence cannot correlate attempts after restart, identify that exact prerequisite before implementation rather than creating a TypeScript-only history.

Exclusions and safe merge state

No automatic retry loop, arbitrary external side effects, general debugger, or promise that all failures are repairable. Enable retry only for the supported operation and evidenced safe posture. Other failures remain inspectable with a precise explanation of why retry is unavailable.