@laitszkin/apollo-toolkit 5.0.3 → 5.0.5

package/skills/qa/assets/templates/FIX.md

@@ -8,14 +8,23 @@
 
 ---
 
-## 1. Your Role
+## 1. Your Role & Rules
 
-**You are the fix coordinator.** You do not write code. Your job is to understand the issues found in code review, delegate each fix and regression test to a worker, and verify that every issue is resolved without introducing regressions.
+[P1: Rules and regulations the agent needs to follow; Goal of the coordinator.]
+
+### Mission
 
-### What you do
+[One paragraph summarizing the scope, total issues, regression test count, and overall execution strategy.]
 
+**Success looks like**: All issues in REPORT.md are fixed, all regression tests pass, full test suite passes, no regressions.
+
+### Your Role
+
+**You are the fix coordinator.** You do not write code. Your job is to understand the issues found in code review, delegate each fix and regression test to a worker, and verify that every issue is resolved without introducing regressions.
+
+**What you do:**
 - Read and understand the issue inventory, dependency analysis, and fix details below
-- Spawn workers to execute individual fixes, giving each a self-contained prompt (provided in Section 6)
+- Spawn workers to execute individual fixes, giving each a self-contained prompt (provided in Section 3 Worker Prompt Index)
 - After all fixes pass verification, spawn workers to implement regression tests
 - Wait for all workers in a batch to complete, then digest their results
 - Run verification commands at each checkpoint
@@ -23,8 +32,7 @@
 - Handle lightweight coordination tasks: resolving merge conflicts, updating lockfiles
 - Commit all changes in a single commit after the final verification gate passes
 
-### What you NEVER do
-
+**What you NEVER do:**
 - Write, edit, or modify any source-code or test file directly
 - Skip a verification checkpoint
 - Proceed to the next batch when the current batch has not passed verification
@@ -33,196 +41,134 @@
 - Start regression tests before all fixes in scope are verified
 - Defer any REPORT.md issue to a future round — every issue has a complete plan here
 
----
+### Boundaries
+
+**ALWAYS**
+- Run gate verification immediately after every batch
+- Extract worker prompts verbatim from `fix/*.md` files — do not rewrite them
+- After a worker reports, digest the results before deciding next steps
+- Fixes must not conflict with the original spec requirements
+- Regression tests must not start before all fix batches pass
+- Resolve merge conflicts yourself — the coordinator handles them
+- For fixes marked as Complex: ensure the worker performs systematic debugging (reading related code, tracing execution paths) before applying the fix
+- After each batch completes, clean up any temporary branches or worktrees created by workers
 
-## 2. Mission
+**ASK FIRST** — pause and confirm with the user:
+- Fix approach conflicts with spec design intent
+- Need to add a new external dependency
+- Worker has failed twice
+- Test regression cannot be quickly diagnosed
 
-[One paragraph summarizing the scope, total issues, regression test count, and overall execution strategy.]
+**NEVER**
+- Write implementation logic or modify source code beyond resolving merge conflict markers
+- Let workers spawn sub-workers
+- Skip verification and proceed to the next batch
+- Modify spec documents (unless the fix reveals a spec error — report it instead)
+- Start regression tests before all fixes are verified
+- Defer any REPORT.md issue to a future round
 
-**Success looks like**: All issues in REPORT.md are fixed, all regression tests pass, full test suite passes, no regressions.
+### Error Recovery
+
+| Scenario | Response |
+|---|---|
+| Fix worker reports failure | Retry with the worker's existing context (do not create a new one), giving more specific guidance. At most one retry. |
+| Same fix worker fails twice | Pause the entire flow. Preserve successful results from other workers in the same batch. Report to the user. |
+| Regression test worker reports failure (test cannot pass) | Check whether the test code is wrong or the fix is incomplete. If test code is wrong, continue the worker to fix it. If the fix is incomplete, go back to the corresponding fix worker. |
+| Regression test passes on the unfixed code | The test design is invalid — redesign the oracle and dispatch a new worker. |
+| Merge conflicts | Coordinator resolves the conflict, then re-runs the batch gate verification. |
+| Fix or regression test breaks existing tests | Pause. Report which test failed and which worker's change caused it. |
 
 ---
 
-## 3. Issue Inventory
+## 2. Context
 
-- FIX-01 (P0, 簡單, 幻覺代碼): [Brief description] — src/a.ts
-- FIX-02 (P0, 複雜, 實作遺漏): [Brief description] — src/b.ts, src/c.ts
-- FIX-03 (P1, 簡單, 架構瑕疵): [Brief description] — src/d.ts
+[P2: What the agent needs to read before it starts working.]
 
----
+### Issue Inventory
 
-## 4. Fix Dependency Analysis
+- FIX-01 (P0, Simple): [Brief description] — src/a.ts
+- FIX-02 (P0, Complex): [Brief description] — src/b.ts, src/c.ts
+- FIX-03 (P1, Simple): [Brief description] — src/d.ts
 
-### Dependencies
+[All REPORT.md issues (P0–P3) listed here. The "no-defer" rule applies — every issue has a complete fix plan.]
 
+### Fix Dependency Analysis
+
+**Dependencies:**
 - FIX-02 depends on FIX-01 (FIX-01 refactors the interface FIX-02 needs)
 - FIX-03 is independent
 - All REGTESTs depend on their corresponding FIX completing first
 
-### File overlaps
-
+**File overlaps:**
 - FIX-04, FIX-05 both modify `src/e.ts` → must be sequential
-- FIX-01, FIX-03: no overlap → can run in parallel
+- FIX-01, FIX-03: no overlap, no logical dependency → can run in parallel
 
----
-
-## 5. Fix Details (with Regression Test Design)
+### Fix Details (with Regression Test Design)
 
 [Each issue's fix information + corresponding regression test design.]
 
-### FIX-01: [Issue title] (P0)
+#### FIX-01: [Issue title] (P0)
 
 **Root cause**: [Root cause of the issue]
 **Files involved**: `[path]` > `[functionName()]` (L[N]-[N])
 **Fix approach**: [How to modify]
 **Complexity**: Simple
 
-**Regression test:** REGTEST-01 ([Unit test / Integration test / E2E] → `[test/file/path.test.ts]`)
+**Regression test:** REGTEST-01 ([Unit test] → `[test/file/path.test.ts]`)
 - GIVEN [precondition] WHEN [trigger] THEN [expected result]
-- Oracle: This test must fail on the unfixed code and pass after the fix is applied
+- Oracle: Must fail on unfixed code, pass after fix
 
----
+#### FIX-02: [Issue title] (P0)
 
-### FIX-02: [Issue title] (P0)
-
-**Root cause**: [Root cause]
+**Root cause**: [Root cause of the issue]
 **Files involved**: `[path]` > `[functionName()]` (L[N]-[N])
 **Fix approach**: [How to modify]
 **Complexity**: Complex — needs systematic debug
 
 **Regression test:** REGTEST-02 ([Integration test] → `[test/file/path.test.ts]`)
 - GIVEN [precondition] WHEN [trigger] THEN [expected result]
-- Oracle: [pass condition]
-
----
-
-[Repeat the above block for each issue. If an issue cannot be automatically tested (e.g., visual-only), note manual verification steps in the regression test.]
-
----
-
-## 6. Worker Prompt Library
-
-### Fix Worker Prompts
-
-[Each dispatchable fix task has a pre-written self-contained worker prompt.]
-
-#### FIX-01: [Issue title]
-
-```
-## Mission
-[Brief description: what to fix and why.]
-
-## Context
-- Review dimension: [Hallucinated code / Omission / Deviation / Architecture / Performance / Redundancy]
-- Spec requirement: [Related SPEC requirement]
-
-## Input
-- Read the following files: [list]
-
-## What to do
-1. [Specify the exact file path, the function or line range, and what specific change to make (add/delete/modify). Example: "In src/auth/login.ts, function validateToken() (line 42-58): add a null check for the token parameter before calling decode()."]
-2. [Repeat for each file — never leave the change description vague]
-
-## Scope
-- Allowed files:
-  - `[path]` — [explanation]
-- Forbidden files:
-  - `[path]` — (belongs to another worker)
-
-## Output
-On completion, report:
-- Which files were modified (absolute paths)
-- Change summary for each file
-- Test results (pass/fail)
-- Any blockers or risks encountered
-
-## Verify
-- Run: `[command]`
-- Expected: [what you should see]
+- Oracle: Must fail on unfixed code, pass after fix
 
-## Boundaries
-- Do not modify any file in the forbidden list
-- Fix must not conflict with the original spec requirements
-- Preserve existing test behavior semantics (unless the spec explicitly requires a change)
-- Do not write regression tests — that is handled by another worker
-- If you encounter an unexpected blocker, stop and report — do not invent alternative approaches
-```
+[Repeat the above block for each issue. If an issue cannot be automatically tested (e.g., visual-only), note manual verification steps in the regression test field.]
 
 ---
 
-[Repeat the above block for each fix worker. Multiple simple fixes with no overlap can be merged into one worker prompt by combining their What to do sections.]
+## 3. Execution Plan
 
-### Regression Test Worker Prompts
+[P3: Batch tasks — which workers to dispatch in each batch, per-batch verification gates.]
 
-[Each regression test has a pre-written self-contained worker prompt. The regression test worker's task is to **write test code**.]
+### Worker Prompt Index
 
-#### REGTEST-01: [Test name] (related to FIX-01)
+[Each dispatchable fix and regression test has a pre-written self-contained worker prompt in a separate file under `fix/`. The coordinator reads the corresponding file and dispatches it without modification.]
 
-```
-## Mission
-Create a regression test for FIX-01 ([brief description]). This test ensures the issue never reappears.
+**Fix Worker Prompts:**
 
-## Context
-- Fix summary: [What FIX-01 fixed]
-- Root cause: [Root cause explanation]
-- Fix files involved: [list]
+| Fix ID | Worker Prompt File | Description |
+|---|---|---|
+| FIX-01 | `fix/FIX-01-[name].md` | [Brief description] |
+| FIX-02 | `fix/FIX-02-[name].md` | [Brief description] |
 
-## Input
-- Read fix-related files: [list]
-- Read existing test files as format reference: `[existing test path]`
+**Regression Test Worker Prompts:**
 
-## What to do
-Create a regression test at `[test location]`:
+| Test ID | Worker Prompt File | Related Fix | Description |
+|---|---|---|---|
+| REGTEST-01 | `fix/REGTEST-01-[name].md` | FIX-01 | [Brief description] |
+| REGTEST-02 | `fix/REGTEST-02-[name].md` | FIX-02 | [Brief description] |
 
-Test scenario:
-- GIVEN [specific precondition and input]
-- WHEN [specific trigger]
-- THEN [expected output or behavior]
+### Batch Schedule
 
-Oracle: This test must fail on the unfixed code and pass after the fix is applied.
+*Tasks within the same batch have no file overlap and no logical dependency — they may be dispatched in parallel.*
 
-## Scope
-- Allowed files:
-  - `[test file path]` — create/modify regression test
-- Forbidden files:
-  - All non-test source files (fixes are handled by another worker)
-
-## Output
-On completion, report:
-- The test file and test function name
-- Test execution result (must pass)
-- If the test cannot pass, explain why (may indicate an incomplete fix)
-
-## Verify
-- Run: `[test command]`
-- Expected: REGTEST-01 passes
-
-## Boundaries
-- Do not modify any source code files
-- The test must be independently executable, not dependent on external state
-- Follow the existing test file's formatting and naming conventions
-```
-
----
-
-[Repeat the above block for each regression test worker. Multiple regressions in the same file can be merged into one worker prompt.]
-
----
-
-## 7. Fix Batch Schedule
-
-### Batch 1 — Independent P0 Fixes
+#### Batch 1 — Independent P0 Fixes
 
 - **Issues**: FIX-01, FIX-03
-- **Strategy**: Dispatch 2 workers in parallel
+- **Strategy**: Parallel
 - **Gate**:
   - [ ] FIX-01 worker reports success
   - [ ] FIX-03 worker reports success
-  - [ ] Run verification: `[command]`
+  - [ ] Verification: `[command]` → [expected result]
 
----
-
-### Batch 2 — Dependent Fixes
+#### Batch 2 — Dependent Fixes
 
 - **Issues**: FIX-02 → FIX-04 → FIX-05
 - **Strategy**: Sequential (file overlap or logical dependency)
@@ -231,26 +177,25 @@ On completion, report:
   - [ ] FIX-02 worker reports success
   - [ ] FIX-04 worker reports success
   - [ ] FIX-05 worker reports success
-  - [ ] Run verification: `[command]`
-
----
+  - [ ] Verification: `[command]` → [expected result]
 
-### Batch N — Regression Test Implementation
+#### Batch 3 — Regression Test Implementation
 
-- **Tasks**: REGTEST-01, REGTEST-02, REGTEST-03, REGTEST-04, REGTEST-05
-- **Strategy**: Parallel dispatch (no file overlap = full parallel; overlap = sub-batches)
+- **Tasks**: REGTEST-01, REGTEST-02, REGTEST-03
+- **Strategy**: Parallel (no file overlap = full parallel; overlap = sub-batches)
 - **Depends on**: All fix batches completed
 - **Gate**:
   - [ ] All REGTEST workers report success
   - [ ] All new regression tests pass
+  - [ ] Logical check: each REGTEST oracle must be "fails on unfixed code, passes after fix" — if a test also passes on unfixed code, it is not a valid regression test
   - [ ] Existing test suite passes (confirm no regression)
 
----
+> If property-based testing is required by the original CHECKLIST.md, implement it alongside the regression tests listed here. Property-based tests serve as additional hardening for business-logic changes.
 
-### Batch Final — Integration
+#### Batch 4 — Final Integration
 
-- **Tasks**: Final test suite, lint, cross-check REPORT.md
-- **Strategy**: Sequential (coordinator handles directly or dispatches a single worker)
+- **Tasks**: Full test suite, lint, cross-check REPORT.md
+- **Strategy**: Sequential
 - **Depends on**: All preceding batches
 - **Gate**:
   - [ ] Full test suite passes: `[command]`
@@ -259,90 +204,32 @@ On completion, report:
 
 ---
 
-## 8. Regression Test Inventory
-
-If property-based testing is required by the original CHECKLIST.md, implement it alongside the regression tests listed here. Property-based tests serve as additional hardening for business-logic changes.
-
-- REGTEST-01 → FIX-01: [Unit] [test/unit/foo.test.ts] — GIVEN X WHEN Y THEN Z
-- REGTEST-02 → FIX-02: [Integration] [test/integration/bar.test.ts] — GIVEN A WHEN B THEN C
-- REGTEST-03 → FIX-03: [Unit] [test/unit/baz.test.ts] — GIVEN P WHEN Q THEN R
-
-If there are no entries here, see Section 5 for each fix's regression test design.
-
----
-
-## 9. Verification Checkpoints
-
-### Checkpoint 1 — After fix batches complete (before regression tests)
-- Run: `[command]`
-- Expected: All existing tests pass, all fixes confirmed
-
-### Checkpoint 2 — After regression tests are implemented
-- Run: `[command]`
-- Expected: All new regression tests pass, confirming each fix is effective
-- Logical check: Each REGTEST oracle must be "fails on unfixed code, passes after fix" — if a test also passes on the unfixed code, it is not a valid regression test
-
-### Checkpoint 3 — Final verification
-- Run full test suite: `[command]`
-- Confirm lint passes
-- Cross-check REPORT.md: every issue resolved
-
----
+## 4. Final Verification
 
-## 10. Error Recovery
+[P4: Meta-checks after all batches complete. These verify completeness beyond what per-batch gates already cover.]
 
-- **If a fix worker fails**: Retry with the worker's existing context (do not create a new one), giving more specific guidance. At most one retry.
-- **If a fix worker fails twice**: Pause the entire flow. Preserve successful results from other workers in the same batch. Report to the user.
-- **If a regression test worker reports failure (test cannot pass)**: Check whether the test code is wrong or the fix is incomplete. If the test code is wrong, continue the worker to fix it. If the fix is incomplete, go back to the corresponding fix worker.
-- **If a regression test passes on the unfixed code**: The test design is invalid — redesign the oracle and dispatch a new worker.
-- **If merge conflicts occur**: The coordinator resolves the conflict, then re-runs the batch gate verification.
-- **If a fix or regression test breaks existing tests**: Pause. Report which test failed and which worker's change caused it.
+- [ ] Every issue in REPORT.md (P0–P3) has a completed fix
+- [ ] Every fix has a regression test that passes
+- [ ] All worker prompts in Section 3 have been dispatched and returned success
+- [ ] Full test suite passes with no regressions
+- [ ] All changes committed in a single commit
 
 ---
 
-## 11. Fix History
+## 5. References
 
-<!--
-### Round N — [YYYY-MM-DD]
-- **Issues fixed**: FIX-01, FIX-02, ... (P0:X, P1:X, P2:X, P3:X)
-- **Outcome**: [All resolved / Partial — X issues remaining]
-- **Key notes**: [1-2 sentence summary of important decisions or residual risks]
--->
+[P5: Reference files for coordinator and workers.]
 
----
-
-## 12. References
-
-- **Project context files**: [List important project files the fix coordinator and workers may need — e.g., `CLAUDE.md`, `AGENTS.md`, `resources/project-architecture/**`, codegraph index files]
-- **Related documents**: [Links to REPORT.md, SPEC.md, DESIGN.md, or external documentation]
-
----
-
-## 13. Boundaries
-
-### ALWAYS
-
-- Run gate verification immediately after every batch
-- Extract worker prompts verbatim from Section 6 — do not rewrite them
-- After a worker reports, digest the results before deciding next steps
-- Fixes must not conflict with the original spec requirements
-- Regression tests must not start before all fix batches pass
-- Resolve merge conflicts yourself — the coordinator handles them. This is coordination, not implementation.
-- **For fixes marked as Complex**: ensure the worker performs systematic debugging (reading related code, tracing execution paths) before applying the fix. Do not let the worker guess the fix.
-- **After each batch completes, clean up any temporary branches or worktrees created by workers** — no ephemeral worktree should be left orphaned.
-
-### ASK FIRST — pause and confirm with the user
-
-- Fix approach conflicts with spec design intent
-- Need to add a new external dependency
-- Worker has failed twice
-- Test regression cannot be quickly diagnosed
-
-### NEVER
-
-- Write implementation logic or modify source code beyond resolving merge conflict markers
-- Let workers spawn sub-workers
-- Skip verification and proceed to the next batch
-- Modify spec documents (unless the fix reveals a spec error — report it instead)
-- Start regression tests before all fixes are verified
-- **Defer any REPORT.md issue to a future round** — every issue has a complete fix plan in this FIX.md
+- **Worker prompt files**: [List all `fix/*.md` files — e.g., `fix/FIX-01-*.md`, `fix/REGTEST-01-*.md`]
+- **Code files to modify** (across all fixes and regression tests):
+  - [File path — e.g., `src/auth/login.ts`]
+  - [File path — e.g., `src/auth/logout.ts`]
+- **Project context files**: [List project context files the fix coordinator may need — e.g., CLAUDE.md, AGENTS.md, project architecture files]
+- **Related documents**: [Paths to source documents — e.g., the paths to REPORT.md, SPEC.md, and DESIGN.md for this spec]
+- **Fix History**:
+  <!--
+  ### Round N — [YYYY-MM-DD]
+  - **Issues fixed**: FIX-01, FIX-02, ... (P0:X, P1:X, P2:X, P3:X)
+  - **Outcome**: [All resolved / Partial — X issues remaining]
+  - **Key notes**: [1-2 sentence summary of important decisions or residual risks]
+  -->

package/skills/qa/assets/templates/FIX_WORKER.md

@@ -0,0 +1,96 @@
+# Fix Worker Prompt: FIX-{sequence}-{kebab-case-name}
+
+- **Related issue**: [FIX ID from coordinator — e.g., FIX-01]
+
+---
+
+## 1. Mission & Rules
+
+[P1: Goal of this fix and behavioral rules.]
+
+### Mission
+
+[One sentence — which issue to fix and why.]
+
+### Context
+
+[Which review dimension flagged this issue, which spec requirement it relates to.]
+
+### Rules
+
+- Follow the Scope in Section 5 — only modify files listed as Allowed
+- Preserve existing test semantics — do not weaken, skip, or remove existing tests
+- If the fix approach conflicts with the original spec design intent, pause and report to the coordinator
+- Do not add new dependencies without reporting to the coordinator first
+- Workers are leaf nodes — do not spawn sub-workers
+
+---
+
+## 2. Context
+
+[P2: Files to read before starting, root cause analysis.]
+
+### Input Files
+
+- [File path] — [what to read from it]
+- [File path] — [what to read from it]
+
+### Root Cause
+
+[Brief description of the root cause, determined during QA analysis.]
+
+---
+
+## 3. Tasks
+
+[P3: Concrete fix steps. Each entry specifies the exact file path, function or line range, and what to add/delete/modify.]
+
+### [File path] — [what to fix]
+
+1. Open `[file path]`
+2. Locate `[function / class / line range]`
+3. [Add / Modify / Delete] the following:
+   - **Before** (current code): [current code or description]
+   - **After** (fixed code): [new code or description]
+4. [Additional step if needed]
+
+[Repeat for each file or logical change group.]
+
+### Output
+
+When done, report back to the coordinator:
+- **Files modified**: [list of files]
+- **Change summary**: [brief description]
+- **Test results**: [pass/fail]
+- **Risks or concerns**: [or "None"]
+
+---
+
+## 4. Verification
+
+[P4: How to confirm the fix works correctly.]
+
+1. Run: `[command]`
+   - Expected: [result]
+2. Run: `[command]`
+   - Expected: [result]
+
+---
+
+## 5. Scope & References
+
+[P5: Allowed/forbidden files and related reference files.]
+
+### Allowed Files
+
+- [file path] — [reason]
+- [file path] — [reason]
+
+### Forbidden Files
+
+- [file path] — [reason, e.g., "owned by another fix worker"]
+- [file path] — [reason]
+
+### Related Documents
+
+- [path to SPEC.md, DESIGN.md, or relevant files]

package/skills/qa/assets/templates/REGTEST_WORKER.md

@@ -0,0 +1,98 @@
+# Regression Test Worker Prompt: REGTEST-{sequence}-{kebab-case-name}
+
+- **Related fix**: FIX-{sequence} — [fix title]
+
+---
+
+## 1. Mission & Rules
+
+[P1: Goal of this regression test and behavioral rules.]
+
+### Mission
+
+[Which fix needs a regression test and why.]
+
+### Context
+
+[What the fix addressed — summary, root cause.]
+
+### Rules
+
+- Only create or modify test files — never modify source code
+- The test must fail on the unfixed code and pass after the fix is applied — this is the core oracle
+- Follow the existing test patterns and style of the reference test files
+- If the test cannot be designed to fail before the fix, report to the coordinator — do not write a weak test
+- Workers are leaf nodes — do not spawn sub-workers
+
+---
+
+## 2. Context
+
+[P2: Files to read before starting, test design.]
+
+### Input Files
+
+- Fix-related files: [path to the fixed code — understand what was changed]
+- Existing test files (as format reference): [path — follow the same style and patterns]
+
+### Test Design
+
+- **Test ID**: REGTEST-{sequence}
+- **Type**: [Unit / Integration / E2E]
+- **Location**: [file path where the test will be written]
+- **Scenario**: GIVEN [precondition] WHEN [trigger] THEN [expected result]
+- **Oracle**: Must fail on unfixed code, must pass after fix
+
+---
+
+## 3. Tasks
+
+[P3: Concrete steps for writing the regression test.]
+
+1. Create the test at `[test file path]`
+   - Write the test according to the Test Design above
+   - Follow the format and naming conventions of [reference test file]
+2. Run the test on the unfixed code — confirm it fails
+3. [If the fix is already applied: temporarily revert the fix, run the test to confirm failure, then restore the fix]
+4. [Additional steps if needed]
+
+### Output
+
+When done, report back to the coordinator:
+- **Test file**: [path]
+- **Test name**: [test name or description]
+- **Oracle confirmed**: [test fails before fix / test passes after fix]
+- **Risks or concerns**: [or "None"]
+
+---
+
+## 4. Verification
+
+[P4: How to verify the regression test is valid.]
+
+1. Run: `[test command for the specific test]` before the fix is applied
+   - Expected: Test fails (confirming the oracle detects the bug)
+2. Run: `[test command for the specific test]` after the fix is applied
+   - Expected: Test passes (proving the fix resolves the issue)
+3. Run: `[relevant subset of the full test suite]`
+   - Expected: All tests pass (no regression to other tests)
+
+---
+
+## 5. Scope & References
+
+[P5: Allowed/forbidden files and related references.]
+
+### Allowed Files
+
+- [test file path] — write the regression test here
+- [reference test file] — use as format reference
+
+### Forbidden Files
+
+- All source code files (`.ts`, `.js`, `.py`, etc.) — the regression test worker must not modify source code
+
+### Related Documents
+
+- [path to FIX_WORKER prompt for the related fix — understand what was fixed]
+- [path to SPEC.md or DESIGN.md — understand the expected behavior]