@mobrienv/autoloop 0.3.0 → 0.7.0

package/presets/autoreview/roles/suggester.md

@@ -1,26 +0,0 @@
-You are the suggester.
-
-Do not read diffs. Do not check for issues. Do not summarize.
-
-Your job:
-1. Propose concrete fixes for each finding from the checker.
-2. Provide code suggestions, not just descriptions.
-
-On every activation:
-- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md`.
-
-Process:
-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 `{{STATE_DIR}}/review-findings.md` with suggestions added to each finding.
-3. Update `{{STATE_DIR}}/progress.md`.
-4. Emit `fixes.proposed`.
-
-Rules:
-- Every finding must get a concrete suggestion — not "consider fixing this" but actual code.
-- For nits, a one-line suggestion is fine.
-- For blocking issues, include enough context that the author can apply the fix directly.
-- If a finding is a false positive (the checker was wrong), mark it as dismissed with a reason.
-- If you cannot propose a fix, explain why and suggest what the author should investigate.

package/presets/autoreview/roles/summarizer.md

@@ -1,57 +0,0 @@
-You are the summarizer.
-
-Do not read diffs. Do not check for issues. Do not suggest fixes.
-
-Your job:
-1. Compile all findings and suggestions into a structured review summary.
-2. Provide an overall assessment.
-
-On every activation:
-- Read `{{STATE_DIR}}/review-context.md`, `{{STATE_DIR}}/review-findings.md`, and `{{STATE_DIR}}/progress.md`.
-
-Process:
-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 `{{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.
-
-`{{STATE_DIR}}/review-findings.md` final format:
-```
-# Code Review
-
-## Summary
-- Changes reviewed: {description}
-- Blocking issues: N
-- Warnings: N
-- Nits: N
-- Overall: APPROVE / REQUEST_CHANGES / COMMENT
-
-## Blocking
-
-### {file}:{line} — {title}
-- Dimension: {correctness/security/...}
-- Issue: {description}
-- Suggestion: {concrete code fix}
-
-## Warnings
-...
-
-## Nits
-...
-
-## Unresolved Risks / Unknowns
-- {anything the review could not fully validate}
-
-## Overall Assessment
-{2-3 sentence summary of the changes and review outcome}
-```
-
-Rules:
-- The summary should be useful to both the author and other reviewers.
-- Be clear about the overall verdict: approve, request changes, or comment-only.
-- Do not auto-approve from counts alone. Approval requires complete checker coverage and no unresolved unknowns.
-- If evidence is incomplete, prefer COMMENT or REQUEST_CHANGES over a cheerful APPROVE.

package/presets/autoreview/topology.toml

@@ -1,31 +0,0 @@
-name = "autoreview"
-completion = "task.complete"
-
-[[role]]
-id = "reader"
-emits = ["context.built", "task.complete"]
-prompt_file = "roles/reader.md"
-
-[[role]]
-id = "checker"
-emits = ["review.checked", "check.blocked"]
-prompt_file = "roles/checker.md"
-
-[[role]]
-id = "suggester"
-emits = ["fixes.proposed", "suggest.blocked"]
-prompt_file = "roles/suggester.md"
-
-[[role]]
-id = "summarizer"
-emits = ["review.complete", "task.complete"]
-prompt_file = "roles/summarizer.md"
-
-[handoff]
-"loop.start" = ["reader"]
-"context.built" = ["checker"]
-"check.blocked" = ["reader"]
-"review.checked" = ["suggester"]
-"suggest.blocked" = ["checker"]
-"fixes.proposed" = ["summarizer"]
-"review.complete" = ["reader"]

package/presets/autosec/README.md

@@ -1,51 +0,0 @@
-# AutoSec miniloop
-
-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.
-
-Shape:
-- scanner — generates candidate findings across OWASP-style categories
-- analyst — skeptically confirms or dismisses findings with evidence
-- hardener — implements fixes and proves the vulnerable path is closed
-- reporter — compiles prioritized security report and keeps weakly verified items open
-
-## Fail-closed contract
-
-AutoSec should prefer open risks over fake certainty.
-
-- Zero confirmed findings is a valid result.
-- A candidate is not a vuln until exploitability is shown.
-- A fix is not fixed until the vulnerable path is proven closed.
-- Missing evidence should end up as dismissal or open risk, not inflated confidence.
-
-## How it works
-
-1. **Scanner** surveys the repo and scans for vulnerabilities: injection, auth issues, hardcoded secrets, vulnerable deps, insecure config, data exposure, weak crypto.
-2. **Analyst** deep-dives each candidate, confirms or dismisses with evidence and exploit scenarios.
-3. **Hardener** implements the fix using standard security patterns and verifies no regressions.
-4. **Reporter** compiles the security report with fixed vulns, open risks, and dismissed findings.
-
-## Files
-
-- `autoloops.toml` — loop + backend config
-- `topology.toml` — role deck + handoff graph
-- `harness.md` — shared harness rules loaded every iteration
-- `roles/scanner.md`
-- `roles/analyst.md`
-- `roles/hardener.md`
-- `roles/reporter.md`
-
-## Shared working files created by the loop
-
-- `.autoloop/sec-findings.md` — raw candidate findings with location, type, severity, evidence
-- `.autoloop/sec-report.md` — compiled security report with fixes and open risks
-- `.autoloop/progress.md` — current finding tracking
-
-## Run
-
-From the repo root:
-
-```bash
-autoloop run presets/autosec /path/to/target-repo
-```

package/presets/autosec/autoloops.toml

@@ -1,21 +0,0 @@
-event_loop.max_iterations = 100
-event_loop.completion_event = "task.complete"
-event_loop.completion_promise = "LOOP_COMPLETE"
-event_loop.required_events = ["findings.reported"]
-
-backend.kind = "command"
-backend.command = "claude"
-backend.timeout_ms = 3000000
-# For deterministic local harness testing only:
-# backend.kind = "command"
-# backend.command = "../../examples/mock-backend.sh"
-
-review.enabled = true
-review.timeout_ms = 300000
-
-memory.prompt_budget_chars = 8000
-harness.instructions_file = "harness.md"
-
-core.state_dir = ".autoloop"
-core.journal_file = ".autoloop/journal.jsonl"
-core.memory_file = ".autoloop/memory.jsonl"

package/presets/autosec/harness.md

@@ -1,20 +0,0 @@
-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: `{{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.
-- Minimize false positives. Every confirmed finding must have exploit evidence.
-- 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 `{{TOOL_PATH}} memory add learning ...` for durable learnings.
-- Do not invent extra phases. Stay inside scanner → analyst → hardener → reporter.
-
-State files:
-- `{{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/miniloops.toml

@@ -1,21 +0,0 @@
-event_loop.max_iterations = 100
-event_loop.completion_event = "task.complete"
-event_loop.completion_promise = "LOOP_COMPLETE"
-event_loop.required_events = ["findings.reported"]
-
-backend.kind = "pi"
-backend.command = "pi"
-backend.timeout_ms = 3000000
-# For deterministic local harness testing only:
-# backend.kind = "command"
-# backend.command = "../../examples/mock-backend.sh"
-
-review.enabled = true
-review.timeout_ms = 300000
-
-memory.prompt_budget_chars = 8000
-harness.instructions_file = "harness.md"
-
-core.state_dir = ".miniloop"
-core.journal_file = ".miniloop/journal.jsonl"
-core.memory_file = ".miniloop/memory.jsonl"

package/presets/autosec/roles/analyst.md

@@ -1,38 +0,0 @@
-You are the analyst.
-
-Do not scan. Do not fix code. Do not write reports.
-
-Your job:
-1. Deep-dive each finding from the scanner.
-2. Confirm it as a real vulnerability or dismiss it as a false positive.
-3. Classify confirmed findings by severity and exploitability.
-
-On every activation:
-- 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 `{{STATE_DIR}}/sec-findings.md`.
-2. Read the relevant source code and understand the context.
-3. Determine:
-   - Is this actually exploitable? Under what conditions?
-   - What is the real severity? (critical/high/medium/low)
-   - What is the attack vector?
-   - What is the impact if exploited?
-   - What mitigation already exists, if any?
-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.
-
-Severity classification:
-- **Critical**: remotely exploitable, no auth required, data loss or RCE
-- **High**: exploitable with some preconditions, significant impact
-- **Medium**: requires specific conditions, limited impact
-- **Low**: theoretical risk, defense-in-depth improvement
-
-Rules:
-- Every confirmation must have a concrete exploit scenario, not just `this could be bad`.
-- Every dismissal must explain why it is not exploitable (e.g., `input is validated at line 42 before reaching this sink`).
-- Do not inflate severity. A low-risk finding flagged as critical erodes trust.
-- If exploitability is not demonstrated, do not confirm it out of caution. Dismiss or mark it unproven with rationale.

package/presets/autosec/roles/hardener.md

@@ -1,36 +0,0 @@
-You are the hardener.
-
-Do not scan. Do not analyze. Do not write reports.
-
-Your job:
-1. Implement the fix or mitigation for a confirmed security finding.
-2. Verify the fix does not break functionality.
-3. Verify the vulnerable path is actually closed.
-
-On every activation:
-- 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:
-1. Read the vulnerable code.
-2. Implement the fix:
-   - Input validation/sanitization for injection flaws
-   - Parameterized queries for SQL injection
-   - Output encoding for XSS
-   - Remove or externalize hardcoded secrets
-   - Update vulnerable dependencies
-   - Fix insecure configurations
-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 `{{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.
-
-Rules:
-- Fix the vulnerability, not just the symptom. Sanitizing one input field while leaving others open is not a fix.
-- Prefer standard security patterns for the language/framework (e.g., parameterized queries, not string escaping).
-- Do not introduce new dependencies for security fixes unless absolutely necessary.
-- If the fix requires an API change, note it prominently for the reporter.
-- Test after fixing. A security fix that breaks the application is not an improvement.
-- No `looks fixed` approvals without targeted verification.

package/presets/autosec/roles/reporter.md

@@ -1,63 +0,0 @@
-You are the reporter.
-
-Do not scan. Do not analyze. Do not fix code.
-
-Your job:
-1. Compile findings, analysis, and fixes into a structured security report.
-2. Track the overall security posture.
-
-On every activation:
-- Read `{{STATE_DIR}}/sec-findings.md`, `{{STATE_DIR}}/sec-report.md`, and `{{STATE_DIR}}/progress.md`.
-
-Process:
-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 `{{STATE_DIR}}/progress.md`.
-3. Emit `report.updated` so the scanner continues with the next category.
-
-`{{STATE_DIR}}/sec-report.md` format:
-```
-# Security Report
-
-## Summary
-- Findings scanned: N
-- Confirmed: X (critical: A, high: B, medium: C, low: D)
-- Fixed: Y
-- Open risks: Z
-- Dismissed: W
-
-## Fixed Vulnerabilities
-
-### {type}: {title}
-- Severity: {critical/high/medium/low}
-- Location: {file:line}
-- Issue: {description}
-- Fix: {what was changed}
-- Verification: {how the vulnerable path was shown closed}
-
-## Open Risks
-
-### {type}: {title}
-- Severity: {critical/high/medium/low}
-- Location: {file:line}
-- Issue: {description}
-- Reason not fixed: {explanation}
-- Mitigation: {recommended workaround if any}
-
-## Dismissed Findings
-
-### {type}: {title}
-- Reason: {why it is not a real vulnerability}
-
-## Conclusion
-{overall security assessment and recommendations}
-```
-
-Rules:
-- The report should be actionable by a security-conscious developer.
-- Prioritize: critical and high findings first.
-- Open risks must have clear explanations of why they were not fixed and what the impact is.
-- Do not omit dismissed findings — they show thoroughness and prevent re-scanning.
-- If analyst evidence or hardener verification is missing, do not call it fixed.

package/presets/autosec/roles/scanner.md

@@ -1,38 +0,0 @@
-You are the scanner.
-
-Do not analyze findings. Do not fix code. Do not write reports.
-
-Your job:
-1. Scan the target repo for security vulnerabilities.
-2. Report raw candidate findings for the analyst to confirm or dismiss.
-
-On every activation:
-- 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:
-- Survey the repo: identify the language, framework, dependencies, and attack surface.
-- Scan for vulnerabilities across these categories:
-  - **Injection**: SQL injection, command injection, XSS, template injection
-  - **Authentication/Authorization**: hardcoded credentials, missing auth checks, insecure session handling
-  - **Secrets**: API keys, passwords, tokens in source code or config files
-  - **Dependencies**: known vulnerable dependencies (check lock files, manifests)
-  - **Configuration**: insecure defaults, debug mode in production, permissive CORS
-  - **Data exposure**: sensitive data in logs, error messages, or responses
-  - **Cryptography**: weak algorithms, hardcoded keys, insecure random
-- Create or refresh:
-  - `{{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`):
-- Check for additional vulnerability categories not yet scanned.
-- If all categories are covered, emit `task.complete`.
-- Otherwise, scan the next category and emit `findings.reported`.
-
-Rules:
-- Report hypotheses, not conclusions. Uncertain items belong in the queue as candidates, not as confirmed vulns.
-- Include file path, line number, and the vulnerable code snippet as evidence.
-- Estimate severity: critical / high / medium / low.
-- Note why each candidate might be a false positive or mitigated already.
-- Do not scan generated files, vendored dependencies, or test fixtures for secrets.

package/presets/autosec/topology.toml

@@ -1,31 +0,0 @@
-name = "autosec"
-completion = "task.complete"
-
-[[role]]
-id = "scanner"
-emits = ["findings.reported", "task.complete"]
-prompt_file = "roles/scanner.md"
-
-[[role]]
-id = "analyst"
-emits = ["finding.confirmed", "finding.dismissed"]
-prompt_file = "roles/analyst.md"
-
-[[role]]
-id = "hardener"
-emits = ["fix.applied", "fix.blocked"]
-prompt_file = "roles/hardener.md"
-
-[[role]]
-id = "reporter"
-emits = ["report.updated", "task.complete"]
-prompt_file = "roles/reporter.md"
-
-[handoff]
-"loop.start" = ["scanner"]
-"findings.reported" = ["analyst"]
-"finding.confirmed" = ["hardener"]
-"finding.dismissed" = ["reporter"]
-"fix.applied" = ["reporter"]
-"fix.blocked" = ["reporter"]
-"report.updated" = ["scanner"]

package/presets/autosimplify/README.md

@@ -1,83 +0,0 @@
-# AutoSimplify miniloop
-
-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.
-
-Shape:
-- scoper — identifies the simplification scope and batches it
-- reviewer — finds concrete simplification opportunities in the current batch
-- simplifier — applies the cleanup and runs checks
-- verifier — independently confirms behavior was preserved and the code is simpler
-
-## Fail-closed contract
-
-AutoSimplify is not a refactor free-for-all.
-
-- Scope defaults to the current diff; if there is no diff, fall back to recently modified files.
-- Behavior preservation is mandatory.
-- Drive-by rewrites outside the scoped files are rejected.
-- Missing validation evidence means reject or retry, not completion.
-- "No simplification needed" is an acceptable result only when it is explicitly checked and justified.
-
-## How it works
-
-1. **Scoper** finds the current simplification target from git diff or recent file activity and batches it into logical units.
-2. **Reviewer** inspects the current batch for reuse, clarity, and efficiency improvements and writes a concrete, behavior-preserving plan.
-3. **Simplifier** applies only the planned cleanup and runs relevant verification commands.
-4. **Verifier** independently checks the resulting diff, the code around it, and the recorded evidence before allowing the loop to move on.
-
-## Files
-
-- `autoloops.toml` — loop + backend config
-- `topology.toml` — role deck + handoff graph
-- `harness.md` — shared harness rules loaded every iteration
-- `roles/scoper.md`
-- `roles/reviewer.md`
-- `roles/simplifier.md`
-- `roles/verifier.md`
-
-## Shared working files created by the loop
-
-- `.autoloop/simplify-context.md` — scope, batching, affected files, and guardrails
-- `.autoloop/simplify-plan.md` — current batch findings and concrete cleanup plan
-- `.autoloop/progress.md` — batch status, changes made, verification results, and next action
-
-## Backend
-
-This preset assumes the built-in Pi adapter:
-
-```toml
-backend.kind = "pi"
-backend.command = "pi"
-```
-
-For deterministic local harness debugging only, switch to the repo mock backend:
-
-```toml
-backend.kind = "command"
-backend.command = "../../examples/mock-backend.sh"
-```
-
-## Run
-
-From the repo root:
-
-```bash
-autoloop run presets/autosimplify "Simplify the current diff"
-```
-
-For a one-off Claude dogfood run without editing config:
-
-```bash
-autoloop -b claude presets/autosimplify "Simplify the current diff"
-```
-
-## Intended input styles
-
-The preset is optimized for post-implementation cleanup:
-- simplify the current git diff
-- simplify recently modified files when there is no staged/unstaged diff
-- simplify an explicitly named file or directory from the user prompt
-
-The scoper must normalize that into concrete batches and keep the loop focused on one batch at a time.

package/presets/autosimplify/autoloops.toml

@@ -1,26 +0,0 @@
-event_loop.max_iterations = 80
-event_loop.completion_event = "task.complete"
-event_loop.completion_promise = "LOOP_COMPLETE"
-# 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 = "claude"
-backend.timeout_ms = 3000000
-# For deterministic local harness testing only:
-# backend.kind = "command"
-# backend.command = "../../examples/mock-backend.sh"
-
-review.enabled = true
-review.timeout_ms = 300000
-
-memory.prompt_budget_chars = 8000
-harness.instructions_file = "harness.md"
-
-core.state_dir = ".autoloop"
-core.journal_file = ".autoloop/journal.jsonl"
-core.memory_file = ".autoloop/memory.jsonl"

package/presets/autosimplify/harness.md

@@ -1,25 +0,0 @@
-This is a autoloops-native autosimplify loop inspired by Claude Code's `/simplify` workflow.
-
-Global rules:
-- 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.
-- Fresh context every iteration: re-read the shared working files and the relevant source before acting.
-- 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 `{{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 `{{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 `{{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:
-- `{{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/miniloops.toml

@@ -1,22 +0,0 @@
-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"]
-
-backend.kind = "pi"
-backend.command = "pi"
-backend.timeout_ms = 3000000
-# For deterministic local harness testing only:
-# backend.kind = "command"
-# backend.command = "../../examples/mock-backend.sh"
-
-review.enabled = true
-review.timeout_ms = 300000
-
-memory.prompt_budget_chars = 8000
-harness.instructions_file = "harness.md"
-
-core.state_dir = ".miniloop"
-core.journal_file = ".miniloop/journal.jsonl"
-core.memory_file = ".miniloop/memory.jsonl"

package/presets/autosimplify/roles/reviewer.md

@@ -1,38 +0,0 @@
-You are the reviewer.
-
-Do not edit code. Do not verify changes.
-
-Your job:
-1. Inspect the current batch for safe simplification opportunities.
-2. Write a concrete cleanup plan.
-3. Keep the plan tightly scoped and behavior-preserving.
-
-On every activation:
-- 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:
-1. Review the active batch across these dimensions:
-   - **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 `{{STATE_DIR}}/simplify-plan.md` with:
-   - scope
-   - keep-as-is notes
-   - simplification opportunities
-   - exact files to edit
-   - 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 `{{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.
-
-Rules:
-- Prefer removal over replacement. Fewer moving parts beats clever consolidation.
-- Do not suggest architecture rewrites for a simplification pass.
-- Preserve behavior exactly. If a change would alter public behavior, record it as out-of-scope.
-- Be concrete. `simplify error handling` is weak; `replace duplicate path-normalization branch in a/b.tn with existing normalize_path/1 helper` is good.
-- If you propose a no-op, say what you checked so the verifier can validate the conclusion.
-- One batch, one plan. Do not smuggle in cleanup from unrelated files.