# AceLM artifact transitions and remediation catalog

Authoritative design record, 2026-10-05. Expressly labeled recommendations and open decisions remain provisional. Based on the lifecycle rules, metadata, plan items, and isolation policy in acelm-lifecycle-docs-03.tgz. This is a proposed transition contract, not a claim about what AW currently implements.

## Reading the catalog

**Latest design companion:** [AceLM status vocabulary and terminal UX](acelm-status-and-terminal-ux.md) captures the favored compact names, eight-character display, finalized Run labels, and finalized readiness. See [the status migration contract](acelm-status-migration.md) for type-specific mappings and adoption boundaries. Naming is not yet finalized, so this catalog retains older status tokens. The agreed behavioral correction is effective here: lifecycle phase is retained while work waits or pauses; active worker activity is tracked separately.

The original forward lifecycles are retained. All detailed gates, return routes, recovery policies, and additional states below are recommendations for discussion. **[NEW]** specifically identifies additions to the original status vocabulary or a return from a successful completion state. No other status is silently added.

AA = authoring agent; RA = adversarial review agent, distinct from AA in a separate context; EA = implementation/execution agent; VA = verification agent, recommended to be distinct from EA in a separate context. RA may also be VA if it was not EA. Human acceptance or explicit, scoped human delegation is required. The transition service enforces gates and publishes status changes; agents request transitions and provide evidence.

A failed request does not first enter its requested target status. A failed gate returns a structured decision: revise artifact, repair work, rerun checks, wait, ask for authority, or record a specific failure. Scope expansion always needs appropriate review and acceptance.

`A` below means any of specification, backlog item, or plan; `completed(A)` means implemented, done, or executed respectively. A self-transition means a recorded retry/activity event, not an unrecorded overwrite. Retry rules are in section 8 and apply to every repair, rerun, recovery, and iterative return in this catalog. The retry hierarchy requested for this revision is defined there; the cumulative multiplier of 20 reflects the latest requested update; the scope and detailed accounting rules are explicit implementation recommendations.

## 1. Shared authoring, review, and acceptance transitions

These rows apply separately to specifications, backlog items, and plans.

| ID | Transition or requested action | Passing gate / responsible actor | Failed gate and return route |
| --- | --- | --- | --- |
| R01 | New artifact → draft | AA/system allocates unique id6, type, provenance, revision, and workspace. | Repair serialization/registry/workspace; do not invent an accepted imported status. Reconcile duplicate requests idempotently. |
| R02 | draft → draft | AA revises content and records revision. | Validation feedback goes to AA; unresolved human decisions become blocking OQs. |
| R03 | draft → to-review | Required content, metadata, references, scope, review prerequisites, and blocking OQs are satisfactory. | Stay draft; AA fixes deficiencies. Human-dependent questions wait. |
| R04 | to-review → reviewing | RA independent of AA, isolated snapshot, current revision, exclusive action claim, available retry budget. | Remain to-review; reassign RA, repair infrastructure, or wait. Never pretend review occurred. |
| R05 | reviewing → reviewed | RA produces a positive verdict, evidence, and report for exactly the current revision; required review checks pass. | Negative verdict follows R06 or R07. A stale/incomplete report requires fresh review, not acceptance. |
| R06 | reviewing → draft | Negative review has remediable findings and review retries remain. RA returns findings to AA. | AA revises, then R03 - R05 repeat. Record unresolved disagreements; do not let AA certify its own revision. |
| R07 | reviewing → fail-review | Completed negative verdict exhausts the configured review retry budget. | Preserve findings; authorized recovery uses F01. A crash is not a negative verdict. |
| R08 | reviewing → to-review | Orderly release before a verdict, unsuitable RA, lost independence, or invalidated review snapshot. | Queue a fresh RA session; preserve prior findings and attempt history. Infrastructure retries use FAIL limits, separately from REVIEW verdict retries, and share the cumulative ceiling (section 8). |
| R09 | reviewed → to-review | Content unchanged but review is stale, insufficient, disputed, or must be repeated under changed context/policy. | Fresh RA checks the current context. If content must change, use R10 instead. |
| R10 | reviewed → draft | Authoring defects or substantive new requirements are found before acceptance. | AA revises; old review is no longer sufficient for the new revision. |
| R11 | reviewed → accepted | Valid current review, action-specific dependencies/OQs, authorized human or scoped delegated acceptance, current revision. | Missing approval: remain reviewed with need-ok (legacy: go-pending-approval). Content defect: R10. Stale review: R09. Other blockers: wait or bounded remediation. |
| R12 | accepted → to-review | Accepted content unchanged, but review/acceptance is invalidated by changed project context, policy, or an authority decision. | Suspend downstream launch; RA rereviews; obtain valid acceptance again. Preserve the previous acceptance as history. |
| R13 | accepted → draft | Accepted artifact needs a substantive revision. | AA revises; invalidate authorization for the changed revision and repeat review/acceptance. |
| R14 | accepted → accepted | Waiting for work, dependency, approval to perform a separate action, resources, or a start/resume decision. | Set action-specific readiness and waiting reason; do not turn ordinary waiting into fail-gate. |
| R15 | Any active downstream state → draft or to-review | New requirements, invalid scope, or stale authority invalidate the governing artifact. | First checkpoint and revoke/fence the old worker. Use draft for content changes, to-review for unchanged-content reassessment. Reaccept before resuming execution. |

A deterministic formatter may fix mechanical issues under explicit policy, but any changed artifact still needs the correct revision-bound review. Review findings alone never give RA authority to silently alter accepted requirements.

## 2. Specification transitions

Original forward chain: draft → to-review → reviewing → reviewed → accepted → implementing → implemented.

Shared review/acceptance rows apply in full.

| ID | Transition or action | Passing gate | Failed gate and return route |
| --- | --- | --- | --- |
| S01 | accepted → implementing | Valid accepted revision; scoped authorized EA actively starts implementation in its claimed workspace; relevant dependencies/OQs pass. | Remain accepted; AA fixes artifact defects, RA rechecks stale review, human supplies authority, or scheduler waits. |
| S02 | implementing → implementing | EA performs or repairs authorized implementation work; budget and authority remain valid. | In-scope repair stays with EA. Scope/criteria changes use R15. Specific implementation failure may use fail-execute. |
| S03 | implementing → implementing; activity becomes waiting/paused | Implementation began and is now orderly paused, yielded, or waiting. | Preserve phase, checkpoint, and resume action; release mutation ownership as appropriate. Interruption/death records its specific outcome. |
| S04 | accepted or implementing → implemented | All direct required fulfillment descendants are implemented/executed/done; original spec criteria and completion evidence pass; required integration/verification is current. | Pending children: wait. Defective child result: repair/reopen the responsible child. Missing evidence: regenerate/recheck it. Wrong spec: AA revises via R15. Exhausted completion verification: fail-verify. |
| S05 | Accepted specification → create backlog items, plans, or plan sets | Authorized derivation; unique children, correct links, acceptance-criterion coverage, reviewable membership. This is an activity, not a new spec status. | AA/planning agent repairs missing links/coverage or partially published children. Reconcile existing IDs before retrying. Children start draft; source acceptance is not inherited. |
| S06 | implemented → completion revalidation **[NEW reopening policy]** | Later changes invalidate current fulfillment/evidence; record the earlier completed revision and reason. | Return to accepted for revalidation/wait, implementing only with active authorized repair, or draft/to-review if the spec itself needs revision. See section 10. |

**Important:** no explicit specification verifying state was previously agreed. S04 is a completion-check activity. During an orderly implementation wait/pause, retain implementing and record separate activity. S04 remains a completion-check activity pending final naming/state decisions. An explicit verifying state is an alternative to discuss; do not label a verifier as an active implementer to satisfy implementing semantics.

Literal earlier rule: all artifacts with the specification as direct ancestor must be successful completions. Recommendation: distinguish required fulfillment edges from discovery/provenance edges, but adopting that distinction changes the literal rule and needs agreement. Superseded/retired/abandoned descendants do not automatically fulfill a specification.

## 3. Plan transitions

Original forward chain: draft → to-review → reviewing → reviewed → accepted → executing → verifying → executed.

Shared review/acceptance rows apply in full.

| ID | Transition or action | Passing gate | Failed gate and return route |
| --- | --- | --- | --- |
| P01 | accepted → executing | Current acceptance, dependencies, OQs, workspace/fencing, allowed files/resources, E/V structure, and EA authority pass; EA actually starts. | Stay accepted; repair authoring, authority, infrastructure, or wait as appropriate. |
| P02 | executing → executing | EA continues or makes bounded in-scope repairs, with evidence/checkpoints. | Failed action needs root-cause classification; do not blindly repeat non-idempotent effects. |
| P03 | executing → executing; activity becomes waiting/paused | Orderly pause/yield/wait after execution began. | Save completed E items and resume target; preserve phase, progress, and budgets. |
| P04 | executing → verifying | All required E items performed and recorded; frozen result snapshot and complete handoff to independent VA plus programmatic checks. | Missing work: EA finishes it. Missing handoff/evidence: EA reconstructs it. Invalid scope/plan: R15. No VA/resources: release EA mutation ownership; retain execution phase until verification starts, with the handoff queued/waiting and its resume action recorded. |
| P05 | verifying → executed | Every required V passes for final result and accepted plan; E/V coverage, scope, evidence, regression checks, acceptance criteria, descendants, integration, and publication gates pass. | Route by the gate catalog below. Never enter executed first and repair afterward. |
| P06 | verifying → executing | Verification found a bounded, authorized implementation defect and retries remain; EA actively resumes. | Invalidate affected V results; EA repairs; P04 - P05 repeat with independent verification. |
| P07 | verifying → verifying | Work is sound but checks/report/evidence must be rerun or completed for the same snapshot. | Send to VA or the evidence-producing agent. A product edit instead requires P06. |
| P08 | verifying → draft or to-review | Findings require changing accepted requirements, scope, files, methods, or acceptance authority. | Checkpoint; AA revision or RA reassessment; human/scoped acceptance; resume through P01. Preserve verification retry history. |
| P09 | verifying → fail-verify | Completed unsuccessful verification exhausts the action budget. | Authorized recovery uses F02; no cosmetic V checkbox or budget reset. |
| P10 | executing → executed, requested directly | Rejected: verification is required. | Route to P04 and P05. A compound API operation may perform both, but must record and enforce both. |
| P11 | Executing/verifying plan → create discovery backlog item | Concrete bug/feature/chore/new work with evidence, provenance, and appropriate blocking classification. | AA/planning agent repairs the new draft item. Discovery does not authorize executing it within the current plan. If it blocks current fulfillment, revise or explicitly model the blocker. |
| P12 | Orchestrator verifying → executed | Every child plan fully executed, current membership/graph, orchestrator's own E/V complete, combined integration checks pass. | Repair responsible child or integration in the orchestration workspace. Reverify combined result; children alone cannot certify the orchestrator. |
| P13 | executed → accepted / verifying / executing / draft / to-review **[NEW reopening policy]** | Result invalidated by later change, integration, revocation, or discovered incomplete work; preserve original completion history. | Choose destination by remedy: queued revalidation, active verification, active in-scope repair, changed plan, or fresh unchanged-content review. |

Plans may originate ex novo, from a specification, or from a backlog item. Creating a plan is distinct from accepting it. Plan-set membership is versioned; sets have no agreed independent status machine yet.

## 4. Backlog item transitions

Original graduated route: draft → to-review → reviewing → reviewed → accepted → graduating → graduated → done.

Recommended explicit direct-work route **[NEW states for backlog]**: accepted → executing → verifying → done. A small rename need not have a full plan, but still needs scope, acceptance criteria, evidence, and verification.

| ID | Transition or action | Passing gate | Failed gate and return route |
| --- | --- | --- | --- |
| B01 | accepted → graduating | Accepted outcome needs specs/plans/sets; authorized decomposition agent actively starts; dependencies, OQs, ownership, and scope pass. | Stay accepted; AA resolves ambiguity, authority waits, or infrastructure is repaired. |
| B02 | graduating → graduating | Agent creates/repairs successor artifacts and mappings. | Reconcile partial creation; reuse recorded IDs; no duplicate children from retries. |
| B03 | graduating → graduated | At least one valid intended successor; complete outcome coverage, stable IDs/provenance, published links, versioned set membership. | Planning/AA agent repairs omitted work, malformed children, broken links, duplication, or missing publication; remain in activity while actually active. |
| B04 | graduating → graduating; activity becomes waiting/paused | Orderly pause/yield/wait before decomposition finishes. | Retain phase and checkpoint published/pending children; resume idempotently. Interrupt/death is classified separately. |
| B05 | graduated → graduating | Decomposition incomplete or needs additional successors without changing accepted backlog outcome; agent actively resumes. | Repair mappings/children. If the backlog outcome changes, use R15 and reaccept. Child artifacts retain their own review lifecycle. |
| B06 | graduated → done | Every required successor has its successful completion; backlog outcome, evidence, integration, and closure checks pass. | Pending successor: wait. Bad successor: return its work to EA/VA/AA as appropriate. Missing closure evidence: recheck. Wrong decomposition: B05. Changed backlog: draft/to-review. Exhausted closure verification: fail-verify. |
| B07 | accepted → executing **[NEW]** | Bounded direct task is suitable without a plan; current authority, scope, criteria, deps, OQs, workspace, and active EA pass. | If too large/risky/ambiguous, B01 or revise/review first. No automatic bypass of acceptance. |
| B08 | executing → verifying **[NEW]** | Direct task performed; result snapshot, scope, and evidence ready for independent checking. | EA finishes work or evidence; changed scope requires review and acceptance. |
| B09 | verifying → done **[NEW]** | Direct-work acceptance criteria, required regression/scope/security checks, independent verification, and evidence pass. | B10 for code repair, B11 for check-only repair, or revision/review for changed requirements. |
| B10 | verifying → executing **[NEW]** | In-scope defect and remaining verification budget; EA actively repairs. | Recheck affected criteria and final result independently. |
| B11 | verifying → verifying **[NEW]** | No implementation edit required; rerun missing/invalid checks or evidence. | VA/evidence agent repairs; environment unavailability waits rather than inventing a pass. |
| B12 | executing → executing; activity becomes waiting/paused **[NEW]** | Orderly direct-work pause/yield/wait. | Preserve lifecycle phase, actual progress, and resume target. |
| B13 | executing/verifying → graduating **[NEW route switch]** | Task now needs decomposition but accepted outcome remains sufficient and authorizes that route; old worker fenced and planning agent active. | If outcome/scope/authority changes, draft → review → acceptance first. Preserve work already performed; do not convert it into proof of done. |
| B14 | verifying → fail-verify **[NEW direct route]** | Failed verification exhausts its budget. | F02, same as plan verification. |
| B15 | accepted → done, requested directly | No bare status jump. A small-task shortcut must execute and verify the task with recorded gates. | Expand to B07 - B09, or documented work/check activities if new statuses are declined. |
| B16 | done → graduated / accepted / verifying / executing / draft / to-review **[NEW reopening policy]** | Earlier outcome is invalidated; preserve historical completion. | Graduated for successor closure reevaluation; accepted for queued direct work; active states only with active owner; draft/to-review if definition or review needs correction. |

For B06, closure verification can remain an activity under graduated. **Alternative [NEW]:** graduated → verifying → done, with verifying → graduated for pending children and verifying → graduating for decomposition repair. Decide whether one backlog verifying state should cover both closure and direct-work verification.

## 5. Cross-cutting transitions and lifecycle-control events

| ID | Transition/event | Required behavior and return route |
| --- | --- | --- |
| X01 | Any ordinary state, including implemented/executed/done → superseded | Authorized disposition, explicit replacement link(s), reason, downstream impact analysis. Checkpoint and fence active workers first. Replacement does not inherit acceptance. |
| X02 | Any ordinary state, including completed states → retired | Authorized no-longer-needed decision and downstream disposition. Stop/fence active work; preserve evidence/history. |
| X03 | Any ordinary state, including completed states → abandoned | Authorized decision to stop pursuing outcome and downstream impact. Do not imply fulfillment or delete evidence. |
| X04 | Any failure state → superseded / retired / abandoned | Same disposition controls; these are proposed recovery exits. Preserve the original failure. |
| X05 | superseded / retired / abandoned → active state, requested | Reject automatic resumption. Explicit human-authorized restoration policy is an open decision; normally create a replacement/new revision in draft with provenance. |
| X06 | Active action → fail-interrupt | Confirmed interruption such as SIGINT. Record checkpoint, cleanup result, and side-effect reconciliation; no automatic success or rollback. |
| X07 | Active action → fail-died | Confirmed unexpected death / crash / power loss / reboot / unclean termination. Runner identity confirmed terminated using durable run records, host/boot identity, process-start identity, and ownership (never infer merely from missing heartbeat or SSH disconnect). Display Run=died, artifact=fail-died. Fence stale mutation ownership before assigning a replacement. Preserve lane/branch/worktree, commits, uncommitted work, E/V progress, execution logs, checkpoint, and record uncertain side effects. `died` never means discard or blindly reexecute. Inspect actual results and resume only unestablished work. Recovery uses FAIL limits and the cumulative ceiling. |
| X08 | Lost terminal connection → same status | Healthy service/agent continues; reconnect to same run. Do not duplicate work or spend a review/verification retry solely due to disconnect. |
| X09 | Missing heartbeat / uncertain worker liveness | Reconcile uncertainty and prevent conflicting mutation; freeze new conflicting mutation authority; do not equate a missing heartbeat, unreachable host, uncertain ownership, or terminal disconnection alone with confirmed death (`died`). |
| X10 | executing / implementing / graduating → fail-execute | Specific failed implementation/execution/decomposition action when safe bounded remediation is unavailable or fails. Applying this label to specs/backlogs/decomposition is recommended. |
| X11 | Any nonreview/nonverification gate → fail-gate | Required gate cannot be satisfied within authorized remediation policy, or is classified as unrecoverable. Waiting for human/dependency is not this state by itself. |
| X12 | Any transition request with stale revision/owner/event | Reject request; keep authoritative state; reconcile/refetch/reassign. A concurrency conflict is not automatically an artifact failure. |
| X13 | Post-verification edit / merge / rebase / changed dependency | Invalidate affected evidence and check relevance. Before completion, send to EA/VA/AA/RA according to G26. After completion, use an explicit reopening policy. |
| X14 | Artifact update published in only one worktree or cache | Reconcile canonical committed metadata and runtime event ledger. Hold completion until required publication succeeds; do not repeat completed side effects merely because publication failed. |
| X15 | Any artifact → needs-human intervention → resolved/cancelled intervention **[NEW orthogonal state]** | Record the blocking OQ/decision, notify through authorized UI channels, checkpoint affected work, and reevaluate gates after human resolution. This does not replace lifecycle status or confer acceptance; see section 5.1. |

### 5.1 Human intervention state and transitions

**Recommendation:** explicitly model `needs-human` as an orthogonal intervention state rather than another lifecycle status. An artifact can be `accepted` and `needs-human` at the same time. This retains its lifecycle position while identifying who must unblock the next action. The UI should display both, the blocked action, and the question/decision. Lifecycle phase is retained while blocked; separate activity records waiting/paused/running. This corrects the earlier proposal to revert execution to accepted solely because the agent stopped.

Proposed representation:

```yaml
status: executing
activity: waiting
readiness: no-go
intervention:
  state: needs-human
  reason: unanswered-question
  question_ids: [OQ-03]
  blocks_actions: [execute]
  requested_from: human-maintainer
  resume_phase: execute
  checkpoint_ref: run-checkpoint-reference
```

Possible reasons include an agent-unanswerable OQ, conflicting requirements, ambiguous scope, unavailable authority/credentials, disputed findings, exhausted retries, or an impactful decision outside agent delegation. An agent should first perform available, authorized investigation; it must not invent an answer or endlessly retry investigation when human judgment is needed. Do not include secrets in the request.

| Intervention transition | Gates and effects |
| --- | --- |
| No pending intervention → needs-human | Agent/system records the exact question or decision, context/evidence, options where useful, requested human, blocked actions, artifact revision, and checkpoint. AA/RA/EA/VA may request it. Creating the request consumes no retry. |
| needs-human → needs-human | Add/update context or record a partial answer; outstanding blockers remain. Do not create duplicate requests on reconnect or spend retries while waiting. A nonblocking question need not suspend unrelated authorized work. |
| needs-human → resolved | Authorized human supplies an actual answer/decision, with actor, timestamp, rationale, and revision applicability. Resolve referenced OQs only as far as answered; retain other outstanding intervention requests. |
| needs-human → cancelled | Authorized decision or supersession makes the request irrelevant; record why. Cancellation is not an answer and does not automatically clear other blockers or grant completion. |
| resolved/cancelled → eligible action or new needs-human | Reevaluate current revision, dependencies, acceptance, scope, ownership, and retry limits. Resume only permitted work. New questions or stale answers require a fresh linked request. |

When affected work blocks, checkpoint and release/fence mutation ownership as appropriate, but retain the lifecycle phase: reviewing, implementing/executing, graduating, or verifying. Record activity=waiting or paused, the intervention, and resume phase. A phase must have genuinely begun; merely queued work does not falsely advance its lifecycle. Authoring remains draft; reviewed remains reviewed while an acceptance-blocking OQ or acceptance decision is pending. Preserve a fail-* status when intervention requests recovery of an already failed artifact. Do not replace recorded failure with ordinary waiting. Human attention may display as issue in the finalized Run vocabulary while underlying activity is waiting; see the UX companion.

An answer that changes requirements/scope routes to AA revision → RA review → acceptance. An answer supplying missing information within accepted scope may permit checkpointed resume after gates pass. Permission to answer an OQ is not automatically permission to accept an artifact, relax a gate, extend retries, or execute an external action. A checkpointed ordinary resume is not a retry; actual corrective reattempts remain subject to section 8, with no counter resets.

For approval alone, show readiness=need-ok (legacy mapping: go-pending-approval) when all other gates pass, optionally with a needs-human intervention whose reason is approval-required. An unresolved substantive question blocking that action gives readiness=no-go. A nonblocking OQ can remain open without forcing needs-human blocking behavior. Other authorized actions may proceed if they do not depend on the unanswered decision.

This is a proposed schema/UI contract; field names and notification channels remain implementation choices. The transition service should publish a human-input-requested event and the subsequent decision event. The pending-intervention registry may support multiple requests, so resolving one question does not silently resolve every human blocker.

## 6. Gate failures: all known remediation cases in this design

This catalog applies to the relevant transition rows above. It separates the responsible repair actor from the agent that detected the failure. Review/verification findings use their respective failure budgets, even when the finding is informally called a gate.

| ID | Failed check / concrete trigger | Send back to whom; required handling |
| --- | --- | --- |
| G01 | Missing/invalid id6, type, status, priority, metadata, duplicate identifiers, malformed artifact | AA/system validates and repairs; unknown status cannot imply acceptance. Duplicate creation retries reconcile identity. |
| G02 | Missing/ambiguous dependency ID, wrong target type/state, contradictory predicates, self-dependency or cycle | AA fixes graph/references; semantic change needs review. Do not silently follow a superseding replacement. |
| G03 | Valid dependency not yet in required state | Wait with no-go; do not dispatch EA to force an unrelated artifact complete or mark fail-gate just for waiting. |
| G04 | Dependency revision or predicate became invalid during work | Checkpoint affected work; AA/RA assess impact; revalidate authority and downstream evidence before continuation. Ordinary milestone progress need not stop a pinned run. |
| G05 | Blocking OQ unanswered, deferred without authority, or stale resolution | AA investigates/clarifies; request needs-human intervention when judgment lies outside agent capability/authority (section 5.1). Record actual answer and authority; no fabricated resolution or retry while merely waiting. |
| G06 | Missing/expired/out-of-scope human acceptance or autonomous delegation | Human/authorized approver supplies valid authority. Stay pending; do not ask EA to manufacture it. |
| G07 | Stale review after content/context/policy changes | Unchanged artifact: RA rereviews. Changed artifact: AA revises then RA reviews. Reaccept the resulting revision where necessary. |
| G08 | RA is AA, shared prohibited context, unsupported review verdict, missing review report | Independent RA reruns review. AA fixes content findings only; a report defect is not automatically a product defect. |
| G09 | Specification architectural misalignment, incompatible live specs, invalid supersession impacts, poor principles/best practices | AA revises spec; independent RA rechecks. Review excludes only explicitly superseded specs, not inconvenient requirements. |
| G10 | Specification bug/design risk, obsolete premise, vague/untestable criteria, missing interface/compatibility/security/privacy requirements | AA repairs spec and rationale; human resolves product choices; RA verifies relevance and criteria. |
| G11 | Plan contradicts specs/architecture/principles, interferes with functionality, introduces risks, no longer relevant | AA revises plan; RA rereviews; new acceptance before execution. |
| G12 | Plan missing at least one E and V, duplicate IDs, uncovered E/criteria, bad E/V references/cycles, untestable V | AA repairs checklist/coverage. Do not let EA fill in unapproved requirements during execution. |
| G13 | Missing create/modify/delete/rename scope, resources, execution order, recovery/rollback/stop instructions, verification methods | AA defines scope/requirements; RA reviews risk; approver accepts. Risk-proportionate recovery requirements must be explicit. |
| G14 | Backlog unclear outcome/type/criteria, inadequate bug reproduction, duplication, irrelevance, wrong route | AA improves item; human resolves intent; RA rechecks. Link duplicate/superseding work instead of silently asserting completion. |
| G15 | Dirty/shared checkout, wrong base/ref, missing IWT, workspace collision, lost lease/fencing token, wrong repository | System/operator reconciles ownership/isolation before EA mutates. Preserve unrelated work; recreate safe workspace if needed. |
| G16 | Agent/context/model/tool/credential/service/test environment unavailable | Infrastructure agent/operator repairs or waits; record diagnostic. Never create evidence of tests that did not run. |
| G17 | Execution precondition, command, tool action, or individual E item fails | EA diagnoses and makes bounded authorized repair. Retry only after reconciling side effects. Persistent failure: fail-execute; requirement change: AA/review/accept. |
| G18 | Partial non-idempotent effect, unknown deployment/external mutation result, crash halfway through work | EA/system inspects actual result, then resumes or compensates under approved authority. Never blindly replay. Outside authority requires human decision. |
| G19 | Execution agent claims completion but E work, files, outcome, or promised deliverable is missing | EA completes required work; VA independently rechecks actual result. A performed checkbox is insufficient. |
| G20 | Missing, truncated, contradictory, stale, forged, or unverifiable evidence; wrong commit/run | EA/evidence agent reconstructs truthful evidence or reruns checks; VA validates provenance. If result cannot be established, keep unmet. Investigate integrity failure before trusting the run. |
| G21 | Missing/skipped V, no independent verifier, weak check method, test only inferred from memory | VA executes required checks; AA revises inadequate V definitions through review/acceptance. EA cannot self-certify independent checks. |
| G22 | Failing functional tests, required regression tests, acceptance criteria, or adversarial implementation inspection | In-scope implementation fault: EA repairs then VA reruns. Bad requirement: AA revises. Existing failure requires recorded disposition and authorized policy; no silent exemption. |
| G23 | Applicable security/privacy, exfiltration, hardening, ransomware resilience, auth/2FA/MFA, vulnerability checks fail | EA fixes within authorized scope; otherwise AA writes/revises plan or creates blocking successor. VA reruns checks. Do not weaken the gate to obtain a pass. |
| G24 | Applicable WCAG 2.1 AA/accessibility, UX, architecture/API/redundancy/fragmentation, performance, compatibility, release checks fail | Same implementation-versus-requirement routing as G23; use measurable acceptance criteria and evidence. Additional configured lens obligations follow the same routing. |
| G25 | EA edited outside allowed files/resources, introduced unauthorized behavior, or deviation explanation is inadequate | EA restores unauthorized changes safely or AA seeks explicit scope revision and review/acceptance. An explanation alone is not retrospective authorization. |
| G26 | Edits during verification; rebase/merge/conflict resolution or later lens changes assessed code | Freeze new result; VA reruns affected checks plus required integration/regression checks. EA repairs conflicts/defects. RA reassesses governing artifact if requirements/context changed materially. |
| G27 | VA identifies issue outside current approved scope | Create draft discovery backlog with evidence. If release/fulfillment-blocking, hold closure and obtain accepted remediation plan; otherwise record authorized nonblocking disposition. |
| G28 | Flaky or nondeterministic check, conflicting reviewer/verifier verdicts, unsupported finding | VA reproduces/triages; RA/independent adjudicator reviews disputed reasoning; human resolves policy. No rerun-until-green or issue invention to satisfy a quota. |
| G29 | Child not completed, child failed, required child retired/abandoned/superseded, missing child output | Pending: wait. Failed: recover that child. Disposed: AA proposes explicit replacement/coverage revision; reviewers/approver authorize. Do not count disposition as fulfillment. |
| G30 | Partial graduation, orphan/duplicate successors, broken links, uncovered criteria, inconsistent set membership | AA/planning agent reconciles same recorded children, repairs mapping and publishes atomically/idempotently; re-review changed scope. |
| G31 | Orchestrator children passed but own E/V or combined integration failed | EA repairs orchestration/integration or responsible child; VA verifies combined result and orchestrator checklist. |
| G32 | Parent closure evidence fails even though children individually completed | VA checks parent outcome; EA repairs actual responsible result or AA fixes decomposition/criteria. No automatic replay of every already-passing child test absent impact. |
| G33 | Artifact/result commit, report, portable metadata, registry, or authoritative event publication fails | System/evidence agent repairs/reconciles publication; rerun only unestablished work/checks. Hold authoritative completion until publication requirements pass. |
| G34 | Retry budget exhausted, missing config, invalid reset, or retry storm | System blocks launch; route to matching failure and explicit recovery authority. Resolve the section 8 inheritance hierarchy and check local plus cumulative limits before every retry; never silently reset counters. |
| G35 | Agent dies, interrupts, loses its terminal, or ownership is uncertain | Apply X06 - X09 distinctly. Startup and periodic reconciliation for crashes, power loss, reboot, and unclean termination. Confirm worker identity/termination using durable run records, host/boot identity, process-start identity, and ownership. Unreachable host, uncertain ownership, or terminal disconnection alone does not justify died/fail-died. Reconcile uncertainty, fence stale ownership, preserve worktree/commits/uncommitted work/checkpoints, inspect actual results, and resume only unestablished work. |
| G36 | Disposition/replacement requested while active descendants/workers still mutate | System fences relevant workers; AA/human reviews downstream effects and explicit replacements before disposition. Preserve valid historical results. |
| G37 | Gate policy or required check was added after acceptance | RA assesses applicability/current artifact; AA adds explicit obligations where needed; human accepts changes. Do not quietly grandfather or silently expand EA scope. |
| G38 | Final check passes but evidence becomes stale before status commit | Transition service rechecks revision/dependency/ownership atomically; VA revalidates affected checks. Never commit completion using a stale pass. |
| G39 | Cleanup or workspace removal fails after successful work | System/operator repairs cleanup. Do not revoke valid product completion solely for housekeeping unless cleanup is an explicit acceptance/security obligation. Preserve uncommitted/unintegrated work. |
| G40 | Request attempts to skip states, use invalid target, forge authority, or apply wrong artifact transition | Transition service rejects; caller corrects request. Do not mutate status merely to accommodate the caller. |

A release-lens finding is not automatically a mandatory check on every artifact. Applicable accepted V items and project gate policy determine what must pass. First-pass release assessment should seek comprehensive issues; later light passes should seek supported significant omissions/regressions, not fabricate fresh findings. Generated remediation plans still follow the plan lifecycle.

## 7. Failure states and explicit recovery transitions

Recovery is an authorized new run/continuation with reconciled checkpoints, not deletion of the failed run. These destinations are recommended, not automatically permitted jumps.

| ID | From | Recovery destinations and gate |
| --- | --- | --- |
| F01 | fail-review | draft when AA must revise; to-review when a fresh authorized review is appropriate. New local budget/cycle requires authorized decision; preserve previous attempts and the artifact-wide cumulative count (section 8). |
| F02 | fail-verify | executing/implementing only when authorized EA actively repairs; verifying only when VA/checks actively resume; accepted or graduated for queued recovery; draft/to-review if definition/review changes. Explicit exhausted-budget override/new cycle required; cumulative exhaustion needs its own explicit extension (section 8). Spec verifying remains an activity unless adopted. |
| F03 | fail-execute | accepted for queued recovery; executing/implementing/graduating when correct agent actually resumes; draft/to-review if artifact/authority needs correction. Reconcile side effects first. |
| F04 | fail-gate | Restore last valid stable status and resume action after gate remediation and authority check; or draft/to-review for governing artifact changes. Preserve the prior phase and separately record whether recovery is queued, waiting, or running. |
| F05 | fail-interrupt | Restore stable checkpoint status; launch correct active phase only after authorized resume and side-effect/ownership reconciliation. Preserve counts. |
| F06 | fail-died | Same as F05 plus confirmed death reconciliation, fencing stale worker authority, workspace inspection, and dependent process/resource checks. |
| F07 | Any failure → same failure | Record unsuccessful recovery decision/attempt; do not cycle through draft to erase failure history or budgets. |
| F08 | Any failure → superseded/retired/abandoned | Authorized disposition with links/impact; X04. |

No failure state has a direct completion bypass. Recovery must establish every remaining relevant completion gate. A gate failure, interrupted run, or death does not itself roll back commits, files, or external effects.

## 8. Retry contract

### 8.1 Configuration and inheritance

**Required by the requested update:** all automatic retry loops use the global fallback MAX_RETRY, the REVIEW/VERIFY/FAIL/GATE family limits, applicable artifact-family overrides, and a separate global configuration MAX_CUMULATIVE_RETRIES. MAX_RETRY defaults to **2** when unset. The cumulative limit must stop repeated work across different categories, gates, phases, and local cycles.

**Cumulative default:** when MAX_CUMULATIVE_RETRIES is missing/null, it defaults to **20 × the resolved global MAX_RETRY**. With MAX_RETRY unset, resolve it to 2 first, giving a cumulative default of **40**. With MAX_RETRY=3, the cumulative default is **60**. An explicitly configured MAX_CUMULATIVE_RETRIES overrides this formula, including zero. REVIEW/VERIFY/FAIL/GATE family and artifact-specific overrides do not change the multiplier base. Keep the canonical global key MAX_RETRY (singular); “MAX_RETRIES” in discussion refers to this key, not a second setting.

**Recommended cumulative scope:** the cumulative limit is enforced separately for each artifact across its lifecycle, including reopening and authorized new local cycles. It is not one shared counter across every unrelated artifact in the installation. A parent does not reset its count by producing children; children have their own artifact counters, and repeated parent orchestration/closure work consumes the parent's budget. An optional aggregate run/release budget can supplement these limits, but is not implied by this setting.

| Setting | Meaning | Fallback when missing/null |
| --- | --- | --- |
| MAX_RETRY | Global default number of retries for any retry family | 2 |
| MAX_REVIEW_RETRY | Default limit for one review loop | MAX_RETRY |
| MAX_VERIFY_RETRY | Default limit for one verification loop, including completion/closure checks | MAX_RETRY |
| MAX_FAIL_RETRY | Default limit for recovery of one execution/process/infrastructure failure episode | MAX_RETRY |
| MAX_GATE_RETRY | Default limit for remediation of any one distinct nonreview/nonverification gate | MAX_RETRY |
| MAX_<TYPE>_REVIEW_RETRY | Review override for SPEC, PLAN, or BACKLOG | MAX_REVIEW_RETRY |
| MAX_<TYPE>_VERIFY_RETRY | Verification override for SPEC, PLAN, or BACKLOG | MAX_VERIFY_RETRY |
| MAX_<TYPE>_FAIL_RETRY | Optional failure-recovery override for SPEC, PLAN, or BACKLOG | MAX_FAIL_RETRY |
| MAX_<TYPE>_GATE_RETRY | Optional gate-remediation override for SPEC, PLAN, or BACKLOG | MAX_GATE_RETRY |
| MAX_CUMULATIVE_RETRIES | Independent ceiling on all retry units for each artifact | 20 × resolved MAX_RETRY |

Examples:

- MAX_SPEC_REVIEW_RETRY → MAX_REVIEW_RETRY → MAX_RETRY → 2.
- MAX_PLAN_VERIFY_RETRY → MAX_VERIFY_RETRY → MAX_RETRY → 2.
- MAX_BACKLOG_FAIL_RETRY → MAX_FAIL_RETRY → MAX_RETRY → 2.
- MAX_SPEC_GATE_RETRY → MAX_GATE_RETRY → MAX_RETRY → 2.
- MAX_CUMULATIVE_RETRIES → 20 × resolved MAX_RETRY → 40 when all settings are unset. This is a computed default, not the same-value inheritance used by family limits.

The first explicitly configured non-null value wins. **Zero is an explicit setting**, allowing no retries; it must not fall through to a parent. Require nonnegative integers, reject booleans/fractions/negative values, and reject invalid configured values instead of silently inheriting around them. Missing/null means inherit. No implicit unlimited value is supported.

**MAX_RETRY is a fallback, not an additional hard ceiling.** For example, MAX_PLAN_VERIFY_RETRY=5 overrides MAX_VERIFY_RETRY=3 or MAX_RETRY=2. The independently enforced cumulative ceiling still applies. A separate hard per-action ceiling would be a different policy, not this inheritance rule.

```yaml
# Example project configuration, not an assertion of current AW syntax.
MAX_RETRY: 3
# Omit MAX_CUMULATIVE_RETRIES to use 20 × 3 = 60.
# A deliberate override such as MAX_CUMULATIVE_RETRIES: 20 is also valid.

# Omitted family/type settings inherit. Examples of deliberate exceptions:
MAX_REVIEW_RETRY: 2
MAX_PLAN_VERIFY_RETRY: 4
MAX_BACKLOG_GATE_RETRY: 0
```

In this example, specification review allows 2 retries, plan verification allows 4, unspecified failure recovery allows 3, and backlog gate remediation allows no automatic retry. Every artifact additionally has at most 60 cumulative retries. With all settings omitted, each local limit is 2 and the cumulative limit is 40. If MAX_RETRY=0 and no cumulative override exists, both default local limits and the computed cumulative limit are zero; enabling an explicit family override then also requires a positive cumulative override.

### 8.2 What a retry means

1. **Initial attempt plus N retries.** A limit of 3 permits up to 4 attempts of that action. Initial attempts do not consume retry counts. A genuine first-time step in the forward lifecycle is not a retry.
2. A retry is an automatic repeated attempt or corrective dispatch caused by a failed, interrupted, invalidated, or insufficient prior attempt. It includes returning to an earlier agent, repeating a check, redoing a completed step, resuming failed execution, or repairing a rejected transition. Calling it a fresh session, new revision, new gate label, or new run does not make it a first attempt.
3. **Count one corrective round once.** A review retry may include AA revision and fresh RA review; a verification retry may include EA repair and fresh VA verification. Those constituent phases share one retry-unit ID and increment their governing family counter and cumulative counter once. Ordinary handoffs and multiple findings within that same round are not separate retries. If a constituent phase itself fails and needs another independently dispatched repair/recovery, that is a new retry unit in the appropriate family.
4. REVIEW and VERIFY apply to completed negative content/check verdicts. A crashed RA/VA, unavailable environment, invalidated snapshot, or interrupted process uses FAIL recovery while preserving the unfinished review/verification action and its content-verdict counters. Every such automatic recovery still consumes the cumulative budget. A later negative verdict uses the relevant REVIEW/VERIFY policy.
5. Review/verification finding repairs belong to their REVIEW/VERIFY round, not fresh GATE or FAIL budgets just because the finding is informally called a gate or failure. A separate infrastructure failure during that round can require a distinct FAIL recovery unit.
6. Ordinary dependency waiting, human approval waiting, queueing, readiness reevaluation, healthy-terminal reconnect, and checkpointed orderly pause/resume consume **no retries**. Repeated corrective work after an actual failure does. Passive bounded liveness checks and backoff are observations, not repair attempts; they need separate timeout/poll limits so waiting cannot busy-loop indefinitely.
7. Counts are reserved atomically before dispatch. A started retry counts whether it passes, fails, crashes, or is interrupted. Release a reservation only when the system establishes that no worker started and no side effect occurred; record that cancellation. A refused request that launches no correction consumes no retry, but remains audited and may be rate-limited.
8. Successful retries remain in the cumulative count. Passing a gate does not refund its earlier repairs.

### 8.3 Counter scope and enforcement

Keep durable counters and history keyed by artifact identity and stable loop identity, independent of sessions, branches, IWT paths, revisions, or cosmetic finding labels:

| Counter | Scope | Reset policy |
| --- | --- | --- |
| REVIEW | One artifact's review loop in an explicitly identified authorization cycle | No automatic reset after revision, re-review, or verification-driven authoring changes |
| VERIFY | One artifact's verification/closure loop in that cycle | No fresh budget per V item, criterion, child check, or result commit |
| FAIL | One stable failure episode, identified by action/phase and root cause | Repeated recurrence of the same unresolved failure remains the same episode; each distinct episode may have a local counter, all sharing cumulative |
| GATE | One stable gate predicate for a named action in that cycle | Each distinct gate may have a local counter; renaming or splitting the same gate does not reset it |
| CUMULATIVE | All retry units for one artifact across categories, episodes, gates, phases, and local cycles | No automatic reset, including reopening |

Before any corrective dispatch:

```text
local_limit = first_configured(
    MAX_<TYPE>_<FAMILY>_RETRY,
    MAX_<FAMILY>_RETRY,
    MAX_RETRY,
    2
)
global_retry = first_configured(MAX_RETRY, 2)
cumulative_limit = first_configured(MAX_CUMULATIVE_RETRIES, 20 * global_retry)

allow only if:
    applicable_local_retries_used < local_limit
    AND artifact_cumulative_retries_used < cumulative_limit
    AND all required authority, ownership, revision, and safety gates pass

atomically reserve one local retry and one cumulative retry
attach the same retry_unit_id to its repair and recheck phases
```

For an explicit cumulative override of 20, exactly 20 cumulative retries may start; the request for retry 21 is refused. A smaller local limit may stop a loop much earlier. Example: 2 review retries + 4 verification retries + 3 failure recoveries + 11 repairs across distinct gates = 20 cumulative retries. Even if the next gate has local budget remaining, no further automatic retry may start.

Pin the resolved limit, configuration provenance, counters, cycle, and retry-unit ID in each decision. Config edits never reset counts. Increasing a limit requires authorized configuration change; decreasing it takes effect before subsequent dispatches. Already-running work is checkpointed safely rather than blindly killed solely because a lowered limit is now exceeded.

### 8.4 Applying the limits to every iterative route

This table governs all return paths and repair cases in sections 1 - 7, including self-transitions. Normal forward transitions and successful first-time activities remain unaffected.

| Catalog steps/cases | Iteration | Governing family |
| --- | --- | --- |
| R06; negative review feedback from R03 - R05, R10, R13, R15; G08 - G14 when found by RA | AA correction plus fresh adversarial review | REVIEW |
| R08 - R09, R12; S06, P13, B16; G07/G26/G37 when a prior assessment must be repeated without a negative verdict | Invalidated assessment/result recovery | FAIL for the recovery dispatch; later negative review/verification uses REVIEW/VERIFY |
| R01 - R03 and authoring self-loops R02; S05, B01 - B05, P11; G01 - G02/G05/G12 - G14/G30 outside review | Iterative preflight/content/derivation correction | GATE for the failed predicate; actual action/process failure uses FAIL |
| S04; P05 - P09/P12; B06/B09 - B11/B14; G19 - G28/G31 - G32/G38 when verification verdict fails | Implementation/evidence repair and independent recheck | VERIFY, including spec completion and backlog closure |
| S02; P02/P04; B02/B08/B13; G17 - G18 | Recovery from failed implementation/execution/decomposition action | FAIL; unmet handoff predicate alone uses GATE |
| G15 - G16/G20 - G21/G33 - G35; X06 - X07/X09/X12 - X14; F03/F05/F06 | Workspace, process, infrastructure, snapshot, or publication recovery | FAIL when technical recovery is needed; actual negative verdict uses its content family |
| G03 - G06/G15/G29/G36 - G40; X11; F04, when authorized agent correction is required | One nonreview/nonverification gate's remediation | GATE; ordinary waiting or rejected request without repair has no retry |
| F01 - F02; revising/re-reviewing after verification or changing work route | Recovery of an exhausted review/verification loop | Original REVIEW/VERIFY limits persist; no category-switch reset |
| F07; repeated failed recovery or recurring unresolved cause | Further actual repair/recovery dispatch | The original applicable family; all count cumulatively |
| G39 housekeeping after product completion | Repeated cleanup correction | FAIL for technical failure or GATE for an explicit cleanup obligation; do not invalidate unrelated valid completion |
| Any other automatic iterative repair/adjudication/reassessment, including configured release-lens remediation | Select by root cause under the rules above | REVIEW, VERIFY, FAIL, or GATE, plus CUMULATIVE; there is no unbudgeted corrective family |

Family selection follows **why the retry is needed**, not merely the row number or agent receiving it. Preserve one primary retry-unit classification and record related gates/findings; never charge the same unit twice or relabel it to obtain fresh budget. If unsure, stop for classification instead of launching unbounded remediation.

A required second or third release-lens pass is a planned workflow step, not by itself a retry. Fixing a failed lens-derived plan, repeating an invalidated assessment, or rerunning failed release checks is corrective iteration and uses the appropriate artifact's budget. This prevents treating the expected 62 assessments as 62 retries while still bounding repair loops.

### 8.5 Exhaustion and recovery

- Local REVIEW exhaustion → fail-review; local VERIFY exhaustion → fail-verify.
- Local GATE exhaustion → fail-gate. Local FAIL exhaustion retains/records the appropriate fail-execute, fail-interrupt, or fail-died cause; a technical inability to satisfy a noncontent gate may be fail-gate. Do not introduce an undifferentiated fail state.
- Cumulative exhaustion stops all further automatic corrective dispatches for that artifact. Use fail-review/fail-verify when the blocked corrective action concerns those verdicts; otherwise use the applicable failure above. Record `retry_exhaustion: cumulative`, the original root cause, blocked action, all local counters, cumulative count/limit, and remaining local budgets. No new status is required.
- If a planned next phase is a genuine first attempt and no corrective retry is required, reaching the cumulative ceiling alone does not prevent that phase or a completion that already has valid passing evidence. It prohibits further corrective retries. No further retry may be launched to obtain missing evidence or fix a failed check.
- Preserve workspace, evidence, checkpoints, prior verdicts, and incomplete side effects. Budget exhaustion is neither rollback nor permission to mark work complete.
- Human or explicitly scoped recovery authority may grant a bounded local extension/new cycle. The artifact cumulative count survives that decision. If cumulative budget is exhausted, authority must explicitly extend its ceiling as well; approving a local cycle is insufficient. Record rationale, old/new limits, scope, and actor. Autonomous acceptance permission alone does not imply retry-limit override authority.
- Replacing, splitting, or superseding an artifact requires legitimate lifecycle authority and provenance; never create a cosmetic new ID to evade exhausted limits. Aggregate parent/run cost controls may additionally be configured.

## 9. Suggested transition service contract

Every request supplies artifact ID/type, expected current status/revision, action, actor/run, fencing token, governing acceptance, target snapshot, evidence, evaluated dependencies, applicable gate-policy version, pending intervention IDs and applicable human resolutions, retry family and stable loop/episode/gate ID, retry cycle/attempt/unit ID, resolved local limit and inheritance source, and cumulative count/limit. The service returns either a committed transition or a structured rejection with gate ID, repair owner, permitted next action, blocking reason, remaining local/cumulative budget, and any required needs-human intervention.

Use an atomic compare-and-set for revision/status/ownership. Record immutable history, including negative verdicts, refused transitions, and invalidated evidence. Durable runtime state supports reconnect; committed portable metadata and links support another clone. Publish/reconcile both without treating SQLite caches or arbitrary branch-local status edits as authority. Schedule agents only after authority is established.

A final completion request must bind to the artifact and result snapshots that actually passed verification. Completion and required metadata publication must be reconciled idempotently across failures; don't claim impossible distributed atomicity between Git and a local database.

## 10. Decisions to discuss

| Decision | Recommendation | Why it matters |
| --- | --- | --- |
| D01 Active states vs queued/waiting phase | Retain reached lifecycle phase plus separate activity/owner/wait reason and orthogonal needs-human intervention. Do not revert to accepted merely because execution waits. Consider explicit spec verifying for clarity. | Prevents implementing/executing from falsely claiming an agent is working. |
| D02 Backlog direct execution | Adopt executing and verifying; use verifying for both direct-work checking and graduated closure, with recorded route. | Avoids hiding work and verification inside accepted → done. |
| D03 Default dependency predicate | Prefer successful completion by default; explicit terminal-any for disposal-aware dependencies. This changes the earlier literal terminal rule. | Abandoned should not imply required deliverable exists. |
| D04 State selector semantics | Explicit exact vs milestone selector; recommend revision-bound milestones for accepted prerequisites. | Normal forward progress should not unexpectedly unsatisfy approval requirements. |
| D05 Spec ancestry and closure | Distinguish required fulfillment from discovery/provenance; require every direct fulfillment child and original criteria. | A newly discovered optional backlog should not accidentally keep a spec open forever. |
| D06 Reopening completed artifacts | Preserve historical completed revisions; record current validity/closure invalidation and explicit recovery event. Reopen current revision only under defined authority; changed intent generally produces new revision/artifact. | Do not rewrite history or leave invalid current claims unchallenged. |
| D07 Automatic remediation authority | Permit bounded in-scope EA fixes and truthful evidence reruns; scope/criteria/gate relaxation require review and acceptance. | Prevents repair loops from becoming uncontrolled scope growth. |
| D08 Retry exhaustion recovery | Inherited TYPE → family → MAX_RETRY → 2 limits; cumulative default 20 × resolved MAX_RETRY per artifact; initial+N interpretation; durable category counters; explicit authorized extensions. | Prevents loops and cosmetic counter resets while allowing accountable recovery. |
| D09 Plan-set closure | Versioned membership, explicit required children and orchestrator integration predicates; define independent set states only if needed. | A dependency on an undefined set terminal state cannot be safely satisfied. |
| D10 Disputed/flaky/preexisting findings | Evidence-driven adjudication; documented policy for accepted existing failures; no silent waiver and no issue quota. | Prevents rerun-until-green and endless adversarial issue invention. |
| D11 In-flight dependency invalidation | Pin qualifying revision for normal milestone progress; pause/reassess material revocation or semantic change. | Avoids needless interruption while preserving meaningful dependency safety. |
| D12 Graduation and publication failures | Idempotent child creation and evidence/event publication; checkpoint partial progress. | Prevents duplicate artifacts and repeat side effects after reconnect. |

Suggested discussion order: D01 - D02 (state vocabulary), D03 - D05 (dependency/closure semantics), D07 - D08 (repair authority/budgets), D06 (reopening), then D09 - D12. Any unlisted transition should be rejected until explicitly added to the contract, rather than guessed by an agent.