| 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:
-
draft-rca → rca.yaml (+ resolution-trace.yaml when LTM context is present)
-
draft-fix-design → design.yaml
-
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.
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_stamp=$(python3 scripts/session_stamp.py --phase close \
--marker "${stm_base}${issue}/status/session-stamp-fix-bug.json")
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=$?
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.
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 |
