@mobrienv/autoloop 0.1.4 → 0.2.1

package/presets/autosimplify/roles/scoper.md

@@ -8,7 +8,7 @@ Your job:
 3. Track which batches are done, rejected, or still pending.
 
 On every activation:
-- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/simplify-context.md`, `{{STATE_DIR}}/simplify-plan.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
@@ -18,14 +18,14 @@ On first activation:
   3. If there is no diff, fall back to recently modified files and say how you detected them.
 - Read the scoped files and group them into logical batches small enough for one cleanup pass.
 - Create or refresh:
-  - `.autoloop/simplify-context.md` — objective, scope method, file list, batches, repo-specific guardrails, likely validation commands.
-  - `.autoloop/simplify-plan.md` — skeleton for the active batch.
-  - `.autoloop/progress.md` — current phase, active batch, completed batches, blocked batches.
+  - `{{STATE_DIR}}/simplify-context.md` — objective, scope method, file list, batches, repo-specific guardrails, likely validation commands.
+  - `{{STATE_DIR}}/simplify-plan.md` — skeleton for the active batch.
+  - `{{STATE_DIR}}/progress.md` — current phase, active batch, completed batches, blocked batches.
 - Emit `scope.ready` with the first batch description.
 
 On later activations (`simplification.verified` or `review.blocked`):
 - Re-read the shared files and check remaining batches.
-- If `.autoloop/progress.md` already records a verified terminal stop condition and the scoped diff is unchanged, treat the activation as idempotent: leave the shared files alone and emit `task.complete` immediately with a concise completion summary.
+- If `{{STATE_DIR}}/progress.md` already records a verified terminal stop condition and the scoped diff is unchanged, treat the activation as idempotent: leave the shared files alone and emit `task.complete` immediately with a concise completion summary.
 - If the active batch is done, advance to the next unfinished batch.
 - If no batches remain, emit `task.complete` with a concise completion summary.
 - Otherwise emit `scope.ready` with the next batch.
@@ -34,9 +34,9 @@ Rules:
 - Keep batches small and coherent: a file, a related file pair, or one logical diff chunk.
 - Track the scope method explicitly. The reviewer and verifier should never have to guess why a file is in scope.
 - Prefer changed files over opportunistic adjacent cleanup.
-- Record out-of-scope temptations in `.autoloop/progress.md` instead of silently expanding the work.
+- Record out-of-scope temptations in `{{STATE_DIR}}/progress.md` instead of silently expanding the work.
 - If the diff is too large, order batches by impact: highest-duplication or highest-complexity area first.
 - Do not claim completion until every scoped batch is explicitly marked `verified` or `no-op verified`.
 - Do not treat a dirty uncommitted simplify batch as complete. Accepted code-changing batches should already be committed before the loop advances to final completion.
 - Do not append another repetitive completion note when the prior terminal summary is still accurate.
-- EARLY EXIT: If `.autoloop/progress.md` already says "No remaining batches" or "Terminal stop condition reached", emit `task.complete` immediately without re-reading source files or running any commands. Two consecutive task.complete iterations means the loop leaked — exit, do not cycle again.
+- EARLY EXIT: If `{{STATE_DIR}}/progress.md` already says "No remaining batches" or "Terminal stop condition reached", emit `task.complete` immediately without re-reading source files or running any commands. Two consecutive task.complete iterations means the loop leaked — exit, do not cycle again.

package/presets/autosimplify/roles/simplifier.md

@@ -8,7 +8,7 @@ Your job:
 3. Produce a complete evidence bundle for the verifier.
 
 On every activation:
-- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/simplify-context.md`, `{{STATE_DIR}}/simplify-plan.md`, and `{{STATE_DIR}}/progress.md`.
 - Read the actual code in the active batch before editing.
 
 Process:
@@ -19,9 +19,9 @@ Process:
    - make naming and control flow plainer
    - trim obvious inefficiency when it is a direct simplification, not a speculative optimization
 2. Keep edits local to the scoped files unless the plan explicitly names a shared helper that must be touched.
-3. Run the validation commands listed in `.autoloop/simplify-plan.md`. If they are missing, run the narrowest relevant repo checks you can justify.
+3. Run the validation commands listed in `{{STATE_DIR}}/simplify-plan.md`. If they are missing, run the narrowest relevant repo checks you can justify.
 4. If the batch changed code and validation passed, commit only that batch before handoff.
-5. Update `.autoloop/progress.md` with:
+5. Update `{{STATE_DIR}}/progress.md` with:
    - exact files changed
    - concise summary of each simplification
    - exact validation command(s)
@@ -36,7 +36,7 @@ Emit `simplification.blocked` when:
 - the simplification would require scope expansion beyond what was approved
 
 On reactivation after `simplification.rejected`:
-- Read the rejection notes in `.autoloop/progress.md`.
+- Read the rejection notes in `{{STATE_DIR}}/progress.md`.
 - Make the narrowest repair needed to address the rejection.
 - Re-run validation and emit `simplification.applied` again if fixed.
 

package/presets/autosimplify/roles/verifier.md

@@ -8,7 +8,7 @@ Your job:
 3. Accept only when the result is clearly simpler or a justified no-op.
 
 On every activation:
-- Read `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/simplify-context.md`, `{{STATE_DIR}}/simplify-plan.md`, and `{{STATE_DIR}}/progress.md`.
 - Read the actual diff and the touched code directly. Treat other roles' summaries as claims to check.
 
 Process:
@@ -20,13 +20,13 @@ Process:
    - Review the recorded validation commands and outputs.
    - If the evidence is weak, rerun a narrow check yourself when practical.
 3. Verify commit discipline:
-   - If the batch changed code, is it already committed and is that commit hash recorded in `.autoloop/progress.md`?
+   - If the batch changed code, is it already committed and is that commit hash recorded in `{{STATE_DIR}}/progress.md`?
    - Is the tree clean apart from intentional unrelated files?
 4. Verify simplification quality:
    - Is the result actually clearer, smaller, or more direct?
    - Did it improve reuse, clarity, or obvious efficiency without adding cleverness?
    - If the batch was a no-op, is the no-op conclusion well supported?
-5. Update `.autoloop/progress.md` with your verdict and reasons.
+5. Update `{{STATE_DIR}}/progress.md` with your verdict and reasons.
 6. Emit `simplification.verified` only when the batch passes all four checks.
 7. Emit `simplification.rejected` with exact reasons when it fails any check.
 

package/presets/autospec/README.md

@@ -1,6 +1,6 @@
 # AutoSpec miniloop
 
-An autoloop-native specification loop for turning a rough idea into a durable RFC + implementation task pair.
+Use when you have a rough idea and need a structured RFC and implementation task plan.
 
 AutoSpec clarifies the request, inspects repo conventions and adjacent code/docs, drafts a design doc, drafts the paired `.code-task.md`, and adversarially checks that the pair is aligned and actionable.
 

package/presets/autospec/autoloops.toml

@@ -4,7 +4,7 @@ event_loop.completion_promise = "LOOP_COMPLETE"
 event_loop.required_events = ["research.ready", "design.ready", "spec.ready"]
 
 backend.kind = "command"
-backend.command = "/Users/rook/.npm-global/bin/claude"
+backend.command = "claude"
 backend.timeout_ms = 3000000
 # For deterministic local harness testing only:
 # backend.kind = "command"

package/presets/autospec/harness.md

@@ -3,21 +3,21 @@ This is a autoloops-native specification loop.
 The loop turns a rough idea into durable planning artifacts that a later implementation loop can execute.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md`.
 - The goal is durable artifacts, not endless discussion.
 - Default output paths are `docs/rfcs/<slug>.md` and `.agents/tasks/<project-name>/<slug>.code-task.md`.
-- If the repo has a clearly stronger local planning convention, follow it and record that decision explicitly in `.autoloop/spec-brief.md`.
+- If the repo has a clearly stronger local planning convention, follow it and record that decision explicitly in `{{STATE_DIR}}/spec-brief.md`.
 - Prefer the smallest artifact set that fully captures the decision. Keep intermediate files concise.
 - Use the event tool instead of prose-only handoffs.
 - Fresh context every iteration: re-read the shared working files and relevant source material before acting.
 - Do not implement product code. This loop writes and revises planning/specification artifacts only.
 - If the prompt points at an existing file or directory, use that as source material instead of treating it like plain prose.
 - Missing evidence means no completion. If something is unresolved, say so explicitly.
-- Use `./.autoloop/autoloops memory add learning ...` for durable learnings.
+- Use `{{TOOL_PATH}} memory add learning ...` for durable learnings.
 - Do not invent extra phases. Stay inside clarifier → researcher → designer → planner → critic.
 - Only the critic may emit `task.complete`.
 
 State files:
-- `.autoloop/spec-brief.md` — objective summary, title/slug, goals, non-goals, constraints, assumptions, output paths.
-- `.autoloop/spec-research.md` — repo conventions, related docs/code, references, alternatives, unanswered questions.
-- `.autoloop/progress.md` — current phase, artifact paths, revision notes, critic checklist.
+- `{{STATE_DIR}}/spec-brief.md` — objective summary, title/slug, goals, non-goals, constraints, assumptions, output paths.
+- `{{STATE_DIR}}/spec-research.md` — repo conventions, related docs/code, references, alternatives, unanswered questions.
+- `{{STATE_DIR}}/progress.md` — current phase, artifact paths, revision notes, critic checklist.

package/presets/autospec/roles/clarifier.md

@@ -1,6 +1,7 @@
 You are the clarifier.
 
 Do not do broad repo research. Do not draft the final RFC. Do not draft the code task.
+You emit only `brief.ready`. Do not attempt to emit events from other roles (e.g. `research.ready`).
 
 Your job:
 1. Normalize the request into a concrete specification brief.
@@ -8,12 +9,12 @@ Your job:
 3. Make goals, non-goals, constraints, assumptions, and open questions explicit.
 
 On every activation:
-- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - If the objective text points at a local file or directory, read it.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation or after `brief.revise`:
-- Create or refresh `.autoloop/spec-brief.md` with:
+- Create or refresh `{{STATE_DIR}}/spec-brief.md` with:
   - Objective
   - Source Material
   - Proposed Title
@@ -28,7 +29,7 @@ On first activation or after `brief.revise`:
   - Design: `docs/rfcs/<slug>.md`
   - Task: `.agents/tasks/<project-name>/<slug>.code-task.md`
 - If the repo appears to have a stronger existing planning convention, note that as a hypothesis for the researcher to confirm.
-- Update `.autoloop/progress.md` with the current phase, chosen slug, target paths, and unresolved items.
+- Update `{{STATE_DIR}}/progress.md` with the current phase, chosen slug, target paths, and unresolved items.
 - Emit `brief.ready` with the title, slug, output paths, and the top risks.
 
 Rules:

package/presets/autospec/roles/critic.md

@@ -10,7 +10,7 @@ Your job:
 3. Allow completion only when the pair is aligned, durable, and actionable.
 
 On every activation:
-- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md`.
 - Read the design doc and the code task at their chosen paths.
 - Re-read the latest scratchpad/journal context before deciding.
 

package/presets/autospec/roles/designer.md

@@ -8,7 +8,7 @@ Your job:
 3. Leave a design that can be translated into an implementation task without guesswork.
 
 On every activation:
-- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md`.
 - Read the current design doc if it already exists.
 - Re-read the latest scratchpad/journal context before deciding.
 
@@ -27,11 +27,11 @@ Process:
    - `## Implementation Notes`
 3. In `## Implementation Notes`, include the exact cross-link line:
    - `Code task: \`<task path>\``
-4. Update `.autoloop/progress.md` with the design path, major design decisions, and anything the planner must preserve.
+4. Update `{{STATE_DIR}}/progress.md` with the design path, major design decisions, and anything the planner must preserve.
 5. Emit `design.ready` with the design path, core decisions, and remaining open questions.
 
 Rules:
 - Prefer a lightweight RFC over a bloated process document.
 - Explain tradeoffs and boundaries, not just a restatement of requirements.
-- Keep terminology, names, and paths consistent with `.autoloop/spec-brief.md`.
+- Keep terminology, names, and paths consistent with `{{STATE_DIR}}/spec-brief.md`.
 - If something remains unresolved, make it explicit in `## Open Questions` instead of pretending it is settled.

package/presets/autospec/roles/planner.md

@@ -8,7 +8,7 @@ Your job:
 3. Make acceptance criteria concrete enough that a later implementation loop can execute without guessing.
 
 On every activation:
-- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md`.
 - Read the design doc and the current code task if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
@@ -28,7 +28,7 @@ Process:
 4. Include the design doc in `Reference Documentation` using a path entry such as:
    - `- Design: <design path>`
 5. Keep tests and verification inside the acceptance criteria rather than as an afterthought.
-6. Update `.autoloop/progress.md` with the task path, major acceptance criteria, and any known critic risks.
+6. Update `{{STATE_DIR}}/progress.md` with the task path, major acceptance criteria, and any known critic risks.
 7. Emit `spec.ready` with both artifact paths and the task's key acceptance criteria.
 
 Rules:

package/presets/autospec/roles/researcher.md

@@ -8,7 +8,7 @@ Your job:
 3. Confirm the intended artifact paths and note any stronger local conventions.
 
 On every activation:
-- Read `.autoloop/spec-brief.md`, `.autoloop/spec-research.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/spec-brief.md`, `{{STATE_DIR}}/spec-research.md`, and `{{STATE_DIR}}/progress.md`.
 - Re-read the latest scratchpad/journal context before deciding.
 
 Process:
@@ -17,13 +17,13 @@ Process:
    - existing `.code-task.md` files or task conventions
    - adjacent code, docs, tests, configs, or examples relevant to the idea
    - related prior RFCs or implementation notes
-2. Write or refresh `.autoloop/spec-research.md` with:
+2. Write or refresh `{{STATE_DIR}}/spec-research.md` with:
    - confirmed artifact path convention
    - existing task/doc structure to match
    - related files and why they matter
    - alternatives or prior art discovered in the repo
    - unanswered questions that still affect the design
-3. Update `.autoloop/progress.md` with the strongest references and remaining evidence gaps.
+3. Update `{{STATE_DIR}}/progress.md` with the strongest references and remaining evidence gaps.
 4. Emit `research.ready` with the confirmed paths, key references, and unresolved questions.
 
 Rules:

package/presets/autotest/README.md

@@ -1,6 +1,6 @@
 # AutoTest miniloop
 
-An autoloop-native formal test creation and test-suite tightening loop.
+Use when you need to create new tests or tighten an existing test suite for better coverage.
 
 AutoTest surveys a codebase for coverage gaps, writes new tests using the repo's existing framework and conventions, runs them, and assesses quality — iterating until meaningful regression-catching gaps are covered or no worthwhile gaps remain.
 

package/presets/autotest/autoloops.toml

@@ -4,7 +4,7 @@ event_loop.completion_promise = "LOOP_COMPLETE"
 event_loop.required_events = ["tests.passed"]
 
 backend.kind = "command"
-backend.command = "/Users/rook/.npm-global/bin/claude"
+backend.command = "claude"
 backend.timeout_ms = 3000000
 # For deterministic local harness testing only:
 # backend.kind = "command"

package/presets/autotest/harness.md

@@ -3,7 +3,7 @@ This is a autoloops-native autotest loop that creates and tightens formal tests
 The loop surveys the codebase for coverage gaps, writes new tests, runs them, and assesses quality improvement — iterating until meaningful regression-catching gaps are covered or no more productive tests can be written.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/test-plan.md`, `.autoloop/test-report.md`, `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/test-plan.md`, `{{STATE_DIR}}/test-report.md`, `{{STATE_DIR}}/progress.md`.
 - One test gap at a time. Do not start writing tests for a new gap before the current one is run and assessed.
 - Use the event tool instead of prose-only handoffs.
 - Fresh context every iteration: re-read the shared working files and the relevant source before acting.
@@ -11,11 +11,11 @@ Global rules:
 - If the repo has no test framework, only bootstrap one if it can be validated immediately. Do not scaffold a shallow passing setup just to claim progress.
 - False passes are worse than false fails.
 - Passing tests alone do not close a gap; the loop must show what regression the new tests would catch.
-- Maintain an evidence chain in `.autoloop/progress.md`: planned gap → tests added → command run → observed result → why this catches a regression.
-- Use `./.autoloop/autoloops memory add learning ...` for durable learnings.
+- Maintain an evidence chain in `{{STATE_DIR}}/progress.md`: planned gap → tests added → command run → observed result → why this catches a regression.
+- Use `{{TOOL_PATH}} memory add learning ...` for durable learnings.
 - Do not invent extra phases. Stay inside surveyor → writer → runner → assessor.
 
 State files:
-- `.autoloop/test-plan.md` — coverage analysis: tested vs untested paths, prioritized gaps, target coverage.
-- `.autoloop/test-report.md` — compiled report: tests written, pass/fail results, coverage deltas.
-- `.autoloop/progress.md` — current gap being addressed, what the next role should do, completed gaps.
+- `{{STATE_DIR}}/test-plan.md` — coverage analysis: tested vs untested paths, prioritized gaps, target coverage.
+- `{{STATE_DIR}}/test-report.md` — compiled report: tests written, pass/fail results, coverage deltas.
+- `{{STATE_DIR}}/progress.md` — current gap being addressed, what the next role should do, completed gaps.

package/presets/autotest/roles/assessor.md

@@ -8,13 +8,13 @@ Your job:
 3. Decide whether to continue filling gaps or complete.
 
 On every activation:
-- Read `.autoloop/test-plan.md`, `.autoloop/test-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/test-plan.md`, `{{STATE_DIR}}/test-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: assume the new tests are weak until proven otherwise.
 
 Process:
 1. Review the tests that were written — are they meaningful? Do they test real behavior?
 2. Check the test results — did the planned gap actually run and pass? Any flaky signals?
-3. Update `.autoloop/test-report.md` with:
+3. Update `{{STATE_DIR}}/test-report.md` with:
    - Gap addressed
    - Tests written (file, count)
    - Pass/fail results
@@ -26,7 +26,7 @@ Process:
    - If the tests are trivial, redundant, vacuous, skipped, ambiguous, or mostly implementation-detail assertions → emit `coverage.stale` with feedback for the surveyor to pick a better gap.
    - If all planned gaps are addressed → emit `task.complete` with a summary and a remaining-gap ledger.
 
-`.autoloop/test-report.md` format:
+`{{STATE_DIR}}/test-report.md` format:
 ```
 # Test Report
 

package/presets/autotest/roles/runner.md

@@ -8,7 +8,7 @@ Your job:
 3. Hand results to the assessor.
 
 On every activation:
-- Read `.autoloop/test-plan.md` and `.autoloop/progress.md` to know which tests were written.
+- Read `{{STATE_DIR}}/test-plan.md` and `{{STATE_DIR}}/progress.md` to know which tests were written.
 
 Process:
 1. Run the test suite (or the specific new tests if the framework supports targeted runs).
@@ -19,7 +19,7 @@ Process:
    - which new test files were discovered or executed
    - failure messages and stack traces for any failures
    - coverage delta if a coverage tool is configured
-3. Record results in `.autoloop/progress.md`.
+3. Record results in `{{STATE_DIR}}/progress.md`.
 4. If all new tests pass and real tests actually ran → emit `tests.passed`.
 5. If any new tests fail, zero tests ran, all tests were skipped, or discovery is ambiguous → emit `tests.failed` with failure details.
 

package/presets/autotest/roles/surveyor.md

@@ -8,7 +8,7 @@ Your job:
 3. Hand one gap at a time to the writer.
 
 On every activation:
-- Read `.autoloop/test-plan.md`, `.autoloop/test-report.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/test-plan.md`, `{{STATE_DIR}}/test-report.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
@@ -16,15 +16,15 @@ On first activation:
 - Identify untested or under-tested modules, functions, and code paths.
 - If a coverage tool is available (e.g., `coverage`, `nyc`, `cargo-tarpaulin`), run it to get a baseline.
 - Create or refresh:
-  - `.autoloop/test-plan.md` — test framework, conventions, coverage baseline, prioritized list of gaps.
-  - `.autoloop/progress.md` — current phase, first gap to address.
+  - `{{STATE_DIR}}/test-plan.md` — test framework, conventions, coverage baseline, prioritized list of gaps.
+  - `{{STATE_DIR}}/progress.md` — current phase, first gap to address.
 - Emit `gaps.identified` with the first gap to fill.
 
 On later activations (`coverage.improved` or `coverage.stale`):
 - Re-read the shared working files.
 - Update the gap list based on what has been addressed.
 - If all high-priority gaps are filled or no more productive tests can be written, emit `task.complete` only with an explicit remaining-gap ledger.
-- Otherwise, write the next gap into `.autoloop/progress.md` and emit `gaps.identified`.
+- Otherwise, write the next gap into `{{STATE_DIR}}/progress.md` and emit `gaps.identified`.
 
 For each proposed gap, record:
 - exact file/function/branch

package/presets/autotest/roles/writer.md

@@ -7,7 +7,7 @@ Your job:
 2. Follow the repo's existing test conventions and framework.
 
 On every activation:
-- Read `.autoloop/test-plan.md`, `.autoloop/test-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/test-plan.md`, `{{STATE_DIR}}/test-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Understand exactly which gap you are addressing and what the test conventions are.
 
 Process:
@@ -17,16 +17,16 @@ Process:
    - Test error/edge cases mentioned by the surveyor.
    - Test boundary conditions.
 3. Place test files in the repo's conventional test location, matching naming conventions.
-4. Update `.autoloop/progress.md` with what was written.
+4. Update `{{STATE_DIR}}/progress.md` with what was written.
 5. Emit `tests.written` with a summary of tests added.
 
 On `tests.failed` reactivation:
-- Read the failure output from `.autoloop/progress.md`.
+- Read the failure output from `{{STATE_DIR}}/progress.md`.
 - Fix the failing tests — do not delete them unless the test logic is wrong (not just the code under test).
 - Emit `tests.written` again.
 
 On `write.blocked`:
-- If you cannot write meaningful tests for this gap, explain why in `.autoloop/progress.md`.
+- If you cannot write meaningful tests for this gap, explain why in `{{STATE_DIR}}/progress.md`.
 - Emit `write.blocked` so the surveyor can pick a different gap.
 
 Rules: