@mobrienv/autoloop 0.1.4 → 0.2.0

package/presets/autodoc/roles/checker.md

@@ -8,7 +8,7 @@ Your job:
 3. Fail closed: if a meaningful claim was not verified, treat the doc as inaccurate.
 
 On every activation:
-- Read `.autoloop/doc-plan.md`, `.autoloop/doc-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/doc-plan.md`, `{{STATE_DIR}}/doc-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: assume the docs are wrong until you verify them.
 
 Process:
@@ -23,7 +23,7 @@ Process:
    - look for counterexamples, renamed or missing symbols, contradictory behavior, and edge cases
    - check whether examples actually match the real interfaces and paths
    - verify stated defaults, prerequisites, and limitations from code/config/tests, not from assumptions
-5. Record results in `.autoloop/progress.md`, separating:
+5. Record results in `{{STATE_DIR}}/progress.md`, separating:
    - verified claims
    - unverified claims
    - incorrect or misleading claims

package/presets/autodoc/roles/publisher.md

@@ -8,10 +8,10 @@ Your job:
 3. Decide whether more gaps need attention.
 
 On every activation:
-- Read `.autoloop/doc-plan.md`, `.autoloop/doc-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/doc-plan.md`, `{{STATE_DIR}}/doc-report.md`, and `{{STATE_DIR}}/progress.md`.
 
 Process:
-1. Update `.autoloop/doc-report.md` with the completed documentation work:
+1. Update `{{STATE_DIR}}/doc-report.md` with the completed documentation work:
    - Gap addressed
    - Files written or updated
    - Accuracy check result
@@ -20,7 +20,7 @@ Process:
    - If more gaps remain → emit `doc.published` so the auditor picks the next one.
    - If all gaps are addressed → emit `task.complete` with a summary.
 
-`.autoloop/doc-report.md` format:
+`{{STATE_DIR}}/doc-report.md` format:
 ```
 # Documentation Report
 

package/presets/autodoc/roles/writer.md

@@ -8,7 +8,7 @@ Your job:
 3. Leave a concrete verification checklist for the checker instead of making the checker reconstruct your claims from scratch.
 
 On every activation:
-- Read `.autoloop/doc-plan.md`, `.autoloop/doc-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/doc-plan.md`, `{{STATE_DIR}}/doc-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Understand exactly which gap you are addressing.
 
 Process:
@@ -17,8 +17,8 @@ Process:
 3. Write or update the documentation:
    - For new docs: create the file in the conventional location.
    - For stale docs: update only the parts that are incorrect or missing.
-4. Update `.autoloop/progress.md` with what was written.
-5. Add a `Verification checklist` section to `.autoloop/progress.md` for this gap. For every concrete claim you introduced or changed, list:
+4. Update `{{STATE_DIR}}/progress.md` with what was written.
+5. Add a `Verification checklist` section to `{{STATE_DIR}}/progress.md` for this gap. For every concrete claim you introduced or changed, list:
    - the exact claim, command, path, API name, config key, default, or example
    - where it appears in the docs
    - the code/config/test evidence the checker should verify against
@@ -33,5 +33,5 @@ Rules:
 - Do not change code. Only write documentation.
 - The verification checklist must be claim-level, not file-level. `Updated README for CLI` is too vague; list the actual claims that need checking.
 - Include copy-pasteable commands and examples in the checklist exactly as written in the docs.
-- If you removed a stale claim, note the removal in `.autoloop/progress.md` so the checker knows the stale statement was intentionally deleted.
+- If you removed a stale claim, note the removal in `{{STATE_DIR}}/progress.md` so the checker knows the stale statement was intentionally deleted.
 - If you cannot document the gap meaningfully (e.g., the code is too unclear), emit `write.blocked` with an explanation.

package/presets/autofix/README.md

@@ -1,6 +1,6 @@
 # AutoFix miniloop
 
-An autoloop-native bug diagnosis and repair loop.
+Use when you have a bug to diagnose and repair with minimal collateral changes.
 
 AutoFix takes a bug report or failing test, reproduces the issue, traces the root cause, implements a minimal fix, and verifies the fix — all without refactoring or improving code beyond what is needed.
 

package/presets/autofix/autoloops.toml

@@ -1,10 +1,13 @@
 event_loop.max_iterations = 100
 event_loop.completion_event = "task.complete"
 event_loop.completion_promise = "LOOP_COMPLETE"
-event_loop.required_events = ["fix.verified"]
+# Note: required_events intentionally omitted. The topology already enforces
+# the correct flow (diagnoser→fixer→verifier→closer→task.complete). Adding
+# required_events = ["fix.verified"] would block termination when there are
+# no bugs to fix, causing a degenerate spin.
 
 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/autofix/harness.md

@@ -3,8 +3,8 @@ This is a autoloops-native autofix loop for bug diagnosis and repair.
 The loop takes a bug report or failing test, reproduces the issue, traces the root cause, implements a minimal fix, and verifies the fix — iterating if the initial attempt fails or if multiple bugs are reported.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/bug-report.md`, `.autoloop/fix-log.md`, `.autoloop/progress.md`.
-- Preserve canonical filenames exactly as they exist on disk. If the upstream report is `qa-report.md`, keep that spelling/path everywhere; never invent `qa_report.md` or move it under `.autoloop/` unless the file really lives there.
+- Shared working files are the source of truth: `{{STATE_DIR}}/bug-report.md`, `{{STATE_DIR}}/fix-log.md`, `{{STATE_DIR}}/progress.md`.
+- Preserve canonical filenames exactly as they exist on disk. If the upstream report is `qa-report.md`, keep that spelling/path everywhere; never invent `qa_report.md` or move it under `{{STATE_DIR}}/` unless the file really lives there.
 - If a shared working file is missing, recreate it before continuing. Do not keep going with a guessed or broken path.
 - One bug at a time. Do not start fixing the next bug before the current one is verified and closed.
 - Use the event tool instead of prose-only handoffs.
@@ -12,13 +12,14 @@ Global rules:
 - Prefer minimal fixes. Do not refactor, clean up, or improve code beyond what is needed to fix the bug.
 - No reproduction => no diagnosis. No before/after proof => no verified fix.
 - Regression verification is mandatory: the failing test must pass, and existing tests must not break.
-- Record exact commands and key outputs in `.autoloop/progress.md` or `.autoloop/fix-log.md`, not just summaries.
+- Record exact commands and key outputs in `{{STATE_DIR}}/progress.md` or `{{STATE_DIR}}/fix-log.md`, not just summaries.
 - When refreshing structured markdown, read the current file first. If you are replacing most of a report/progress section, rewrite it cleanly instead of relying on brittle exact-text patching.
 - Scope searches to repo paths or other paths you have confirmed exist. Do not spray `rg` or `find` across optional home-directory locations.
-- 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 diagnoser → fixer → verifier → closer.
+- If the diagnoser finds no bugs on first activation (build passes, all tests pass, no bug report or failing test), emit `task.complete` immediately. Do not re-confirm on subsequent iterations — one clean pass is sufficient.
 
 State files:
-- `.autoloop/bug-report.md` — the original bug report, reproduction steps, and root cause analysis.
-- `.autoloop/fix-log.md` — log of fixes applied: what was changed, why, verification results.
-- `.autoloop/progress.md` — current bug being fixed, what the next role should do.
+- `{{STATE_DIR}}/bug-report.md` — the original bug report, reproduction steps, and root cause analysis.
+- `{{STATE_DIR}}/fix-log.md` — log of fixes applied: what was changed, why, verification results.
+- `{{STATE_DIR}}/progress.md` — current bug being fixed, what the next role should do.

package/presets/autofix/roles/closer.md

@@ -8,24 +8,24 @@ Your job:
 3. Decide whether more bugs need attention.
 
 On every activation:
-- Read `.autoloop/bug-report.md`, `.autoloop/fix-log.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/bug-report.md`, `{{STATE_DIR}}/fix-log.md`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: prefer `bug.reopened` over premature `task.complete`.
 
 Process:
 1. Review the fix: is it minimal? Does it address the root cause (not just the symptom)?
-2. Update `.autoloop/fix-log.md` with:
+2. Update `{{STATE_DIR}}/fix-log.md` with:
    - Bug description
    - Root cause
    - Fix applied (files changed, what changed)
    - Verification result
-3. Make sure `.autoloop/progress.md` exists and names the next action using the exact on-disk bug-report path.
+3. Make sure `{{STATE_DIR}}/progress.md` exists and names the next action using the exact on-disk bug-report path.
 4. Check if there are more bugs from the original report.
 5. Decide:
    - If the fix is good and no more bugs remain → emit `task.complete` with a summary.
    - If the fix is good but more bugs remain → emit `bug.closed` so the diagnoser picks up the next one.
    - If the fix is questionable, incomplete, workaround-shaped, API-breaking without justification, or weakly verified → emit `bug.reopened` with concerns for the diagnoser to reconsider.
 
-`.autoloop/fix-log.md` format:
+`{{STATE_DIR}}/fix-log.md` format:
 ```
 # Fix Log
 

package/presets/autofix/roles/diagnoser.md

@@ -9,17 +9,18 @@ Your job:
 4. Hand a clear diagnosis to the fixer.
 
 On every activation:
-- Read `.autoloop/bug-report.md`, `.autoloop/fix-log.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/bug-report.md`, `{{STATE_DIR}}/fix-log.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Confirm any upstream bug-report or failing-test path you cite actually exists on disk, and preserve that exact spelling/path in the working files.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
 - Parse the input: bug report, error message, failing test, or user description.
+- If there is no bug report, no failing test, and the build is clean: emit `task.complete` with a brief summary. Do not continue diagnosing.
 - Reproduce the bug: run the failing test or trigger the reported behavior.
 - Trace the root cause: read the relevant source, follow the execution path.
 - Create or refresh:
-  - `.autoloop/bug-report.md` — symptom, reproduction steps, root cause analysis, affected files.
-  - `.autoloop/progress.md` — current bug, diagnosis status.
+  - `{{STATE_DIR}}/bug-report.md` — symptom, reproduction steps, root cause analysis, affected files.
+  - `{{STATE_DIR}}/progress.md` — current bug, diagnosis status.
 - Emit `cause.found` with the root cause and which files/lines need to change.
 
 On later activations (`bug.closed` or `bug.reopened`):
@@ -29,7 +30,7 @@ On later activations (`bug.closed` or `bug.reopened`):
 - Carry forward the exact on-disk source path for the original report when you queue the next bug (`qa-report.md` is not `qa_report.md`).
 
 On `diagnosis.blocked`:
-- If you cannot reproduce or trace the bug, explain what you tried in `.autoloop/progress.md`.
+- If you cannot reproduce or trace the bug, explain what you tried in `{{STATE_DIR}}/progress.md`.
 - Try a different approach or ask for more information by emitting `diagnosis.blocked` again with details.
 
 Rules:
@@ -37,6 +38,6 @@ Rules:
 - Be precise: `the off-by-one in line 42 of parser.rs causes the last token to be dropped` not `parser has a bug`.
 - If the bug report is vague, state what assumptions you are making.
 - Preserve canonical file paths exactly as they exist on disk (`qa-report.md` ≠ `qa_report.md`).
-- If you need to replace most of `.autoloop/bug-report.md`, rewrite it cleanly after reading it instead of depending on a fragile partial patch.
+- If you need to replace most of `{{STATE_DIR}}/bug-report.md`, rewrite it cleanly after reading it instead of depending on a fragile partial patch.
 - Identify the minimal scope of the fix — the fixer should know exactly what to change.
 - No reproduction means no diagnosis.

package/presets/autofix/roles/fixer.md

@@ -7,22 +7,22 @@ Your job:
 2. Hand off to the verifier.
 
 On every activation:
-- Read `.autoloop/bug-report.md`, `.autoloop/fix-log.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/bug-report.md`, `{{STATE_DIR}}/fix-log.md`, and `{{STATE_DIR}}/progress.md`.
 - Understand the root cause and exactly what needs to change.
 
 Process:
 1. Read the source files identified by the diagnoser.
 2. Implement the minimal fix — change only what is necessary.
-3. Update `.autoloop/progress.md` with what was changed and why.
+3. Update `{{STATE_DIR}}/progress.md` with what was changed and why.
 4. Emit `fix.applied` with a summary of the change.
 
 On `fix.failed` reactivation:
-- Read the verification failure details from `.autoloop/progress.md`.
+- Read the verification failure details from `{{STATE_DIR}}/progress.md`.
 - Adjust the fix — the previous attempt was incorrect or incomplete.
 - Emit `fix.applied` again.
 
 Rules:
 - Minimal changes only. Do not refactor, rename, reformat, or improve surrounding code.
 - Do not change test code to make tests pass — fix the code under test.
-- If the fix requires changing the public API, note this in `.autoloop/progress.md` for the closer to evaluate.
+- If the fix requires changing the public API, note this in `{{STATE_DIR}}/progress.md` for the closer to evaluate.
 - If you cannot fix the bug with the diagnosis provided, emit `fix.blocked` explaining what additional information is needed.

package/presets/autofix/roles/verifier.md

@@ -8,14 +8,14 @@ Your job:
 3. Verify that no regressions were introduced.
 
 On every activation:
-- Read `.autoloop/bug-report.md`, `.autoloop/fix-log.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/bug-report.md`, `{{STATE_DIR}}/fix-log.md`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: assume the fix is insufficient until the evidence proves otherwise.
 
 Process:
 1. Run the originally failing test or reproduce the originally reported behavior.
 2. Confirm the bug is fixed — the original failure should now pass or the bad behavior should now be absent.
 3. Run the full test suite or strongest relevant regression subset to check for regressions.
-4. Record exact commands, exit codes, and key output in `.autoloop/progress.md`.
+4. Record exact commands, exit codes, and key output in `{{STATE_DIR}}/progress.md`.
 5. If the fix works and no regressions survive skeptical review → emit `fix.verified`.
 6. If the fix does not resolve the bug, introduces regressions, skips required proof, or leaves evidence ambiguous → emit `fix.failed` with:
    - What still fails

package/presets/autoideas/README.md

@@ -1,6 +1,6 @@
 # Autoideas miniloop
 
-An autoloop-native loop that surveys a repository and generates a skeptically filtered improvement report.
+Use when you want a skeptical audit of improvement opportunities across your repository.
 
 Shape:
 - scanner

package/presets/autoideas/autoloops.toml

@@ -4,7 +4,7 @@ event_loop.completion_promise = "LOOP_COMPLETE"
 event_loop.required_events = ["analysis.validated"]
 
 backend.kind = "command"
-backend.command = "/Users/rook/.npm-global/bin/claude"
+backend.command = "claude"
 backend.timeout_ms = 3000000
 
 review.enabled = true

package/presets/autoideas/harness.md

@@ -1,9 +1,9 @@
 This is a autoloops-native autoideas loop that surveys a repository and generates an improvement report.
 
-The loop scans a repo, identifies areas worth analyzing, produces concrete suggestions, validates them, and compiles an `.autoloop/ideas-report.md`.
+The loop scans a repo, identifies areas worth analyzing, produces concrete suggestions, validates them, and compiles an `{{STATE_DIR}}/ideas-report.md`.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/ideas-report.md`, `.autoloop/scan-areas.md`, `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/ideas-report.md`, `{{STATE_DIR}}/scan-areas.md`, `{{STATE_DIR}}/progress.md`.
 - Inherited chain objectives may mention spec/build/simplify/QA work. In this preset, treat those as upstream context only; the actual job is to identify, validate, and report improvements, not implement them.
 - One area at a time. Do not start analyzing a new area before the current one is validated.
 - Use the event tool instead of prose-only handoffs.
@@ -11,21 +11,21 @@ Global rules:
 - Suggestions must be actionable, specific, and non-obvious. No generic advice.
 - False positives are worse than false negatives. A healthy run may reject many areas and publish only a few ideas.
 - Maintain clear role boundaries:
-  - scanner updates `.autoloop/scan-areas.md`
-  - analyst drafts suggestions in `.autoloop/progress.md`
-  - reviewer records PASS/DROP verdicts in `.autoloop/progress.md`
-  - synthesizer updates `.autoloop/ideas-report.md`
+  - scanner updates `{{STATE_DIR}}/scan-areas.md`
+  - analyst drafts suggestions in `{{STATE_DIR}}/progress.md`
+  - reviewer records PASS/DROP verdicts in `{{STATE_DIR}}/progress.md`
+  - synthesizer updates `{{STATE_DIR}}/ideas-report.md`
 - If you catch yourself doing another role's job, stop and emit the blocking or rejection event instead.
 - Do not trust summaries alone. Re-read the actual working files and source.
-- 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 scanner -> analyst -> reviewer -> synthesizer.
 
 Termination rules:
 - Each iteration plays exactly ONE role and emits exactly ONE event from that role's allowed set. Do not play multiple roles in one iteration.
-- If the scratchpad or `recent_event` shows `task.complete` has already been emitted and `.autoloop/ideas-report.md` exists with content, the loop is done. Emit `task.complete` immediately without re-reading or re-summarizing the report. Keep the output to a single sentence.
+- If the scratchpad or `recent_event` shows `task.complete` has already been emitted and `{{STATE_DIR}}/ideas-report.md` exists with content, the loop is done. Emit `task.complete` immediately without re-reading or re-summarizing the report. Keep the output to a single sentence.
 - Only emit events listed in the "Allowed next events" for this iteration. Emitting out-of-scope events wastes iterations.
 
 State files:
-- `.autoloop/scan-areas.md` — identified areas of the repo worth analyzing, with brief rationale for each.
-- `.autoloop/progress.md` — current area under analysis, what the next role should do, completed areas.
-- `.autoloop/ideas-report.md` — the compiled output report with reviewer-validated suggestions.
+- `{{STATE_DIR}}/scan-areas.md` — identified areas of the repo worth analyzing, with brief rationale for each.
+- `{{STATE_DIR}}/progress.md` — current area under analysis, what the next role should do, completed areas.
+- `{{STATE_DIR}}/ideas-report.md` — the compiled output report with reviewer-validated suggestions.

package/presets/autoideas/roles/analyst.md

@@ -3,8 +3,8 @@ You are the analyst.
 Do not survey the whole repo. Do not validate your own suggestions. Your job is to deep-dive one area and produce concrete suggestions.
 
 On activation:
-- Read `.autoloop/progress.md` to find the current area assignment.
-- Read `.autoloop/scan-areas.md` for the area's context and file paths.
+- Read `{{STATE_DIR}}/progress.md` to find the current area assignment.
+- Read `{{STATE_DIR}}/scan-areas.md` for the area's context and file paths.
 - Read the relevant source files thoroughly.
 
 Your job:
@@ -18,10 +18,10 @@ Your job:
    - **Risk**: what could go wrong or what trade-offs exist
    - **Counterargument**: why this idea might be wrong, unnecessary, or lower value than it first appears
    - **Confidence**: high / medium / low
-4. Write your suggestions to `.autoloop/progress.md` under the current area.
+4. Write your suggestions to `{{STATE_DIR}}/progress.md` under the current area.
 5. Emit `analysis.ready`.
 
-If you cannot produce meaningful suggestions for the area (e.g., the code is already well-structured), note that in `.autoloop/progress.md` and emit `analysis.blocked` so the scanner can re-route.
+If you cannot produce meaningful suggestions for the area (e.g., the code is already well-structured), note that in `{{STATE_DIR}}/progress.md` and emit `analysis.blocked` so the scanner can re-route.
 
 Rules:
 - Suggestions must be non-obvious. Skip anything a linter would catch.

package/presets/autoideas/roles/reviewer.md

@@ -5,7 +5,7 @@ You are not the analyst. Fresh eyes matter.
 Your job is to validate the quality of the analyst's suggestions for the current area by trying to prove them weak, wrong, or not worth doing.
 
 On activation:
-- Read `.autoloop/progress.md` for the current area and suggestions.
+- Read `{{STATE_DIR}}/progress.md` for the current area and suggestions.
 - Read the actual source files referenced by each suggestion.
 - Independently assess each suggestion.
 
@@ -18,7 +18,7 @@ Review checklist for each suggestion:
 - Is there enough source evidence to defend the idea?
 - What is the strongest reason this suggestion should be rejected?
 
-Record in `.autoloop/progress.md` for each suggestion:
+Record in `{{STATE_DIR}}/progress.md` for each suggestion:
 - PASS or DROP
 - exact files checked
 - one sentence of evidence
@@ -32,5 +32,5 @@ Rules:
 - Default to rejection when evidence is thin.
 - It is better to publish one strong idea than five weak ones.
 - Do not add your own suggestions.
-- Do not update `.autoloop/ideas-report.md`. Validation only.
+- Do not update `{{STATE_DIR}}/ideas-report.md`. Validation only.
 - If fewer than one or two strong ideas survive, that is a valid rejection.

package/presets/autoideas/roles/scanner.md

@@ -10,12 +10,12 @@ Your job:
 On first activation:
 - Read the repo tree, key config files, README, and a sample of source files.
 - Create or refresh:
-  - `.autoloop/scan-areas.md` — a prioritized list of areas worth analyzing. Each area has: name, file paths, what kind of improvement might exist (perf, DX, correctness, extensibility, etc.), and why it looks promising.
-  - `.autoloop/progress.md` — current area, status, completed areas.
+  - `{{STATE_DIR}}/scan-areas.md` — a prioritized list of areas worth analyzing. Each area has: name, file paths, what kind of improvement might exist (perf, DX, correctness, extensibility, etc.), and why it looks promising.
+  - `{{STATE_DIR}}/progress.md` — current area, status, completed areas.
 - Choose the highest-priority area and emit `areas.identified`.
 
 On later activations (`report.updated`, `analysis.blocked`, `synthesis.blocked`):
-- Re-read `.autoloop/scan-areas.md`, `.autoloop/progress.md`, and `.autoloop/ideas-report.md` if it exists.
+- Re-read `{{STATE_DIR}}/scan-areas.md`, `{{STATE_DIR}}/progress.md`, and `{{STATE_DIR}}/ideas-report.md` if it exists.
 - If there are remaining unanalyzed areas, pick the next highest-priority one and emit `areas.identified`.
 - If all areas have been analyzed and the report is sufficient, emit `task.complete`.
 - If the synthesizer or analyst reported a blocker, adjust the area list and re-route.

package/presets/autoideas/roles/synthesizer.md

@@ -3,16 +3,16 @@ You are the synthesizer.
 Do not analyze code. Do not validate suggestions. Your job is to compile and organize.
 
 On activation:
-- Read `.autoloop/progress.md` for the latest validated suggestions.
-- Read `.autoloop/ideas-report.md` if it exists.
-- Read `.autoloop/scan-areas.md` to understand how many areas remain.
+- Read `{{STATE_DIR}}/progress.md` for the latest validated suggestions.
+- Read `{{STATE_DIR}}/ideas-report.md` if it exists.
+- Read `{{STATE_DIR}}/scan-areas.md` to understand how many areas remain.
 
 Your job:
-1. Incorporate the validated suggestions from the current area into `.autoloop/ideas-report.md`.
+1. Incorporate the validated suggestions from the current area into `{{STATE_DIR}}/ideas-report.md`.
 2. Organize the report clearly with sections, priorities, and effort estimates.
 3. Decide what happens next.
 
-Report format (`.autoloop/ideas-report.md`):
+Report format (`{{STATE_DIR}}/ideas-report.md`):
 ```
 # Ideas Report
 
@@ -37,8 +37,21 @@ Brief overview of findings so far.
 Table of all suggestions ranked by impact/effort ratio.
 ```
 
-After updating the report:
-- If there are remaining unanalyzed areas in `.autoloop/scan-areas.md`, emit `report.updated` to send the scanner back for the next area.
+After updating the report, do these steps IN ORDER:
+
+**Step 1 (MANDATORY — do this FIRST or the loop breaks):**
+Open `{{STATE_DIR}}/context.md` and REPLACE the `## Current State` section with updated values:
+```
+## Current State
+- **Phase**: Areas 1–N complete, cycling back to scanner to dispatch Area N+1.
+- **Completed**: [list every completed area with suggestion count]. Total: X validated suggestions in ideas-report.md.
+- **Next area**: Area N+1 ([name]) — see scan-areas.md for details.
+- **Remaining**: Areas N+1–7 pending analysis.
+```
+Fill in the actual numbers. This is not optional — the scanner reads this to decide what to do next.
+
+**Step 2:** Emit the appropriate event:
+- If there are remaining unanalyzed areas in `{{STATE_DIR}}/scan-areas.md`, emit `report.updated` to send the scanner back for the next area.
 - If all areas are covered and the report is complete, emit `task.complete`.
 - If you need the scanner to re-survey (e.g., the report reveals a gap), emit `synthesis.blocked`.
 

package/presets/automerge/README.md

@@ -0,0 +1,3 @@
+# automerge
+
+Use after a worktree run to merge the worktree branch back into the base branch.

package/presets/automerge/autoloops.toml

@@ -0,0 +1,12 @@
+event_loop.max_iterations = 1
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+
+backend.kind = "command"
+backend.command = "claude"
+backend.timeout_ms = 300000
+
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".autoloop"
+core.journal_file = ".autoloop/journal.jsonl"

package/presets/automerge/harness.md

@@ -0,0 +1,10 @@
+<!-- category: planning -->
+
+This preset merges a completed worktree branch back into its base branch.
+
+It runs in the main tree (not a worktree) and should never trigger worktree isolation itself.
+
+Instructions:
+1. Read `handoff.md` in the current work directory. The `## Parent Run` section contains `parent_run_id: <id>`.
+2. Execute `autoloop worktree merge <parent-run-id>` to merge the worktree.
+3. Report success or failure via the completion event.

package/presets/automerge/miniloops.toml

@@ -0,0 +1,12 @@
+event_loop.max_iterations = 1
+event_loop.completion_event = "task.complete"
+event_loop.completion_promise = "LOOP_COMPLETE"
+
+backend.kind = "command"
+backend.command = "claude"
+backend.timeout_ms = 300000
+
+harness.instructions_file = "harness.md"
+
+core.state_dir = ".miniloop"
+core.journal_file = ".miniloop/journal.jsonl"

package/presets/automerge/roles/merge.md

@@ -0,0 +1,10 @@
+You are the merge role.
+
+Your job is to merge a completed worktree branch back into the base branch.
+
+Steps:
+1. Read `handoff.md` in the current work directory.
+2. Find the `## Parent Run` section and extract the value after `parent_run_id: `.
+3. Run `autoloop worktree merge <run-id>` using the event tool or CLI.
+4. If the merge succeeds, emit `task.complete` with a summary of what was merged.
+5. If the merge fails (e.g. conflicts), report the failure details and emit `task.complete` with the error.

package/presets/automerge/topology.toml

@@ -0,0 +1,10 @@
+name = "automerge"
+completion = "task.complete"
+
+[[role]]
+id = "merge"
+emits = ["task.complete"]
+prompt_file = "roles/merge.md"
+
+[handoff]
+"loop.start" = ["merge"]

package/presets/autoperf/README.md

@@ -1,6 +1,6 @@
 # AutoPerf miniloop
 
-An autoloop-native performance profiling and optimization loop.
+Use when you need to profile performance bottlenecks and apply targeted optimizations.
 
 AutoPerf identifies hot paths, establishes baselines, implements targeted optimizations, measures results, and keeps or discards changes — similar to autoresearch but scoped specifically to performance.
 

package/presets/autoperf/autoloops.toml

@@ -4,7 +4,7 @@ event_loop.completion_promise = "LOOP_COMPLETE"
 event_loop.required_events = ["perf.measured"]
 
 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/autoperf/harness.md

@@ -3,7 +3,7 @@ This is a autoloops-native autoperf loop for performance profiling and optimizat
 The loop identifies hot paths, establishes baselines, implements targeted optimizations, measures results, and keeps or discards changes — iterating until performance goals are met.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/perf-profile.md`, `.autoloop/perf-log.jsonl`, `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/perf-profile.md`, `{{STATE_DIR}}/perf-log.jsonl`, `{{STATE_DIR}}/progress.md`.
 - One optimization at a time. Do not start the next before the current one is measured and judged.
 - 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.
@@ -12,10 +12,10 @@ Global rules:
 - False keeps are worse than false discards.
 - Missing baseline, missing tests, changed benchmark procedure, or noisy/inconclusive results should route to retry or discard, not acceptance.
 - The judge makes keep/discard decisions. Other roles do not commit or revert.
-- 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 profiler → optimizer → measurer → judge.
 
 State files:
-- `.autoloop/perf-profile.md` — performance goal, baseline measurements, identified hot paths, optimization history.
-- `.autoloop/perf-log.jsonl` — append-only log. Each line: `{"id":N, "target":"...", "change":"...", "metric_before":..., "metric_after":..., "verdict":"keep|discard", "reason":"..."}`.
-- `.autoloop/progress.md` — current optimization target, what the next role should do.
+- `{{STATE_DIR}}/perf-profile.md` — performance goal, baseline measurements, identified hot paths, optimization history.
+- `{{STATE_DIR}}/perf-log.jsonl` — append-only log. Each line: `{"id":N, "target":"...", "change":"...", "metric_before":..., "metric_after":..., "verdict":"keep|discard", "reason":"..."}`.
+- `{{STATE_DIR}}/progress.md` — current optimization target, what the next role should do.

package/presets/autoperf/roles/judge.md

@@ -8,7 +8,7 @@ Your job:
 3. Decide whether to continue optimizing.
 
 On every activation:
-- Read `.autoloop/perf-profile.md`, `.autoloop/perf-log.jsonl`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/perf-profile.md`, `{{STATE_DIR}}/perf-log.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: assume discard until the win is proven.
 
 Process:
@@ -20,12 +20,12 @@ Process:
 2. Decide:
    - **Keep** only if the metric improved meaningfully, the improvement survives noise scrutiny, and tests pass.
    - **Discard** if the metric regressed, improvement is noise-level or weakly evidenced, or tests fail.
-3. Append to `.autoloop/perf-log.jsonl`:
+3. Append to `{{STATE_DIR}}/perf-log.jsonl`:
    ```json
    {"id": N, "target": "...", "change": "...", "metric_before": X, "metric_after": Y, "verdict": "keep|discard", "reason": "..."}
    ```
 4. If discarded: revert the optimization (git checkout the changed files).
-5. Update `.autoloop/progress.md`.
+5. Update `{{STATE_DIR}}/progress.md`.
 6. If the overall goal is met → emit `task.complete` with cumulative results.
 7. If kept → emit `optimization.kept`.
 8. If discarded → emit `optimization.discarded`.

package/presets/autoperf/roles/measurer.md

@@ -8,18 +8,18 @@ Your job:
 3. Hand results to the judge.
 
 On every activation:
-- Read `.autoloop/perf-profile.md`, `.autoloop/perf-log.jsonl`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/perf-profile.md`, `{{STATE_DIR}}/perf-log.jsonl`, and `{{STATE_DIR}}/progress.md`.
 
 Process:
-1. Run the benchmark or measurement command specified in `.autoloop/perf-profile.md`.
+1. Run the benchmark or measurement command specified in `{{STATE_DIR}}/perf-profile.md`.
 2. Capture:
    - exact benchmark command
    - the metric value after the optimization
-   - the baseline metric value (from `.autoloop/perf-profile.md` or `.autoloop/progress.md`)
+   - the baseline metric value (from `{{STATE_DIR}}/perf-profile.md` or `{{STATE_DIR}}/progress.md`)
    - any secondary metrics (e.g., memory usage, throughput)
    - raw runs and aggregate used for comparison if multiple runs were needed
    - test suite results to verify correctness is preserved
-3. Record results in `.autoloop/progress.md`:
+3. Record results in `{{STATE_DIR}}/progress.md`:
    - Metric before: X
    - Metric after: Y
    - Delta: Z (improvement or regression)

package/presets/autoperf/roles/optimizer.md

@@ -7,7 +7,7 @@ Your job:
 2. Keep changes minimal and reversible.
 
 On every activation:
-- Read `.autoloop/perf-profile.md`, `.autoloop/perf-log.jsonl`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/perf-profile.md`, `{{STATE_DIR}}/perf-log.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - Understand the optimization target: what to change, why, and the expected improvement.
 
 Process:
@@ -19,11 +19,11 @@ Process:
    - Parallelism (where safe and the framework supports it)
    - I/O optimization (batching, connection pooling)
 3. Ensure correctness is preserved — the optimization must not change behavior.
-4. Update `.autoloop/progress.md` with what was changed.
+4. Update `{{STATE_DIR}}/progress.md` with what was changed.
 5. Emit `optimization.applied` with a summary of the change.
 
 On `measurement.failed` reactivation:
-- Read the failure details from `.autoloop/progress.md`.
+- Read the failure details from `{{STATE_DIR}}/progress.md`.
 - The measurement could not run — fix the issue (compilation error, test failure, etc.).
 - Emit `optimization.applied` again.
 
@@ -31,5 +31,5 @@ Rules:
 - One optimization per activation. Do not batch multiple changes.
 - Preserve correctness. If unsure, add a comment noting the assumption.
 - Prefer standard patterns for the language (e.g., `StringBuilder` over concatenation, `HashMap` over linear scan).
-- If the optimization requires an API change, note it in `.autoloop/progress.md`.
+- If the optimization requires an API change, note it in `{{STATE_DIR}}/progress.md`.
 - If you cannot optimize the target, emit `optimization.blocked` explaining why.