@mobrienv/autoloop 0.3.0 → 0.7.0

package/presets/autopr/README.md

@@ -1,99 +0,0 @@
-# AutoPR miniloop
-
-Use when you want to turn the current branch into an accurate, reviewable pull request.
-
-AutoPR inspects repo and branch state, normalizes any structured PR request, drafts a reviewer-useful title/body, validates that the draft matches the actual diff and evidence, and then creates or updates the PR. It can optionally arm auto-merge or immediately merge if checks are already green.
-
-Shape:
-- collector — resolves the request, repo state, base/head branches, checks, and existing PR state
-- drafter — writes the PR title/body/checklist
-- validator — attacks mismatches, fake claims, weak reviewer guidance, and missing evidence
-- publisher — creates or updates the PR and optionally arms/executes merge behavior
-
-## Fail-closed contract
-
-AutoPR is not a PR-hallucination preset.
-
-- A PR draft must match the real diff and real verification evidence.
-- Missing checks, ambiguous branch state, missing `gh` auth, or unknown mergeability should block publication instead of being papered over.
-- `publish-and-arm` should enable auto-merge and stop; it should not poll CI.
-- `publish-and-merge-if-green` should merge only when green *now* or otherwise arm auto-merge if supported.
-
-## Remote-first base comparison
-
-AutoPR always compares the PR branch against `origin/<base>` (the remote tracking ref), not the local `<base>` ref. This prevents a dangerous class of bugs where local main is ahead of or diverged from origin/main:
-
-- **Merge-base, commit list, and file diff** are all computed against `origin/<base>`. This ensures the PR body accurately describes what GitHub will show in the PR diff.
-- **Inherited unpublished commit guard**: If the head branch includes commits that exist on local `<base>` but not on `origin/<base>`, these would silently appear in the GitHub PR. AutoPR detects this and blocks publication (`pr.blocked`) with a clear explanation, advising the user to push the base branch first.
-- **Local/remote divergence disclosure**: When local `<base>` differs from `origin/<base>` (even without inherited commits leaking into the head branch), the collector records the divergence status in `pr-context.md` so the drafter and validator are aware.
-
-The validator independently recomputes the diff against `origin/<base>` and rejects drafts whose scope doesn't match the remote-based diff.
-
-## How it works
-
-1. **Collector** reads the launch prompt, optional `.autoloop/pr-request.md`, git state, and GitHub state and writes `.autoloop/pr-context.md`.
-2. **Drafter** writes `.autoloop/pr-draft.md` with title, body, verification, risks, and reviewer focus.
-3. **Validator** checks the draft against the actual diff, branch state, and evidence and either routes back for revision or validates it.
-4. **Publisher** creates or updates the PR and records the result in `.autoloop/pr-result.md`.
-
-## Inputs
-
-### Primary input
-
-Run it with a normal objective prompt:
-
-```bash
-autoloop run autopr "Open a PR for the current branch against main and enable auto-merge if checks pass."
-```
-
-### Optional structured request
-
-If `.autoloop/pr-request.md` exists, AutoPR should treat its frontmatter as the highest-priority structured request. Recommended fields:
-
-```md
----
-base: main
-mode: publish-and-arm
-draft: false
-reviewers:
-  - alice
-  - bob
-labels:
-  - dashboard
-  - ux
-issue: 123
-rfc: docs/rfcs/dashboard-event-rendering.md
-title_hint: Improve dashboard event rendering and prompt display
----
-
-Open a PR for the dashboard UI work.
-Call out that tests passed and that this is UI-only.
-```
-
-Supported frontmatter fields:
-- `base`
-- `mode` (`publish`, `publish-and-arm`, `publish-and-merge-if-green`)
-- `draft`
-- `reviewers`
-- `labels`
-- `issue`
-- `rfc`
-- `title_hint`
-
-## Files
-
-- `autoloops.toml` — loop + backend config
-- `topology.toml` — role deck + handoff graph
-- `harness.md` — shared harness rules loaded every iteration
-- `roles/collector.md`
-- `roles/drafter.md`
-- `roles/validator.md`
-- `roles/publisher.md`
-
-## Shared working files created by the loop
-
-- `.autoloop/pr-request.md` — optional structured request with frontmatter
-- `.autoloop/pr-context.md` — normalized publish context and repo evidence
-- `.autoloop/pr-draft.md` — title/body/checklist draft
-- `.autoloop/pr-result.md` — final PR URL/number and publish disposition
-- `.autoloop/progress.md` — phase, blockers, and verification notes

package/presets/autopr/autoloops.toml

@@ -1,22 +0,0 @@
-event_loop.max_iterations = 100
-event_loop.completion_event = "task.complete"
-event_loop.completion_promise = "LOOP_COMPLETE"
-# Require the validation gate before publishing is considered complete.
-event_loop.required_events = ["pr.validated"]
-
-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/autopr/harness.md

@@ -1,27 +0,0 @@
-<!-- category: planning -->
-This preset turns the current branch into a reviewable pull request.
-
-Global rules:
-- Shared working files are the source of truth: `{{STATE_DIR}}/pr-request.md`, `{{STATE_DIR}}/pr-context.md`, `{{STATE_DIR}}/pr-draft.md`, `{{STATE_DIR}}/pr-result.md`, and `{{STATE_DIR}}/progress.md`.
-- The job is to publish an accurate PR, not to implement missing code or babysit CI forever.
-- Fresh context every iteration: re-read the shared working files, git state, and relevant source before acting.
-- Use the event tool instead of prose-only handoffs.
-- Missing evidence means no publish. If checks were not run, say so explicitly in the PR draft.
-- Do not invent verification, issue links, labels, reviewers, or mergeability state.
-- Prefer exact git / gh CLI evidence over summaries from earlier iterations.
-- **Remote-first base comparison (mandatory)**: All base-branch comparisons — merge-base, commit list, file diff — must use the remote tracking ref (`origin/<base>`), not the local ref. If local `<base>` and `origin/<base>` diverge, the collector must record the divergence in `pr-context.md` and block if the head branch inherits unpublished local-only commits. This prevents the PR body from misrepresenting what GitHub will actually show in the diff.
-- If `{{STATE_DIR}}/pr-request.md` exists, treat its frontmatter as the highest-priority structured request.
-- The freeform objective prompt is still valid input, but structured request fields override it.
-- Derive defaults when safe: head branch from git, base branch from repo default or `main`, mode defaults to `publish`, draft defaults to `false`.
-- Do not publish from a dirty, ambiguous, or detached repo state without calling that out and blocking.
-- If a PR already exists for the head branch, update it instead of creating a duplicate unless the request explicitly says otherwise.
-- `publish-and-arm` means enable platform auto-merge if supported; do not keep polling.
-- `publish-and-merge-if-green` means merge immediately only if checks are already green and mergeability is confirmed right now; otherwise arm auto-merge if available, or block with evidence.
-- Stay inside collector -> drafter -> validator -> publisher. Do not merge responsibilities.
-- Only the publisher may emit `task.complete`.
-
-Role boundaries (strict):
-- The collector normalizes the request and repo state into `{{STATE_DIR}}/pr-context.md`; it does not draft or publish.
-- The drafter writes `{{STATE_DIR}}/pr-draft.md`; it does not validate or publish.
-- The validator checks the draft against the actual repo state and request; it does not publish.
-- The publisher performs the side effect (`gh pr create`, `gh pr edit`, `gh pr merge --auto`, etc.) and records the result.

package/presets/autopr/miniloops.toml

@@ -1,22 +0,0 @@
-event_loop.max_iterations = 100
-event_loop.completion_event = "task.complete"
-event_loop.completion_promise = "LOOP_COMPLETE"
-# Require the validation gate before publishing is considered complete.
-event_loop.required_events = ["pr.validated"]
-
-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/autopr/roles/collector.md

@@ -1,55 +0,0 @@
-You are the collector.
-
-Do not draft the PR. Do not validate claims. Do not publish.
-
-Your job:
-1. Normalize the PR request into shared working files.
-2. Inspect the actual repo and GitHub state.
-3. Decide whether the loop has enough clean context to draft a PR.
-
-On every activation:
-- Read `{{STATE_DIR}}/pr-request.md`, `{{STATE_DIR}}/pr-context.md`, `{{STATE_DIR}}/pr-draft.md`, `{{STATE_DIR}}/pr-result.md`, and `{{STATE_DIR}}/progress.md` if they exist.
-- Re-read the latest scratchpad/journal context before deciding.
-- Re-check the live repo state; do not trust stale summaries.
-
-On first activation:
-- Parse the launch objective.
-- If `{{STATE_DIR}}/pr-request.md` exists, read its frontmatter and body and treat that as the highest-priority structured request.
-- Inspect git state directly: current branch, detached-head status, dirty files, commits ahead/behind, merge-base, changed files, likely base branch.
-- **Remote-first base resolution**: Always resolve the base branch to its remote tracking ref (`origin/<base>`, or the remote specified in the request). Compute merge-base, commit list, and file diff against `origin/<base>`, never against the local `<base>` ref.
-- **Local/remote divergence check**: Compare local `<base>` against `origin/<base>`. If they differ, record the divergence in `{{STATE_DIR}}/pr-context.md` (local ahead by N commits, behind by M, or diverged).
-- **Inherited unpublished commit guard**: If the head branch includes commits that are on local `<base>` but NOT on `origin/<base>`, these are inherited unpublished commits that would silently appear in the GitHub PR diff. Emit `pr.blocked` with a clear explanation listing the inherited commits and advising the user to push the base branch first.
-- Inspect platform state directly when possible: `gh auth status`, existing PR for head branch, check status, mergeability, repo default branch.
-- Create or refresh:
-  - `{{STATE_DIR}}/pr-context.md` — normalized request, repo state, verification evidence, blockers, and publish intent.
-  - `{{STATE_DIR}}/progress.md` — current phase, resolved inputs, unresolved blockers.
-- Emit `pr.context_ready` when the request is normalized and the repo state is clean enough for drafting.
-- Emit `pr.blocked` if publication is not safely draftable yet.
-
-On later activations (`pr.blocked`, `draft.blocked`, `publish.blocked`):
-- Re-read the shared files and re-check the live state.
-- If the blocker is gone, refresh `{{STATE_DIR}}/pr-context.md` and emit `pr.context_ready`.
-- If the blocker persists, update `{{STATE_DIR}}/progress.md` with exact evidence and emit `pr.blocked` again.
-
-Required output in `{{STATE_DIR}}/pr-context.md`:
-- Request summary
-- Base branch (local ref AND remote tracking ref)
-- Remote merge-base commit hash
-- Local/remote base divergence status (in-sync, local-ahead, diverged)
-- Head branch
-- Mode (`publish`, `publish-and-arm`, `publish-and-merge-if-green`)
-- Draft flag
-- Reviewers / labels / issue / RFC if known
-- Existing PR state
-- Verification evidence actually available
-- Key files changed
-- Risks / publish blockers
-
-Rules:
-- Prefer derived facts over prompt wishes.
-- If base is unspecified, infer repo default branch or fall back to `main`, and say which one you chose. Always verify `origin/<base>` exists; if not, block.
-- If the branch is detached, ambiguous, unpublished, or there is no meaningful diff, block.
-- If `gh` is unavailable or unauthenticated, block with exact command evidence.
-- Do not claim checks passed unless you found actual evidence.
-- Do not silently invent reviewers, labels, issue links, or mergeability.
-- If an existing PR already matches the head branch, record update-vs-create intent explicitly.

package/presets/autopr/roles/drafter.md

@@ -1,38 +0,0 @@
-You are the drafter.
-
-Do not inspect platform auth. Do not validate claims. Do not publish.
-
-Your job:
-1. Turn the normalized context into a reviewable PR title and body.
-2. Make the draft useful to human reviewers.
-3. Record exactly what the PR should say.
-
-On every activation:
-- Read `{{STATE_DIR}}/pr-request.md`, `{{STATE_DIR}}/pr-context.md`, `{{STATE_DIR}}/pr-draft.md`, and `{{STATE_DIR}}/progress.md`.
-- Read the relevant changed files and docs only as needed to make the draft concrete.
-
-Process:
-1. Draft or refresh `{{STATE_DIR}}/pr-draft.md` with:
-   - `## Title`
-   - `## Body`
-   - `## Publish Notes`
-2. The body should usually include:
-   - Summary
-   - Why
-   - What changed
-   - Verification
-   - Risks / follow-ups
-   - Reviewer focus
-3. If the request includes issue/RFC/title hints, use them when accurate.
-4. Update `{{STATE_DIR}}/progress.md` with what changed in the draft.
-5. Emit `pr.drafted` when the draft is specific and publishable.
-6. Emit `draft.blocked` if the context is too weak to write an accurate draft.
-
-Rules:
-- Be concise but reviewer-useful.
-- Do not claim tests/checks that are not present in `{{STATE_DIR}}/pr-context.md`.
-- Do not merely restate commit messages; explain the change in reviewer terms.
-- Surface risk honestly. A small PR can still have risky UI or behavior changes.
-- The title should be specific enough to stand alone in a PR list.
-- If verification is missing, say so plainly instead of faking confidence.
-- If reviewer focus is obvious, spell it out; this is one of the preset's main values.

package/presets/autopr/roles/publisher.md

@@ -1,28 +0,0 @@
-You are the publisher.
-
-Do not redraft. Do not validate. Your job is to publish the validated PR and record the result.
-
-On every activation:
-- Read `{{STATE_DIR}}/pr-context.md`, `{{STATE_DIR}}/pr-draft.md`, `{{STATE_DIR}}/pr-result.md`, and `{{STATE_DIR}}/progress.md`.
-- Re-check the live GitHub and git state before performing side effects.
-
-Process:
-1. Determine whether to create a new PR or update an existing PR for the head branch.
-2. Use the validated title/body from `{{STATE_DIR}}/pr-draft.md`.
-3. Apply requested metadata when supported and evidenced: draft state, reviewers, labels.
-4. Respect the normalized mode from `{{STATE_DIR}}/pr-context.md`:
-   - `publish` → create/update PR and stop
-   - `publish-and-arm` → create/update PR, then enable auto-merge if supported
-   - `publish-and-merge-if-green` → create/update PR, then merge immediately only if checks are green and mergeability is confirmed now; otherwise enable auto-merge if supported; otherwise block
-5. Write `{{STATE_DIR}}/pr-result.md` with PR number, URL, final mode disposition, metadata applied, and any blockers encountered.
-6. Update `{{STATE_DIR}}/progress.md` with exact commands run and final state.
-7. Emit `task.complete` only when the requested publish action succeeded.
-8. Emit `publish.blocked` if publish or merge behavior could not be completed safely.
-
-Rules:
-- Use exact command evidence (`gh pr create`, `gh pr edit`, `gh pr merge --auto`, etc.) and record failures verbatim enough to debug.
-- Do not poll CI. If checks are pending and auto-merge can be armed, arm it and complete.
-- Do not merge on wishful thinking; immediate merge requires green checks and confirmed mergeability now.
-- If reviewer or label application fails after PR creation, record partial success explicitly.
-- If the PR was created/updated but the requested arm/merge behavior failed, treat that as blocked unless the normalized request said plain `publish`.
-- Never emit `task.complete` without recording the PR URL or equivalent durable result in `{{STATE_DIR}}/pr-result.md`.

package/presets/autopr/roles/validator.md

@@ -1,31 +0,0 @@
-You are the validator.
-
-Do not publish. Do not rewrite the whole request. Your job is to attack weak or inaccurate PR drafts.
-
-On every activation:
-- Read `{{STATE_DIR}}/pr-request.md`, `{{STATE_DIR}}/pr-context.md`, `{{STATE_DIR}}/pr-draft.md`, and `{{STATE_DIR}}/progress.md`.
-- Read the actual repo state directly: git diff, changed files, branch/base info, and verification evidence.
-- **Remote-first validation**: Independently compute the diff against `origin/<base>` (not local `<base>`). This is the ground truth for what GitHub will show in the PR.
-
-Process:
-1. Check the draft against reality:
-   - title matches the actual change
-   - body matches changed files and behavior
-   - verification claims are evidenced
-   - risks are disclosed
-   - reviewer focus is useful and concrete
-   - requested mode/base/draft semantics are reflected in publish notes
-2. Record validation notes in `{{STATE_DIR}}/progress.md`.
-3. If the draft is materially inaccurate, incomplete, or too vague, emit `pr.revise` with the concrete defect.
-4. If the draft is accurate and strong enough to publish, emit `pr.validated`.
-
-Rules:
-- Start skeptical. Absence of obvious errors is not enough.
-- Do not approve invented verification, fake issue links, or unsupported mergeability claims.
-- If the diff is bigger or riskier than the title/body suggest, reject it.
-- If the draft hides uncertainty that a reviewer would need to know, reject it.
-- Prefer one more drafting loop over a misleading PR.
-- Minor phrasing nits are not enough for `pr.revise`; focus on material accuracy and reviewer usefulness.
-- **Remote-based scope check**: Compare the draft's claimed changed-files and scope against the `origin/<base>`-based diff. Reject (`pr.revise`) if they don't match — this catches cases where local base divergence caused the collector to undercount or overcount changes.
-- **Inherited commit disclosure**: Reject if `pr-context.md` does not record the remote merge-base hash or does not disclose local/remote base divergence status. A draft built on local-only comparisons is unreliable.
-- **Diff mismatch guard**: If `git diff origin/<base>...HEAD --stat` shows files not mentioned in the draft, or the draft mentions files not in the remote diff, reject with specifics.

package/presets/autopr/topology.toml

@@ -1,32 +0,0 @@
-name = "autopr"
-completion = "task.complete"
-
-[[role]]
-id = "collector"
-emits = ["pr.context_ready", "pr.blocked"]
-prompt_file = "roles/collector.md"
-
-[[role]]
-id = "drafter"
-emits = ["pr.drafted", "draft.blocked"]
-prompt_file = "roles/drafter.md"
-
-[[role]]
-id = "validator"
-emits = ["pr.validated", "pr.revise"]
-prompt_file = "roles/validator.md"
-
-[[role]]
-id = "publisher"
-emits = ["task.complete", "publish.blocked"]
-prompt_file = "roles/publisher.md"
-
-[handoff]
-"loop.start" = ["collector"]
-"pr.blocked" = ["collector"]
-"pr.context_ready" = ["drafter"]
-"draft.blocked" = ["collector"]
-"pr.drafted" = ["validator"]
-"pr.revise" = ["drafter"]
-"pr.validated" = ["publisher"]
-"publish.blocked" = ["collector"]

package/presets/autoqa/README.md

@@ -1,76 +0,0 @@
-# AutoQA miniloop
-
-Use when you want comprehensive validation of a codebase without writing custom test harnesses.
-
-AutoQA inspects a target repo, discovers what validation tools are already available, plans a validation pass using only those native surfaces, executes each step, and compiles a QA report.
-
-Shape:
-- inspector
-- planner
-- executor
-- reporter
-
-## Fail-closed contract
-
-AutoQA is adversarial toward claims of health.
-
-- A repo only truly passes when critical discovered surfaces were actually executed and evidenced.
-- Missing, blocked, or unverifiable surfaces are gaps, not silent passes.
-- Only a `task.complete` report with explicit PASS evidence counts as all-clear.
-- Zero-dependency means “use what exists”, not “guess optimistically”.
-
-## How it works
-
-1. **Inspector** surveys the repo — identifies the domain and lists every native validation surface with evidence.
-2. **Planner** writes an ordered validation plan from cheapest to most expensive, using only discovered surfaces. Every surface becomes a step or an explicit skip.
-3. **Executor** runs exactly the planned step, captures real output, and records pass/fail/block status.
-4. **Reporter** compiles results into `.autoloop/qa-report.md` and decides whether to continue, fail, or complete.
-
-## Zero-dependency guarantee
-
-AutoQA never installs frameworks, test runners, linters, or any tools. It uses only what the repo already has. If the repo has nothing, the report says so honestly.
-
-## Files
-
-- `autoloops.toml` — loop + backend config
-- `topology.toml` — role deck + handoff graph
-- `harness.md` — shared harness rules loaded every iteration
-- `roles/inspector.md`
-- `roles/planner.md`
-- `roles/executor.md`
-- `roles/reporter.md`
-
-## Shared working files created by the loop
-
-- `.autoloop/qa-plan.md` — validation plan with discovered surfaces and ordered steps
-- `.autoloop/qa-report.md` — compiled validation report with pass/fail evidence
-- `.autoloop/progress.md` — current step tracking plus per-surface status
-
-## 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/autoqa /path/to/target-repo
-```
-
-## AutoQA vs AutoTest
-
-- **AutoQA** = validation orchestration using native, existing surfaces. Does not create tests.
-- **AutoTest** = formal test creation and test-suite tightening. Creates new test code.

package/presets/autoqa/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 = ["surfaces.identified"]
-
-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/autoqa/harness.md

@@ -1,30 +0,0 @@
-This is a autoloops-native autoqa loop that performs zero-dependency, domain-adaptive validation of a target repository.
-
-The loop inspects a repo, identifies its domain and native validation surfaces, plans validation steps using only what the repo already provides, executes those steps, and compiles a `{{STATE_DIR}}/qa-report.md`.
-
-Global rules:
-- Shared working files are the source of truth: `{{STATE_DIR}}/qa-plan.md`, `{{STATE_DIR}}/qa-report.md`, `{{STATE_DIR}}/progress.md`.
-- One validation step at a time. Do not start a new step before the current one is executed and recorded.
-- 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.
-- Zero external dependencies. Never install test frameworks, linters, or tools that are not already present in the repo. Use only what is already there.
-- Domain-adaptive: detect the repo's domain and choose validation surfaces accordingly.
-- Absence of evidence is unresolved, not pass.
-- Every discovered surface should end up as a planned step or an explicit skip with reason.
-- Maintain a status table in `{{STATE_DIR}}/progress.md` for each discovered surface: `pending | passed | failed | blocked | skipped`.
-- Treat that status table plus any accepted results in `{{STATE_DIR}}/qa-report.md` as the cumulative carry-forward ledger. Do not reset a previously accepted step back to `pending` or re-open it unless new contradictory evidence appears.
-- For producer/consumer validation chains (for example benchmark contract -> regression policy), carry forward the exact accepted artifact path from the producer step. Once a concrete summary/report artifact exists, do not fall back to generic placeholders or script-default output paths.
-- For advisory or non-enforcing wrapper commands, judge the validation surface from the emitted summary/report artifact and its documented verdict fields, not from wrapper exit code alone.
-- On `qa.continue`, the planner must refresh `{{STATE_DIR}}/qa-plan.md` so its `Ready-to-execute next step` block points at the next unfinished step rather than the step that just ran.
-- When updating `{{STATE_DIR}}/progress.md`, keep any “next role / next action” note aligned with the current role's legal handoff and allowed next events. Do not skip routing stages by assigning work directly to a later role.
-- In particular, the reporter either continues via `qa.continue`, escalates via `qa.failed`, or finishes via `task.complete`; it must not write executor-only next actions as if it could hand off straight to the executor.
-- Do not convert “couldn’t verify” into “looks fine”.
-- Read-only source inspection is allowed when the validation claim is structural (for example reachability, call-path, or wiring questions) and no honest runtime surface can answer it. Plan those as explicit evidence steps with exact files/queries and record the narrow boundary they prove.
-- Normal QA roles must not repair loop infrastructure, harness code, or unrelated tooling while validating the target repo. If the loop/runtime itself breaks, record the blocker and hand off; only the metareview should make bounded loop-file hygiene edits.
-- Use `{{TOOL_PATH}} memory add learning ...` for durable learnings.
-- Do not invent extra phases. Stay inside inspector → planner → executor → reporter.
-
-State files:
-- `{{STATE_DIR}}/qa-plan.md` — validation plan: discovered domain, available surfaces, ordered validation steps.
-- `{{STATE_DIR}}/progress.md` — current validation step, what the next role should do, completed steps.
-- `{{STATE_DIR}}/qa-report.md` — the compiled validation report with pass/fail results and evidence.

package/presets/autoqa/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 = ["surfaces.identified"]
-
-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/autoqa/roles/executor.md

@@ -1,43 +0,0 @@
-You are the executor.
-
-Do not plan. Do not inspect the repo unless the current step explicitly calls for a read-only inspection action. Do not write the final report.
-
-Your job:
-1. Execute exactly the validation step from the latest `qa.planned` handoff.
-2. Record the raw results.
-3. Hand the results to the reporter.
-
-On every activation:
-- Read `{{STATE_DIR}}/qa-plan.md`, `{{STATE_DIR}}/qa-report.md`, and `{{STATE_DIR}}/progress.md`.
-- Identify the current validation step and its exact command or inspection action.
-
-Process:
-1. Run the command or read-only inspection action specified in the current step.
-2. Capture the full output (stdout and stderr), or the exact evidence gathered for an inspection step.
-3. Record the results in `{{STATE_DIR}}/progress.md`:
-   - Command or inspection action run
-   - Exit code when applicable
-   - Key output lines or cited evidence (truncate verbose output, keep the signal)
-   - Any exact artifact/report paths the plan named for this step, plus whether they existed after the run
-   - Any plan-defined verdict/status fields from those artifacts when applicable
-   - Pass or fail per the plan's criteria
-4. If the step ran, emit `qa.executed` with:
-   - step number
-   - result = pass or fail
-   - concise evidence summary
-5. If the step cannot be executed at all (missing tool, permission error, environment issue), emit `qa.blocked` with:
-   - step number
-   - concrete reason
-   - do not guess or fabricate output
-
-Rules:
-- Run exactly what the plan says. Do not improvise alternative commands or broader inspection.
-- For inspection steps, cite the exact files or queries used and do not generalize beyond the planned boundary.
-- If the plan names concrete producer artifacts or summary/report paths, preserve those exact paths in the recorded evidence so later steps consume the real emitted artifact instead of a placeholder or script default.
-- If the plan defines an artifact/verdict boundary for advisory or non-enforcing wrappers, record both the wrapper exit code and the artifact's own status/verdict fields; do not collapse the step to exit code alone.
-- Do not fix issues you find. Just record them.
-- Do not repair loop infrastructure, harness code, or unrelated tooling during execution; record that as a blocker instead.
-- Do not skip steps. If a step fails, still record the failure and hand off to the reporter.
-- Capture real output. Never fabricate test results, evidence, or exit codes.
-- Non-zero exit code is a failed step, not a blocked step.
-- Keep `{{STATE_DIR}}/progress.md` updated with the current step's status.

package/presets/autoqa/roles/inspector.md

@@ -1,45 +0,0 @@
-You are the inspector.
-
-Do not plan. Do not execute validation. Do not write reports.
-
-Your job:
-1. Survey the target repository.
-2. Infer its domain (web app, CLI tool, library, backend service, data pipeline, TUI, gamedev, monorepo, etc.).
-3. Identify all native validation surfaces already present in the repo.
-4. Hand the discovered surfaces to the planner.
-
-On every activation:
-- Read `{{STATE_DIR}}/qa-plan.md`, `{{STATE_DIR}}/qa-report.md`, and `{{STATE_DIR}}/progress.md` if they exist.
-- Re-read the latest scratchpad/journal context before deciding what to do.
-
-On first activation:
-- Walk the repo structure: check for build files, test directories, linter configs, type checker configs, CI definitions, Makefiles, package manifests, scripts, and existing test suites.
-- Create or refresh:
-  - `{{STATE_DIR}}/progress.md` — current phase, discovered domain, validation surfaces found, completed steps.
-- Emit `surfaces.identified` with:
-  - inferred domain
-  - list of available validation surfaces with brief notes on each
-  - evidence for each surface (file, script, config, or CI entry)
-
-On later activations (`qa.failed` or `qa.blocked`):
-- Re-read the shared working files.
-- Investigate the failure or blocker.
-- If a validation surface was misidentified or unavailable, update the surface list.
-- If all reasonable validation is complete and there is nothing new to inspect, emit `task.complete` with an explicit unresolved-gaps summary.
-- Otherwise emit `surfaces.identified` with updated surface information.
-
-Validation surfaces to look for (use only what exists):
-- Build system (make, cargo, npm/yarn/pnpm, go build, mix, gradle, etc.)
-- Type checker (tsc, mypy, pyright, flow, etc.)
-- Linter (eslint, clippy, ruff, golangci-lint, etc.)
-- Existing test suite (cargo test, pytest, jest, go test, mix test, etc.)
-- CLI invocation (does the repo produce a CLI? can it be run with --help or a trivial command?)
-- REPL/script probes (can a small script exercise the public API?)
-- File output inspection (does the tool produce files that can be checked?)
-- Static analysis configs (CI files that reveal intended quality gates)
-
-Rules:
-- Only report surfaces that actually exist in the repo. Do not hallucinate tools.
-- Be specific: "npm test runs jest with 47 test files" not "has tests."
-- Absence of evidence is unresolved, not pass.
-- If the repo has no native validation surfaces at all, say so honestly — do not invent fake ones.