cc-codeconductor 0.4.3 → 1.0.0

package/presets/agy/workflows/cc-triage.md

@@ -0,0 +1,35 @@
+---
+name: cc-triage
+description:
+  Classify a request into type, risk, and the destination CodeConductor command.
+---
+
+# Triage Workflow
+
+Triage request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `triage` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command triage "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command triage "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile triage --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command triage --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Classify (task-coach)
+
+Invoke `task-coach`. Produce: title, type (`feature` | `fix` | `refactor` | `review` | `docs` | `test`), risk, named scope, and the destination command (`feature`, `fix`, `refactor`, `review`, `explore`, …).
+
+Ask one question per unresolved branch. If the human is unavailable, emit a Markdown questionnaire and stop at ConfirmationGate.
+
+**STOP here. Show the classification and wait for confirmation before running the destination workflow.**
+
+---
+
+## Completion
+
+Do not implement. Hand the human a destination slash command and a partial Task Card.

package/presets/claude/CLAUDE.md

@@ -384,6 +384,20 @@ contract tests. Does not write production code.
 - Cover three cases for every behavior: happy path, edge case, error case.
 - Test names must describe what is being tested and the expected outcome.
 
+**Anti-pattern checklist** — before declaring tests ready, verify none of
+these apply:
+
+- **Implementation-coupled** — the test asserts internal implementation
+  details (private state, call order, mock invocations) instead of observable
+  behavior. It breaks when the implementation is refactored even if the
+  behavior is unchanged.
+- **Tautological** — the test asserts something that cannot fail given the
+  test's own setup (e.g., asserting a value the test itself just hardcoded).
+  It always passes regardless of the code under test.
+- **Horizontal slicing** — the test spans multiple unrelated behaviors or
+  layers in one assertion block instead of a single vertical slice of one
+  behavior.
+
 **Test types:**
 
 | Type        | When to write                                            |
@@ -494,6 +508,56 @@ _(none)_ if no suggestions
 - **Verdict justification**: [one sentence]
 ```
 
+
+**Two-Axis Review Model (Standards + Spec)**
+
+The Reviewer role executes two independent, parallel sub-agents without reranking between them:
+
+1.
+
+_El modelo de dos ejes (Standards, Spec) es la estructura de ejecución de `/cc:review`; los review axes listados en la tabla anterior se aplican DENTRO de cada eje._ **Standards Axis** — Code smell detection against the Fowler baseline (Long Method, Large Class, Duplicated Code, Feature Envy, Shotgun Surgery, Primitive Obsession, Data Clumps, Switch Statements, Speculative Generality, Temporary Fields, Message Chains, Middle Man, Inappropriate Intimacy, Data Class, Comments-as-apology), with documented override allowed via repo standards documentation (e.g., CONTEXT.md or project norms).
+
+2. **Spec Axis** — Alignment with Task Card, acceptance criteria, and scope boundaries.
+
+Each axis produces findings independently. **No reranking** occurs between axes — each axis is evaluated in parallel and its findings remain independent. After parallel execution, a **combined verdict** integrates findings from both axes:
+
+- If either axis finds CRITICAL issues → verdict is `blocked`
+- Else if either axis finds WARNING → verdict is `approved with warnings`
+- Else → verdict is `approved`
+
+**Two-Axis Review Report format:**
+
+```markdown
+## Review Report
+
+**Task**: [objective from Task Card] **Verdict**: [approved | approved with warnings | blocked]
+
+---
+
+### Standards Axis
+
+Applies Fowler code smell baseline with documented overrides.
+
+- [ ] [S1] [file:line] — [code smell] | Override: [documented or N/A] | Required action: [what must change] (CRITICAL) or Recommended action: [what must change] (WARNING)
+
+_(none)_ if no findings
+
+### Spec Axis
+
+Validates Task Card, acceptance criteria, and scope alignment.
+
+- [ ] [Sp1] [criterion number] — [description] | Evidence: [quote] | Required action: [what must change] (CRITICAL) or Recommended action: [what must change] (WARNING)
+
+_(none)_ if no findings
+
+### Combined Summary
+
+- Standards findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- Spec findings: [count] (X CRITICAL, Y WARNING, Z SUGGESTION)
+- **Combined Verdict**: [approved | approved with warnings | blocked]
+- **Verdict justification**: [one sentence]
+```
+
 ---
 
 ### Complexity Auditor

package/presets/claude/commands/cc/api-contract.md

@@ -8,6 +8,18 @@ description: >-
 
 API contract request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `api-contract` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command api-contract "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command api-contract "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile api-contract --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command api-contract --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
 ## Step 1 — Task Card validation (Task Coach role)
 
 Adopt the **Task Coach** role as defined in `CLAUDE.md`.

package/presets/claude/commands/cc/ask.md

@@ -0,0 +1,55 @@
+---
+description: >-
+  [cc: alias] Recommend one CodeConductor slash command from a natural-language
+  problem. Does not start that workflow.
+---
+
+# Ask — recommend a slash command
+
+Problem: $ARGUMENTS
+
+This is a **router**, not a delivery workflow. Recommend exactly one command.
+Do **not** run the recommended `/cc:` command unless the human confirms.
+
+---
+
+## Step 1 — Recommend (deterministic)
+
+Run (local repo: `bun run dev`; published package: `npx cc-codeconductor`):
+
+```bash
+bun run dev ask "$ARGUMENTS" --output json
+```
+
+or:
+
+```bash
+npx cc-codeconductor ask "$ARGUMENTS" --output json
+```
+
+The catalog is only:
+
+| Slash | When |
+| ----- | ---- |
+| `/cc:feature` | new behavior |
+| `/cc:fix` | bug / regression |
+| `/cc:refactor` | structure, no behavior change |
+| `/cc:review` | inspect a diff/PR |
+| `/cc:tdd-cycle` | red → green → refactor |
+| `/cc:openspec` | BACKLOG / BC-xxx delivery |
+
+If the CLI is unavailable, apply the same catalog and the same priority:
+openspec → tdd-cycle → review → refactor → fix → feature (default).
+
+---
+
+## Step 2 — Show and stop
+
+Print:
+
+- **Recommended:** the slash command
+- **Why:** one or two sentences from the CLI `reason` (or your matching)
+
+**STOP.** Wait for the human. Do not invoke the recommended workflow.
+
+For a full preset inventory (skills, commands on disk), use `/cc:help` / `cc-help`.

package/presets/claude/commands/cc/clarify.md

@@ -0,0 +1,32 @@
+---
+description: >-
+  [cc: alias] Re-explain the last deliverable in Task Card vocabulary when it did not land.
+---
+
+# Clarify Workflow
+
+Clarify request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `clarify` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command clarify "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command clarify "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile clarify --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command clarify --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Re-explain (task-coach)
+
+Invoke `task-coach` / `orchestrator`. Restate the last Task Card, plan, or review in the project's vocabulary. Do not add new scope. If questions remain, one question per branch.
+
+**STOP if ConfirmationGate reports questions.**
+
+---
+
+## Completion
+
+A plain-language restatement plus any remaining questions. Then resume the previous workflow.

package/presets/claude/commands/cc/council.md

@@ -0,0 +1,87 @@
+---
+description: Council-driven workflow with CCEP-1 bootstrap
+---
+
+# Council-Driven Workflow
+
+Task request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `council` (fixed for this workflow — do not infer from user text)
+command: council
+
+1. Run: `npx cc-codeconductor ccep parse --command council "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command council "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile council --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command council --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map impact radius before deliberation. Do not write code in this step.
+
+---
+
+## Step 2 — Deliberation & Specification (SDD)
+
+Invoke the `council` skill to analyze the request before writing any code. The council must act as a steering committee involving `task-coach` (Product), `architect`, and `devil`.
+
+The council must:
+1. Clarify the prompt and define the absolute minimum scope (Simplicity Gate).
+2. Explicitly document all assumptions and run the Grilling protocol on each one (Think Before Coding).
+3. Draft a Task Card & Technical Plan (The Specification).
+
+**STOP here.** Unresolved grilling questions populate `questionsForUser` in the
+CCEP-1 `planner-output`; `ccep evaluate` (ConfirmationGate) halts until a human
+answers. Show the agreed Task Card & Technical Plan and wait for confirmation
+before continuing.
+
+---
+
+## Step 3 — Test Definition (TDD)
+
+Invoke `tester` with the approved Task Card & Technical Plan.
+
+tester must:
+1. Write failing tests based on the Acceptance Criteria defined in the Task Card.
+2. Confirm the tests fail as expected (Red state).
+
+**Goal-Driven Execution (Karpathy)**: Do not proceed until verifiable tests are written and fail for the correct reasons.
+
+---
+
+## Step 4 — Surgical Implementation
+
+Invoke `implementer` with the failing tests and the Technical Plan.
+
+implementer must:
+1. Write the minimal code required to pass the tests.
+2. Touch ONLY the files specified in the Technical Plan (Surgical Changes).
+3. NOT refactor adjacent code, change existing styles, or build speculative features.
+4. Run the tests. Loop `implementer` -> `tester` until all tests pass (Green state).
+
+---
+
+## Step 5 — Multi-Perspective Council Review
+
+Invoke the `council` skill on the generated diff to perform the final review phase.
+
+The council will evaluate the diff against the 6 axes (Architecture, Security, Product, Delivery, DataOps, Devil).
+
+If ANY agent votes CRITICAL (especially due to over-engineering, scope creep, or missing the verifiable goals):
+- The Review Report status is **BLOCKED**.
+- Return to Step 4 with the feedback.
+
+If APPROVED (no CRITICAL findings):
+- Deliver the final Council Verdict and the diff summary.
+
+---
+
+## Completion
+
+Deliver the complete Council Verdict. The feature is only complete when tests pass and the council explicitly approves the implementation according to the specification.

package/presets/claude/commands/cc/db-migration.md

@@ -8,6 +8,19 @@ description: >-
 
 Migration request: $ARGUMENTS
 
+## Step 0 — CCEP Bootstrap
+
+Command: `db-migration` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command db-migration "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command db-migration "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile db-migration --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command db-migration --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
 ## Step 1 — Task Card validation (Task Coach role)
 
 Adopt the **Task Coach** role as defined in `CLAUDE.md`.
@@ -31,22 +44,22 @@ rollback/forward-fix notes, and test approach.
 
 ---
 
-## Step 3 — Implementation (Implementer role)
+## Step 3 — Migration Tests (Tester role)
 
-Adopt the **Implementer** role as defined in `CLAUDE.md`.
+Adopt the **Tester** role as defined in `CLAUDE.md`.
 
-Keep model and migration changes together, avoid unrelated refactors, and
-preserve the deployment order specified by architect.
+Cover migration-sensitive behavior where the stack supports it, including
+existing-data edge cases and rollback/forward-fix notes when automated rollback
+tests are not practical.
 
 ---
 
-## Step 4 — Migration Tests (Tester role)
+## Step 4 — Implementation (Implementer role)
 
-Adopt the **Tester** role as defined in `CLAUDE.md`.
+Adopt the **Implementer** role as defined in `CLAUDE.md`.
 
-Cover migration-sensitive behavior where the stack supports it, including
-existing-data edge cases and rollback/forward-fix notes when automated rollback
-tests are not practical.
+Keep model and migration changes together, avoid unrelated refactors, and
+preserve the deployment order specified by architect.
 
 ---
 

package/presets/claude/commands/cc/explore.md

@@ -0,0 +1,36 @@
+---
+description: >-
+  [cc: alias] Map the repository and recommend the next CodeConductor slash command. Read-only.
+---
+
+# Explore Workflow
+
+Explore request: $ARGUMENTS
+
+## Step 0 — CCEP Bootstrap
+
+Command: `explore` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command explore "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command explore "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile explore --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command explore --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+
+---
+
+## Step 1 — Map (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"`. Invoke `repo-explorer`. Produce a Repo Map. Do not write code.
+
+---
+
+## Step 2 — Suggest next command (orchestrator)
+
+Recommend exactly one next slash command (`/cc:feature`, `/cc:fix`, `/cc:refactor`, `/cc:review`, `/cc:triage`, …) with a one-sentence rationale. Do not start that workflow.
+
+---
+
+## Completion
+
+Report the Repo Map and the recommended next `/cc:` command.

package/presets/claude/commands/cc/feature.md

@@ -10,22 +10,49 @@ Feature request: $ARGUMENTS
 
 ---
 
-## Step 1 — Task Card validation (Task Coach role)
+## Step 0 — CCEP Bootstrap
+
+Command: `feature` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command feature "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command feature "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile feature --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command feature --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
 
 Adopt the **Task Coach** role as defined in `CLAUDE.md`.
 
 Produce a complete Task Card. The Task Card is ready when it contains: title,
-type, risk classification, scope, context, acceptance criteria, and constraints.
+type, risk classification, scope, context, acceptance criteria, and
+constraints, and every assumption behind it has survived one grilling
+question (Grilling protocol).
 
 If any field is missing or ambiguous, ask one clarifying question at a time and
 wait for the answer. Do not proceed with an incomplete Task Card.
 
-**STOP here. Show the completed Task Card and wait for human confirmation before
-continuing.**
+**STOP here.** Unresolved grilling questions or missing fields populate
+`questionsForUser` in the CCEP-1 `planner-output`; the `ConfirmationGate`
+(`ccep evaluate`) reads that field and halts the workflow until a human
+answers. Show the completed Task Card and wait for that confirmation before
+continuing.
 
 ---
 
-## Step 2 — Technical Plan (Architect role)
+## Step 3 — Technical Plan (Architect role)
 
 Adopt the **Architect** role as defined in `CLAUDE.md`.
 
@@ -43,7 +70,20 @@ not proceed to implementation until the plan is approved.**
 
 ---
 
-## Step 3 — Implementation (Implementer role)
+## Step 4 — Test coverage (Tester role)
+
+Adopt the **Tester** role as defined in `CLAUDE.md`.
+
+Use the Implementation Summary and the Task Card.
+
+1. Write or extend failing tests for the new behavior before implementation (RED).
+2. Ensure all acceptance criteria from the Task Card have at least one test.
+3. Run the full test suite and confirm it passes.
+4. Produce a Test Report: test files added or modified, cases covered.
+
+---
+
+## Step 5 — Implementation (Implementer role)
 
 Adopt the **Implementer** role as defined in `CLAUDE.md`.
 
@@ -52,26 +92,13 @@ Implementer creates a Git Worktree before touching any file; all edits happen in
 
 1. Read the Technical Plan before touching any file.
 2. Apply the minimal diff — only what the plan specifies.
-3. Run the project test suite after implementation.
+3. Run the project test suite and make the previously written failing tests pass.
 4. Produce an Implementation Summary: what changed, which files, how to verify
    locally.
 
 ---
 
-## Step 4 — Test coverage (Tester role)
-
-Adopt the **Tester** role as defined in `CLAUDE.md`.
-
-Use the Implementation Summary and the Task Card.
-
-1. Write or extend tests to cover the new behavior.
-2. Ensure all acceptance criteria from the Task Card have at least one test.
-3. Run the full test suite and confirm it passes.
-4. Produce a Test Report: test files added or modified, cases covered.
-
----
-
-## Step 5 — Code review (Reviewer role)
+## Step 6 — Code review (Reviewer role)
 
 Adopt the **Reviewer** role as defined in `CLAUDE.md`.
 
@@ -85,7 +112,7 @@ they are resolved and the diff is re-reviewed.
 
 ---
 
-## Step 6 — Documentation (Docs role)
+## Step 7 — Documentation (Docs role)
 
 Adopt the **Docs** role as defined in `CLAUDE.md`.
 

package/presets/claude/commands/cc/fix.md

@@ -18,7 +18,29 @@ Provide the following information in $ARGUMENTS:
 
 ---
 
-## Step 1 — Task Card validation (Task Coach role)
+## Step 0 — CCEP Bootstrap
+
+Command: `fix` (fixed for this workflow — do not infer from user text)
+
+1. Run: `npx cc-codeconductor ccep parse --command fix "$ARGUMENTS" --output json`
+2. Run: `npx cc-codeconductor ccep resolve --command fix "$ARGUMENTS" --output json`
+3. Run: `npx cc-codeconductor ccep profile fix --output json`
+4. After planner/intake JSON is available, run: `npx cc-codeconductor ccep evaluate --command fix --input <planner.json> --output json`. If `stop` is true, show questions or risks and wait for human input.
+5. Delegate to subagents using compiled CCEP prompts — never forward raw `$ARGUMENTS` to planners.
+   Canonical delivery order is test-before-implement whenever both phases apply.
+
+---
+
+## Step 1 — Wayfinding (repo-explorer)
+
+If `graphify-out/graph.json` exists, run `graphify query "$ARGUMENTS"` (and
+`graphify path` / `graphify explain` when needed). Then invoke `repo-explorer`
+to map modules, conventions, and impact radius. Do not write code in this step.
+Record a Repo Map artifact before intake.
+
+---
+
+## Step 2 — Task Card validation (Task Coach role)
 
 Adopt the **Task Coach** role as defined in `CLAUDE.md`.
 
@@ -32,11 +54,43 @@ Produce a Task Card that includes:
 If reproduction steps are missing, ask for them before classifying risk. A bug
 without a reproduction path cannot be classified reliably.
 
+Capture evidence before tests: reproduction, logs or stack traces, and one
+falsifiable hypothesis of the root cause. Do not patch without that evidence.
+Redact secrets, tokens, and credential dumps from logs before they enter the
+Task Card. Summarize stack traces; do not paste env files.
+
 **STOP here. Show the Task Card and wait for human confirmation.**
 
 ---
 
-## Step 2 — Route by risk
+## Step 2.5 — Red loop gate
+
+Before hypothesizing about the root cause, produce a reproduction command:
+one deterministic, tight command that exercises the real bug path and asserts
+the exact symptom the user reported (not a proxy or a related error).
+
+Requirements:
+
+- The command must be **deterministic** — running it twice produces the same
+  result.
+- The command's assertion must match the exact user-reported symptom (actual
+  vs. expected from the Task Card), not a generic failure.
+- Run it at least once before continuing. Do not proceed to Step 3 until you
+  have run it and it reproduces the bug (RED).
+
+Record the run as evidence so `cc verify` can see it: write a JSON file to
+`.codeconductor/evidence/` matching `EvidenceSchema` with `type: 'test'` and a
+`data` payload shaped like `ImplementerTestsSchema` (`runner`, `result`,
+`failedTests`), e.g. `{ "runner": "<reproduction command>", "result": "failed" }`
+for this red run. After the fix (Step 3/4a/4b), re-run the same command and
+update the evidence to `"result": "passed"` — `cc verify --task <id>` reads
+this evidence directly, no code changes required.
+
+**Do not proceed to Step 2 without a reproduction command that has been run.**
+
+---
+
+## Step 3 — Route by risk
 
 Read the risk field from the Task Card and follow the corresponding route.
 
@@ -45,16 +99,16 @@ Read the risk field from the Task Card and follow the corresponding route.
 Applies when: the bug is isolated to a single component, existing tests cover
 the affected code, and no public API or shared state is involved.
 
-Route: Task Coach → Implementer → Tester
+Route: Task Coach → Tester → Implementer
 
-Proceed directly to Step 3a.
+Proceed directly to Step 3 (tests), then Step 4a.
 
 ### Medium or high-risk route
 
 Applies when: the bug touches shared state, a public API, auth or payment paths,
 database writes, or the root cause is not yet understood.
 
-Route: Task Coach → Architect → Implementer → Tester → Reviewer
+Route: Task Coach → Architect → Tester → Implementer → Reviewer
 
 Adopt the **Architect** role before implementation. Architect must:
 
@@ -68,19 +122,30 @@ before continuing.**
 
 ---
 
-## Step 3a — Implementation, low-risk (Implementer role)
+## Step 4 — Regression tests (Tester role)
+
+Adopt the **Tester** role as defined in `CLAUDE.md`. Apply for all risk levels.
+
+1. Write a regression test that reproduces the original bug and confirm it fails
+   before any fix (RED).
+2. Verify that existing tests still pass.
+3. Produce a Test Report: test added, case covered.
+
+---
+
+## Step 5a — Implementation, low-risk (Implementer role)
 
 Adopt the **Implementer** role as defined in `CLAUDE.md`. Use the Task Card.
 Implementer creates a Git Worktree before touching any file; all edits happen inside it.
 
 1. Locate the defect using the reproduction steps.
 2. Apply the minimal fix — no unrelated changes.
-3. Run the test suite.
+3. Run the suite and make the RED regression test pass.
 4. Produce an Implementation Summary: root cause, fix applied, files changed.
 
 ---
 
-## Step 3b — Implementation, medium/high-risk (Implementer role)
+## Step 5b — Implementation, medium/high-risk (Implementer role)
 
 Adopt the **Implementer** role as defined in `CLAUDE.md`. Use the approved
 Technical Plan and the Task Card.
@@ -91,18 +156,7 @@ After implementation, run the full test suite.
 
 ---
 
-## Step 4 — Regression tests (Tester role)
-
-Adopt the **Tester** role as defined in `CLAUDE.md`. Apply for all risk levels.
-
-1. Write a regression test that reproduces the original bug (fails before the
-   fix, passes after).
-2. Verify that existing tests still pass.
-3. Produce a Test Report: test added, case covered.
-
----
-
-## Step 5 — Review (Reviewer role) — medium/high-risk only
+## Step 6 — Review (Reviewer role) — medium/high-risk only
 
 Adopt the **Reviewer** role as defined in `CLAUDE.md`. Use the diff and Task
 Card.