@mobrienv/autoloop 0.1.4 → 0.2.1

package/presets/autoperf/roles/measurer.md

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

package/presets/autoperf/roles/optimizer.md

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

package/presets/autoperf/roles/profiler.md

@@ -8,7 +8,7 @@ Your job:
 3. Hand one optimization target at a time to the optimizer.
 
 On every activation:
-- Read `.autoloop/perf-profile.md`, `.autoloop/perf-log.jsonl`, and `.autoloop/progress.md` if they exist.
+- Read `{{STATE_DIR}}/perf-profile.md`, `{{STATE_DIR}}/perf-log.jsonl`, and `{{STATE_DIR}}/progress.md` if they exist.
 - Re-read the latest scratchpad/journal context before deciding.
 
 On first activation:
@@ -19,9 +19,9 @@ On first activation:
   - If no benchmarks exist, identify how to measure the target metric.
   - Identify hot paths: slow functions, unnecessary allocations, N+1 queries, redundant computation.
 - Create or refresh:
-  - `.autoloop/perf-profile.md` — goal, metric, baseline, identified hot paths ranked by estimated impact.
-  - `.autoloop/perf-log.jsonl` — empty file (will be appended to by the judge).
-  - `.autoloop/progress.md` — current phase, first optimization target.
+  - `{{STATE_DIR}}/perf-profile.md` — goal, metric, baseline, identified hot paths ranked by estimated impact.
+  - `{{STATE_DIR}}/perf-log.jsonl` — empty file (will be appended to by the judge).
+  - `{{STATE_DIR}}/progress.md` — current phase, first optimization target.
 - Emit `hotspot.identified` with the highest-impact target and baseline measurement.
 
 On later activations (`optimization.kept` or `optimization.discarded`):

package/presets/autopr/README.md

@@ -0,0 +1,99 @@
+# 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

@@ -0,0 +1,22 @@
+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

@@ -0,0 +1,27 @@
+<!-- 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

@@ -0,0 +1,22 @@
+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

@@ -0,0 +1,55 @@
+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

@@ -0,0 +1,38 @@
+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

@@ -0,0 +1,28 @@
+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

@@ -0,0 +1,31 @@
+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

@@ -0,0 +1,32 @@
+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,6 +1,6 @@
 # AutoQA miniloop
 
-An autoloop-native zero-dependency, domain-adaptive validation orchestrator.
+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.
 

package/presets/autoqa/autoloops.toml

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

@@ -1,9 +1,9 @@
 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 `.autoloop/qa-report.md`.
+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: `.autoloop/qa-plan.md`, `.autoloop/qa-report.md`, `.autoloop/progress.md`.
+- 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.
@@ -11,20 +11,20 @@ Global rules:
 - 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 `.autoloop/progress.md` for each discovered surface: `pending | passed | failed | blocked | skipped`.
-- Treat that status table plus any accepted results in `.autoloop/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.
+- 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 `.autoloop/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 `.autoloop/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.
+- 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 `./.autoloop/autoloops memory add learning ...` for durable learnings.
+- Use `{{TOOL_PATH}} memory add learning ...` for durable learnings.
 - Do not invent extra phases. Stay inside inspector → planner → executor → reporter.
 
 State files:
-- `.autoloop/qa-plan.md` — validation plan: discovered domain, available surfaces, ordered validation steps.
-- `.autoloop/progress.md` — current validation step, what the next role should do, completed steps.
-- `.autoloop/qa-report.md` — the compiled validation report with pass/fail results and evidence.
+- `{{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/roles/executor.md

@@ -8,13 +8,13 @@ Your job:
 3. Hand the results to the reporter.
 
 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`.
 - 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 `.autoloop/progress.md`:
+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)
@@ -40,4 +40,4 @@ Rules:
 - 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 `.autoloop/progress.md` updated with the current step's status.
+- Keep `{{STATE_DIR}}/progress.md` updated with the current step's status.

package/presets/autoqa/roles/inspector.md

@@ -9,13 +9,13 @@ Your job:
 4. Hand the discovered surfaces to the planner.
 
 On every activation:
-- Read `.autoloop/qa-plan.md`, `.autoloop/qa-report.md`, and `.autoloop/progress.md` if they exist.
+- 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:
-  - `.autoloop/progress.md` — current phase, discovered domain, validation surfaces found, completed steps.
+  - `{{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

package/presets/autoqa/roles/planner.md

@@ -8,11 +8,11 @@ Your job:
 3. Hand exactly one validation step to the executor.
 
 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`.
 - Re-read the latest scratchpad/journal context.
 
 On first activation (after `surfaces.identified`):
-- Create `.autoloop/qa-plan.md` with:
+- Create `{{STATE_DIR}}/qa-plan.md` with:
   - Domain summary (one line)
   - Available validation surfaces (from inspector)
   - A coverage map: every discovered surface becomes either a planned step or an explicit skip with reason
@@ -29,7 +29,7 @@ On first activation (after `surfaces.identified`):
   4. Existing test suite (if available)
   5. CLI smoke test (if applicable)
   6. Script probes / manual checks (if applicable)
-- Update `.autoloop/progress.md` with the active step.
+- Update `{{STATE_DIR}}/progress.md` with the active step.
 - Emit `qa.planned` with:
   - step number
   - exact command or action
@@ -37,11 +37,11 @@ On first activation (after `surfaces.identified`):
 
 On later activations (`qa.blocked` or `qa.continue`):
 - Read what blocked the executor or what the reporter recorded.
-- Reconcile `.autoloop/progress.md` and `.autoloop/qa-report.md` first; treat their accepted step results as the authoritative carry-forward ledger.
+- Reconcile `{{STATE_DIR}}/progress.md` and `{{STATE_DIR}}/qa-report.md` first; treat their accepted step results as the authoritative carry-forward ledger.
 - Carry forward every already-executed step exactly as accepted unless new evidence invalidates it.
 - If the latest reporter handoff accepted the last step and more work remains, advance to the next unfinished planned step instead of re-planning from scratch or revisiting passed steps.
-- Refresh `.autoloop/qa-plan.md`'s `Ready-to-execute next step` block whenever the active step changes; never leave it pointing at the step that just executed.
-- Update `.autoloop/progress.md` so the accepted ledger, next role, and planner-owned next action all match that newly selected unfinished step.
+- Refresh `{{STATE_DIR}}/qa-plan.md`'s `Ready-to-execute next step` block whenever the active step changes; never leave it pointing at the step that just executed.
+- Update `{{STATE_DIR}}/progress.md` so the accepted ledger, next role, and planner-owned next action all match that newly selected unfinished step.
 - Do not duplicate completed steps, renumber them, or change `passed` / `skipped` rows back to `pending` without explicit contradictory evidence.
 - Adjust the plan only where the new evidence requires it: skip the surface, try an alternative, or reorder.
 - Emit `qa.planned` with the next viable step.