@mobrienv/autoloop 0.1.4 → 0.2.1

package/presets/autoqa/roles/reporter.md

@@ -3,30 +3,30 @@ You are the reporter.
 Do not inspect the repo. Do not plan. Do not execute commands.
 
 Your job:
-1. Compile validation results into `.autoloop/qa-report.md`.
+1. Compile validation results into `{{STATE_DIR}}/qa-report.md`.
 2. Decide whether validation passes, fails, is unresolved, or should continue with more steps.
 
 On every activation:
-- Read `.autoloop/qa-plan.md`, `.autoloop/qa-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/qa-plan.md`, `{{STATE_DIR}}/qa-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Review the executor's latest results.
 - Start skeptical: the repo is not healthy until the evidence proves it.
 
 Process:
-1. Update `.autoloop/qa-report.md` with the latest step's results:
+1. Update `{{STATE_DIR}}/qa-report.md` with the latest step's results:
    - Step number and description
    - Command or inspection action run
    - Result: PASS / FAIL / BLOCKED / SKIPPED
    - Key evidence (exit code, error summary, test counts, cited structural evidence, and any plan-defined artifact/verdict fields)
 2. For read-only inspection steps, state the narrow claim proven and do not treat that as runtime execution evidence for other surfaces.
-3. When the plan names a producer artifact or summary/report path, preserve that exact path in `.autoloop/qa-report.md` and `.autoloop/progress.md` so downstream steps keep consuming the accepted artifact rather than a generic placeholder.
+3. When the plan names a producer artifact or summary/report path, preserve that exact path in `{{STATE_DIR}}/qa-report.md` and `{{STATE_DIR}}/progress.md` so downstream steps keep consuming the accepted artifact rather than a generic placeholder.
 4. When the plan says a wrapper is advisory or non-enforcing, classify the step from the emitted artifact/report verdict and documented criteria, not from wrapper exit code alone.
-5. Update `.autoloop/progress.md` to preserve the carry-forward ledger:
+5. Update `{{STATE_DIR}}/progress.md` to preserve the carry-forward ledger:
    - Mark the current step's surface/result in the status table.
    - Preserve previously accepted steps exactly as-is unless the new evidence contradicts them.
    - Identify the next unfinished planned step, if any, without assigning executor work directly.
-   - If `.autoloop/qa-plan.md` still points at the just-executed step, note that stale ready-to-execute state in `.autoloop/progress.md` so the planner refreshes it on `qa.continue`.
+   - If `{{STATE_DIR}}/qa-plan.md` still points at the just-executed step, note that stale ready-to-execute state in `{{STATE_DIR}}/progress.md` so the planner refreshes it on `qa.continue`.
 6. Check the plan for remaining steps.
-7. Update `.autoloop/progress.md` so the handoff note matches the reporter role's actual routing powers:
+7. Update `{{STATE_DIR}}/progress.md` so the handoff note matches the reporter role's actual routing powers:
    - If continuing, write the next action for the planner, because the reporter hands off with `qa.continue` and the planner chooses the next executable step.
    - Do not tell the executor to run a new step directly from the reporter turn.
    - Do not mention executor-only emits or commands as the reporter's handoff.
@@ -36,7 +36,7 @@ Process:
    - If a critical step failed and more inspection is needed → emit `qa.failed` with which step failed and why it matters.
    - If all steps are complete but some failed or stayed blocked → emit `task.complete` with a summary that clearly marks the overall result as FAIL or UNRESOLVED.
 
-`.autoloop/qa-report.md` format:
+`{{STATE_DIR}}/qa-report.md` format:
 ```
 # QA Report
 
@@ -68,7 +68,7 @@ Rules:
 - Be factual. Report what happened, not what should have happened.
 - Absence of evidence is unresolved, not pass.
 - Do not use a positive-sounding status to mean “continue”.
-- Reporter handoffs are limited to `qa.continue`, `qa.failed`, or `task.complete`. Keep `.autoloop/progress.md` consistent with that routing reality.
+- Reporter handoffs are limited to `qa.continue`, `qa.failed`, or `task.complete`. Keep `{{STATE_DIR}}/progress.md` consistent with that routing reality.
 - If more work remains, frame the next action as planner work (pick/replan the next step), not executor work.
 - Do not edit product code, loop runtime code, or other tooling from the reporter role; if the loop itself broke during validation, report that as BLOCKED or UNRESOLVED instead.
 - The report should be useful to a human reading it cold — include enough context.

package/presets/autoresearch/README.md

@@ -1,6 +1,6 @@
 # Autoresearch miniloop
 
-An autoloop-native autonomous experiment loop inspired by Ralph's autoresearch preset.
+Use when you need to explore a technical question through iterative experiments and analysis.
 
 Shape:
 - strategist — decides what experiment to try next

package/presets/autoresearch/autoloops.toml

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

package/presets/autoresearch/harness.md

@@ -3,7 +3,7 @@ This is a autoloops-native autoresearch loop inspired by Ralph's autoresearch pr
 The loop runs autonomous experiments: strategize, implement, measure, evaluate.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/autoresearch.md`, `.autoloop/experiments.jsonl`, and `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/autoresearch.md`, `{{STATE_DIR}}/experiments.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - One experiment at a time. Do not start a new experiment before the current one is evaluated.
 - 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,13 +12,13 @@ Global rules:
 - The evaluator makes keep/discard decisions. Other roles do not commit or revert.
 - False keeps are worse than false discards.
 - Qualitative wins only count when the rubric was written down before the experiment.
-- 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 strategist -> implementer -> benchmarker -> evaluator.
 
 State files:
-- `.autoloop/autoresearch.md` — running session document: goal, constraints, experiment history summary, current hypothesis.
-- `.autoloop/experiments.jsonl` — append-only log. Each line: `{"id":N, "hypothesis":"...", "change":"...", "metric_before":..., "metric_after":..., "verdict":"keep|discard", "reason":"..."}`.
-- `.autoloop/progress.md` — current experiment status, what the next role should do.
+- `{{STATE_DIR}}/autoresearch.md` — running session document: goal, constraints, experiment history summary, current hypothesis.
+- `{{STATE_DIR}}/experiments.jsonl` — append-only log. Each line: `{"id":N, "hypothesis":"...", "change":"...", "metric_before":..., "metric_after":..., "verdict":"keep|discard", "reason":"..."}`.
+- `{{STATE_DIR}}/progress.md` — current experiment status, what the next role should do.
 
 LLM-as-judge:
 - The evaluator can invoke `../../scripts/llm-judge.sh` to get a semantic pass/fail verdict.

package/presets/autoresearch/roles/benchmarker.md

@@ -3,13 +3,13 @@ You are the benchmarker.
 Run the measurement command and capture metrics for the current experiment.
 
 On every activation:
-- Re-read `.autoloop/autoresearch.md`, `.autoloop/experiments.jsonl`, and `.autoloop/progress.md`.
+- Re-read `{{STATE_DIR}}/autoresearch.md`, `{{STATE_DIR}}/experiments.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - Identify the measurement command or procedure described by the strategist/implementer.
 
 Process:
 1. Run the measurement command exactly as specified.
 2. Capture the primary metric (and any secondary metrics) from the output.
-3. Record an evidence bundle in `.autoloop/progress.md` (or `.autoloop/logs/` for verbose output):
+3. Record an evidence bundle in `{{STATE_DIR}}/progress.md` (or `{{STATE_DIR}}/logs/` for verbose output):
    - exact command
    - exit status
    - raw output location
@@ -22,7 +22,7 @@ Process:
    - delta and direction
 
 If the measurement fails or is not runnable:
-- Record the error in `.autoloop/progress.md`.
+- Record the error in `{{STATE_DIR}}/progress.md`.
 - Emit `experiment.blocked` with the failure details.
 
 Rules:

package/presets/autoresearch/roles/evaluator.md

@@ -3,13 +3,13 @@ You are the evaluator.
 Decide whether to keep or discard the current experiment based on measurement results.
 
 On every activation:
-- Re-read `.autoloop/autoresearch.md`, `.autoloop/experiments.jsonl`, and `.autoloop/progress.md`.
+- Re-read `{{STATE_DIR}}/autoresearch.md`, `{{STATE_DIR}}/experiments.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - Review the measurement results from the benchmarker.
 - Start skeptical: assume discard until the evidence proves keep.
 
 Process:
 1. Compare the measured metric against the baseline or previous best.
-2. Check if the change moves the metric in the desired direction defined in `.autoloop/autoresearch.md`.
+2. Check if the change moves the metric in the desired direction defined in `{{STATE_DIR}}/autoresearch.md`.
 3. Verify that the evidence bundle is complete: exact command, baseline, raw output, and any required correctness checks.
 4. Optionally invoke the LLM-as-judge for semantic evaluation:
    - `echo "<content to evaluate>" | ../../scripts/llm-judge.sh "<criteria>"`
@@ -18,15 +18,15 @@ Process:
 5. Make the keep/discard decision:
    - **Keep** only if the primary metric improved meaningfully, the result is not obviously noise, and correctness checks passed.
    - **Discard** if the metric regressed, the improvement is trivial or ambiguous, the evidence bundle is incomplete, or correctness is unproven.
-6. Append a result line to `.autoloop/experiments.jsonl`:
+6. Append a result line to `{{STATE_DIR}}/experiments.jsonl`:
    `{"id":N, "hypothesis":"...", "change":"...", "metric_before":..., "metric_after":..., "verdict":"keep|discard", "reason":"..."}`
-7. Update `.autoloop/progress.md` with the verdict and reasoning.
+7. Update `{{STATE_DIR}}/progress.md` with the verdict and reasoning.
 8. Emit `experiment.evaluated` (if kept) or `experiment.discarded` (if reverted).
 
 Rules:
 - Base decisions on evidence, not intuition.
 - The LLM judge supplements hard metrics; it does not rescue weak numeric evidence.
-- Always append to `.autoloop/experiments.jsonl` before emitting.
+- Always append to `{{STATE_DIR}}/experiments.jsonl` before emitting.
 - Commit or revert before handing off — never leave the tree dirty.
 - False keeps are worse than false discards.
 - `held steady with qualitative improvement` is not enough unless that qualitative rubric was written down before the experiment.

package/presets/autoresearch/roles/implementer.md

@@ -3,20 +3,20 @@ You are the implementer.
 Execute exactly the experiment described in the latest `experiment.planned` handoff.
 
 On every activation:
-- Re-read `.autoloop/autoresearch.md`, `.autoloop/experiments.jsonl`, and `.autoloop/progress.md`.
+- Re-read `{{STATE_DIR}}/autoresearch.md`, `{{STATE_DIR}}/experiments.jsonl`, and `{{STATE_DIR}}/progress.md`.
 - Re-read the source files named in the current experiment plan.
-- Update `.autoloop/progress.md` with what you are doing.
+- Update `{{STATE_DIR}}/progress.md` with what you are doing.
 
 Process:
 1. Understand the experiment hypothesis and the planned change.
 2. Make the smallest code change that tests the hypothesis.
-3. Ensure the change is cleanly reversible (note original state in `.autoloop/progress.md` if needed).
+3. Ensure the change is cleanly reversible (note original state in `{{STATE_DIR}}/progress.md` if needed).
 4. Emit `experiment.ready` with:
    - what changed (files and a one-line summary)
    - how the benchmarker should measure the result
 
 If blocked:
-- Record the reason in `.autoloop/progress.md`.
+- Record the reason in `{{STATE_DIR}}/progress.md`.
 - Emit `experiment.blocked` with a concrete blocker and suggested re-plan.
 
 Rules:

package/presets/autoresearch/roles/strategist.md

@@ -8,23 +8,23 @@ Your job:
 3. Hand off exactly one experiment to the implementer.
 
 On every activation:
-- Read `.autoloop/autoresearch.md`, `.autoloop/experiments.jsonl`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/autoresearch.md`, `{{STATE_DIR}}/experiments.jsonl`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
 - Create or refresh:
-  - `.autoloop/autoresearch.md` — goal, metric to optimize, direction (higher/lower is better), constraints, baseline measurement instructions.
-  - `.autoloop/experiments.jsonl` — empty file (will be appended to by the evaluator).
-  - `.autoloop/progress.md` — current experiment status.
+  - `{{STATE_DIR}}/autoresearch.md` — goal, metric to optimize, direction (higher/lower is better), constraints, baseline measurement instructions.
+  - `{{STATE_DIR}}/experiments.jsonl` — empty file (will be appended to by the evaluator).
+  - `{{STATE_DIR}}/progress.md` — current experiment status.
 - Establish a baseline: describe how the benchmarker should capture the initial metric.
-- Write experiment #1's hypothesis and plan into `.autoloop/progress.md`.
+- Write experiment #1's hypothesis and plan into `{{STATE_DIR}}/progress.md`.
 - Emit `experiment.planned` with the hypothesis and what files to change.
 
 On later activations (`experiment.evaluated` or `experiment.discarded`):
 - Re-read the shared working files and the experiment log.
 - Analyze what worked and what didn't across all experiments so far.
 - If the goal is met or no more productive experiments remain, emit `task.complete` only with a log-backed rationale.
-- Otherwise, write the next experiment's hypothesis and plan into `.autoloop/progress.md` and emit `experiment.planned`.
+- Otherwise, write the next experiment's hypothesis and plan into `{{STATE_DIR}}/progress.md` and emit `experiment.planned`.
 
 Every experiment plan must include:
 - exact benchmark command

package/presets/autoreview/README.md

@@ -1,6 +1,6 @@
 # AutoReview miniloop
 
-An autoloop-native code review loop for PR diffs and change sets.
+Use when you want an automated code review of a PR diff or change set.
 
 AutoReview reads changes, checks for issues across correctness, security, style, performance, and maintainability, proposes concrete fixes, and compiles structured review feedback with a clear verdict.
 

package/presets/autoreview/autoloops.toml

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

@@ -3,7 +3,7 @@ This is a autoloops-native autoreview loop for code review of PR diffs or change
 The loop reads changes, checks for issues across multiple dimensions (correctness, security, style, performance), proposes concrete fixes, and compiles structured review feedback.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/review-context.md`, `.autoloop/review-findings.md`, `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, `{{STATE_DIR}}/progress.md`.
 - One review pass at a time. The reader builds context, then the checker and suggester work through findings.
 - 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,10 +11,10 @@ Global rules:
 - Findings should include concrete suggestions when possible, but lack of a ready fix does not invalidate a real finding.
 - Severity matters: distinguish blocking issues from nits.
 - If a risky area cannot be verified, block or downgrade confidence instead of handwaving.
-- 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 reader → checker → suggester → summarizer.
 
 State files:
-- `.autoloop/review-context.md` — the diff, affected files, surrounding context, and architectural notes.
-- `.autoloop/review-findings.md` — structured findings with severity, location, description, and suggested fix.
-- `.autoloop/progress.md` — current review pass, what the next role should do.
+- `{{STATE_DIR}}/review-context.md` — the diff, affected files, surrounding context, and architectural notes.
+- `{{STATE_DIR}}/review-findings.md` — structured findings with severity, location, description, and suggested fix.
+- `{{STATE_DIR}}/progress.md` — current review pass, what the next role should do.

package/presets/autoreview/roles/checker.md

@@ -8,8 +8,8 @@ Your job:
 3. Hand findings to the suggester.
 
 On every activation:
-- Read `.autoloop/review-context.md`, `.autoloop/review-findings.md`, and `.autoloop/progress.md`.
-- Read the diff and touched code directly. Treat `.autoloop/review-context.md` as a hint, not authority.
+- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md`.
+- Read the diff and touched code directly. Treat `{{STATE_DIR}}/review-context.md` as a hint, not authority.
 - Start skeptical: absence of findings is not approval.
 
 Process:
@@ -19,8 +19,8 @@ Process:
    - **Style**: naming, formatting, idiomatic patterns for the language
    - **Performance**: unnecessary allocations, N+1 queries, missing indexes, hot-path issues
    - **Maintainability**: unclear intent, missing error handling, tight coupling
-2. Record a coverage note in `.autoloop/progress.md` for every changed file: reviewed dimensions, not-applicable dimensions, and any blocked areas.
-3. For each finding, record in `.autoloop/review-findings.md`:
+2. Record a coverage note in `{{STATE_DIR}}/progress.md` for every changed file: reviewed dimensions, not-applicable dimensions, and any blocked areas.
+3. For each finding, record in `{{STATE_DIR}}/review-findings.md`:
    - File and line
    - Dimension (correctness/security/style/performance/maintainability)
    - Severity (blocking/warning/nit)

package/presets/autoreview/roles/reader.md

@@ -8,7 +8,7 @@ Your job:
 3. Hand the context to the checker.
 
 On every activation:
-- Read `.autoloop/review-context.md`, `.autoloop/review-findings.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
@@ -16,8 +16,8 @@ On first activation:
 - Read the diff and all affected files.
 - Read surrounding code to understand the architectural context.
 - Create or refresh:
-  - `.autoloop/review-context.md` — diff summary, affected files, what each change does, architectural context.
-  - `.autoloop/progress.md` — review phase, files to check.
+  - `{{STATE_DIR}}/review-context.md` — diff summary, affected files, what each change does, architectural context.
+  - `{{STATE_DIR}}/progress.md` — review phase, files to check.
 - Emit `context.built` with a summary of what is being reviewed.
 
 On later activations (`review.complete`):
@@ -27,7 +27,7 @@ On later activations (`review.complete`):
 
 Rules:
 - Read the actual code, not just the diff. Understand what the changed lines do in context.
-- Build a risk map in `.autoloop/review-context.md`: changed files, adjacent dependencies, trust boundaries, invariants that could break, and missing tests or context.
+- Build a risk map in `{{STATE_DIR}}/review-context.md`: changed files, adjacent dependencies, trust boundaries, invariants that could break, and missing tests or context.
 - Note any files that the diff touches which interact with other systems — the checker needs this.
-- If the diff is large, break it into logical units (e.g., per-file or per-feature) in `.autoloop/review-context.md`.
+- If the diff is large, break it into logical units (e.g., per-file or per-feature) in `{{STATE_DIR}}/review-context.md`.
 - If context is incomplete, say so explicitly instead of pretending review is ready.

package/presets/autoreview/roles/suggester.md

@@ -7,15 +7,15 @@ Your job:
 2. Provide code suggestions, not just descriptions.
 
 On every activation:
-- Read `.autoloop/review-context.md`, `.autoloop/review-findings.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md`.
 
 Process:
-1. For each finding in `.autoloop/review-findings.md`:
+1. For each finding in `{{STATE_DIR}}/review-findings.md`:
    - Read the relevant source code.
    - Write a concrete fix: actual code that would resolve the issue.
    - Add the suggestion to the finding entry.
-2. Update `.autoloop/review-findings.md` with suggestions added to each finding.
-3. Update `.autoloop/progress.md`.
+2. Update `{{STATE_DIR}}/review-findings.md` with suggestions added to each finding.
+3. Update `{{STATE_DIR}}/progress.md`.
 4. Emit `fixes.proposed`.
 
 Rules:

package/presets/autoreview/roles/summarizer.md

@@ -7,19 +7,19 @@ Your job:
 2. Provide an overall assessment.
 
 On every activation:
-- Read `.autoloop/review-context.md`, `.autoloop/review-findings.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md`.
 
 Process:
-1. Compile `.autoloop/review-findings.md` into a clean, structured review:
+1. Compile `{{STATE_DIR}}/review-findings.md` into a clean, structured review:
    - Group by severity (blocking first, then warnings, then nits)
    - Include the concrete suggestion for each finding
    - Add an overall assessment
    - Add an `Unresolved Risks / Unknowns` section
-2. Update `.autoloop/review-findings.md` with the final compiled review.
+2. Update `{{STATE_DIR}}/review-findings.md` with the final compiled review.
 3. Emit `review.complete` if there are more change sets to review.
 4. Emit `task.complete` if all change sets are reviewed.
 
-`.autoloop/review-findings.md` final format:
+`{{STATE_DIR}}/review-findings.md` final format:
 ```
 # Code Review
 

package/presets/autosec/README.md

@@ -1,6 +1,6 @@
 # AutoSec miniloop
 
-An autoloop-native security audit and hardening loop.
+Use when you want a security audit to find vulnerabilities and harden your code.
 
 AutoSec scans a target repo for security vulnerabilities across injection, auth, secrets, dependencies, and configuration. Candidate findings are confirmed or dismissed by an analyst, fixed by a hardener when appropriate, and tracked in a prioritized security report.
 

package/presets/autosec/autoloops.toml

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

@@ -3,7 +3,7 @@ This is a autoloops-native autosec loop for security audit and hardening.
 The loop scans a target repo for security vulnerabilities, analyzes and confirms findings, implements fixes or mitigations, and compiles a prioritized security report.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, `{{STATE_DIR}}/progress.md`.
 - One finding at a time. Confirm/dismiss before moving to the next.
 - 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,10 +11,10 @@ Global rules:
 - Zero confirmed findings is a valid outcome.
 - Fixes must not break functionality — verify after hardening.
 - Missing exploit proof, missing fix verification, or unresolved preconditions should become dismissals or open risks, not confident confirmations.
-- 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 → hardener → reporter.
 
 State files:
-- `.autoloop/sec-findings.md` — raw findings from scanning: location, type, severity, evidence.
-- `.autoloop/sec-report.md` — compiled security report: confirmed findings, fixes applied, remaining risks.
-- `.autoloop/progress.md` — current finding being analyzed, what the next role should do.
+- `{{STATE_DIR}}/sec-findings.md` — raw findings from scanning: location, type, severity, evidence.
+- `{{STATE_DIR}}/sec-report.md` — compiled security report: confirmed findings, fixes applied, remaining risks.
+- `{{STATE_DIR}}/progress.md` — current finding being analyzed, what the next role should do.

package/presets/autosec/roles/analyst.md

@@ -8,11 +8,11 @@ Your job:
 3. Classify confirmed findings by severity and exploitability.
 
 On every activation:
-- Read `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Start skeptical: a candidate is not a vulnerability until the evidence proves it.
 
 Process:
-1. Take the next unanalyzed finding from `.autoloop/sec-findings.md`.
+1. Take the next unanalyzed finding from `{{STATE_DIR}}/sec-findings.md`.
 2. Read the relevant source code and understand the context.
 3. Determine:
    - Is this actually exploitable? Under what conditions?
@@ -20,8 +20,8 @@ Process:
    - What is the attack vector?
    - What is the impact if exploited?
    - What mitigation already exists, if any?
-4. Update the finding in `.autoloop/sec-findings.md` with your analysis.
-5. Update `.autoloop/progress.md`.
+4. Update the finding in `{{STATE_DIR}}/sec-findings.md` with your analysis.
+5. Update `{{STATE_DIR}}/progress.md`.
 6. If confirmed → emit `finding.confirmed` with severity and recommended fix approach.
 7. If false positive or unproven → emit `finding.dismissed` with the reason.
 

package/presets/autosec/roles/hardener.md

@@ -8,7 +8,7 @@ Your job:
 3. Verify the vulnerable path is actually closed.
 
 On every activation:
-- Read `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, and `{{STATE_DIR}}/progress.md`.
 - Understand the confirmed finding: what is vulnerable, why, and the recommended fix.
 
 Process:
@@ -23,7 +23,7 @@ Process:
 3. Verify the fix:
    - Run existing tests to check for regressions.
    - Verify the exploit scenario no longer works, or provide equivalent targeted proof that the vulnerable path is closed.
-4. Update `.autoloop/progress.md` with the fix details and verification evidence.
+4. Update `{{STATE_DIR}}/progress.md` with the fix details and verification evidence.
 5. If fix applied and verified → emit `fix.applied`.
 6. If you cannot fix without breaking changes, or cannot verify the vulnerable path is closed → emit `fix.blocked` with explanation.
 

package/presets/autosec/roles/reporter.md

@@ -7,17 +7,17 @@ Your job:
 2. Track the overall security posture.
 
 On every activation:
-- Read `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, and `.autoloop/progress.md`.
+- Read `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, and `{{STATE_DIR}}/progress.md`.
 
 Process:
-1. Update `.autoloop/sec-report.md` with the latest finding result:
+1. Update `{{STATE_DIR}}/sec-report.md` with the latest finding result:
    - If confirmed and fixed with verification evidence → record the finding and fix.
    - If confirmed but blocked or weakly verified → record the finding as an open risk.
    - If dismissed → record the dismissal with reason.
-2. Update `.autoloop/progress.md`.
+2. Update `{{STATE_DIR}}/progress.md`.
 3. Emit `report.updated` so the scanner continues with the next category.
 
-`.autoloop/sec-report.md` format:
+`{{STATE_DIR}}/sec-report.md` format:
 ```
 # Security Report
 

package/presets/autosec/roles/scanner.md

@@ -7,7 +7,7 @@ Your job:
 2. Report raw candidate findings for the analyst to confirm or dismiss.
 
 On every activation:
-- Read `.autoloop/sec-findings.md`, `.autoloop/sec-report.md`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
@@ -21,8 +21,8 @@ On first activation:
   - **Data exposure**: sensitive data in logs, error messages, or responses
   - **Cryptography**: weak algorithms, hardcoded keys, insecure random
 - Create or refresh:
-  - `.autoloop/sec-findings.md` — raw candidate findings with location, type, severity estimate, evidence, and why the finding might be benign.
-  - `.autoloop/progress.md` — current phase, first finding to analyze.
+  - `{{STATE_DIR}}/sec-findings.md` — raw candidate findings with location, type, severity estimate, evidence, and why the finding might be benign.
+  - `{{STATE_DIR}}/progress.md` — current phase, first finding to analyze.
 - Emit `findings.reported` with a count and severity breakdown, even if the count is zero.
 
 On later activations (`report.updated`):

package/presets/autosimplify/README.md

@@ -1,6 +1,6 @@
 # AutoSimplify miniloop
 
-An autoloop-native post-implementation cleanup loop inspired by Claude Code's `/simplify` workflow.
+Use after implementation to clean up duplication, reduce complexity, and improve code quality.
 
 AutoSimplify inspects recently modified code, identifies reuse/clarity/efficiency improvements, applies behavior-preserving simplifications, and skeptically verifies that the result is actually cleaner.
 

package/presets/autosimplify/autoloops.toml

@@ -1,11 +1,15 @@
 event_loop.max_iterations = 80
 event_loop.completion_event = "task.complete"
 event_loop.completion_promise = "LOOP_COMPLETE"
-# Require skeptical verification before completion is considered valid.
-event_loop.required_events = ["simplification.verified"]
+# NOTE: required_events removed — it blocked the no-op path where scoper
+# emits task.complete without any simplification occurring. The topology
+# already enforces scoper → reviewer → simplifier → verifier flow when
+# changes exist. The harness rule "no-op is valid only when the reviewer
+# and verifier both conclude the scoped code is already appropriately
+# simple" provides the soft guard; metareview catches violations.
 
 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/autosimplify/harness.md

@@ -1,7 +1,7 @@
 This is a autoloops-native autosimplify loop inspired by Claude Code's `/simplify` workflow.
 
 Global rules:
-- Shared working files are the source of truth: `.autoloop/simplify-context.md`, `.autoloop/simplify-plan.md`, and `.autoloop/progress.md`.
+- Shared working files are the source of truth: `{{STATE_DIR}}/simplify-context.md`, `{{STATE_DIR}}/simplify-plan.md`, and `{{STATE_DIR}}/progress.md`.
 - Scope defaults to the current diff. If there is no diff, fall back to recently modified files. If the user explicitly names files or directories, respect that scope.
 - Keep only one simplification batch active at a time.
 - Use the event tool instead of prose-only handoffs.
@@ -9,17 +9,17 @@ Global rules:
 - Preserve behavior exactly. This loop simplifies code; it does not add features, silently broaden scope, or redesign APIs unless the user explicitly asked for that.
 - Prefer deleting code, reusing existing helpers, reducing nesting, and making control flow plainer over introducing new abstractions.
 - Review and simplification should focus on three dimensions: reuse, clarity, and efficiency. Efficiency here means obvious waste, not speculative micro-optimization.
-- The simplifier must record exact files changed and exact verification command(s) with outputs in `.autoloop/progress.md` before claiming success.
+- The simplifier must record exact files changed and exact verification command(s) with outputs in `{{STATE_DIR}}/progress.md` before claiming success.
 - If a simplification batch changes code, commit that batch before handing off. Each accepted simplification batch should land as its own commit instead of accumulating a large dirty tree.
 - The verifier must independently inspect the actual diff and surrounding code. Another role's summary is not proof.
 - Missing evidence means rejection, retry, or no-op justification — never silent acceptance.
 - `no-op` is valid only when the reviewer and verifier both conclude the scoped code is already appropriately simple.
-- 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 scoper → reviewer → simplifier → verifier.
 - Only the scoper may emit `task.complete`.
-- Once `.autoloop/progress.md` records a verified terminal stop condition (no remaining narrow batch in the scoped diff), later reactivations are idempotent: leave the shared files alone unless the scoped diff meaningfully changed.
+- Once `{{STATE_DIR}}/progress.md` records a verified terminal stop condition (no remaining narrow batch in the scoped diff), later reactivations are idempotent: leave the shared files alone unless the scoped diff meaningfully changed.
 
 State files:
-- `.autoloop/simplify-context.md` — current objective, scope detection method, batched files, and out-of-scope guardrails.
-- `.autoloop/simplify-plan.md` — current batch findings, what to keep, what to simplify, and relevant validation commands.
-- `.autoloop/progress.md` — active batch, edits made, verification evidence, rejected attempts, and next action.
+- `{{STATE_DIR}}/simplify-context.md` — current objective, scope detection method, batched files, and out-of-scope guardrails.
+- `{{STATE_DIR}}/simplify-plan.md` — current batch findings, what to keep, what to simplify, and relevant validation commands.
+- `{{STATE_DIR}}/progress.md` — active batch, edits made, verification evidence, rejected attempts, and next action.

package/presets/autosimplify/roles/reviewer.md

@@ -8,7 +8,7 @@ Your job:
 3. Keep the plan tightly scoped and behavior-preserving.
 
 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 and current diff for the active batch. Treat the shared files as hints, not authority.
 
 Process:
@@ -16,7 +16,7 @@ Process:
    - **Reuse**: duplicated logic, hand-rolled helpers, existing utilities not being used
    - **Clarity**: unnecessary branching, awkward naming, redundant state, needless abstraction, comments that explain obvious code
    - **Efficiency**: obvious waste, repeated work, overly broad file or collection operations, hot-path clutter
-2. Write or refresh the active batch section in `.autoloop/simplify-plan.md` with:
+2. Write or refresh the active batch section in `{{STATE_DIR}}/simplify-plan.md` with:
    - scope
    - keep-as-is notes
    - simplification opportunities
@@ -24,7 +24,7 @@ Process:
    - exact validation commands the simplifier should run
    - out-of-scope guardrails
 3. If the code is already appropriately simple, write an explicit `no-op` plan explaining why no safe simplification is warranted.
-4. Update `.autoloop/progress.md` with the current review status.
+4. Update `{{STATE_DIR}}/progress.md` with the current review status.
 5. Emit `plan.ready` when the batch has a concrete plan.
 
 Emit `review.blocked` only when the scope is unclear, the diff cannot be reconstructed, or the repo lacks enough context to produce a safe plan.