theslopmachine 0.9.9 → 0.9.12

package/MANUAL.md

@@ -48,6 +48,7 @@ slopmachine init -o
 ## What `init` does
 
 - creates `.ai/` workflow files plus `.ai/artifacts`
+- creates hidden `.ai/worktrees/` as the default location for parallel git worktrees
 - initializes git when needed
 - updates `.gitignore`
 - bootstraps beads_rust (`br`)
@@ -59,6 +60,7 @@ slopmachine init -o
 - seeds `.ai/startup-context.md` plus the parent-root planning docs under `docs/`
 - 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
 
 ## Rough workflow
 

package/README.md

@@ -145,6 +145,7 @@ What it creates:
 - `metadata.json`
 - `.ai/metadata.json`
 - `.ai/startup-context.md`
+- hidden `.ai/worktrees/` for parallel git worktrees when used
 - root `.beads/`
 - `repo/AGENTS.md`
 - `repo/CLAUDE.md`
@@ -167,6 +168,7 @@ Important details:
 - `project_type` should use only `fullstack`, `backend`, `android`, `ios`, `desktop`, or `web` when known
 - 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/`
 - 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

package/assets/agents/developer.md

@@ -159,7 +159,7 @@ Broad commands you are not allowed to run during ordinary work:
 - never run full test suites during ordinary implementation work unless explicitly instructed to run that exact command
 - do not use those commands even if they are documented in the repo, requested by the owner, suggested by a playbook, implied by `plan.md`, or look convenient for debugging
 - if your work would normally call for one of those commands, stop at targeted local verification and report that the change is ready for broader verification
-- do not run Docker-based runtime/test commands under any circumstances before `P9`, including when explicitly asked during planning, development, `P5`, or `P7`; the owner handles final Docker and `./run_tests.sh` verification after evaluation is complete
+- do not run Docker-based runtime/test commands under any circumstances during planning, development, `P5`, or `P7`; the owner handles the first broad Docker and `./run_tests.sh` verification in `P5` and may rerun it in `P9` for final confirmation
 
 Your job is to make the broader verification likely to pass without running it yourself.
 

package/assets/agents/slopmachine-claude.md

@@ -190,7 +190,8 @@ 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 fast stabilization pass; only major brokenness should trigger a bounded Claude developer reroute before returning to evaluation readiness
+- `P5 Integrated Verification and Hardening` should normally be one fast stabilization pass that includes the first real owner-run `docker compose up --build` and `./run_tests.sh` gate; owner-fixable Docker/config/wrapper churn should be fixed there directly, and only major brokenness should trigger a bounded Claude developer reroute before returning to evaluation readiness
+- `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
 - `P10 Retrospective` runs automatically after successful packaging and is non-blocking unless it finds a real delivery defect
 
 ## Developer Session Model
@@ -210,11 +211,14 @@ Maintain exactly one active developer session at a time.
 - the final coverage/README audit then uses one additional fresh evaluator session and stays in that same session through its reruns, so the whole `P7` flow uses exactly 3 evaluator sessions total
 - after any kept audit report is saved, reread it and reject it if it hints at prior runs or if it has degraded materially from the original evaluation prompt's required depth, structure, sections, tables, verdict blocks, or evidence style
 - each audit result decides the remediation lane:
-  - `fail` -> route the exact issue list back to the most recent recoverable Claude developer lane, discard the fail working report, fix the issues there, and then regenerate inside the same evaluator session
-  - `partial pass` -> keep `audit_report-<N>.md`, start `bugfix-N`, and keep its fix loop scoped to that audit report's issue list
-  - `pass` -> keep `audit_report-<N>.md`, start `bugfix-N` only for that report's recommended improvements, and if there are no actionable recommendations mark the audit session complete without inventing new issues
+  - 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/`, send the full issue list from that failed attempt to that audit session's exact `bugfix-N` Claude lane, require that whole list to be fixed, and then rerun the full prepared evaluation prompt 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
+  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` Claude lane for every actionable reported issue and recommendation in that report, and if there are no actionable 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`, reread each generated report and reject prior-run wording such as `previously` or `remaining` when it refers to report history, and if it finds any issue route the fixes back to the currently active recoverable developer session, replace the report, and rerun up to 3 times before carrying the latest report forward
+- 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`, reread each generated report and reject prior-run wording such as `previously` or `remaining` when it refers to report history, and judge the result by the owner's reading of the report as a whole: if it does not read as an overall pass, move the displaced report into `../.ai/archive/`, route the fixes to `bugfix-2` when that lane exists or else to the current recoverable Claude developer session, replace the report, and rerun up to 3 times before carrying the latest report forward
 - 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
 - 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
@@ -245,43 +249,42 @@ If adopted or repaired work reaches development, integrated verification and har
 During `P1 Clarification`, use this clarification handshake:
 
 1. launch one short-lived `General` clarification worker
-2. use the packaged `~/slopmachine/clarifier-agent-prompt.md` as the worker prompt, injecting the original prompt and supporting stack/context notes
-3. require the worker to output only `../docs/questions.md`
-4. review `../docs/questions.md`; if it misses material ambiguity, contains filler, or drifts from the prompt, correct clarification before continuing
-5. parse `../docs/questions.md` into the approved clarification package for planning: the accepted clarification list plus any short additional locked deltas that are not already captured there
-6. only after that package is strong enough should `P2` begin and the live `develop-1` lane be launched
+2. use the packaged `~/slopmachine/clarifier-agent-prompt.md` verbatim as the worker prompt, injecting only the original prompt and supporting stack/context notes, and require it to output only `../docs/questions.md`
+3. use `clarification-gate` to review `../docs/questions.md` and turn it into the approved clarification package
+4. only when that package is complete and unambiguous enough to serve as the clarified prompt for planning should `P2` begin and the live `develop-1` lane be launched
 
 When the first develop developer session begins in `P2`, start it in this exact order through the live bridge:
 
 1. launch the live `develop-1` Claude `developer` lane
 2. send the original prompt and a plain instruction to read it carefully, not plan yet, and wait for design direction
 3. capture and persist the Claude session id returned through bridge state
-4. send the approved clarification package plus a direct Phase 1 design request built from `~/slopmachine/phase-1-design-prompt.md` and `~/slopmachine/phase-1-design-template.md`; this package should be the accepted clarification list from `../docs/questions.md` plus any short additional locked deltas; require `../docs/design.md` and, when backend/fullstack APIs exist, `../docs/api-spec.md`, and say explicitly not to start execution planning yet
+4. send the inline approved clarification package plus a direct Phase 1 design request built from `~/slopmachine/phase-1-design-prompt.md` and `~/slopmachine/phase-1-design-template.md`; require `../docs/design.md` and, when backend/fullstack APIs exist, `../docs/api-spec.md`, and say explicitly not to start execution planning yet
 5. review Phase 1 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; reject only material gaps, and directly patch small owner-fixable contract issues until the design is accepted
 6. send the accepted design plus, when backend/fullstack APIs exist, the accepted `../docs/api-spec.md`, with a direct Phase 2 execution-planning request built from `~/slopmachine/phase-2-execution-planning-prompt.md`, `~/slopmachine/phase-2-plan-template.md`, and `~/slopmachine/exact-readme-template.md`; require `plan.md` plus an updated parent-root `../docs/test-coverage.md`, and say explicitly not to start implementation yet
-7. in that Phase 2 request, require the lane map to be derived from the directory tree and owned-file boundaries, require as many bounded branches or worktrees or helper-agent lanes as safely possible, target at least 5 lanes when the codebase clearly supports it, require preplanned shared-file overlap and merge checkpoints, require exact serial-only justifications, require a dedicated git worktree plus explicit branch name for every planned parallel lane, and identify which named safe lanes must actually launch during implementation unless a blocker forces a reviewed revision
-8. review Phase 2 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; reject only material gaps, and directly patch small owner-fixable contract issues until `plan.md` is accepted
-9. only after both planning phases are accepted may the broad `plan.md` development run begin
+7. in that Phase 2 request, explicitly require a directory-tree-derived lane map, explicit shared-file control, exact serial-only justifications, a dedicated git worktree plus explicit branch name for every planned parallel lane, and at least 5 lanes when the codebase clearly supports that level of safe fan-out; also identify which named safe lanes must actually launch during implementation unless a blocker forces a reviewed revision
+8. review Phase 2 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; before leaving `P2`, do one final combined no-drift reread of the accepted design plus accepted plan against the original prompt and accepted clarifications, confirm `../docs/api-spec.md` when applicable and `../docs/test-coverage.md` are fulfilled from the accepted plan, and reject any remaining critical security weakness or planning drift
+9. only after that final planning reread passes may the broad `plan.md` development run begin
 
 Do not reorder that sequence.
 Do not ask for Phase 1 and Phase 2 in the same turn.
 Do not create fresh Claude lanes or fresh Claude sessions for ordinary follow-up turns inside the same developer session.
-After planning is accepted, the default next substantive Claude turn should be the broad `plan.md` execution run rather than many narrow development follow-up turns. That turn should first land the scaffold step from section 3 of `plan.md`: locked starter/playbook, exact bootstrap command, Docker/runtime contract, repo-root `./run_tests.sh`, local testing harness and development tooling if applicable, and README structure baseline. Require the developer session to set up those files honestly but not run Docker or `./run_tests.sh`. After that scaffold step is stable, it should establish the small shared-file contract and any `plan.md`-marked pre-fan-out security contract in the main lane, keep `plan.md`, `README.md`, and other shared integration files main-lane-owned by default, then explicitly tell the same lane to create the planned git worktrees and spawn all planned internal branches or helper agents for the named `plan.md` sections during the main implementation run instead of waiting for another owner nudge, target at least 5 concurrent lanes when the codebase supports it, require each lane to complete its owned implementation plus all matching tests inside its assigned worktree, and keep final fan-in and merged verification in the main lane before any corresponding `plan.md` items are marked complete. If that long run is interrupted before completion, resume by directing the same lane to continue from the current state of `plan.md`.
+After planning is accepted, the default next substantive Claude turn should be the broad `plan.md` execution run rather than many narrow development follow-up turns. That turn should tell the same lane to land the scaffold step from section 3 of `plan.md` first without running Docker or `./run_tests.sh`, then stabilize the shared-file and pre-fan-out security contract in the main lane, then create the planned git worktrees and launch the named internal branches or helper agents, keep implementation plus matching tests together inside each lane, and keep final fan-in and merged verification in the main lane before any corresponding `plan.md` items are marked complete. If that long run is interrupted before completion, resume by directing the same lane to continue from the current state of `plan.md`.
 During `P1`, choose `CLAUDE.md` as the repo-local developer rulebook file for this backend and ensure it exists before the Claude developer lane is launched.
 If `repo/CLAUDE.md` is missing, restore it directly from `~/slopmachine/templates/CLAUDE.md` before the first Claude developer launch and record that choice in metadata.
 
 ## Verification Budget
 
-Docker and `./run_tests.sh` are deferred until after `P7`.
+Docker and `./run_tests.sh` are deferred until the owner-run gate in `P5`.
 
 Target budget for the whole workflow:
 
-- one owner-side Docker submission-readiness check after `P7`, with immediate reruns there only if Docker config or wrapper fixes are needed
+- one owner-side Docker/runtime and broad-test gate in `P5`, with immediate reruns there for owner-fixable Docker/config/wrapper/test-harness issues
+- one final confirmation rerun in `P9` when late fixes or packaging changes could still affect the runtime/test contract
 
 Selected-stack rule:
 
 - follow the original prompt and existing repository first; only use package defaults when they do not already specify the platform or stack
-- do not run Docker-based broad verification before `P9`; use static review, local non-Docker evidence, and evaluator loops instead
+- do not run Docker-based broad verification before `P5`; use static review and local non-Docker evidence before that point, then keep `P7` non-Docker and reserve `P9` for final confirmation reruns only
 
 Every project must end up with:
 
@@ -304,14 +307,15 @@ Broad test command rule:
 
 Default moments:
 
-1. development complete -> direct fused `P5` entry for repo coherence only
-2. after `P7` completes -> owner-side Docker submission-readiness check in `P9`
+1. development complete -> direct fused `P5` entry with the owner-run Docker/runtime and broad-test gate
+2. after `P7` completes -> `P9` final confirmation rerun when the latest changes could affect the runtime/test contract
 
 For all project types, enforce this cadence:
 
-- do not run Docker during planning, development, `P5`, or `P7`
-- do not ask the developer session to run Docker or `./run_tests.sh` under any circumstances before `P9`
-- after `P7` completes, the owner may run the documented Docker/runtime path and `./run_tests.sh` in `P9`, fix Docker config directly if needed, and rerun there before packaging closes
+- do not run Docker during planning, development, or `P7`
+- do not ask the developer session to run Docker or `./run_tests.sh` under any circumstances; the owner handles the first broad gate in `P5` and may rerun it in `P9` for final confirmation
+- after `P3` completes, the owner should run the documented Docker/runtime path and `./run_tests.sh` in `P5`, fix owner-side Docker/config/wrapper/test-harness issues directly if needed, and rerun there before moving to evaluation
+- after `P7` completes, rerun those commands in `P9` only when final confirmation is still needed because late fixes or packaging changes touched the contract
 
 Docker timeout rule:
 
@@ -373,10 +377,10 @@ When talking to the Claude developer worker:
 - when backend or fullstack APIs are relevant, explicitly require progress on endpoint inventory, true no-mock HTTP coverage for important `METHOD + PATH` surfaces, and honest classification of mocked or indirect tests
 - when README compliance is relevant, explicitly require the strict audit sections: project type, startup instructions, access method, verification method, and demo credentials or the exact statement `No authentication required`
 - during ordinary development you may allow fast local iteration, but before final release-readiness review closes require cleanup of local-only setup traces so the delivered runtime and broad test contract is Docker-contained and reviewable
-- do not tell the Claude developer worker to run Docker-based runtime/test commands; the owner handles that only after `P7`
+- do not tell the Claude developer worker to run Docker-based runtime/test commands; the owner handles the first broad Docker gate in `P5`
 - speak to the developer like a human project manager or technical lead who cares about the project outcome; do not sound like workflow software or an orchestration relay
 - use the canonical prompt-shape discipline from `claude-worker-management`, but keep the actual message natural and low-noise: do not send labeled sections like `Context snapshot` or `This turn only`, and do not mention turns, workflow state, or prompt-contract jargon in the message itself
-- for the first broad development turn, make the prompt mostly a restatement of section 3 of the accepted `plan.md`: exact playbook, exact bootstrap command, Docker/runtime contract, `./run_tests.sh`, local testing harness and development tooling if applicable, README structure baseline, explicit no-Docker execution before `P9`, exact stop boundary if that scaffold step is isolated, and exact evidence required
+- for the first broad development turn, make the prompt mostly a restatement of section 3 of the accepted `plan.md`: exact playbook, exact bootstrap command, Docker/runtime contract, `./run_tests.sh`, local testing harness and development tooling if applicable, README structure baseline, explicit no-Docker execution before `P5`, exact stop boundary if that scaffold step is isolated, and exact evidence required
 - for development-completion review and the opening pass of fused `P5`, collect findings across the whole review sweep and send one consolidated fix request unless a hard blocker stops further checking
 - treat fused `P5` as a fast handoff phase: if rough repo-coherence review passes, proceed to evaluation instead of asking for more `P5` cleanup
 - default to one bounded engineering objective per Claude turn, except for the intentional broad `plan.md` execution run after planning acceptance where the worker is expected to complete the whole implementation checklist end to end
@@ -422,6 +426,7 @@ To the developer, this should feel like a normal engineering conversation with a
 - when several issues are found in one review sweep, batch them into one correction request grouped by failure class or surface instead of drip-feeding one issue at a time
 - for small non-core fixes such as README cleanup, docs sync, test config, Docker config, wrapper/config glue, or similar release-churn cleanup, fix them directly in the owner session instead of bouncing them 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
 - 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
@@ -445,7 +450,7 @@ To the developer, this should feel like a normal engineering conversation with a
 - at every gate exit, require the result to be checked against the relevant accepted plan sections and an explicit current-boundary checklist before accepting it
 - be especially strict before leaving planning and before leaving development: require explicit section coverage, concrete evidence, and no known prompt-critical gap hidden behind future work
 - in `P5`, prefer fast rough release-alignment over perfectionism; reserve evaluation for the stricter final check
-- prefer moving into evaluation from `P5` once the repo is coherent enough by static review and reported evidence; Docker execution is deferred until `P9`
+- prefer moving into evaluation from `P5` once the repo is coherent enough by the owner-run Docker/runtime gate, prompt review, and security review; `P9` is final confirmation rather than first execution
 - before every substantive Claude turn, review the last normalized result, decide whether the next turn is a correction, continuation, resume, or new bounded objective, and compose the prompt accordingly rather than sending vague nudges
 
 ## Claude Live Bridge Discipline
@@ -454,8 +459,8 @@ All Claude developer lane launch and turn actions should go through the packaged
 
 Evaluation-prompt rule:
 
-- backend and frontend evaluation prompts may only be changed by injecting the original project prompt into `{prompt}`; otherwise send them verbatim
-- the test-coverage prompt must be read from the file and sent verbatim with no additions, reductions, trimming, paraphrasing, or partial pasting
+- backend and frontend evaluation prompts must be prepared through `node ~/slopmachine/utils/prepare_evaluation_prompt.mjs --workspace-root .. --prompt-file <chosen-prompt-file>`, which reads parent-root `../metadata.json`, injects the real project prompt where needed, and writes the exact sendable body to a deterministic file under `../.ai/`
+- the owner must send the exact contents of that prepared file to the evaluator; on same-session reruns, prepare the file again with `--mode rerun` and then send the exact saved rerun file contents
 
 Operation map:
 
@@ -470,7 +475,7 @@ Operation map:
 - package the Claude project session folder for final delivery as one root zip bundle:
   - `node ~/slopmachine/utils/package_claude_session.mjs`
   - this resolves the tracked relevant Claude session artifacts from the tracked `session_id` values plus the project `cwd` under `~/.claude/projects/`, packages the normalized tracked transcript JSONL files together with the raw matching session directories once, and avoids sweeping unrelated random Claude sessions into the archive
-- after Claude session packaging is fully complete, stop each tracked live Claude lane with `node ~/slopmachine/utils/claude_live_stop.mjs --runtime-dir <dir>` and verify the tmux session is gone before closing `P9`
+- after Claude session packaging is fully complete, attempt to stop each tracked live Claude lane with `node ~/slopmachine/utils/claude_live_stop.mjs --runtime-dir <dir>`, but only when the bridge can prove the tmux session belongs to the current task runtime; if that check fails or the stop fails, leave the tmux session alone rather than risking another tmux instance
 
 Timeout rule:
 

package/assets/agents/slopmachine.md

@@ -185,7 +185,8 @@ 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 fast stabilization pass; only major brokenness should trigger a bounded developer reroute before returning to evaluation readiness
+- `P5 Integrated Verification and Hardening` should normally be one fast stabilization pass that includes the first real owner-run `docker compose up --build` and `./run_tests.sh` gate; owner-fixable Docker/config/wrapper churn should be fixed there directly, and only major brokenness should trigger a bounded developer reroute before returning to evaluation readiness
+- `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
 - `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`
 
@@ -202,11 +203,14 @@ Maintain exactly one active developer session at a time.
 - the final coverage/README audit then uses one additional fresh evaluator session and stays in that same session through its reruns, so the whole `P7` flow uses exactly 3 evaluator sessions total
 - after any kept audit report is saved, reread it and reject it if it hints at prior runs or if it has degraded materially from the original evaluation prompt's required depth, structure, sections, tables, verdict blocks, or evidence style
 - each audit result decides the remediation lane:
-  - `fail` -> route the exact issue list back to the most recent recoverable developer lane, discard the fail working report, fix the issues there, and then regenerate inside the same evaluator session
-  - `partial pass` -> keep `audit_report-<N>.md`, start `bugfix-N`, and keep its fix loop scoped to that audit report's issue list
-  - `pass` -> keep `audit_report-<N>.md`, start `bugfix-N` only for that report's recommended improvements, and if there are no actionable recommendations mark the audit session complete without inventing new issues
+  - 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/`, send the full issue list from that failed attempt to that audit session's exact `bugfix-N` lane, require that whole list to be fixed, and then rerun the full prepared evaluation prompt 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
+  - `pass` -> keep `audit_report-<N>.md`, use that audit session's exact `bugfix-N` lane for every actionable reported issue and recommendation in that report, and if there are no actionable 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`, reread each generated report and reject prior-run wording such as `previously` or `remaining` when it refers to report history, and if it finds any issue route the fixes back to the currently active recoverable developer session, replace the report, and rerun up to 3 times before carrying the latest report forward
+- 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`, reread each generated report and reject prior-run wording such as `previously` or `remaining` when it refers to report history, and judge the result by the owner's reading of the report as a whole: if it does not read as an overall pass, move the displaced report into `../.ai/archive/`, route the fixes to `bugfix-2` when that lane exists or else to the current recoverable developer session, replace the report, and rerun up to 3 times before carrying the latest report forward
 - 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
 
@@ -232,22 +236,20 @@ Do not launch the developer before clarification is complete and the workflow is
 During `P1 Clarification`, use this clarification handshake:
 
 1. launch one short-lived `General` clarification worker
-2. use the packaged `~/slopmachine/clarifier-agent-prompt.md` as the worker prompt, injecting the original prompt and supporting stack/context notes
-3. require the worker to output only `../docs/questions.md`
-4. review `../docs/questions.md`; if it misses material ambiguity, contains filler, or drifts from the prompt, correct clarification before continuing
-5. parse `../docs/questions.md` into the approved clarification package for planning: the accepted clarification list plus any short additional locked deltas that are not already captured there
-6. only after that package is strong enough should `P2` begin and the `develop-1` lane be launched
+2. use the packaged `~/slopmachine/clarifier-agent-prompt.md` verbatim as the worker prompt, injecting only the original prompt and supporting stack/context notes, and require it to output only `../docs/questions.md`
+3. use `clarification-gate` to review `../docs/questions.md` and turn it into the approved clarification package
+4. only when that package is complete and unambiguous enough to serve as the clarified prompt for planning should `P2` begin and the `develop-1` lane be launched
 
 When the first develop developer session begins in `P2`, use this planning sequence:
 
 1. send the original prompt and tell the developer to read it carefully, not plan yet, and wait for design direction
 2. wait for the developer's first reply
-3. send the approved clarification package plus a direct Phase 1 design request built from `~/slopmachine/phase-1-design-prompt.md` and `~/slopmachine/phase-1-design-template.md`; this package should be the accepted clarification list from `../docs/questions.md` plus any short additional locked deltas; require `../docs/design.md` and, when backend/fullstack APIs exist, `../docs/api-spec.md`, and say explicitly not to start execution planning yet
+3. send the inline approved clarification package plus a direct Phase 1 design request built from `~/slopmachine/phase-1-design-prompt.md` and `~/slopmachine/phase-1-design-template.md`; require `../docs/design.md` and, when backend/fullstack APIs exist, `../docs/api-spec.md`, and say explicitly not to start execution planning yet
 4. review Phase 1 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; reject only material gaps, and directly patch small owner-fixable contract issues until the design is accepted
 5. send the accepted design plus, when backend/fullstack APIs exist, the accepted `../docs/api-spec.md`, with a direct Phase 2 execution-planning request built from `~/slopmachine/phase-2-execution-planning-prompt.md`, `~/slopmachine/phase-2-plan-template.md`, and `~/slopmachine/exact-readme-template.md`; require `plan.md` plus an updated parent-root `../docs/test-coverage.md`, and say explicitly not to start implementation yet
-6. in that Phase 2 request, require the lane map to be derived from the directory tree and owned-file boundaries, require as many bounded branches or worktrees or agent lanes as safely possible, target at least 5 lanes when the codebase clearly supports it, require preplanned shared-file overlap and merge checkpoints, require exact serial-only justifications, require a dedicated git worktree plus explicit branch name for every planned parallel lane, and identify which named safe lanes must actually launch during implementation unless a blocker forces a reviewed revision
-7. review Phase 2 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; reject only material gaps, and directly patch small owner-fixable contract issues until `plan.md` is accepted
-8. only after both planning phases are accepted may the broad `plan.md` development run begin
+6. in that Phase 2 request, explicitly require a directory-tree-derived lane map, explicit shared-file control, exact serial-only justifications, a dedicated git worktree plus explicit branch name for every planned parallel lane, and at least 5 lanes when the codebase clearly supports that level of safe fan-out; also identify which named safe lanes must actually launch during implementation unless a blocker forces a reviewed revision
+7. review Phase 2 using `planning-gate` plus `~/slopmachine/owner-verification-checklist.md`; before leaving `P2`, do one final combined no-drift reread of the accepted design plus accepted plan against the original prompt and accepted clarifications, confirm `../docs/api-spec.md` when applicable and `../docs/test-coverage.md` are fulfilled from the accepted plan, and reject any remaining critical security weakness or planning drift
+8. only after that final planning reread passes may the broad `plan.md` development run begin
 
 Do not ask for Phase 1 and Phase 2 in the same turn.
 Do not ask for a plan in the first message.
@@ -256,18 +258,19 @@ After planning is accepted:
 
 - the default development request should be the broad `plan.md` execution run rather than many narrow feature follow-up prompts
 - tell the developer to work through `plan.md` end to end, keep `plan.md` updated from the main lane as items complete, verify honestly through non-Docker means, and return only when the whole implementation plan is done or a real blocker prevents continuation
-- in that default request, first land the scaffold step from section 3 of `plan.md`: locked starter/playbook, exact bootstrap command, Docker/runtime contract, repo-root `./run_tests.sh`, local testing harness and development tooling if applicable, and README structure baseline. Require the developer to set up those files honestly but not run Docker or `./run_tests.sh`. After that scaffold step is stable, establish the small shared-file contract and any `plan.md`-marked pre-fan-out security contract in the main lane, keep `plan.md`, `README.md`, and other shared integration files main-lane-owned by default, then explicitly tell the developer to create the planned git worktrees and spawn all planned parallel agents for the named `plan.md` sections during the main implementation run instead of waiting for another owner nudge, target at least 5 concurrent lanes when the codebase supports it, require each lane to complete its owned implementation plus all matching tests inside its assigned worktree, and keep final fan-in plus integrated verification in the main developer session
+- in that default request, tell the developer to land the scaffold step from section 3 of `plan.md` first without running Docker or `./run_tests.sh`, then stabilize the shared-file and pre-fan-out security contract in the main lane, then launch the named planned worktrees and parallel lanes, keep implementation plus matching tests together inside each lane, and keep final fan-in plus integrated verification in the main developer session
 - if development is interrupted before completion, resume by directing the developer to continue from the current state of `plan.md`
 
 ## Verification Budget
 
-Docker and `./run_tests.sh` are deferred until after `P7`.
+Docker and `./run_tests.sh` are deferred until the owner-run gate in `P5`.
 
 Owner-side discipline:
 
-- one owner-side Docker submission-readiness check after `P7`, with immediate reruns there only if Docker config or wrapper fixes are needed
+- one owner-side Docker/runtime and broad-test gate in `P5`, with immediate reruns there for owner-fixable Docker/config/wrapper/test-harness issues
+- one final confirmation rerun in `P9` when late fixes or packaging changes could still affect the runtime/test contract
 
-- do not run `./run_tests.sh` or `docker compose up --build` anywhere from planning through the end of `P7`
+- do not run `./run_tests.sh` or `docker compose up --build` anywhere from planning through the end of `P3`, and do not run them inside `P7`
 - do not rerun expensive local test or E2E commands just because the developer already ran them
 - when the developer reports the exact verification command and its result clearly, use that evidence unless there is a concrete reason to challenge it
 - rerun expensive non-Docker verification only when the developer evidence is weak, contradictory, flaky, high-risk, needed to answer a new question, or needed for a static owner decision
@@ -276,7 +279,7 @@ Owner-side discipline:
 Selected-stack rule:
 
 - follow the original prompt and existing repository first; only use package defaults when they do not already specify the platform or stack
-- do not run Docker-based broad verification before `P9`; use static review, local non-Docker evidence, and evaluator loops instead
+- do not run Docker-based broad verification before `P5`; use static review and local non-Docker evidence before that point, then keep `P7` non-Docker and reserve `P9` for final confirmation reruns only
 
 Every project must end up with:
 
@@ -299,22 +302,23 @@ Broad test command rule:
 
 Default moments:
 
-1. development complete -> direct fused `P5` entry for repo coherence only
-2. after `P7` completes -> owner-side Docker submission-readiness check in `P9`
+1. development complete -> direct fused `P5` entry with the owner-run Docker/runtime and broad-test gate
+2. after `P7` completes -> `P9` final confirmation rerun when the latest changes could affect the runtime/test contract
 
 For all project types, enforce this cadence:
 
-- do not run Docker during planning, development, `P5`, or `P7`
-- do not ask the developer to run Docker or `./run_tests.sh` under any circumstances before `P9`
-- after `P7` completes, the owner may run the documented Docker/runtime path and `./run_tests.sh` in `P9`, fix Docker config directly if needed, and rerun there before packaging closes
+- do not run Docker during planning, development, or `P7`
+- do not ask the developer to run Docker or `./run_tests.sh` under any circumstances; the owner handles the first broad gate in `P5` and may rerun it in `P9` for final confirmation
+- after `P3` completes, the owner should run the documented Docker/runtime path and `./run_tests.sh` in `P5`, fix owner-side Docker/config/wrapper/test-harness issues directly if needed, and rerun there before moving to evaluation
+- after `P7` completes, rerun those commands in `P9` only when final confirmation is still needed because late fixes or packaging changes touched the contract
 
 Docker timeout rule:
 
-- whenever the owner finally runs a Docker-based runtime or broad-test command after `P7`, or a repo-root `./run_tests.sh` that shells out to Docker, invoke it through `node ~/slopmachine/utils/run_with_timeout.mjs --label docker-gate -- <command ...>` instead of running the command directly
+- whenever the owner runs a Docker-based runtime or broad-test command in `P5` or `P9`, or a repo-root `./run_tests.sh` that shells out to Docker, invoke it through `node ~/slopmachine/utils/run_with_timeout.mjs --label docker-gate -- <command ...>` instead of running the command directly
 - the helper default is one 30 minute attempt, then one 45 minute retry after 30 seconds of backoff; do not let any single Docker attempt exceed 60 minutes
 - when invoking that helper through the OpenCode Bash tool, set the outer Bash timeout high enough to cover the helper retry budget plus cleanup buffer instead of using a short default
 
-Before that `P9` submission-readiness check, rely on:
+Before that owner-run `P5` Docker gate, rely on:
 
 - local runtime checks
 - targeted unit tests
@@ -368,10 +372,10 @@ When talking to the developer:
 - when backend or fullstack APIs are relevant, explicitly require progress on endpoint inventory, true no-mock HTTP coverage for important `METHOD + PATH` surfaces, and honest classification of mocked or indirect tests
 - when README compliance is relevant, explicitly require the strict audit sections: project type, startup instructions, access method, verification method, and demo credentials or the exact statement `No authentication required`
 - during ordinary development you may allow fast local iteration, but before final release-readiness review closes require cleanup of local-only setup traces so the delivered runtime and broad test contract is Docker-contained and reviewable
-- do not tell the developer to run Docker-based runtime/test commands; the owner handles that only after `P7`
+- do not tell the developer to run Docker-based runtime/test commands; the owner handles the first broad Docker gate in `P5`
 - speak to the developer like a human project manager or technical lead who cares about the project outcome; do not sound like workflow software or an orchestration relay
 - do not re-dump the entire design, but do point the developer back to `plan.md` as the working checklist and add only the narrow delta, guardrail, or review concern that matters now
-- for the first broad development turn, make the prompt mostly a restatement of section 3 of the accepted `plan.md`: exact playbook, exact bootstrap command, Docker/runtime contract, `./run_tests.sh`, local testing harness and development tooling if applicable, README structure baseline, explicit no-Docker execution before `P9`, exact stop boundary if that scaffold step is isolated, and exact evidence required
+- for the first broad development turn, make the prompt mostly a restatement of section 3 of the accepted `plan.md`: exact playbook, exact bootstrap command, Docker/runtime contract, `./run_tests.sh`, local testing harness and development tooling if applicable, README structure baseline, explicit no-Docker execution before `P5`, exact stop boundary if that scaffold step is isolated, and exact evidence required
 - after planning is accepted, the default development ask is the broad `plan.md` execution run rather than many narrow follow-up prompts
 - for planning turns, explicitly say that the developer must plan for parallelization up front, derive the lane map from the directory tree and owned-file boundaries, maximize the safe lane count, target at least 5 lanes when the codebase supports it, and justify any serial-only major section concretely
 - in that first broad `plan.md` execution turn, explicitly tell the developer to spawn the planned parallel agents or branches or worktrees for the named `plan.md` sections, with named branch contracts and main-session fan-in requirements
@@ -407,6 +411,7 @@ Do not speak as a relay for a third party.
 - when several issues are found in one review sweep, batch them into one correction request grouped by failure class or surface instead of drip-feeding one issue at a time
 - for small non-core fixes such as README cleanup, docs sync, test config, Docker config, wrapper/config glue, or similar release-churn cleanup, fix them directly in the owner session instead of bouncing them 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
 - 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 gate checklists over repeated prompt dumps
@@ -433,7 +438,7 @@ Be a strict reviewer.
 - do not progress because the developer sounds confident
 - reject weak evidence, decorative verification, and half-finished surfaces quickly
 - require enough runtime, test, and UI confidence for the current gate, but do not turn `P5` into a perfection loop over small documentation or configuration defects
-- prefer moving into evaluation from `P5` once the repo is coherent enough by static review and reported evidence; Docker execution is deferred until `P9`
+- prefer moving into evaluation from `P5` once the repo is coherent enough by the owner-run Docker/runtime gate, prompt review, and security review; `P9` is final confirmation rather than first execution
 - be especially strict before leaving planning and before leaving development: those exits require explicit checklist coverage against the accepted plan plus concrete supporting evidence
 - keep review messages direct, technical, and specific
 
@@ -456,8 +461,8 @@ Treat packaging as a first-class delivery contract from the start, not as late c
 
 - the evaluation prompt files under `~/slopmachine/` are used only during evaluation runs
 - the packaged source copies of those prompts live under `assets/slopmachine/`, and the installed runtime copies live under `~/slopmachine/`; ordinary evaluation runs should use the installed runtime copies
-- backend and frontend evaluation prompts may only be changed by injecting the original project prompt into `{prompt}`; otherwise send them verbatim
-- the test-coverage prompt must be read from the file and sent verbatim with no additions, reductions, trimming, paraphrasing, or partial pasting
+- backend and frontend evaluation prompts must be prepared through `node ~/slopmachine/utils/prepare_evaluation_prompt.mjs --workspace-root .. --prompt-file <chosen-prompt-file>`, which reads parent-root `../metadata.json`, injects the real project prompt where needed, and writes the exact sendable body to a deterministic file under `../.ai/`
+- the owner must send the exact contents of that prepared file to the evaluator; on same-session reruns, prepare the file again with `--mode rerun` and then send the exact saved rerun file contents
 - load `submission-packaging` before any packaging action
 - follow its exact artifact, export, cleanup, and output contract
 - do not invent extra artifact structures during ordinary packaging

package/assets/claude/agents/developer.md

@@ -74,6 +74,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - if a planned parallel lane cannot be launched, stop and record the exact skipped lane, blocker, and revised sequencing before proceeding serially
 - 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
 - when `plan.md` marks mutually exclusive file ownership, use separate git worktrees for those sections rather than overlapping edits in one checkout
+- by default, place planned worktrees under parent-root hidden `.ai/worktrees/` rather than as visible root-level sibling folders
 - keep shared files and final integration work in the main developer session unless the accepted plan explicitly delegates them
 - after any parallel fan-out, reconcile the work in the main developer session, verify the integrated result yourself, and only then mark the relevant `plan.md` items complete
 - when explicit agent selection is available for internal task fan-out, prefer the installed `developer` agent for implementation-capable branches so helper work stays aligned with the same engineering standard
@@ -133,9 +134,9 @@ During ordinary work, prefer:
 
 - fast local tooling setup is allowed during ordinary iteration, but it must not become a dependency of the final delivered runtime or broad test contract
 
-Do not run broad Docker, `./run_tests.sh`, browser E2E, Playwright, or full-suite commands during work from planning through the end of `P7`.
+Do not run broad Docker, `./run_tests.sh`, browser E2E, Playwright, or full-suite commands during work from planning through the end of `P3`, and do not run them inside `P7`.
 
-Do not run `docker compose up --build`, `./run_tests.sh`, or any other Docker-based runtime/test command under any circumstances before `P9`, even if the repo documents it, the plan implies it, or the owner explicitly asks; the owner handles final Docker and `./run_tests.sh` verification after evaluation is complete.
+Do not run `docker compose up --build`, `./run_tests.sh`, or any other Docker-based runtime/test command under any circumstances during planning, development, `P5`, or `P7`, even if the repo documents it, the plan implies it, or the owner explicitly asks; the owner handles the first broad Docker and `./run_tests.sh` verification in `P5` and may rerun it in `P9` for final confirmation.
 
 Selected-stack defaults:
 

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

@@ -14,61 +14,53 @@ Do not recreate the older owner-side clarification-options or clarification-prom
 
 ## Purpose
 
-Use this skill to drive the owner through the clarification procedure cleanly and consistently.
+Use this skill to keep `P1` narrow and useful.
 
-Its job is to ensure the owner:
-- starts from the original prompt plus supporting stack/context notes
-- runs one bounded clarification worker using the packaged `clarifier-agent-prompt.md`
-- requires the clarification worker to output only `../docs/questions.md`
-- treats `questions.md` as the clarification record of material ambiguities and prompt-faithful defaults
-- reviews `questions.md` critically before planning begins
-- extracts the approved clarification package from `questions.md` for Phase 1 design, with any extra locked deltas kept short and explicit
+Clarification should:
+- start from the original prompt plus supporting stack/context notes
+- run one bounded clarification worker using the packaged `clarifier-agent-prompt.md` verbatim
+- require the worker to output only `../docs/questions.md`
+- treat `questions.md` as the only clarification artifact planning depends on
+- extract an approved clarification package from `questions.md` before `P2`
+- make that approved package the complete unambiguous clarified-prompt baseline for planning
 
 ## Core Rule
 
-Clarification exists to resolve material ambiguity before design.
+Clarification exists to resolve material product ambiguity before design.
 
-It must not:
-- become planning
-- become architecture design
-- become execution planning
-- narrow the prompt for convenience
-- fill `questions.md` with trivial tooling, Docker, or implementation-structure questions
+It must not become planning, architecture design, execution planning, or convenience narrowing. Stack, tooling, Docker, and implementation-structure questions belong later unless they materially change the product contract.
 
 ## Procedure
 
-1. Confirm the clarification inputs.
-- Keep the original product prompt as the primary source of truth.
+1. Confirm the inputs.
+- Keep the original product prompt as the source of truth.
 - Treat supporting stack/context as supporting information unless it materially changes the product contract.
 
 2. Run the clarifier worker.
-- Use the packaged `clarifier-agent-prompt.md` as the worker prompt.
-- Require the worker to produce only `../docs/questions.md`.
+- Use the packaged `clarifier-agent-prompt.md` verbatim.
+- Only inject the original prompt and supporting stack/context notes into that packet; do not prepend or append a second owner-written clarification contract.
+- Require only `../docs/questions.md` as output.
 
-3. Review `questions.md` against the clarification bar.
+3. Review `questions.md` critically.
 - It should cover material ambiguity only.
-- It should preserve prompt faithfulness.
+- It should preserve prompt faithfulness and avoid convenience narrowing.
 - Each entry should end with a decisive solution.
-- It should not contain planning, implementation structure, or convenience narrowing.
-- It should survive an explicit anti-degradation read against the original prompt: no dropped implied requirements, no softened enforcement, no collapsed workflows, and no operator/admin narrowing for convenience.
+- It should not leak into planning or implementation structure.
+- Reread it once against the original prompt and reject any degradation of implied scope, enforcement, workflow closure, or operator/admin behavior.
 
-4. Correct weak clarification before planning.
-- If `questions.md` misses major ambiguity, contains filler, or drifts from the prompt, correct it before moving on.
-- Do not begin design or planning until `questions.md` is strong enough.
-
-5. Build the approved clarification package.
-- Read `../docs/questions.md` and extract the accepted clarification list.
-- If a small number of additional locked deltas must accompany it, keep them short and explicit rather than inventing a second clarification artifact.
-- Use that accepted clarification package as the Phase 1 design baseline.
+4. Build the approved clarification package.
+- Extract the accepted clarification list from `../docs/questions.md`.
+- If a few extra locked deltas are still needed, keep them short and explicit.
+- Use that package as the complete clarified-prompt baseline for Phase 1 design and later planning.
 
 ## Rejection Triggers
 
-Reject the clarification result if any of the following is true:
-- material ambiguity is still unresolved
+Reject the clarification result if:
+- material ambiguity remains unresolved
 - the clarifier narrowed scope for convenience
-- the clarification record degrades the original prompt by reducing implied scope, enforcement, actor responsibilities, workflow closure, or reporting/operational expectations
-- the questions are mostly about stack, tooling, Docker, or testing process
-- entries end in vague or deferred language instead of decisive solutions
+- the clarification record degrades the original prompt
+- the file is mostly stack, tooling, Docker, or testing-process questions
+- entries are vague or deferred instead of decisive
 - planning or implementation structure leaked into `questions.md`
 
 ## Exit Condition
@@ -76,6 +68,7 @@ Reject the clarification result if any of the following is true:
 `P1 Clarification` is complete only when:
 - `../docs/questions.md` exists
 - it resolves the material prompt ambiguities with prompt-faithful defaults
-- it has been read once more against the original prompt and does not materially degrade it
+- it has survived one explicit reread against the original prompt
 - the owner has extracted the approved clarification package from it
+- that package is complete and unambiguous enough to act as the clarified prompt for planning
 - planning can begin without inventing missing product meaning

package/assets/skills/claude-worker-management/SKILL.md

@@ -43,6 +43,7 @@ Before any Claude-backed developer work continues:
 
 - determine whether the intended developer lane already has a recoverable live Claude session
 - if the intended lane exists and its bridge state is recoverable, recover that same session and continue there
+- if the intended lane's tmux process died but bridge state still has a recoverable Claude `session_id`, relaunch that same lane by resuming the existing Claude session instead of starting a fresh Claude conversation
 - if the current workflow boundary requires Claude developer work and no recoverable session is present yet, launch the necessary Claude lane first instead of treating the missing session as a handoff blocker
 - do not send substantive work until the live lane exists, bridge registration has captured the Claude `session_id`, owner metadata and Beads comments have been synced, and the first session-start message for that lane has completed
 - a missing Claude session during adoption, conservative lifecycle-state repair, or other first-entry work is not itself an error; it means the owner must establish the correct live lane before continuing
@@ -79,6 +80,8 @@ node ~/slopmachine/utils/claude_live_status.mjs --runtime-dir ../.ai/claude-live
 node ~/slopmachine/utils/claude_live_stop.mjs --runtime-dir ../.ai/claude-live/develop-1
 ```
 
+- the stop helper must only kill a tmux session when bridge state proves it belongs to the current task runtime; if ownership is not proven or kill fails, leave the tmux session alone instead of touching unrelated tmux instances
+
 If you need argument help, these scripts should support `--help`; do not guess flag shapes when an exact command pattern is already available here.
 
 ## Model selection rule
@@ -146,7 +149,7 @@ For substantive live-lane prompts, write the message in natural engineering lang
 - the important shortcuts that are not acceptable
 - where Claude should stop
 - the exact changed-files and verification summary expected back
-- do not ask Claude to run Docker-based runtime/test commands under any circumstances during planning, development, `P5`, or `P7`; Docker execution is owner-only after `P7`
+- do not ask Claude to run Docker-based runtime/test commands under any circumstances during planning, development, `P5`, or `P7`; Docker execution is owner-only, first in `P5` and then only as a final confirmation rerun in `P9` when needed
 
 When the message intentionally uses internal parallel fan-out, also cover naturally: