fix-bug

name	fix-bug
position	both
description	RCA-driven defect resolution — opens the bug issue, traces the root cause, designs a fix with alternatives, presents it at a single human checkpoint, then implements with independent verification and lands it on main. The /fix command in the ProductOS command model. Use when you have an open bug issue to fix end to end.
user-invocable	true

fix-bug

Given an existing open defect issue, find the true root cause — trace the symptom to the specific code and the reason it is wrong — design a fix that has weighed at least one alternative, present root cause and fix design at a single human checkpoint, and on approval implement the fix and prove it works by an independent check. After the checkpoint everything runs autonomously.

Pipeline position: both. This play owns only the defect-resolution core (RCA → design → checkpoint → implement → verify). The D2 pipeline-position rule (standards/rules/pipeline-position.md) brackets it: start-change is injected at the head (resolve the existing issue, cut the branch off fresh main, optional worktree, init STM) and the end sequence commit-change → propose-change → review-change → merge-change is injected as the closing chain. This source never hand-rolls issue/branch/PR/merge steps — they come only via injection.

Compiled From

This play was compiled from the fix-bug ICE (reference/ice.md) by play-editor (#466 Batch B, Level 3 rollout per ADR 025; #467 Batch D — design gate unpinned). Intent defines constraints (C1–C14) and failure conditions (F1–F13); the expectation defines success scenarios (S1–S4), a Done means (D1–D4, baked to stop-condition.yaml), and one recovery entry per failure condition. To modify this play, update reference/ice.md and recompile with play-editor. Do NOT edit this file manually — it is a compiled artifact.

Supersedes the old fix-it play: the branch-creation and ship sections fix-it carried are gone — they are now the injected start-change head and the commit-change → propose-change → review-change → merge-change tail.

Role

You are the orchestrator. You own the workflow and the step order. You delegate domain work to agents via JSON contracts over files on disk — never execute domain work directly.

Forbidden: direct git/gh commands or codebase analysis in play prose. All domain work goes through the agents below; all issue/branch/PR/merge work comes via the injected member sub-plays, never hand-rolled here.

Agent boundaries:

Agent	Type	Domain	Phases
project-orchestrator	utility	Issues: confirm the issue is open (manage-issue read); post the RCA-approved comment (manage-issue comment, background)	Validate; Checkpoint
tech-designer	domain	RCA, fix design with alternatives, blast radius, LTM resolution trace, the failing regression test, and re-plan on verify exhaustion	RCA & Design; Re-plan
code-builder	domain	Implement the fix from the design artifacts (context-isolated)	Implement
quality-auditor	domain	Independent verification — run the regression test, write the pass/fail verdict	Verify
repo-orchestrator	utility	Self-commit the evidence files	Evidence & Close

Domain agents: 3 (tech-designer, code-builder, quality-auditor) — within the ≤5 budget. Utility agents: 2 (project-orchestrator, repo-orchestrator) — exempt. The injected member sub-plays (start-change, commit-change, propose-change, review-change, merge-change) carry their own agents; those are not counted here.

Pre-flight

Execute these checks before any work. The play delegates domain work to agents — pre-flight itself only reads config and the branch/argument context.

Check	Constraint	Action on Failure
Resolve working base + config (.garura/core/config.yaml)	—	Hard halt — config is required
Resolve stm.base-path and ltm.project-target	—	Hard halt
Resolve product LTM base; set has_product_ltm from whether its architecture dir exists	C6	Soft — has_product_ltm=false, continue
Issue resolvable (number passed in, or a fix//feature/ branch carries one)	C1	Hard halt — "No issue provided. Give an issue number or run from a fix/feature branch."

Resolve the working base once and hold it for every later path. Extract the issue number from the branch name when present. Because the issue must pre-exist for a defect fix, the issue number is passed into the injected start-change so it resolves the existing issue and does not create a new one.

Right after the issue number resolves, record the session identity stamp's start marker (#463 — soft-fail, never a halt):

python3 scripts/session_stamp.py --phase start \
    --marker "{stm_base}{issue}/status/session-stamp-fix-bug.json" \
    --cwd "$(pwd)" --branch "$(git branch --show-current)"

Resume check: if a status marker for this play exists at {stm_base}/{issue}/status/fix-bug.json, resume — skip completed steps, reset any in-progress step to pending, and continue from the first incomplete one.

Task DAG

Create ALL tasks via TaskCreate immediately after resolving the working base — before any domain work. The play owns this DAG; agents must not edit its top-level tasks (they may TaskCreate discovered sub-work with addBlockedBy).

[T1]  start-change  (injected — position: both, head)   blockedBy: []
[T2]  Validate Issue Open                                blockedBy: [T1]
[T3]  RCA & Design (+ failing regression test)           blockedBy: [T2]
[T4]  Prepare Inline Checkpoint                          blockedBy: [T3]
[T5]  Human Approval Gate (+ background issue comment)    blockedBy: [T4]
[T6]  Implement Fix                                       blockedBy: [T5]
[T7]  Verify Fix (independent)                            blockedBy: [T6]
[T8]  commit-change   (injected — end #1)                blockedBy: [T7]
[T9]  propose-change  (injected — end #2)                blockedBy: [T8]
[T10] review-change   (injected — end #3)                blockedBy: [T9]
[T11] merge-change    (injected — end #4)                blockedBy: [T10]
[T12] Scenario Validation                                blockedBy: [T11]
[T13] Evidence & Close                                   blockedBy: [T12]

The implement→verify retry loop wraps T6 and T7 (cap 2 per C13); on exhaustion the play re-invokes tech-designer to revise, then resumes. review-change's verdict (T10) gates merge-change (T11): a reject stops the sequence before merge (the review-pr.bypass config governs whether it hard-blocks). Mark each task in-progress before its step and completed right after its eval passes. No runtime reordering.

Workflow

Phase: Start (injected — D2 position: both)

Step 1 — start-change · Owner: start-change (sub-play) · Depends on: pre-flight Run the start-of-pipeline member as a sub-play, dispatched with parent_run_id so it emits only its own C1 evidence and this play's close absorbs it. The contract passes the resolved issue number so start-change resolves the existing defect issue (does not create one), cuts feature/<issue>-<slug> off fresh main, sets up a worktree iff config calls for it, and initializes the STM workspace:

{
  "play":         "start-change",
  "parent_run_id": "<this run id>",
  "inputs":  { "issue_number": "<resolved issue number>" },
  "outputs": { "issue": "{stm_base}/{issue}/evidence/fix-bug/start/issue.json",
               "branch": "{stm_base}/{issue}/evidence/fix-bug/start/branch.json" }
}

start-change owns its own evals (issue anchored, branch off latest main, worktree per config, STM initialized); they are not re-checked here.

Phase: Validate

Step 2 — Validate Issue Open · Owner: project-orchestrator · Depends on: Step 1 Dispatch a JSON contract; the agent invokes manage-issue (action: read) for the resolved issue and writes its details, including state, to disk:

{
  "task":    "read the defect issue and record its state",
  "inputs":  { "issue_number": "<resolved issue number>" },
  "outputs": { "issue_read": "{stm_base}/{issue}/evidence/fix-bug/issue-read.yaml" }
}

SE-1 (F4/C1): issue-read.yaml exists and its state is open. If the file is absent or the state is not open, halt — "Issue #{issue} does not exist or is not open." No later step may run.

Phase: RCA & Design

Step 3 — Root Cause Analysis, Fix Design, and Failing Regression Test · Owner: tech-designer · Depends on: Step 2 Dispatch a JSON contract. The agent reads the issue, follows the R1–R4 resolution protocol (standards/rules/resolution.md) grounded in the LTM context, and invokes the three worker skills in order — it does NOT author these artifacts inline:

1. draft-rca → rca.yaml (+ resolution-trace.yaml when LTM context is present)

2. draft-fix-design → design.yaml

3. author-regression-test → the failing regression test at the repo's canonical eval path (red-verified), with its path recorded

   { "task": "trace root cause, design the fix with alternatives, author a failing regression test", "inputs": { "issue_read": "{stm_base}/{issue}/evidence/fix-bug/issue-read.yaml" }, "outputs": { "rca": "{stm_base}/{issue}/evidence/fix-bug/rca.yaml", "design": "{stm_base}/{issue}/evidence/fix-bug/design.yaml", "resolution_trace": "{stm_base}/{issue}/evidence/fix-bug/resolution-trace.yaml", "regression_test_path": "{stm_base}/{issue}/evidence/fix-bug/regression-test-path.yaml" }, "ltm_context": { "project_base": "<product architecture dir, omit when has_product_ltm is false>", "core_base": "~/.garura/core/memory/", "query_domains": ["architecture", "design-patterns", "quality-standards", "domain-context"] } }

Play post-verify (C7): before Step 6, the play reads regression_test_path, confirms the test exists, and confirms it is red (the verifier in Step 7 will confirm green). If the test is missing or already passing, re-invoke tech-designer — never proceed.

SE-2 (F2/C2): rca.yaml exists, root_cause is non-empty, names at least one specific file and the logic within it, explains why it is wrong, and is textually distinct from the title/body in issue-read.yaml. SE-3 (F3/C3): design.yaml exists and alternatives_considered is a non-empty list, each entry carrying both an option and a non-empty rejection_reason. SE-4 (F8/C6): when the contract included ltm_context, resolution-trace.yaml exists with a non-empty list of entries each carrying resolved_from; when has_product_ltm is true at least one entry is project or core (not all llm); when false, at least one core entry or an explicit llm fallback with a rationale. SE-5 (F10/C7): regression_test_path is non-empty, the file exists, and it is failing (red) before any implementation begins.

Phase: Checkpoint

Step 4 — Prepare Inline Checkpoint · Owner: play · Depends on: Step 3 Read rca.yaml and design.yaml and render the checkpoint summary inline in Step 5 from those YAML artifacts. No standalone brief or HTML artifact is produced (C10). SE-6 (F9/C10): after this step, no .html file and no briefs/ directory exists anywhere under {stm_base}/{issue}/evidence/fix-bug/.

Step 5 — Design Approval Gate (class: standard) · Owner: play · Depends on: Step 4 The design checkpoint resolves per standards/rules/gate-config.md (first match wins: per-play gates.plays.fix-bug, then class standard, then default). It is no longer pinned — #467 Batch D unpinned it (an intent change to C4); the machine preconditions below carry what the human was checking.

• off (current config: gates.plays.fix-bug: off) → do NOT wait. Record gate skipped by config (gates.plays.fix-bug) as a Checkpoint Decisions row in the evidence file, then verify the machine wall before any implement step: rca.yaml present with a traced root cause (SE-2), design.yaml present with ≥1 weighed alternative (SE-3), and the regression test proven red before the fix (the Play post-verify above, SE-5 — TDD red-before-green, the hard invariant, never gated). All three present → dispatch the background issue comment (below, C11), record the off-wall clearance timestamp in the status marker, and proceed to Step 6. Any missing → HARD HALT naming the missing precondition (REC13); the fix never starts.
• on (config flipped back) → present the summary inline and wait for the typed response, exactly as below.

Inline summary (rendered only when the gate resolves on):

**Fix Design: #{issue} — {title}**

**Root Cause**
{root cause — file, logic, why it is wrong, from rca.yaml}

**Blast Radius**
| File | Role | Change Needed |
|------|------|---------------|
{affected files from design.yaml}

**Proposed Fix**
{strategy from design.yaml}

**Alternatives Considered**
{alternatives with rejection reasons from design.yaml}

**Confidence**
{confidence from design.yaml}

---
Type **Tether** to approve and proceed, or **Vanish** to reject.

• Tether → dispatch the background issue comment (below), then proceed to Step 6.
• Vanish → halt; write rejection evidence; no implementation occurs.
• else → clarify.

On Tether — background issue comment (C11): immediately dispatch a non-blocking project-orchestrator (run_in_background: true) to post the RCA-approved comment to the originating issue using the issue-comment-rca-approved.md template, and write a tracking stub {stm_base}/{issue}/evidence/fix-bug/issue-comment-agent.yaml (status: dispatched, dispatched_at) before implementation begins. Implementation does not wait for it.

SE-7 (F1/C4/C5): no implementation artifact ({stm_base}/{issue}/evidence/fix-bug/implementation-report.yaml) exists unless EITHER the status file shows the approval gate completed with a tether_received_at that precedes the implement step (gate on), OR the gate resolved off with the gate skipped by config row recorded and all three machine preconditions (rca.yaml, design.yaml, red-verified regression test) present with the off-wall clearance timestamp preceding the implement step (gate off); after the gate clears — Tether or the off-wall — no further human approval is requested (C5). SE-8 (F11/C11): issue-comment-agent.yaml exists with status: dispatched (or completed) and a non-empty dispatched_at before the implement step goes in-progress — on both the Tether path and the gate-off path. SE-14 (F13/C4): with the gate resolved off, no implementation artifact exists until the machine wall held — rca.yaml with a traced root cause, design.yaml with ≥1 alternative, and a regression test proven red before the fix all present; any one missing is a hard halt (REC13) and the fix never starts.

Phase: Implement & Verify (retry loop, cap 2 per C13)

Step 6 — Implement Fix · Owner: code-builder · Depends on: Step 5 (Tether only) Dispatch a JSON contract carrying only the design artifact paths plus the regression-test file path in read_only_files — never the checkpoint brief, never the test's assertion content (C9):

{
  "task":   "implement the fix per the design",
  "inputs": { "design": "{stm_base}/{issue}/evidence/fix-bug/design.yaml",
              "rca":    "{stm_base}/{issue}/evidence/fix-bug/rca.yaml" },
  "read_only_files": ["<regression_test_path>"],
  "outputs": { "implementation_report":
               "{stm_base}/{issue}/evidence/fix-bug/implementation-report.yaml" }
}

code-builder must NOT run its own verification; any builder self-report of pass/fail is not a valid signal (C8). After the report is written, the play runs the scope check:

python3 scripts/check_scope.py <design.yaml> <implementation-report.yaml>

SE-9 (F5/C12): check_scope.py exits 0 — every file in files_modified is in design.yaml.affected_files or carries a deviation_justification. SE-10 (F6/C9): the code-builder contract contains only the design.yaml/rca.yaml paths plus regression_test_path under read_only_files; no checkpoint-brief path, no HTML path, no inline checkpoint markdown, and no test-assertion text appears in any field.

Step 7 — Verify Fix (independent) · Owner: quality-auditor · Depends on: Step 6 Dispatch a JSON contract; the agent runs the regression test against the source now on disk and writes an exit-code-style verdict — the verifier is never the implementer (C8):

{
  "task":   "run the regression test against the fix and record the verdict",
  "inputs": { "regression_test_path": "<regression_test_path>",
              "source_files": "<design.affected_files>" },
  "outputs": { "verdict":
               "{stm_base}/{issue}/evidence/fix-bug/regression-test-verdict.yaml" }
}

SE-11 (F7/C8): the pass/fail verdict used to gate the close comes from regression-test-verdict.yaml authored by quality-auditor; a code-builder self-report is never used. SE-12 (C13): the implement→verify loop retries at most twice per task; on a fail verdict with retries remaining the play re-runs Step 6 → Step 7; on exhaustion it re-invokes tech-designer to revise the design/test and resumes — it does not halt blindly.

Retry semantics: pass → exit the loop, proceed to the end sequence. fail and retries remain → re-run Step 6 → Step 7. fail and retries exhausted → tech-designer re-plan, then resume.

Phase: End sequence (injected — D2 position: both)

Each member runs as a sub-play dispatched with parent_run_id (emits only its own C1 evidence; this play's close absorbs it). Each is independent and resolves its own context from the branch and config; this play passes no hand-rolled git/PR/merge logic.

Step 8 — commit-change · Owner: commit-change (sub-play) · Depends on: Step 7 (verdict pass) — commit the fix grouped by concern with conventional messages referencing the issue; no push.

Step 9 — propose-change · Owner: propose-change (sub-play) · Depends on: Step 8 — run the scope-and-quality self-review, push the branch, open the PR carrying the review and the issue reference.

Step 10 — review-change · Owner: review-change (sub-play) · Depends on: Step 9 — run the diff-scoped quality check, classify by the severity taxonomy, post an approve/reject verdict. A reject stops the sequence before merge.

Step 11 — merge-change · Owner: merge-change (sub-play) · Depends on: Step 10 (approve verdict) — merge the PR, switch to main and pull, delete the feature branch (local + remote).

{
  "play":          "<commit-change | propose-change | review-change | merge-change>",
  "parent_run_id": "<this run id>",
  "inputs":  { "issue_number": "<resolved issue number>" },
  "outputs": { "result": "{stm_base}/{issue}/evidence/fix-bug/end/<member>.json" }
}

Phase: Scenario Validation

Step 12 — Scenario Evals · Owner: play · Depends on: Step 11

• SCE-1 (S1 — developer, end to end): rca.yaml has a non-empty root_cause naming a specific file; design.yaml has at least one alternative with a rejection reason; the quality-auditor verdict is pass; a merged PR references the issue (from the merge-change result).
• SCE-2 (S2 — tech lead, checkpoint): when the Step 5 gate resolved on, the inline summary carries a root cause (specific file + logic), a blast-radius table with ≥1 affected-file row, a fix strategy, ≥1 alternative with a rejection reason, and a confidence value — and no .html/brief file exists under the evidence path. When the gate resolved off the checkpoint is not rendered (skipped by config); the no-.html/brief assertion still holds.
• SCE-3 (S3 — QA engineer, audit trail): the originating issue carries an approved-RCA comment created before implementation; the accepted fix carries the quality-auditor pass verdict; the gate-clearance timestamp (the Tether tether_received_at, or the off-wall clearance timestamp when the gate resolved off) is strictly earlier than the implement start.
• SCE-4 (S4 — developer, red-before-green): the regression test was recorded failing (red) before implementation and the independent verdict after implementation is pass.

Phase: Evidence & Close

Closes with the Standard Play Close — the canonical three-table delivery report (Run Summary / Pipeline Steps / Artifacts), not prose. See standards/rules/play-close.md. SE-13 (F12/C14): the stop-condition verdict is held before the run closes COMPLETED; a close over an unmet or unevaluable verdict reads HALTED, never COMPLETED.

# --- Standard Play Close (canonical; see standards/rules/play-close.md) ---
# Path tokens resolved at pre-flight (resolve here if not already):
#   ltm_project_target  = yq '.ltm.project-target' .garura/core/config.yaml
#   fix-bug is project-scoped:
#     evidence_base="${stm_base}${issue}/evidence/fix-bug/"   ; slug="#${issue}"
evidence_template=$(cat "${ltm_project_target}standards/templates/evidence-file.md")
delivery_template=$(cat "${ltm_project_target}standards/templates/delivery-report.md")
ts=$(date -u +%Y%m%d-%H%M%S)
evidence_dest="${evidence_base}${ts}.md"
mkdir -p "$(dirname "$evidence_dest")"
# Session identity stamp (#463) — close phase; start phase ran at pre-flight
session_stamp=$(python3 scripts/session_stamp.py --phase close \
    --marker "${stm_base}${issue}/status/session-stamp-fix-bug.json")
# Stop-condition gate (#464) — Step C0: this play carries a baked manifest, so the
# gate is LIVE. Evaluate the Done means here as the close's authoritative input.
python3 scripts/check_stop_condition.py \
    --manifest "<play-dir>/stop-condition.yaml" \
    --base "${stm_base}${issue}/" \
    --out "${stm_base}${issue}/status/stop-condition-fix-bug.yaml"
sc_exit=$?   # 0 held · 1 unmet · 2 error

Step C0 — bind the verdict. sc_exit == 0 (held) permits status: COMPLETED. Anything else closes HALTED with exit_reason: stop_condition_unmet and the evidence's Stop Condition section names every unmet clause. An unevaluable verdict is never a pass.

Step C1 — Write evidence file. Gated by the resolved evidence.record flag (per-play evidence.plays.fix-bug first, else global evidence.record, else record). When false, skip the write and record evidence skipped (record=false) in the report's pointer line. Otherwise fill the evidence-file.md slots (play fix-bug, run_id fix-bug-${ts}, issue, started_at/completed_at, status per C0, exit_reason; artifacts: rca/design/resolution-trace/ regression test/verdict/PR + merge SHA/branch status/issue-comment status; step + scenario eval results; checkpoint decision; commit reference; the session identity stamp fields from $session_stamp (#463): session_id, ledger_file, ledger_start_offset, ledger_end_offset (null when unresolved — never blocks the close); and stop_condition per C0 with the Stop Condition section filled) and write to $evidence_dest. Do NOT hand-author the body. Then dispatch repo-orchestrator to self-commit only the listed evidence files with message chore(stm): record fix-bug evidence for #{issue} (non-blocking — a commit failure logs a warning, never halts).

Step C2 — Render delivery report. Also render the Next line: resolve this play in standards/rules/pipeline-next.md and emit **Next:** /<command> — <why>. Or run /next to see all recommended actions. (only /next pointer, or omit, when the mapped command is null), per play-close.md. Fill the delivery-report.md slots and output it: ## fix-bug Delivered — #{issue}, the Run Summary table, the Pipeline Steps table from the task DAG (T1–T13, including the injected start/end members), the Artifacts Produced table, Next Steps (only real follow-ons), and a pointer to $evidence_dest. Always emitted; never gated. When this play itself runs as a sub-play (parent_run_id present), skip C2.

# --- end Standard Play Close ---

Scenario Validation

The success scenarios and their evals (run in Step 12):

Scenario	Persona	Eval
S1 — end to end	developer	SCE-1
S2 — checkpoint review	tech lead	SCE-2
S3 — audit trail	QA engineer	SCE-3
S4 — red-before-green	developer	SCE-4

Recovery

One entry per failure condition. The injected member sub-plays own their own recovery; the entries below cover this play's defect-resolution core.

For	Trigger	Direction	Handoff
F1	an implementation artifact exists, or implement is in progress, with no completed approval preceding it	hold for the single human Tether/Vanish before any implementation step runs	human
F2	rca.yaml is missing, root_cause is empty, or it restates the issue text	re-run RCA to trace symptom → the specific file, logic, and why it is wrong, distinct from the issue text	autonomous
F3	design.yaml is missing or alternatives_considered lacks an entry with a rejection reason	re-run the design step to add at least one alternative with the reason it was rejected	autonomous
F4	the issue does not exist or is not open when the play starts	escalate for a human to provide or reopen a valid open issue before proceeding	human
F5	a modified file is absent from design.affected_files with no deviation justification	restrict the change to the mapped files, or record the deviation justification, before the close	autonomous
F6	the code-builder contract carries checkpoint-brief content or the test's assertion content	rebuild the contract with only the design paths plus the regression-test path, stripping all brief and assertion content	autonomous
F7	the accepting verdict came from the implementing agent	discard the self-report and obtain the verdict from quality-auditor before the close	autonomous
F8	ltm_context was provided but resolution-trace.yaml is missing or empty	re-run RCA to emit a non-empty resolution trace recording the layer that answered each domain question	autonomous
F9	a standalone brief or HTML artifact exists under the evidence path after checkpoint prep	remove the artifact and any briefs/ directory so the evidence path holds none	autonomous
F10	the fix is about to be accepted without a red-then-green regression test	author the failing test and confirm it red before implementation, then confirm it green via quality-auditor before the close	autonomous
F11	Tether received but issue-comment-agent.yaml not written (or status: pending) before implement	write the dispatched tracking stub with a dispatched_at before the implement step goes in-progress	autonomous
F12	the close would report COMPLETED without the Done means held	evaluate the stop condition and surface the unmet clauses; the run closes HALTED until state is fixed	autonomous
F13	the gate resolved off and an implement step is starting while the RCA, the fix design, or a red-verified regression test is missing	HARD HALT and name the missing precondition; do not start the fix until all three exist (re-run the producing step per REC2/REC3/REC10 as needed)	autonomous

At Level 4, intent-resolver runs the autonomous entries without a human; the two human entries always escalate. The implement→verify retry loop is governed separately by C13 (cap 2, then tech-designer re-plan; resume, never halt blindly).

Pause and Resume

Steps run top to bottom. Resolve the issue number from the branch name or input on entry, check the status marker at {stm_base}/{issue}/status/fix-bug.json, skip completed steps, reset any in-progress step to pending, and continue from the first incomplete one. A fresh start with no marker runs everything and creates the marker at Step 1. The injected member sub-plays (start-change and the end sequence) are themselves resumable and never duplicate an issue, branch, PR, or merge on a re-run.

Compilation Metadata

Field	Value
fingerprint	sha256:f696433dbaed99d09b8c2623acf2c30123ceb70821f052cf81ba44a5e950ed4a (of reference/ice.md)
compiled_by	play-editor (#466 Batch B; #467 Batch D — design gate unpinned)
pipeline_position	both (start-change head; commit-change → propose-change → review-change → merge-change tail)
workflow_structure	A (single design checkpoint — class: standard, unpinned #467 Batch D, resolves per gate-config; when off the machine wall carries it — RCA + fix design + red regression test — and TDD red-before-green is never gated; retry loop around implement + verify per C13)
stop_condition	stop-condition.yaml (D1–D4), gate live at Step C0
domain_agents	3 (tech-designer, code-builder, quality-auditor)
utility_agents	2 (project-orchestrator, repo-orchestrator)
skills_reused	draft-rca, draft-fix-design, author-regression-test, manage-issue
member_subplays	start-change, commit-change, propose-change, review-change, merge-change
scripts	3 (check_scope.py, check_stop_condition.py, session_stamp.py)
step_evals	14 (SE-1…SE-14; SE-14 covers the gate-off machine wall F13/C4)
scenario_evals	4 (SCE-1…SCE-4)
recovery_entries	13 (one per failure condition; 11 autonomous / 2 human)
supersedes	fix-it