[taras]

Why

A managed Ticket that stops for a design decision stays held after the coordinator records the accepted decision. This adds the supported transition back to its original owners.

Closes #1165.

What changes

Before: continue.md returned the held Ticket unchanged and advertised a missing resolution action.

After: resolve-decision.md --props-record ... --props-decision ... validates the exact decision, records its evidence and publishes the prepared successor. Normal continue.md --props-steps 1 then dispatches the required original owner. Resolution itself calls no provider.

Planner acceptance returns to its original Planner. Planner amendments and the supported Implementor discovery hold route through the original Architect and retained Planner before implementation. Accepted Architect holds return to the same Architect.

How it works

exact held checkpoint + decision/provenance/input references
  -> validate supported hold and clean launch source
  -> reserve and record the decision
  -> prepare original owner -> confirmed publication
  -> normal continuation

The closed ticket-decision.v1 request carries bounded references. Existing snapshot, source, identity, phase-validation and publication owners retain their responsibilities.

A matching confirmed repeat loads the recorded successor and validates its retained evidence. Rewriting or removing the original evidence files does not strand the repeat. Conflicts refuse; unfinished reservations remain held.

Review guide

Start with examples/adversarial-implementation/components/Ticket/ResolveDecision.md, then Decision.ts and DecisionInputs.ts.

Check routing, first-resolution admission, publication-before-receipt ordering and the confirmed-repeat branch. Executable acceptance lives in tests/DecisionResolution.test.md, with failure cuts and repeats in Fixture/DecisionInterruption.md.

What must stay true

• Preserve original sessions, calls, delivered inputs, source anchor and consumed allowances.
• First resolution requires a completed retained execution with no failure, even when a canonical decision result was saved.
• Confirmed repeats use retained snapshots under current File permission, protection and byte/hash integrity checks.
• Matching successor bytes never establish an unknown publication acknowledgement.
• Execution, permission, changed-input, source-mismatch, exhausted-bound and publication holds retain their existing recovery paths.

How to verify it

Focused checks passed on signed head 48e75b99d5c98b5eff3ff044af201fdd400722cd:

• deno task test packages/cli/tests/adversarial-decision-resolution.test.ts: routing, refusals, repeat/publication cuts, inherited boundaries and native identity.
• deno task test packages/cli/tests/adversarial-artifact-return-recovery.test.ts: retained-text and uncertain-publication boundaries.
• Affected Ticket and fixture/launcher typechecking, including the new component.

The repeat regression rewrites the decision origin and removes provenance, then requires the same successor with no extra publication or role call. Corrupting its retained snapshot still refuses. Restoring the unfixed resolver makes this regression fail. The earlier late-execution-failure regression also has a retained negative control.

Required CI passed, including green: 61 successful jobs, one skipped. The original Architect, original Planner and independent Fable reviewer each returned PASS on this exact head; Fable examined A1–A6. Main CI is healthy.

Scope

This supports clean unchanged launch source before implementation edits or signed feedback. General recovery, post-feedback amendments and adoption of #1164's standalone history are excluded. Runtime/workflow remain frozen at base a6c380e45e56b09305510e730b9881747f402790.

Consumer evidence remains historical: #1164 held source bd85a00406f245adffda5b296d4dc8163347cacd, continuation SHA-256 02b04e1e58668cd0402884ecd56b91ed3f8e26244d0a65a14fe040c20def8733. The tests reproduce its equivalent managed routing without adopting that run.

New abstractions

The per-hold decision receipt distinguishes confirmed repeats, conflicts and unknown publication. DecisionInputs separates first-time evidence acquisition from request binding so confirmed repeats can use retained evidence.

• Each new abstraction has a concrete production consumer and bounded purpose.
• No speculative recovery machinery is included.

Risks and limitations

Flake #1200 remains open: DR6 once failed and then passed on the identical previous commit. Its first failure and unchanged-revision pass are preserved. This repeat-origin correction is not established as that flake's cause or fix.

Source-correction cycle 3 of 3 is recorded without resetting allowances. Earlier managed feedback and the older quota-held Fable attempt remain preserved; separate delivery phases record this head's actual results.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• No generated changes, dependency changes or test-weight changes are included.
• The description matches the final diff and test results.

[github-actions]

PR #1198: Resume held workflows after recording a design decision

31 files, +1264 / -13

Scope

🔴 PR has 1277 lines changed. Split into focused PRs.

🟡 1277 lines changed. PRs under 400 receive more thorough review.

🟡 31 files changed. Are all changes related?

Structural

✅ No structural bloat detected.

Slop

✅ Slop indicators look low.

Static Analysis

Oxlint: 2 diagnostics across 1 file (1 rule)
Density: 0.002 violations/added-line

no-base-to-string (2): examples/adversarial-implementation/components/Ticket/Publish.ts

Correctness

No extraneous code patterns detected.

[taras]

P2: confirmed repeats still depend on mutable decision inputs

Reviewed head c6f995bc26cfe8aa1e3cedc350ca9deef6fc89ab.

ResolveDecision.md:31–32 calls Ticket.Decision before checking the confirmed receipt at lines 48–53. Decision.ts:92–101 validates new evidence against its current original files, using the old held checkpoint's document map. The new snapshots exist in the successor, so the repeat does not reuse them.

I reproduced this with deterministic local fixtures and the exact PR-head components:

1. Resolve an ordinary Planner decision hold successfully.
2. Keep the same decision JSON and old held envelope.
3. Rewrite only the original decision.md; leave the confirmed receipt and captured snapshot intact.
4. Repeat the identical request.

Expected: return the recorded successor, with no new publication or provider call. Observed: publication="held", status="hold", and Decision input differs from its descriptor. Hydrating the retained snapshot still returned the original accepted decision.

This breaks the documented confirmed-repeat/first-observation behavior and can prevent recovery of a lost successor after an original file is reused or cleaned up.

Please separate exact request/hold binding from fresh evidence acquisition: handle an already confirmed matching request using its recorded successor and retained evidence, preserving permission/protection and integrity checks. Keep first-resolution content validation, conflicting-request refusal and unknown-publication holds. Add a focused regression for unchanged requests after origin rewrite/removal.

The probe used the unchanged prepared base runtime and exact changed PR components. This finding is additional review feedback; no CI verdict or passing delivery-review receipt is claimed.