# AceLM lifecycle rules

Status: design specification for discussion. User requirements are authoritative; proposed additions and unresolved decisions are labeled explicitly. The five files in panels/ are exact extractions from the previous SVG, retaining its text, drawing geometry, fonts, colors, and arrows. They are a baseline, not an assertion that the new rules require no state-machine changes. Companion diagrams in rules/ describe the expanded behavior.

# 1. Shared vocabulary and invariants

Required: accepted is the common approval state for specifications, plans, and backlog items. Review success does not itself confer acceptance. Review and verification are separate activities. A normal completion state is different from superseded, retired, or abandoned.

Proposed: use the same agent-independence rule for backlog review and verification as for specifications and plans. A fresh prompt inside AA's or EA's existing context does not count as an independent session. Reviewers must receive the artifact, project rules, relevant existing artifacts, and evidence, rather than only the author's account of the work. A different model is optional; a distinct agent and context are mandatory.

# 2. Specification

Baseline sequence: draft → to-review → reviewing → reviewed → accepted → implementing → implemented.

# 2.1 Review

Required: RA, not AA, reviews in a separate session/context. RA checks:

1. Conformance to the project's architectural guidelines.
2. Alignment with all project specifications, except those explicitly superseded by this specification.
3. Alignment with project best practices and guiding principles.
4. Risk of bugs, design flaws, inconsistencies, or other issues.
5. Current validity and relevance, including project changes since authorship.

Proposed additional checks: requirements are clear, scoped, testable, and internally consistent; acceptance criteria and non-goals are explicit; interfaces, dependencies, compatibility constraints, and applicable security/privacy concerns are addressed; any supersession names the affected artifacts and explains migration or conflict handling. RA records findings, severity, evidence, and a verdict tied to the exact revision. Blocking findings prevent reviewed.

# 2.2 Acceptance

Required: only a human, or an agent explicitly authorized by a human to autonomously accept specifications, can move the specification to accepted.

Proposed: authorization is artifact-type-specific and scoped to project, permitted work, and validity period. It records the delegating human and any limits. Permission to execute does not imply permission to accept. Revocation blocks future agent acceptance. Material content changes invalidate acceptance and require new review and acceptance.

# 2.3 Implementation and completion

Required: Entering implementing requires an authorized actual start of specification fulfillment. An unfinished child alone does not justify entry. Once begun, the phase is retained during ordinary waits, pauses, and human intervention; assignment activity and liveness report whether work is currently active.

Required: implemented requires every artifact having this specification as a direct ancestor to be in its appropriate completion state: specification implemented, plan executed, or backlog item done.

Proposed additional completion gates: the specification's acceptance criteria have supporting evidence; required verification has passed; no blocking findings remain; evidence identifies relevant repository revisions and completed successors. An empty child list must not automatically mark a new specification implemented. Direct implementation with no successors needs explicit evidence that the specification itself was fulfilled.

Proposed clarification: explicit derivation/fulfillment links define “direct ancestor.” Historical discovery links are not fulfillment links by default. A plan set uses the closure rule in section 5 because its completion state has not yet been defined.

Waiting: when an agent stops normally and descendants remain incomplete, use the proposed waiting behavior in section 7. A genuine interrupted or lost process uses the corresponding failure state instead.

# 3. Plan

Baseline sequence: draft → to-review → reviewing → reviewed → accepted → executing → verifying → executed.

Plans may originate ex novo, directly from a specification, or through backlog graduation. Execution may discover a bug, missing feature, chore, improvement, or other needed work and create a backlog item.

# 3.1 Review

Required: RA, not AA, reviews in a separate session/context and checks:

1. Project architecture guidelines.
2. Alignment with all project specifications, best practices, and guiding principles.
3. Preservation of existing functionality.
4. Risk of bugs, design flaws, and other issues.
5. Current validity and relevance.
6. Conformance to all project plan requirements, including at least one E-* execution item and one V-* verification item.
7. An explicit list of files to create or modify.

Proposed additions: include files to delete or rename, allowed path patterns where exact filenames cannot be known, dependencies, execution order, acceptance criteria, tests, evidence requirements, relevant security checks, rollback/recovery, and explicit stop conditions. Define orchestration dependencies and child-plan ownership where applicable. A risky action discovered during execution must not be retroactively approved merely by explaining it afterward.

# 3.2 Acceptance and execution

Required: acceptance requires a human or a human's explicit autonomous-acceptance authorization for plans. Entering executing requires an authorized actual start by EA. Once begun, the phase is retained during ordinary waits, pauses, and human intervention.

Proposed: EA works against the accepted revision and baseline commit in an isolated worktree backed by an artifact/run branch. Separate execution and verification worktrees are required under acelm-isolation-policy.md; a branch alone does not provide workspace isolation. A meaningful change to scope or architecture returns the plan to review and acceptance. EA records discovered work as a backlog item, identifying the originating plan and whether it blocks this plan's completion. New work does not automatically expand the approved scope.

# 3.3 Verification

Required: verification combines programmatic checks and adversarial agent verification. The verifier checks:

1. EA performed the promised work.
2. EA provided evidence.
3. EA changed only the approved scope, or provided an adequate explanation for necessary deviations.
4. All regression tests pass.
5. EA followed project best practices and guiding principles.
6. No new issues were introduced, as assessed by the required checks and adversarial review.

Proposed: VA is independent of EA. Programmatic evidence includes commands, exit codes, logs, test results, changed-file lists, baseline and result commits, and required release/security checks. Skipped, unavailable, or unevaluated checks are not passes. Verification of “no new issues” is a supported judgment, not a mathematical guarantee of absence.

Proposed deviation rule: VA evaluates explanations, but explanations do not grant authority. Material or unauthorized deviations require appropriate human approval or renewed review/acceptance. Verification evidence must remain current for the final code revision; later code edits invalidate affected checks.

# 3.4 Execution and verification item contract

Required: every plan includes at least one E-* and one V-* item. E-* defines concrete execution work; V-* defines separate evidence-based validation. Completing E-* does not automatically complete V-*. See acelm-plan-items.md for IDs, fields, coverage, actor independence, and completion rules.

Proposed: all required E items must be performed, all required V items must pass against the assessed final revision, and orchestration plans must satisfy their own E/V obligations in addition to their children's completion.

# 3.5 Executed

Required: an orchestrating plan in a plan set can be executed only when all child plans are fully executed.

Proposed: every plan also requires successful verification and resolved blockers. Completing commands is insufficient. The orchestrator verifies integration across child results in addition to each child's own verification. A child that is retired, abandoned, or superseded does not count as executed. Any removal or replacement of required children is an explicit reviewed scope change.

# 4. Backlog item

Baseline sequence: draft → to-review → reviewing → reviewed → accepted → graduating → graduated → done.

Alternative baseline route: accepted → done for work completed directly without creating a specification, plan, or plan set. This historical arrow is shorthand for accepted scope, actual execution, recorded evidence, and independent verification against acceptance criteria. There is no bare accepted-to-done jump. Explicit backlog execution/verification states remain a proposal.

# 4.1 Definition and review

Proposed: each item states its type (bug, feature, chore, improvement, research, or another configured type), problem or intended outcome, scope, acceptance criteria, provenance, dependencies, and applicable verification requirements. Bugs include reproduction steps or evidence where available. Lack of reproducibility is recorded rather than fabricated.

RA is distinct from AA and uses a separate context. RA checks architecture, relevant specifications, project principles, relevance, duplication, feasibility, risk, and clear acceptance criteria. For direct work, RA also checks that it is sufficiently bounded to execute safely without a complete plan. “Rename all instances of X to Y” may be direct work if the scope and tests are clear; externally visible APIs or data migrations could require a plan.

# 4.2 Acceptance

Proposed: use the same approval rule as other artifacts, with a distinct human-granted permission for autonomously accepting backlog items. Do not inherit this permission from plan/specification acceptance. The accepted revision includes the intended direct-work or graduation route.

# 4.3 Graduation route

Required: a backlog item may graduate to one or more specifications, plans, or plan sets. It need not create all three types.

Proposed: graduating is active work that creates successors, establishes required derivation links, and records the mapping from acceptance criteria to successors. graduated means that successor creation and linking succeeded; it does not mean successor work is complete. Successors start in draft, unless an explicit independently justified transition is recorded.

Proposed done rule: after graduation, all required successors must reach their appropriate completion states, and evidence must show that the original backlog outcome is satisfied. Optional, informational, or discovery links do not block completion. Superseded/retired/abandoned successors require explicit resolution or replacement; their dispositions do not automatically fulfill the item.

# 4.4 Direct-work route

Proposed state-machine extension: accepted → executing → verifying → done. This is the recommended way to make active work and verification visible for direct backlog work. The five extracted baseline SVGs intentionally retain the earlier accepted → done arrow; the companion verification diagram and this document explain the new proposal.

Entering the proposed executing phase requires an authorized actual start by EA; ordinary waits retain the reached phase. Verification combines applicable automated checks with VA, distinct from EA, in a separate context. VA checks outcome, evidence, file scope, justified deviations, regressions, project principles, and newly introduced issues. Apply relevant release/security checks; a non-code chore may have different checks, with the applicability decision recorded. done requires a successful verification verdict and satisfied acceptance criteria.

Proposed: add a verification activity before post-graduation done as well. Its object is the backlog outcome and required successor closure, rather than replaying every child check.

# 5. Plan sets and relationship semantics

Required: plan sets can be created from specifications or backlog items; an orchestrating plan cannot finish before all its child plans are executed.

Proposed: a plan set is a versioned collection of child plans, their dependency graph, and an orchestrating plan. Keep membership, fulfillment links, and discovery links explicit. Reject cycles in fulfillment dependencies; specification-to-backlog-to-specification derivation is permitted historically, but it must not create a circular completion requirement.

Unresolved: no plan-set lifecycle was supplied. Do not invent a persisted executed state for a set. Until defined, a parent's gate on a required plan set resolves through its accepted membership, fully executed child plans, and executed orchestrating plan, plus any required integration checks.

Proposed: a bug discovered while executing a plan records discovered-by provenance. It blocks that plan only when explicitly linked as a blocking requirement. Otherwise, an unrelated discovered feature would prevent the original plan from ever completing. A nonblocking new issue still requires documented disposition consistent with the user's requirement to verify no new issues were introduced; newly introduced regressions remain blocking unless explicitly resolved through authorized scope changes.

# 6. Review, verification, failure, and gate retry budgets

Required: review, verification, failure recovery, and gate remediation may loop up to their configured retry limits, then enter fail-review, fail-verify, fail-execute, or fail-gate.

# 6.1 Retry inheritance hierarchy

All retry limits follow the four-family inheritance structure:

MAX_<TYPE>_<FAMILY>_RETRY → MAX_<FAMILY>_RETRY → MAX_RETRY → 2

• Artifact Types: SPEC, PLAN, BACKLOG (and RELEASE where documented).
• Retry Families: REVIEW, VERIFY, FAIL, GATE.
• Global Fallback: MAX_RETRY defaults to 2 when unset.

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

The first explicit non-null value wins. 0 is an explicit setting that forbids retries (it does not fall through). MAX_RETRY is a fallback, not an additional hard ceiling on explicit overrides.

# 6.2 Cumulative ceiling and planned passes

Cumulative Ceiling: MAX_CUMULATIVE_RETRIES defaults to 20 x resolved global MAX_RETRY.

• When MAX_RETRY is unset (default 2), cumulative ceiling is 40.
• When MAX_RETRY: 3, cumulative ceiling is 60.
• When MAX_RETRY: 0 and no cumulative override is set, cumulative ceiling is 0.

The cumulative limit is enforced per artifact across all categories, gates, failure episodes, revisions, and reconnects.

Planned lens passes are not retries: The 62 planned evaluations across 31 lenses over 2 passes (and up to 93 over 3 passes) during sequential release qualification are planned workflow steps, not retries. Corrective reassessments, repair iterations, and failed checks consume artifact retry budgets, but planned evaluations do not.

Single-round accounting: One initial attempt plus N retries. A corrective round counts once with one retry-unit ID: AA revision plus RA recheck (or EA repair plus VA recheck) shares one retry-unit charge. REVIEW/VERIFY handle content verdict failures; FAIL handles process/interruption recovery; GATE handles distinct non-content gate remediation.

# 7. Active work, waiting, interruption, and recovery

Required: an authorized actual start is required to enter implementing or executing. Continued phase eligibility does not require continuous worker activity. An untouched queued artifact remains accepted.

Agreed Phase Retention Invariant: When work genuinely began and is now orderly paused, waiting for dependencies, or awaiting human intervention, the artifact retains its reached lifecycle phase (implementing, executing, graduating, verifying). Worker activity is tracked separately in activity metadata (waiting, paused, queued), and the compact terminal Run column displays issue when human attention is required. Work never reverts to accepted merely because an agent stopped or is waiting.

Unexpected termination and recovery: died never means discard or blindly reexecute. Durable recovery fences stale worker authority, inspects actual results, and resumes only unestablished work.

# 8. Failures and exceptional dispositions

Required: any artifact may enter an applicable failure state. Applicability matters: an artifact must not be marked fail-execute without an execution failure. Do not use a generic fail status in place of the specified reason unless the schema intentionally defines one.

Proposed gate distinction: expected waiting, such as a pending human acceptance or unfinished child, is not a failure. A rejected or unresolvable gate becomes fail-gate after the permitted remediation policy ends. A successful check with an unsatisfied completion dependency does not become fail-verify merely because a child has not finished.

Every failure records artifact/revision, failed action, cause, stage, actor/run, attempts, evidence, checkpoint, repository/worktree state, and permitted recovery target. Failure does not imply rollback of files already changed. On recovery, reconcile partial changes and rerun invalidated checks before resuming. Resumption requires explicit authority and must not set a completion state directly.

Required: artifacts may be kicked back, superseded, retired, or abandoned. The last three remain available from every ordinary lifecycle state.

Proposed: also allow these dispositions from failure states. Kickback returns to draft and invalidates affected reviews/acceptance; record who requested it and why. Supersession identifies replacement artifacts. Retired and abandoned retain provenance and evidence. To disposition an actively worked artifact, revoke transition/write authority and stop or isolate its worker before recording the disposition; prevent late worker results from resurrecting it. No implicit resurrection or reopening is defined.

# 9. Evidence and durable metadata

Proposed minimum record: artifact ID/type/revision, lifecycle status, activity metadata, relationships with semantics, accepted scope, review/verification attempts and reports, human acceptance or delegation, retry configuration snapshots, agent ownership/checkpoints, checks and evidence, transitions with actors/reasons/timestamps, and completion/disposition records.

This fits AceLM's two-storage requirement: portable authoritative artifact metadata and event records in the repository, indexed in SQLite for fast access. A new clone must retain artifact history, counters, delegation records, and completion evidence references. It must not revive host-specific process ownership from another machine. Live leases belong to the run service and must be reconciled with repository metadata. Do not commit secrets, credentials, or raw sensitive logs; preserve appropriate evidence references or redacted records.

Proposed concurrency rule: transitions compare the expected artifact revision and status, then atomically update them. A stale review, acceptance, verification result, or worker may not advance a newer revision. Review and verification reports should name both the artifact revision and the repository baseline/result they assessed.

# 10. Missing details and proposed decisions, enumerated

1. Review pass threshold: define blocking severity, allowed nonblocking findings, and who may grant exceptions. Proposed default: no unresolved blocking findings.
2. Acceptance delegation: define scope, expiration, revocation, and authorization for each artifact type separately.
3. Content changes: decide which edits invalidate review/acceptance. Proposed default: any semantic change; cosmetic exceptions must be explicit and recorded.
4. Retry policy: initial-plus-N, inheritance, and cumulative accounting are defined in section 6; only authority for explicit budget extensions remains to be specified.
5. Backlog direct work: adopt executing and verifying, or keep the baseline arrow and represent those phases as activities. This document recommends visible states.
6. Specification verification: decide whether it is an explicit verifying state or a completion-gate activity. Proposed here: a completion-gate activity under the stable state when no implementation agent is active.
7. Graduated backlog completion: adopt required-successor closure plus evidence of the original outcome, rather than completing on successor creation.
8. Plan-set semantics: define membership, orchestration, closure, and whether sets need their own persisted lifecycle.
9. Relationship types: distinguish origin, fulfillment, blocking dependency, supersession, and membership. Reject circular completion dependencies.
10. Empty successor lists: require direct fulfillment evidence, rather than automatic completion by an empty all-children check.
11. Waiting versus failure: define expected waits, retryable gate remediation, gate timeouts, and when a gate becomes irrecoverable.
12. Lease and death detection: choose heartbeat interval, grace period, liveness reconciliation, fencing, and recovery ownership. A terminal disconnect must not kill a healthy agent session.
13. Verification scope: define applicable regression/security/release checks and handling of unavailable or skipped checks. Define how environmental failures differ from work defects.
14. Scope deviations: identify which require prior human approval or new review, and which VA may accept with evidence under existing authorization.
15. Completion becoming stale: decide what happens if code, child fulfillment, or a required dependency changes after completion. Proposed: explicitly invalidate closure and require re-verification; do not silently leave a false completion assertion.
16. Failure recovery: define who can resume, authorize new budgets, reconcile partial changes, and reopen a failed artifact.
17. Human emergency actions: define authorized overrides with reasons and audit records. Overrides must not falsely label unchecked work as verified.
18. Artifact identity and clone behavior: immutable IDs, revision hashes, event ordering, merge-conflict handling, and portable evidence must work across clones; active process leases must not be copied as live runs.
19. Security of metadata and execution: redact evidence, protect credentials, constrain agents to approved work, and record authorization for destructive or external actions.
20. Post-review currency: bind reviews to relevant project/specification baselines and recheck relevant changes before acceptance/execution. An old review cannot guarantee current alignment.

# 11. Common metadata and isolation

Required: every artifact may optionally carry priority, dependency, lifecycle status, readiness, and open questions. Priority uses the exact null-or-0 to 7 scale; readiness uses missing/null, go, no-go, or need-ok (legacy mapping: go-pending-approval); questions use stable OQ-01, OQ-02, etc. See acelm-artifact-metadata.md for values, dependency state predicates, serialization examples, and validation proposals.

The user's bare-ID dependency rule checks terminal status. Terminal dispositions can satisfy that generic scheduling predicate, but they never substitute for the explicit child-completion requirements in specification, plan, or backlog closure. These are different gates. State-qualified dependencies can require successful completion explicitly.

All lifecycle work uses isolated branches/worktrees. The recommended default is a worktree backed by a branch; see acelm-isolation-policy.md for separate execution/reviewer/verifier workspaces and portable versus runtime metadata.

# 12. Release lifecycle and assessment coverage

See acelm-release-lifecycle.md for the proposed draft → to-review → reviewing → reviewed → accepted → releasing → verifying → released flow, candidate-specific authorization, release evidence, post-release checks, and bounded failures/recovery. Specification/plan acceptance does not confer permission to publish or deploy.

The automated release sequence and its two mandatory/three maximum standard passes are specified in acelm-sequential-release-cycle.md: each lens completes its remediation lifecycle before the next, and later passes focus on significant omissions/regressions rather than searching for new work.

All 31 assessment lenses are included in acelm-assessment-catalog.md. A release profile selects required/applicable coverage without dropping the rest of the product catalog. Generic terminal-state dependencies are distinct from explicit release-blocking findings, which require verified resolution or authorized disposition under release policy.

acelm-positioning.md contains the product positioning, enterprise overview, and architectural principles.

# 13. Companion diagrams

The rules/ directory contains editable Mermaid source and rendered SVGs for review retries, verification retries, completion gates, runtime failures, dependency/readiness gates, E/V evidence, workspace isolation, and release review/execution. These are rule diagrams, not replacements for the five unchanged baseline panels. “Pass” always means the configured blocking criteria and evidence requirements were satisfied; it does not promise the absence of every conceivable issue.

# Review Retries

flowchart TB
    D["draft: AA writes or revises"] --> T["to-review"]
    T --> R["reviewing: independent RA, separate context"]
    R --> V{"Review passes for current revision?"}
    V -->|"yes"| OK["reviewed"]
    V -->|"no"| B{"Review retries remain?"}
    B -->|"yes: record and consume retry"| D
    B -->|"no"| F["fail-review"]
    OK --> A{"Human accepts, or scoped human delegation?"}
    A -->|"yes"| AC["accepted"]
    A -->|"pending"| W["Remain reviewed; record waiting reason"]
    W --> A
    A -->|"revision requested"| D
    N["Proposed budget: 1 initial attempt + N retries. Counters persist across restarts."]
    B ~~~ N
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    classDef fail fill:#fff2ee,stroke:#a35743,color:#572d23;
    class OK,AC good;
    class F fail;

# Verification Retries

flowchart TB
    W["Work or successor fulfillment ready for checks"] --> C["Programmatic checks + independent VA; final revision evidence"]
    C --> P{"Verification passes?"}
    P -->|"yes"| G{"Completion gates satisfied?"}
    G -->|"yes"| DONE["implemented / executed / done, by artifact type"]
    G -->|"expected dependency or human wait"| WAIT["Retain reached phase; waiting + wait/issue; no retry charge"]
    WAIT -->|"gates resolve; refresh affected evidence"| C
    G -->|"unrecoverable or exhausted gate remediation"| FG["fail-gate"]
    P -->|"negative content verdict"| B{"VERIFY retries and cumulative budget remain?"}
    B -->|"no"| FV["fail-verify"]
    B -->|"yes; one corrective round"| S{"Classify remediation cause"}
    S -->|"in-scope implementation"| EA["EA repairs accepted work; independent VA rechecks"]
    S -->|"checks or evidence only"| EV["Evidence owner repairs truthful evidence/checks; VA rechecks; no EA replay"]
    S -->|"changed requirements"| AA["AA revises draft; independent RA review and renewed acceptance"]
    AA --> EA
    EA --> C
    EV --> C
    C -->|"infrastructure invalidated snapshot"| INF["FAIL recovery budget; fence/recover; preserve VERIFY counters"]
    INF -->|"authorized recovery; fresh evidence"| C
    NOTE["Spec verifying and backlog executing/verifying remain proposals. All counters and history persist."]
    DONE ~~~ NOTE

# Completion Gates

flowchart TB
    subgraph SPEC["Specification completion"]
      direction LR
      S["Accepted specification + fulfillment evidence"] --> SC["Every direct fulfillment child complete: spec implemented, plan executed, backlog done"]
      SC --> SG["Required checks pass; no blockers; empty child list needs direct-work evidence"]
      SG --> SD["implemented"]
    end
    subgraph PLAN["Plan completion"]
      direction LR
      P["Work complete + programmatic and adversarial verification passed"] --> PC["If orchestrating a plan set: all child plans executed"]
      PC --> PG["All required E-* performed, V-* pass; integration and required gates satisfied"]
      PG --> PD["executed"]
    end
    subgraph BACKLOG["Backlog completion: proposed rules"]
      direction LR
      B["accepted"] --> DIRECT["Direct route: EA executes, VA verifies outcome"]
      B --> GRAD["graduating → graduated: required successors created and linked"]
      GRAD --> BC["Required successors complete + backlog outcome verified"]
      DIRECT --> BD["done"]
      BC --> BD
    end
    SPEC ~~~ PLAN
    PLAN ~~~ BACKLOG
    NOTE["Discovery links are provenance, not automatic completion dependencies. Plan-set closure remains a proposal."]
    BACKLOG ~~~ NOTE
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    class SD,PD,BD good;

# Runtime And Failures

flowchart TB
    CLAIM["Accepted/reviewable artifact + authorized worker claim"] --> RUN["Active work: live owner, run ID, lease, checkpoint"]
    RUN --> EVENT{"What happened?"}
    EVENT -->|"terminal disconnect; worker healthy"| KEEP["Keep active state; reconnect to same run"]
    KEEP --> RUN
    EVENT -->|"orderly pause / wait"| WAIT["Retain lifecycle phase + activity: waiting/paused; release mutation owner"]
    WAIT -->|"authorized resume and fresh claim"| CLAIM
    EVENT -->|"failure or abnormal stop"| STOP{"Failure cause?"}
    STOP -->|"SIGINT or interruption"| FI["fail-interrupt"]
    STOP -->|"confirmed unclean death"| FD["fail-died (Run: died)"]
    STOP -->|"implementation or execution failure"| FE["fail-execute"]
    STOP -->|"unresolvable non-review/non-verify gate"| FG["fail-gate"]
    FI --> REC["Record evidence; authorized recovery reconciles partial work"]
    FD --> REC
    FE --> REC
    FG --> REC
    REC -->|"recheck gates; retain retry history"| CLAIM
    DISP["Any lifecycle or failure state: superseded / retired / abandoned"]
    RUN -. "Revoke active worker authority before disposition" .-> DISP
    classDef fail fill:#fff2ee,stroke:#a35743,color:#572d23;
    class FI,FD,FE,FG fail;

# Dependency Readiness

flowchart TB
    A["Artifact + intended next action"] --> D{"All dependency predicates met?"}
    D -->|"no or unknown"| N["readiness: no-go"]
    D -->|"yes"| G{"Other nonapproval gates met, including blocking OQs?"}
    G -->|"no"| N
    G -->|"yes"| H{"Required human or delegated approval present?"}
    H -->|"yes or not required"| GO["readiness: go"]
    H -->|"pending"| P["readiness: need-ok"]
    NOTE["Bare id6: terminal state. State-qualified id6: specified state. Every list entry must pass."]
    D ~~~ NOTE
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    classDef stop fill:#fff2ee,stroke:#a35743,color:#572d23;
    class GO good;
    class N stop;

# Plan Item Evidence

flowchart TB
    PLAN["Reviewed and accepted plan: at least one E-* and one V-*"] --> EA["EA performs E-* work in allocated IWT/branch"]
    EA --> E["E-* performed + execution evidence + result revision"]
    E --> VA["Separate VA context inspects final result and programmatic evidence"]
    VA --> V{"All required V-* pass with observed evidence?"}
    V -->|"yes"| G{"Required E-* and completion gates satisfied?"}
    G -->|"yes"| DONE["Plan: executed"]
    G -->|"dependency or human wait"| WAIT["Retain reached phase + waiting; no retry charge"]
    WAIT -->|"gates resolve; refresh evidence"| VA
    G -->|"unrecoverable or exhausted gate remediation"| FG["fail-gate"]
    V -->|"negative content verdict"| RETRY{"VERIFY retries and cumulative budget remain?"}
    RETRY -->|"no"| FV["fail-verify"]
    RETRY -->|"yes; one corrective round"| CAUSE{"Classify remediation cause"}
    CAUSE -->|"in-scope implementation"| EA
    CAUSE -->|"checks or evidence only"| EV["Evidence owner repairs truthful checks/evidence; no EA replay"]
    EV --> VA
    CAUSE -->|"changed requirements"| AA["AA revises draft; independent RA review and renewed acceptance"]
    AA --> EA
    VA -->|"infrastructure invalidated snapshot"| INF["FAIL recovery budget; fence/recover; preserve VERIFY counters"]
    INF -->|"authorized recovery; fresh evidence"| VA
    NOTE["E checkmarks never imply V pass. Orchestrators have their own E/V obligations. History persists."]
    DONE ~~~ NOTE

# Workspace Isolation

flowchart TB
    REPO["One project repository: shared Git objects and refs"] --> AUTHOR["AA: artifact branch + authoring IWT"]
    REPO --> EXEC["EA: task branch + execution IWT"]
    REPO --> REVIEW["RA/VA: independent context + pinned snapshot worktree"]
    AUTHOR --> CONTROL["Controlled artifact publication and branch integration"]
    EXEC --> CONTROL
    REVIEW -->|"Evidence and review/verification verdict"| CONTROL
    CONTROL --> GATE["Revision-aware lifecycle gates; recheck changed integration results"]
    SERVICE["Durable run service: live leases, checkpoints, terminal reattachment"]
    SERVICE -. "Ownership per workspace; runtime state does not fork per lane" .-> EXEC
    classDef good fill:#eaf8f5,stroke:#27806d,color:#173d35;
    class GATE good;