theslopmachine 0.9.14 → 1.0.0

package/MANUAL.md

@@ -58,6 +58,7 @@ slopmachine init -o
 - copies the packaged Claude repo rulebook into `repo/CLAUDE.md`
 - seeds `repo/README.md`, `repo/plan.md`, and `repo/.claude/settings.json`
 - seeds `.ai/startup-context.md` plus the parent-root planning docs under `docs/`
+- later, when `P5` closes, the workflow preserves the final truthful execution record in `docs/plan.md` and removes `repo/plan.md` before evaluation begins
 - creates the initial git commit so the workspace starts with a clean tree
 - optionally opens `opencode` in `repo/`
 - parallel worktrees should stay under hidden parent-root `.ai/worktrees/` so the visible workspace root stays clean

package/README.md

@@ -169,7 +169,7 @@ Important details:
 - Beads lives in the workspace root, not inside `repo/`
 - `repo/.claude/settings.json` seeds Claude Code to use the custom `developer` agent by default for that repo
 - planned parallel git worktrees should live under hidden parent-root `.ai/worktrees/` by default so root-level `repo-lane-*` folders do not clutter the workspace
-- final packaging moves `repo/plan.md` to parent-root `docs/plan.md` and removes repo-local `AGENTS.md`, `CLAUDE.md`, and `plan.md` from the delivered `repo/`
+- when `P5` completes, the workflow moves `repo/plan.md` to parent-root `docs/plan.md`; packaging later validates that `repo/plan.md`, `repo/AGENTS.md`, and `repo/CLAUDE.md` are absent from the delivered `repo/`
 - after non-`-o` bootstrap, the command prints the exact `cd repo` next step so you can continue immediately
 - `--adopt` moves the current project files into `repo/`, preserves root workflow state in the parent workspace, and skips the automatic bootstrap commit
 - `--continue-from <PX>` is a smoother alias for existing-project bootstrap; it implies adoption mode and seeds the requested start phase in one step
@@ -177,7 +177,7 @@ Important details:
 - when a later start phase is seeded for adoption or recovery, the Beads workflow phases before that requested phase are created and immediately marked completed so tracker state matches the seeded entry point
 - in the `slopmachine-claude` path, if adopted or resumed later-phase work has no recoverable tracked Claude developer session yet, the owner must launch and orient the needed Claude lane first and only then continue the substantive work in that same session
 - `--phase <PX>` seeds the initial `current_phase` for adoption/recovery bootstrap; the owner should still fall back if the real repo evidence does not support that later phase
-- `repo/plan.md` is seeded at bootstrap and becomes the definitive repo-local execution checklist during planning
+- `repo/plan.md` is seeded at bootstrap and becomes the definitive repo-local execution checklist through planning, development, and `P5`; after `P5`, the preserved reference copy is `docs/plan.md`
 
 ### `slopmachine set-token`
 

package/assets/agents/developer.md

@@ -69,7 +69,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - treat follow-up prompts mainly as narrow deltas, guardrails, or correction signals
 - if the current work is the scaffold step at the start of development, treat section 3 of `plan.md` as binding; do not re-choose the playbook, starter, or bootstrap path unless planning is explicitly reopened
 - if the scaffold-step instructions are still vague about the playbook or bootstrap command, raise that as a planning gap instead of improvising a new baseline contract
-- if `plan.md` includes a security execution contract, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
+- if `plan.md` includes a security execution contract, `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, `Runtime Lifecycle Checklist`, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
 - treat the execution file tree and owned-file map in `plan.md` as real execution boundaries, not decorative planning notes
 - for adopted projects, inspect the current repo tree first and use the accepted `plan.md` delta tree rather than assuming a greenfield layout
 - keep `plan.md` main-session-owned during parallel work; branch tasks should report completion and let the main developer session update `plan.md` after merge
@@ -100,9 +100,9 @@ When instructed to plan without coding yet:
 - when backend or fullstack API endpoints are added or changed, prefer real HTTP tests for the exact `METHOD + PATH` over controller or service bypasses when practical
 - if mocked HTTP tests or unit-only tests still exist for an API surface, do not overstate them as equivalent to true no-mock endpoint coverage
 - when closing a `plan.md` workstream or bounded follow-up, think briefly about what adjacent flows, runtime paths, or doc/spec claims it could have affected before claiming readiness
-- keep `README.md` as the primary documentation file inside the repo; `plan.md` is the explicit execution-plan exception
+- keep `README.md` as the primary documentation file inside the repo; repo-local `plan.md` is the explicit execution-plan exception only during active implementation through `P5`
 - treat `README.md` and other shared integration-heavy files as main-session-owned by default during parallel work unless the accepted plan explicitly delegates them
-- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with `plan.md` as the deliberate execution-plan exception; do not rely on runtime success alone to make the project understandable
+- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with repo-local `plan.md` as the deliberate execution-plan exception only during active implementation through `P5`; do not rely on runtime success alone to make the project understandable
 - keep the repo self-sufficient; do not make it depend on parent-directory docs or sibling artifacts for startup, build/preview, configuration, verification, or basic understanding
 - do not touch workflow or rulebook files such as `AGENTS.md` unless explicitly asked
 - if the work changes acceptance-critical docs or contracts, review those docs yourself before replying instead of assuming someone else will catch inconsistencies later
@@ -113,6 +113,7 @@ When instructed to plan without coding yet:
 - before reporting development complete, remove local-only setup traces and host-only dependency assumptions from the delivered README and wrapper scripts
 - before reporting development complete, run one deliberate main-session reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so the owner is not first discovering obvious drift in `P5`
 - before reporting development complete, close the common late-failure classes inside development: `README.md` drift, API-spec drift, missing auth/authorization/ownership enforcement, weak validation or normalized error handling, missing owned tests, startup/test wrapper dishonesty, and partial user-facing or admin-facing flow closure
+- before reporting development complete, explicitly report proof status for the core semantic path, prompt-critical rules, role surface matrix if applicable, runtime lifecycle checklist if applicable, and any residual risks instead of relying only on general test success
 
 ## Parallel Execution Model
 

package/assets/agents/slopmachine-claude.md

@@ -122,9 +122,9 @@ Think of the workflow as four instruction planes:
 1. owner prompt: lifecycle engine and general discipline
 2. developer prompt: engineering behavior and execution quality
 3. skills: lifecycle-step or activity rules loaded on demand
-4. repo-local rulebooks such as `CLAUDE.md` plus `plan.md`: durable execution guidance the developer should keep seeing in the codebase
+4. repo-local rulebooks such as `CLAUDE.md` plus repo-local `plan.md` during planning, development, and `P5`: durable execution guidance the developer should keep seeing in the codebase
 
-When a rule is not always relevant, it should usually live in a skill or in repo-local rulebooks such as `CLAUDE.md` plus `plan.md`, not here.
+When a rule is not always relevant, it should usually live in a skill or in repo-local rulebooks such as `CLAUDE.md` plus repo-local `plan.md` during planning, development, and `P5`, not here.
 
 ## Source Of Truth
 
@@ -141,6 +141,7 @@ State split:
 - `../metadata.json` stores project facts and exported project metadata
 
 Do not create another competing workflow-state system.
+Treat Beads as the primary lifecycle source of truth. Use `../.ai/metadata.json` as an orchestration mirror and repair metadata from Beads when they drift unless evidence proves the Beads state itself needs mutation.
 
 ## Git Traceability
 
@@ -159,7 +160,7 @@ Use git to preserve meaningful workflow checkpoints.
 Operate in this order:
 
 1. evaluate the current state critically
-2. identify the active root lifecycle state and its exit evidence
+2. identify the active root lifecycle state from Beads first and verify its exit evidence
 3. load the required skill for that lifecycle state or activity first
 4. compose the developer or owner action for the current step and decide whether the work should stay serial or be fanned out across the planned directory-tree branches or worktrees or Claude helper lanes
 5. verify and review the result
@@ -197,8 +198,9 @@ Phase rules:
 - exactly one root phase should normally be active at a time
 - enter the phase before real work for that phase begins
 - do not close multiple root phases in one transition block
-- `P5 Integrated Verification and Hardening` should normally be one minimal gate that includes the owner-run local test harness check; if that passes and the repo is roughly coherent and broadly correct against `plan.md` plus accepted `../docs/design.md`, stop and ask whether to proceed to evaluation; only narrow owner-fixable local-harness/config/wrapper/README/docs/light-script churn should be fixed there directly, and any real code or actual test-file changes should trigger a bounded Claude developer reroute
-- `P8 Final Readiness Decision` should be one fast owner-run reconciliation sweep after `P7`: reread the delivered repo, `README.md`, parent-root `../docs/`, and carried `../.tmp/` audit artifacts together, fix small docs or README or repo-hygiene drift directly, and only reopen evaluation or packaging-adjacent follow-up when a material inconsistency remains
+- `P5 Integrated Verification and Hardening` should normally be one minimal gate that includes the owner-run local test harness check; if that passes and the repo is roughly coherent and broadly correct against repo-local `plan.md` plus accepted `../docs/design.md`, preserve the final truthful plan in parent-root `../docs/plan.md`, remove the repo-local copy, and then stop to ask whether to proceed to evaluation; only narrow owner-fixable local-harness/config/wrapper/README/docs/light-script churn should be fixed there directly, and any real code or actual test-file changes should trigger a bounded Claude developer reroute
+- the explicit post-`P5` pause must be recorded in Beads only after repo-local `plan.md` has been preserved in parent-root `../docs/plan.md` and removed from the repo: add a structured comment showing that `P5` evidence is satisfied and that the workflow is waiting for the proceed-to-evaluation decision; do not silently advance into `P7` before that decision arrives
+- `P8 Final Readiness Decision` should be one fast owner-run reconciliation sweep after `P7`: reread the delivered repo, `README.md`, parent-root `../docs/`, carried `../.tmp/` audit artifacts, and archived stale/fail report lineage together, fix small docs or README or repo-hygiene drift directly, record a readiness reconciliation note, and only reopen evaluation or packaging-adjacent follow-up when a material inconsistency remains
 - `P10 Retrospective` runs automatically after successful packaging and is non-blocking unless it finds a real delivery defect
 
 ## Developer Session Model
@@ -221,12 +223,12 @@ Maintain exactly one active developer session at a time.
 - each audit result decides the remediation lane:
   - audit session `1` keeps all of its remediation in `bugfix-1`, including fail regenerations and later kept-report fixes
   - audit session `2` keeps all of its remediation in `bugfix-2`, including fail regenerations and later kept-report fixes
-  - `fail` -> move the fail working report out of `../.tmp/` into `../.ai/archive/`, extract the full issue set from that failed attempt, analyze the exact failing surfaces and what must change to resolve them, send that full owner-analyzed corrective brief to that audit session's exact `bugfix-N` Claude lane, require that whole list to be fixed, and then rerun the full evaluation send packet inside the same evaluator session
-  - `partial pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` Claude lane, and treat that kept report's full issue list as the authoritative fix-check scope for the rest of that audit session; send the developer the full owner-analyzed corrective brief for that scope rather than a narrow subset
-  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` Claude lane for every reported issue and recommendation in that report, and if there are no reported items mark the audit session complete without inventing new issues
+  - `fail` -> move the fail working report out of `../.tmp/` into `../.ai/archive/`, extract the full issue set from the full failed report file, analyze the exact failing surfaces and what must change to resolve them, send that full owner-analyzed corrective brief to that audit session's exact `bugfix-N` Claude lane, require that whole list to be fixed, and then rerun the full evaluation send packet inside the same evaluator session
+  - `partial pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` Claude lane, and treat the full issue list extracted from that kept report file as the authoritative fix-check scope for the rest of that audit session; send the developer the full owner-analyzed corrective brief for that scope rather than a narrow subset
+  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` Claude lane for every reported issue and recommendation found in that kept report file, and if there are no reported items mark the audit session complete without inventing new issues
 - `audit_report-<N>-fix_check.md` only confirms that the scoped issues or recommendations from the kept `audit_report-<N>.md` are fixed; if it is not clean, send only the unresolved subset back for remediation, then repeat the same-session fix-check loop against the full kept-report scope, and once that scoped set is confirmed fixed move on to the next audit session or next `P7` subphase
 - require both audit sessions to complete before the final post-audit coverage/README audit can run
-- after the second audit session completes, run the installed `~/slopmachine/test-coverage-prompt.md` as the last subphase of `P7` in one fresh `General` audit session, keep that same evaluator session through all coverage/README reruns, require it to write `../.tmp/test_coverage_and_readme_audit_report.md`, and on the initial send and every rerun use the full coverage/README evaluation send packet rather than a hand-written prompt; reread each generated report and reject it if the last evaluator send was not the exact full prepared packet, if it contains prior-run wording such as `previously` or `remaining`, or if it collapses into a tiny targeted issue list instead of a full standalone strict audit; judge the result by the owner's reading of the report as a whole only after that gate passes, and if it does not read as functionally passing overall, move the displaced report into `../.ai/archive/`, route the fixes to `bugfix-2` only, replace the report, and rerun the full test-coverage prompt again in that same evaluator session until the report is functionally passing overall; do not fall back to another developer session for this remediation window
+- after the second audit session completes, run the installed `~/slopmachine/test-coverage-prompt.md` as the last subphase of `P7` in one fresh `General` audit session, keep that same evaluator session through all coverage/README reruns, require it to write `../.tmp/test_coverage_and_readme_audit_report.md`, and on the initial send and every rerun use the full coverage/README evaluation send packet rather than a hand-written prompt; reread each generated report and reject it if the last evaluator send was not the exact full prepared packet, if it contains prior-run wording such as `previously` or `remaining`, or if it collapses into a tiny targeted issue list instead of a full standalone strict audit; then read the full saved report file itself, extract every reported issue/recommendation from that file, and if any remain, move the displaced report into `../.ai/archive/`, route that full extracted issue set to `bugfix-2`, replace the report, and rerun the full test-coverage prompt again in that same evaluator session until the report is a full standalone pass-level report with no remaining issue/recommendation set to hand back; do not fall back to another developer session for this remediation window
 - track the active evaluator session separately in metadata during `P7`
 - if the active Claude developer session becomes rate-limited, keep that session as the active tracked developer session and auto-wait for reset instead of replacing it with owner implementation
 - after every Claude launch or reply outcome, the owner must immediately do one of three things only: continue the workflow, wait for the same session to recover, or stop and inform the user about a real unrecoverable session problem
@@ -448,15 +450,15 @@ To the developer, this should feel like a normal engineering conversation with a
 - when several issues are found in one review sweep, send them together once as one clear issue list instead of drip-feeding or re-batching them across multiple follow-ups
 - for small non-core fixes such as README cleanup, docs sync, Docker config, wrapper/config glue, light `./run_tests.sh` cleanup, or similar release-churn cleanup, fix them directly in the owner session instead of bouncing them back to the Claude developer worker
 - if the fix would require editing actual test files or real product code, do not patch it in the owner session; send it back to the Claude developer worker
-- for small planning-document contract issues in `../docs/design.md`, `../docs/api-spec.md`, or `plan.md`, fix them directly in the owner session instead of bouncing them back to the Claude developer worker
-- during `P8`, do one deliberate cross-surface reconciliation sweep across the delivered repo, `README.md`, parent-root `../docs/`, and carried audit artifacts before packaging starts; prefer direct owner fixes for small drift instead of turning that sweep into another Claude developer loop
+- for small planning-document contract issues in `../docs/design.md`, `../docs/api-spec.md`, or the accepted plan (`plan.md` before `P5` closes, `../docs/plan.md` afterward), fix them directly in the owner session instead of bouncing them back to the Claude developer worker
+- during `P8`, do one deliberate cross-surface reconciliation sweep across the delivered repo, `README.md`, parent-root `../docs/`, carried audit artifacts, archived stale/fail report lineage, report-shape validity, and residual risks before packaging starts; prefer direct owner fixes for small drift instead of turning that sweep into another Claude developer loop
 - keep work moving without low-information continuation chatter
 - read only what is needed to answer the current decision
 - keep routine review inside the main owner session; do not use `Explore` or `General` subagents to verify Claude developer work
 - clarification and evaluation may still use their dedicated subagent flows, but owner verification of Claude developer work stays in the main session
 - at planning, scaffold-step review inside development, the opening full-repo review, any rare major reread, and final evaluation review, demand the exact expected outcomes in itemized form rather than relying on implied standards
 - keep comments and metadata auditable and specific
-- keep external docs owner-maintained and repo-local README developer-maintained
+- keep external docs owner-maintained, keep repo-local README developer-maintained, allow repo-local `plan.md` only through planning, development, and `P5`, and preserve the final plan in parent-root `../docs/plan.md` after `P5`
 
 ## Backend Integrity
 

package/assets/agents/slopmachine.md

@@ -116,9 +116,9 @@ Think of the workflow as four instruction planes:
 1. owner prompt: lifecycle engine and general discipline
 2. developer prompt: engineering behavior and execution quality
 3. skills: lifecycle-step or activity rules loaded on demand
-4. repo-local rulebooks such as `AGENTS.md` plus `plan.md`: durable execution guidance the developer should keep seeing in the codebase
+4. repo-local rulebooks such as `AGENTS.md` plus repo-local `plan.md` during planning, development, and `P5`: durable execution guidance the developer should keep seeing in the codebase
 
-When a rule is not always relevant, it should usually live in a skill or in repo-local rulebooks such as `AGENTS.md` plus `plan.md`, not here.
+When a rule is not always relevant, it should usually live in a skill or in repo-local rulebooks such as `AGENTS.md` plus repo-local `plan.md` during planning, development, and `P5`, not here.
 
 ## Source Of Truth
 
@@ -135,6 +135,7 @@ State split:
 - `../metadata.json` stores project facts and exported project metadata
 
 Do not create another competing workflow-state system.
+Treat Beads as the primary lifecycle source of truth. Use `../.ai/metadata.json` as an orchestration mirror and repair metadata from Beads when they drift unless evidence proves the Beads state itself needs mutation.
 
 ## Git Traceability
 
@@ -153,7 +154,7 @@ Use git to preserve meaningful workflow checkpoints.
 Operate in this order:
 
 1. evaluate the current state critically
-2. identify the active root lifecycle state and its exit evidence
+2. identify the active root lifecycle state from Beads first and verify its exit evidence
 3. load the required skill for that lifecycle state or activity first
 4. compose the developer or owner action for the current step and decide whether the work should stay serial or be split across the planned directory-tree branches or worktrees
 5. verify and review the result
@@ -191,8 +192,9 @@ Phase rules:
 - exactly one root phase should normally be active at a time
 - enter the phase before real work for that phase begins
 - do not close multiple root phases in one transition block
-- `P5 Integrated Verification and Hardening` should normally be one minimal gate that includes the owner-run local test harness check; if that passes and the repo is roughly coherent and broadly correct against `plan.md` plus accepted `../docs/design.md`, stop and ask whether to proceed to evaluation; only narrow owner-fixable local-harness/config/wrapper/README/docs/light-script churn should be fixed there directly, and any real code or actual test-file changes should trigger a bounded developer reroute
-- `P8 Final Readiness Decision` should be one fast owner-run reconciliation sweep after `P7`: reread the delivered repo, `README.md`, parent-root `../docs/`, and carried `../.tmp/` audit artifacts together, fix small docs or README or repo-hygiene drift directly, and only reopen evaluation or packaging-adjacent follow-up when a material inconsistency remains
+- `P5 Integrated Verification and Hardening` should normally be one minimal gate that includes the owner-run local test harness check; if that passes and the repo is roughly coherent and broadly correct against repo-local `plan.md` plus accepted `../docs/design.md`, preserve the final truthful plan in parent-root `../docs/plan.md`, remove the repo-local copy, and then stop to ask whether to proceed to evaluation; only narrow owner-fixable local-harness/config/wrapper/README/docs/light-script churn should be fixed there directly, and any real code or actual test-file changes should trigger a bounded developer reroute
+- the explicit post-`P5` pause must be recorded in Beads only after repo-local `plan.md` has been preserved in parent-root `../docs/plan.md` and removed from the repo: add a structured comment showing that `P5` evidence is satisfied and that the workflow is waiting for the proceed-to-evaluation decision; do not silently advance into `P7` before that decision arrives
+- `P8 Final Readiness Decision` should be one fast owner-run reconciliation sweep after `P7`: reread the delivered repo, `README.md`, parent-root `../docs/`, carried `../.tmp/` audit artifacts, and archived stale/fail report lineage together, fix small docs or README or repo-hygiene drift directly, record a readiness reconciliation note, and only reopen evaluation or packaging-adjacent follow-up when a material inconsistency remains
 - `P10 Retrospective` runs automatically after successful packaging and is non-blocking unless it finds a real delivery defect
 - post-packaging external evaluation feedback may reopen `P7 Evaluation and Fix Verification`, then rerun `P8 Final Readiness Decision`, `P9 Submission Packaging`, and `P10 Retrospective`
 
@@ -211,12 +213,12 @@ Maintain exactly one active developer session at a time.
 - each audit result decides the remediation lane:
   - audit session `1` keeps all of its remediation in `bugfix-1`, including fail regenerations and later kept-report fixes
   - audit session `2` keeps all of its remediation in `bugfix-2`, including fail regenerations and later kept-report fixes
-  - `fail` -> move the fail working report out of `../.tmp/` into `../.ai/archive/`, extract the full issue set from that failed attempt, analyze the exact failing surfaces and what must change to resolve them, send that full owner-analyzed corrective brief to that audit session's exact `bugfix-N` lane, require the whole list to be fixed, and then rerun the full evaluation send packet inside the same evaluator session
-  - `partial pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` lane, and treat that kept report's full issue list as the authoritative fix-check scope for the rest of that audit session; send the developer the full owner-analyzed corrective brief for that scope rather than a narrow subset
-  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` lane for every reported issue and recommendation in that report, and if there are no reported items mark the audit session complete without inventing new issues
+  - `fail` -> move the fail working report out of `../.tmp/` into `../.ai/archive/`, extract the full issue set from the full failed report file, analyze the exact failing surfaces and what must change to resolve them, send that full owner-analyzed corrective brief to that audit session's exact `bugfix-N` lane, require the whole list to be fixed, and then rerun the full evaluation send packet inside the same evaluator session
+  - `partial pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` lane, and treat the full issue list extracted from that kept report file as the authoritative fix-check scope for the rest of that audit session; send the developer the full owner-analyzed corrective brief for that scope rather than a narrow subset
+  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` lane for every reported issue and recommendation found in that kept report file, and if there are no reported items mark the audit session complete without inventing new issues
 - `audit_report-<N>-fix_check.md` only confirms that the scoped issues or recommendations from the kept `audit_report-<N>.md` are fixed; if it is not clean, send only the unresolved subset back for remediation, then repeat the same-session fix-check loop against the full kept-report scope, and once that scoped set is confirmed fixed move on to the next audit session or next `P7` subphase
 - require both audit sessions to complete before the final post-audit coverage/README audit can run
-- after the second audit session completes, run the installed `~/slopmachine/test-coverage-prompt.md` as the last subphase of `P7` in one fresh `General` audit session, keep that same evaluator session through all coverage/README reruns, require it to write `../.tmp/test_coverage_and_readme_audit_report.md`, and on the initial send and every rerun use the full coverage/README evaluation send packet rather than a hand-written prompt; reread each generated report and reject it if the last evaluator send was not the exact full prepared packet, if it contains prior-run wording such as `previously` or `remaining`, or if it collapses into a tiny targeted issue list instead of a full standalone strict audit; judge the result by the owner's reading of the report as a whole only after that gate passes, and if it does not read as functionally passing overall, move the displaced report into `../.ai/archive/`, route the fixes to `bugfix-2` only, replace the report, and rerun the full test-coverage prompt again in that same evaluator session until the report is functionally passing overall; do not fall back to another developer session for this remediation window
+- after the second audit session completes, run the installed `~/slopmachine/test-coverage-prompt.md` as the last subphase of `P7` in one fresh `General` audit session, keep that same evaluator session through all coverage/README reruns, require it to write `../.tmp/test_coverage_and_readme_audit_report.md`, and on the initial send and every rerun use the full coverage/README evaluation send packet rather than a hand-written prompt; reread each generated report and reject it if the last evaluator send was not the exact full prepared packet, if it contains prior-run wording such as `previously` or `remaining`, or if it collapses into a tiny targeted issue list instead of a full standalone strict audit; then read the full saved report file itself, extract every reported issue/recommendation from that file, and if any remain, move the displaced report into `../.ai/archive/`, route that full extracted issue set to `bugfix-2`, replace the report, and rerun the full test-coverage prompt again in that same evaluator session until the report is a full standalone pass-level report with no remaining issue/recommendation set to hand back; do not fall back to another developer session for this remediation window
 - track the active evaluator session separately in metadata during `P7`
 - once `P7` starts, keep looping inside `P7` until its exit criteria are actually satisfied; do not stop between audits, remediation turns, fix-check passes, or coverage/README reruns
 
@@ -429,15 +431,15 @@ Do not speak as a relay for a third party.
 - when several issues are found in one review sweep, send them together once as one clear issue list instead of drip-feeding or re-batching them across multiple follow-ups
 - for small non-core fixes such as README cleanup, docs sync, Docker config, wrapper/config glue, light `./run_tests.sh` cleanup, or similar release-churn cleanup, fix them directly in the owner session instead of bouncing them back to the developer
 - if the fix would require editing actual test files or real product code, do not patch it in the owner session; send it back to the developer
-- for small planning-document contract issues in `../docs/design.md`, `../docs/api-spec.md`, or `plan.md`, fix them directly in the owner session instead of bouncing them back to the developer
-- during `P8`, do one deliberate cross-surface reconciliation sweep across the delivered repo, `README.md`, parent-root `../docs/`, and carried audit artifacts before packaging starts; prefer direct owner fixes for small drift instead of turning that sweep into another developer loop
+- for small planning-document contract issues in `../docs/design.md`, `../docs/api-spec.md`, or the accepted plan (`plan.md` before `P5` closes, `../docs/plan.md` afterward), fix them directly in the owner session instead of bouncing them back to the developer
+- during `P8`, do one deliberate cross-surface reconciliation sweep across the delivered repo, `README.md`, parent-root `../docs/`, carried audit artifacts, archived stale/fail report lineage, report-shape validity, and residual risks before packaging starts; prefer direct owner fixes for small drift instead of turning that sweep into another developer loop
 - keep work moving without low-information continuation chatter
 - read only what is needed to answer the current decision
 - after planning is accepted, prefer plan-section references plus explicit acceptance checklists over repeated prompt dumps
 - at planning, scaffold-step review inside development, the opening full-repo review, any rare major reread, and final evaluation review, demand the exact expected outcomes in itemized form rather than relying on implied standards
 - reject development responses that silently collapse named parallel work bundles into serial work without an exact blocker and revised parallelization map
 - keep comments and metadata auditable and specific
-- keep external docs owner-maintained under parent-root `../docs/` as reference copies, keep `README.md` as the primary repo-local documentation file, and allow `plan.md` as the explicit execution-plan exception
+- keep external docs owner-maintained under parent-root `../docs/` as reference copies, keep `README.md` as the primary repo-local documentation file, allow repo-local `plan.md` only through planning, development, and `P5`, and preserve the final plan in parent-root `../docs/plan.md` after `P5`
 - default review scope to the changed files and the specific supporting files named by the developer
 - expand review scope only when a concrete inconsistency or missing dependency forces it
 - avoid `grep` by default; prefer `glob` to identify exact files and `read` with targeted offsets

package/assets/claude/agents/developer.md

@@ -54,7 +54,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - treat follow-up prompts mainly as narrow deltas, guardrails, or correction signals
 - if the current work is the scaffold step at the start of development, treat section 3 of `plan.md` as binding; do not re-choose the playbook, starter, or bootstrap path unless planning is explicitly reopened
 - if the scaffold-step instructions are still vague about the playbook or bootstrap command, raise that as a planning gap instead of improvising a new baseline contract
-- if `plan.md` includes a security execution contract, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
+- if `plan.md` includes a security execution contract, `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, `Runtime Lifecycle Checklist`, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
 - planning-only deliverables inside the repo should normally stay minimal, but `plan.md` is the explicit allowed execution-plan artifact
 - when planning is accepted, treat the execution file tree and file-ownership map in `plan.md` as real execution boundaries rather than decorative notes
 - for adopted projects, inspect the current repo tree first and use the accepted `plan.md` delta tree rather than assuming a greenfield layout
@@ -67,6 +67,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - for backend, fullstack, and web projects, keep the canonical `docker compose up --build` contract in `README.md` and also include the exact legacy compatibility string `docker-compose up` somewhere in startup guidance
 - for Android, iOS, and desktop projects, keep the required Docker-contained final contract while also maintaining the project-type-specific host-side guidance sections expected by the strict README audit
 - before reporting development complete, remove local-only setup traces and host-only dependency assumptions from the delivered README and wrapper scripts
+- before reporting development complete, explicitly report proof status for the core semantic path, prompt-critical rules, role surface matrix if applicable, runtime lifecycle checklist if applicable, and any residual risks instead of relying only on general test success
 - keep `README.md` and other shared integration-heavy files main-session-owned by default during parallel work unless the accepted plan explicitly delegates them
 - stay in this one developer session as the primary execution lane, but use internal Claude task sub-agents when they can parallelize independent search, reading, verification, or bounded implementation subtasks usefully
 - prefer internal Claude sub-agents when the work naturally decomposes into independent chunks that can be explored or verified in parallel and merged back cleanly
@@ -92,7 +93,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - verify the changed area locally and realistically before reporting completion
 - when backend or fullstack API endpoints are added or changed, prefer real HTTP tests for the exact `METHOD + PATH` over controller or service bypasses when practical
 - if mocked HTTP tests or unit-only tests still exist for an API surface, do not overstate them as equivalent to true no-mock endpoint coverage
-- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with `plan.md` as the deliberate execution-plan exception
+- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with repo-local `plan.md` as the deliberate execution-plan exception only during active implementation through `P5`
 - do not touch workflow or rulebook files such as `CLAUDE.md` unless explicitly asked
 - if the work changes acceptance-critical docs or contracts, review those docs yourself before replying instead of assuming someone else will catch inconsistencies later
 

package/assets/skills/beads-operations/SKILL.md

@@ -18,6 +18,14 @@ When a root phase changes:
 5. open the next root phase
 6. add a `STATE:` transition comment
 
+When `P5` is complete but the workflow is intentionally paused for the user proceed-to-evaluation decision:
+
+1. do not open `P7` yet
+2. keep `P5` as the active root phase until the user explicitly says to proceed
+3. before surfacing that pause, preserve the final truthful contents of repo-local `plan.md` in parent-root `../docs/plan.md` and remove the repo-local copy
+4. add a structured comment such as `APPROVAL:` or `DECISION:` recording that `P5` evidence is satisfied and the workflow is waiting at the evaluation boundary
+5. once the user approves evaluation, close `P5`, update metadata, open `P7`, and add the normal `STATE:` transition comment
+
 ## Rules
 
 - enter the next phase before real work for that phase begins
@@ -25,6 +33,7 @@ When a root phase changes:
 - keep structured comments specific and auditable
 - treat phase-closure failures as real workflow failures to resolve
 - keep Beads and metadata aligned on current phase and active developer session record when either changes
+- when Beads and metadata disagree on the active root phase, treat Beads as the primary lifecycle source of truth and repair metadata unless concrete evidence proves a Beads mutation is required
 
 ## Structured comment prefixes
 

package/assets/skills/clarification-gate/SKILL.md

@@ -51,6 +51,7 @@ It must not become planning, architecture design, execution planning, or conveni
 - It should explain what later planning could miss if each important requirement is not carried forward explicitly.
 - It should distinguish between explicit prompt requirements, implied but binding requirements, and locked safe defaults where that separation helps later planning.
 - It should end with a planning-miss checklist strong enough to expose details later design/planning commonly underbuild.
+- It should explicitly cover hidden environment and trust-boundary assumptions when the prompt mentions or implies on-prem, intranet, offline, LAN, browser access, auth cookies/tokens, local storage, self-contained deployment, external reachability, or secure/insecure transport.
 - It should cover material ambiguity only.
 - It should preserve prompt faithfulness and avoid convenience narrowing.
 - Each entry should end with a decisive solution.
@@ -66,6 +67,7 @@ It must not become planning, architecture design, execution planning, or conveni
 - Require it to write `../.ai/clarification-faithfulness-review.md`.
 - If the review finds only small owner-fixable wording or coverage issues, patch `../.ai/requirements-breakdown.md` and `../docs/questions.md` directly.
 - If the review finds material drift or missing prompt-critical requirements, rerun clarification before leaving `P1`.
+- If planning reveals one real prompt contradiction or materially ambiguous product rule immediately after clarification, allow one bounded clarification addendum; keep it narrow, classify it as product-significant rather than operator noise, update the accepted clarification package, and then resume planning.
 
 5. Build the approved clarification package.
 - Extract the accepted deep core requirements from `../.ai/requirements-breakdown.md` plus the accepted clarification list from `../docs/questions.md`.
@@ -87,6 +89,7 @@ Reject the clarification result if:
 - planning or implementation structure leaked into `questions.md`
 - the requirements breakdown is shallow, incomplete, or not representative enough of the prompt
 - the requirements breakdown fails to expose planning-sensitive details, hidden constraints, negative conditions, or success-closure details that later planning could easily miss
+- hidden environment or trust-boundary assumptions are relevant but absent or vague
 - the prompt-faithfulness review finds material drift that was not corrected
 - the owner still cannot restate the accepted core requirements and clarifications as a clean planning brief without carrying unresolved noise forward
 

package/assets/skills/developer-session-lifecycle/SKILL.md

@@ -162,7 +162,7 @@ Keep `../metadata.json` focused on project facts and exported project metadata w
 - `frontend_framework`
 - `backend_framework`
 
-- use only `fullstack`, `backend`, `android`, `ios`, `desktop`, or `web` for `project_type` when known
+- use only `fullstack`, `server`, `android`, `ios`, `desktop`, or `web` for final `project_type` when known; map backend/server-only projects to `server`
 - fill known values early and keep them current
 - prefer explicit values; use empty strings instead of `null` or extra workflow fields
 - do not use `../metadata.json` as owner workflow scratch state
@@ -257,9 +257,9 @@ For live Claude lanes specifically:
 ## Initial structure rule
 
 - parent-root `../docs/` is the owner-maintained external documentation directory
-- parent-root `../sessions/` is not part of bootstrap and should not be created during workspace init
-- create parent-root `../sessions/` only during packaging when non-Claude developer sessions actually need cleaned export files
-- Claude-backed developer sessions are packaged once as parent-root `claude-sessions.zip` instead of per-session `../sessions/` entries
+- a parent-root session-export directory is not part of bootstrap, packaging, or the final Aquila root structure and should not be created
+- Claude-backed developer sessions are packaged once as parent-root `claude-sessions.zip` by packaging the whole resolved Claude project folder for the current cwd; treat that zip as a separate handoff artifact to move or submit separately before Aquila submission
+- the first usable developer-lane session content must include the original prompt text clearly and verbatim enough to anchor `metadata.prompt`; do not start the developer lane from a paraphrase, summary-only handoff, or mid-work continuation without the original prompt
 - parent-root `../.tmp/` is the `P7` evaluation artifact directory for `audit_report-<N>.md`, `audit_report-<N>-fix_check.md`, and `test_coverage_and_readme_audit_report.md`
 - parent-root `../.ai/claude-live/` is the live Claude bridge runtime directory root
 - `../docs/questions.md` is the mandatory clarification record artifact

package/assets/skills/development-guidance/SKILL.md

@@ -14,6 +14,7 @@ Use this skill before prompting the developer for the main implementation run.
 - update `plan.md` in place from the main developer lane as items move from not started to in progress to done
 - use `../docs/design.md` for system intent and architecture only, and use `plan.md` for the execution file tree, exact execution order, file ownership, and progress state
 - treat the security execution contract and test coverage execution contract in `plan.md` as binding execution inputs, not as later cleanup suggestions
+- treat the `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, and `Runtime Lifecycle Checklist` sections of `plan.md` as binding execution inputs when present
 - read the planned file tree and ownership map before deeper implementation so fan-out follows real file boundaries instead of vague feature labels
 - treat section 3 of `plan.md` as the scaffold step: land the locked starter/playbook, bootstrap path, minimal proof surface, README structure, Docker/runtime files, repo-root dockerized `./run_tests.sh`, and the separate local test environment/tooling before deeper feature work
 - keep that scaffold strict and minimal: set up the delivery contract honestly, avoid host-side setup beyond documented prerequisites, do not run Docker there, and make the local test harness ready for immediate development use
@@ -54,6 +55,7 @@ Use this skill before prompting the developer for the main implementation run.
 - verify the module integrates cleanly with existing modules, routes, permissions, shared state, and cross-cutting helpers rather than only proving the new feature path in isolation
 - before closing the current workstream, do a narrow adjacent-flow sweep: what existing flows, commands, or docs should still be true after this work lands?
 - before marking a `plan.md` item done, make sure the owned behavior is actually closed: actor-facing task completion works, required validation and authorization exist, matching tests landed, and the result is not just wiring or a demo shell
+- before marking a prompt-critical rule row, role surface row, lifecycle row, or core semantic path proof item done, verify the implementation and matching test evidence named by the plan actually exist
 - check cross-cutting consistency where relevant, especially permissions, error handling, audit/logging/redaction behavior, and state or context transition behavior
 - verify tenant or ownership isolation where relevant so access is scoped to the authorized context rather than merely functionally working for one actor
 - verify route-level, object-level, and function-level authorization where those boundaries exist instead of treating “logged in” as sufficient proof
@@ -83,6 +85,9 @@ Use this skill before prompting the developer for the main implementation run.
 - before reporting development complete, make sure the delivered repo is converging on exactly what `README.md` promises; if the README documents a final runtime command or broad test command, treat that as the required final output format rather than a loose note
 - before reporting development complete, do not leave obvious repo-coherence, local-harness, startup, or Docker wiring issues for `P5` or `P9`; `P5` should only need a rough correctness pass over the prepared local harness before evaluation
 - before reporting development complete, run one deliberate main-lane pre-`P5` reread against the original prompt plus accepted requirements-and-clarification package, accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo state so the owner is not first discovering obvious contract drift in `P5`
+- before reporting development complete, fill or update the planned-but-missing proof ledger for core semantic path, prompt-critical rules, role surface matrix, runtime lifecycle behavior, security fail-closed expectations, README command honesty, and behavioral coverage proof
+- before reporting development complete, prove the core semantic path with the exact input/setup, user/API path, expected state/artifact, and failure behavior named in `plan.md`, or report the exact residual risk rather than claiming readiness
+- before reporting development complete, for lifecycle-sensitive behavior, include entrypoint-level proof that the scheduler/worker/timed/export/import/polling/startup/cleanup path is wired and mutates state or artifacts as planned
 - before reporting development complete, close the common `P5` failure classes inside development rather than leaving them for owner rediscovery: `README.md` drift, API-spec drift, missing auth/authorization/ownership enforcement, weak validation or normalized error handling, missing owned tests, startup or wrapper dishonesty, and partial user-facing or admin-facing flow closure
 - before reporting development complete, self-check the integrated repo against the release-readiness requirements already absorbed into `plan.md` `Delivery Review Requirements`; do not leave prompt-fit, static-reviewability, logging/validation, security-boundary, or coverage-structure defects unresolved
 - before reporting development complete, when backend/fullstack APIs exist, make sure endpoint inventory, `METHOD + PATH` mapping, and true no-mock HTTP coverage expectations in `../docs/test-coverage.md` and the repo are genuinely aligned rather than only implied
@@ -129,6 +134,7 @@ Use this skill before prompting the developer for the main implementation run.
 - in each development follow-up or completion reply, report the exact verification commands that were run and the concrete results they produced so the owner can review the evidence without blindly rerunning the same commands
 - when the owner names specific expected outcomes for the current workstream or gate, tie the reported verification and changed files back to those expected outcomes explicitly
 - before reporting overall development complete, run the prepared local test harness and report the exact command plus concrete result; this should normally be the current stack's real local suite rather than an invented placeholder wrapper
+- in the development-complete reply, explicitly report the core semantic path proof, prompt-critical rule proof status, role surface proof status if applicable, lifecycle proof status if applicable, and any accepted or unresolved residual risks
 - when parallel fan-out was part of the planned work, report which planned lanes actually launched, which were skipped, and the exact blocker or revised sequencing for any skipped lane
 - in each development-complete reply, make the owner-side gate questions easy to answer directly: name the closed `plan.md` sections or workstreams, state how the delivered code still matches the accepted design and API contract where applicable, list the exact verification commands and results, and call out only real unresolved issues
 - keep ordinary development follow-up replies short by default: short summary, exact changed files, exact verification commands plus results, and only real unresolved issues unless the owner explicitly asks for a deeper mapping

package/assets/skills/evaluation-triage/SKILL.md

@@ -13,7 +13,8 @@ Use this skill during `P7 Evaluation and Fix Verification` after an audit attemp
 - keep the issue set concrete and exact
 - route every remediation pass to that audit session's matching `bugfix-N` lane
 - do not split, silently drop, or wave through issues from the current audit output
-- the owner must read the current audit output, extract the full issue set, and analyze the exact failing surfaces before talking to the developer
+- the owner must read the full current audit report file, extract the full issue set from that file, and analyze the exact failing surfaces before talking to the developer
+- do not rely on evaluator summaries, top-issue clusters, short follow-up responses, or reduced issue lists when the full saved report file exists
 - after the developer claims fixes are complete for a kept audit session, return to the same evaluator session that produced that audit report
 - keep `P7` moving; after triage, remediation, regeneration, or fix-check, continue with the next required step until the phase is complete or irrecoverably blocked
 
@@ -25,9 +26,10 @@ Use `final-evaluation-orchestration` as the source of truth for session count, r
 
 - treat the audit as a remediation trigger that stays inside the same audit session
 - extract and hand off all issues to the same audit session's `bugfix-N` lane
-- treat the exact full issue list from that failed attempt as the remediation scope for that fail-regeneration pass
-- prioritize issues that cause section failures, hard blockers, or verdict-driving weaknesses first in the owner analysis, but still keep the full issue set in scope
+- treat the exact full issue list extracted from that failed report file as the remediation scope for that fail-regeneration pass
+- analyze every issue from the full saved report file in depth; do not frame remediation scope as only the major issues, top issue clusters, or verdict-driving subset
 - move the fail audit report out of `../.tmp/` into `../.ai/archive/` after triage; do not keep it under the numbered audit-report path
+- do not create or request a fix-check for a failed report; a failed report can only feed developer remediation followed by a full same-session rerun
 - open or reuse the audit session's matching `bugfix-N` lane even during fail-regeneration so all fixes for that numbered audit session stay together
 - after the developer returns, go back to the same evaluator session, prepare the same evaluation send packet again through `node ~/slopmachine/utils/prepare_evaluation_send_packet.mjs --workspace-root .. --prompt-file <chosen-prompt-file> --mode rerun`, and resend that exact packet unchanged as a full rerun instead of sending only a short regeneration instruction
 - do not stop after handing off or fixing a fail audit; keep the current audit session moving until it reaches `pass` or `partial pass`
@@ -35,7 +37,7 @@ Use `final-evaluation-orchestration` as the source of truth for session count, r
 ### `partial pass`
 
 - treat the kept report as the start of a scoped bugfix session
-- use its exact issue list as the scope of that exact audit session's `bugfix-N` lane
+- use its exact issue list extracted from the saved kept report file as the scope of that exact audit session's `bugfix-N` lane
 - save the report as `../.tmp/audit_report-<N>.md`
 - once that report is kept, treat its exact full issue list as the authoritative fix-check scope for the rest of that audit session; later remediation may narrow to the unresolved subset from that kept scope
 - send the full kept-report issue set to the developer in direct human review language, with explicit owner analysis of the failing surfaces and the expected fixes
@@ -43,7 +45,7 @@ Use `final-evaluation-orchestration` as the source of truth for session count, r
 ### `pass`
 
 - keep the audit report as `../.tmp/audit_report-<N>.md`
-- if the report contains any reported issue or recommendation, open or reuse that exact audit session's `bugfix-N` lane and scope it to the full kept-report set
+- if the report contains any reported issue or recommendation, open or reuse that exact audit session's `bugfix-N` lane and scope it to the full kept-report set extracted from the saved report file
 - if the report has no reported issues or recommendations, do not invent a fake issue set; mark the audit session complete and move on
 
 ## Issue handoff standard
@@ -56,6 +58,7 @@ Use `final-evaluation-orchestration` as the source of truth for session count, r
 - require the developer to provide an AI self-test report or concise self-test summary that can be attached or mentioned in the evaluator follow-up
 - if the developer claims an issue is invalid or already fixed, require a concrete justification against the audit output instead of silently omitting it
 - do not reduce the handoff to a small issue subset or a thin summary; the developer-facing prompt should contain the full issue set for the current scope
+- do not reduce the handoff to a small issue subset, top issue cluster list, or thin summary; the developer-facing prompt should contain the full issue set extracted from the saved report file for the current scope
 - for every issue, analyze and state as clearly as possible:
   - what is wrong
   - why it matters
@@ -65,8 +68,11 @@ Use `final-evaluation-orchestration` as the source of truth for session count, r
 - where useful, group issues by failing section or affected surface so the developer sees the real coverage of work instead of a flat checklist
 - include remediation hints or fix suggestions, affected areas, and confirmation text that explicitly requires every listed issue to be fixed before returning
 - treat regenerated-audit quality defects as real issues too: if the kept audit output drops required sections, evidence, or depth from the original audit contract, reject it and rerun instead of waving it through
+- validate report shape before keeping it: verdict, required sections/tables, evidence references, concrete issue list when non-pass, endpoint/surface inventory when applicable, and hard-gate README review for coverage reports
+- if a report is stale or contradicted by current files, archive it with a cited stale reason and rerun instead of replacing it with an owner-authored reconciliation note
 - treat evaluator-send defects as real issues too: if the owner cannot confirm that the last ordinary audit or coverage rerun sent the exact full prepared packet rather than a file reference or short regeneration note, reject the report and rerun instead of waving it through
 - treat tiny regenerated reports as real defects too: outside the scoped fix-check path, reject a measurably small targeted issue list or fix-only note when the evaluator was supposed to regenerate the full report from scratch
+- treat owner-extraction shortcuts as real defects too: if the owner has not extracted every reported issue/recommendation from the saved report file, do not accept the remediation scope as complete
 - prefer a complete owner-analysis format such as: issue id or short label, exact finding, why it matters, failing section or verdict impact, narrow evidence reference, affected surface, required fix, remediation hint, and exact verification target
 
 ## Same-session fix-check standard

package/assets/skills/final-evaluation-orchestration/SKILL.md

@@ -50,6 +50,22 @@ Before accepting any ordinary audit report regeneration or any coverage/README r
 
 If either answer is unacceptable or unknown, reject the generated report, archive or replace it as needed, and rerun inside the same evaluator session with the full prepared packet again.
 
+## Report shape validation
+
+Before keeping any ordinary audit report or final coverage/README report, validate the saved file itself.
+
+Required shape:
+- verdict is present
+- prompt-required major sections and tables are present
+- file-level or route-level evidence references are present where the prompt requires them
+- non-pass reports contain a concrete issue table or issue list
+- coverage reports include endpoint/surface inventory when applicable
+- coverage reports distinguish route/API/surface inventory completeness from behavioral proof sufficiency
+- README audit content reviews hard-gate command, access, auth/credential, mock/debug/demo, and verification disclosures
+- the report contains no owner-authored reconciliation placeholder and no request for the owner to infer missing report sections
+
+Reject and archive the report if shape validation fails. A fix-check report is the only allowed narrow report shape, and only after a kept ordinary report exists.
+
 ## Evaluation selection rule
 
 - choose one fresh-audit evaluation prompt kind for the whole `P7` cycle
@@ -149,7 +165,8 @@ After each audit verdict is produced inside the current audit session, branch by
 
 - record the attempt as a `fail` in metadata
 - move the generated working report file to `../.ai/archive/` instead of keeping it as `audit_report-<N>.md`
-- extract all reported issues from that failed audit attempt
+- never run a scoped fix-check against a failed report; failed reports require full issue extraction, developer remediation, and a full same-session rerun using the prepared packet
+- extract all reported issues from the full generated report file itself, not from any evaluator summary, condensed response, issue cluster list, or owner paraphrase
 - treat that exact full failed-attempt issue list as the remediation scope for the current fail-regeneration pass
 - open or reuse the exact audit-owned remediation lane `bugfix-<N>` for that audit session and send the issues there
 - the owner remediation handoff must include all of the following:
@@ -170,7 +187,7 @@ After each audit verdict is produced inside the current audit session, branch by
 - keep the report as `../.tmp/audit_report-<N>.md`
 - apply the kept-report acceptance rule above before continuing
 - open or reuse `bugfix-<N>`
-- treat the exact issue list from `audit_report-<N>.md` as the full scoped issue set for that bugfix session
+- treat the exact issue list extracted from the full `audit_report-<N>.md` file as the full scoped issue set for that bugfix session
 - once `audit_report-<N>.md` is kept, that exact full issue list becomes the authoritative fix-check scope for the rest of that audit session; later remediation may narrow to the unresolved subset from that kept scope
 - keep using the same evaluator session for the later scoped fix-check loop tied to that audit number
 
@@ -178,7 +195,7 @@ After each audit verdict is produced inside the current audit session, branch by
 
 - keep the report as `../.tmp/audit_report-<N>.md`
 - apply the kept-report acceptance rule above before continuing
-- if the report contains any reported issue or recommendation, open or reuse `bugfix-<N>` and scope it to the full kept-report set, regardless of severity
+- if the report contains any reported issue or recommendation, open or reuse `bugfix-<N>` and scope it to the full kept-report set extracted from the saved report file, regardless of severity
 - if the report contains no reported issues or recommendations, mark the audit session complete immediately and move to the next audit session or to the final coverage/README audit when `N = 2`
 - do not discard a kept `pass` report
 
@@ -186,11 +203,12 @@ After each audit verdict is produced inside the current audit session, branch by
 
 Inside a kept audit session after `audit_report-<N>.md` exists:
 
-- treat the exact issue list from `audit_report-<N>.md` as the scope of the loop for `partial pass`
-- treat every reported issue and recommendation in the kept report as the scope of the loop for `pass`
+- treat the exact issue list extracted from the saved `audit_report-<N>.md` file as the scope of the loop for `partial pass`
+- treat every reported issue and recommendation found in the saved kept report file as the scope of the loop for `pass`
 - send that full scoped issue set to `bugfix-<N>` in direct human review language with owner analysis of the exact surfaces and expected fixes
 - do not tell the developer to read the audit report file directly
 - phrase the fix request as your own review, for example `fix these issues I found`, rather than as a report handoff
+- do not ask the evaluator for `top issues`, `major issue clusters`, `summary issues`, or any other reduced remediation scope when the full report file already exists; the owner must read the whole file and extract the whole issue set instead
 - require the developer to fix the scoped issue set and report:
   - exact verification commands
   - concrete results
@@ -225,18 +243,27 @@ These are the errors I encountered during my previous inspection of the current
 - prepare the coverage/README evaluator send packet with `node ~/slopmachine/utils/prepare_evaluation_send_packet.mjs --workspace-root .. --prompt-file ~/slopmachine/test-coverage-prompt.md` and send that exact packet file unchanged to the evaluator session; do not tell the evaluator to read the file, and do not trim, excerpt, paraphrase, reorder, or partially paste it
 - do not prepend cwd notes, workflow notes, or custom audit instructions because that prompt already defines its own report path and audit workspace assumptions
 - before each rerun, move the previous `../.tmp/test_coverage_and_readme_audit_report.md` to `../.ai/archive/` before replacing it; do not keep numbered variants for this report in `../.tmp/`
-- judge this audit by the owner's reading of the fresh report as a whole, not by the existence of any issue line item; if the fresh report reads as functionally passing overall and the remaining items are non-blocking, that is sufficient
+- judge this audit from the full saved report file itself, not from any evaluator summary; extract the full issue/recommendation set from that file and require remediation of that full set before accepting the rerun as complete
 - after each generated `test_coverage_and_readme_audit_report.md`, reread it and reject it if it mentions, implies, or hints at previous runs, prior inspections, earlier fixes, regeneration, or reruns
 - first verify that the last evaluator send for that report was the exact full prepared packet contents rather than a file reference, short note, footer-only message, or other reduced send
 - explicitly look for wording such as `previously`, `remaining`, `still remaining`, `fixed from the prior run`, `rerun`, `regenerated`, `again`, `previous inspection`, or similar prior-run framing; treat those as audit-output defects when they refer to report history rather than current findings
 - if the report contains that kind of prior-run wording, archive or replace it and rerun the same-session coverage/README audit until the kept report reads as a fresh standalone audit of the current repo state
 - also reject the report if it is materially thinner or less complete than the original strict audit contract; do not allow regeneration to reduce the information depth
 - also reject it if it is a measurably tiny file or a targeted issue list instead of a full strict coverage/README audit; this report should normally remain roughly `150+` lines and cover the full prompt-required review shape rather than collapsing to a short note
-- route those issues to `bugfix-2` only
+- route the full extracted issue/recommendation set from that saved report file to `bugfix-2` only
 - require fixes plus concrete verification evidence from `bugfix-2`
 - do not run Docker or `./run_tests.sh` anywhere inside `P7`; the ordinary local-harness execution point is the owner-run gate in `P5`, and the first real Docker confirmation plus dockerized broad-test run is `P9`
 - after the fixes land, return to that same evaluator session, prepare the coverage/README evaluator send packet again through `node ~/slopmachine/utils/prepare_evaluation_send_packet.mjs --workspace-root .. --prompt-file ~/slopmachine/test-coverage-prompt.md --mode rerun`, send that exact rerun packet unchanged to the evaluator session again, and replace the old report
-- continue the same-session full-prompt coverage/README rerun loop until the fresh report reads as functionally passing overall or an irrecoverable blocker stops the workflow
+- continue the same-session full-prompt coverage/README rerun loop until the fresh report is a full standalone pass-level report with no remaining issue/recommendation set to hand back, or until an irrecoverable blocker stops the workflow
+
+## Stale or degraded report protocol
+
+If a report appears stale, contradicted by current files, or degraded:
+- cite the current-file evidence that contradicts the report before rejecting it as stale
+- archive the stale/degraded report under `../.ai/archive/`; do not keep it in `../.tmp/`
+- record the stale/degraded reason in metadata or Beads comments when available
+- rerun the full prepared packet in the same evaluator session or start a new evaluator session only when same-session recovery is not viable
+- do not replace a stale/degraded report with an owner-authored reconciliation note
 
 ## Scope rule
 
@@ -255,7 +282,7 @@ These are the errors I encountered during my previous inspection of the current
   - audit session `2` is complete
   - the post-audit coverage/README audit has run as the last subphase of `P7`
 - a clean `pass` or `partial pass` verdict alone does not end an audit session; the corresponding `bugfix-<N>` issue/recommendation loop must also close unless the kept `pass` report had no reported items at all
-- after the second audit session completes, run the coverage/README audit; when the fresh report reads as functionally passing overall, move to `P8 Final Readiness Decision` with that passing report; `P8` then performs one fast reconciliation sweep across the repo, parent-root docs, and carried audit artifacts before packaging begins
+- after the second audit session completes, run the coverage/README audit; only when the fresh report is a full standalone pass-level report and the owner has extracted no remaining issue/recommendation set from the saved file may the workflow move to `P8 Final Readiness Decision`; `P8` then performs one fast reconciliation sweep across the repo, parent-root docs, and carried audit artifacts before packaging begins
 - until that exit target is actually met, never stop merely because one audit attempt, one remediation turn, or one fix-check loop pass has finished
 
 ## Boundaries