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**):

```markdown
**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.

```bash
# --- 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.

```bash
# --- 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 |