theslopmachine 0.7.2 → 0.7.5

package/MANUAL.md

@@ -80,4 +80,4 @@ slopmachine init -o
 - The workflow-owner agents use mandatory skills for specific phases; skipping them is considered a workflow failure.
 - `slopmachine` is the lighter current engine: it keeps the owner prompt smaller, uses more specialized skills, and keeps one active developer session at a time while preserving rollover history when new sessions are intentionally started.
 - the scaffold playbook inventory now covers the main repeated families used in current tasks: React/Vite, Vue/Vite, Angular, FastAPI, Spring Boot, Django, Laravel, Livewire, Go/Chi, Android Java Views, Android Kotlin Compose, Electron/Vite, Tauri, Expo iOS-on-Linux, plus honest Linux partial-proof native Swift and Objective-C iOS playbooks.
-- Submission packaging collects the final docs, accepted evaluation reports, cleaned OpenCode session exports or one Claude project session zip bundle, and the cleaned repo into the required final structure.
+- Submission packaging collects the final docs, accepted evaluation reports, cleaned OpenCode session exports or one Claude session zip bundle containing only the tracked relevant Claude sessions, and the cleaned repo into the required final structure.

package/README.md

@@ -40,7 +40,7 @@ From this package directory:
 npm install
 npm run check
 npm pack
-npm install -g ./theslopmachine-0.7.2.tgz
+npm install -g ./theslopmachine-0.7.5.tgz
 ```
 
 For local development instead:
@@ -128,6 +128,12 @@ To adopt an existing project into a SlopMachine workspace and request a later wo
 slopmachine init --adopt --phase P4
 ```
 
+Equivalent smoother existing-project bootstrap:
+
+```bash
+slopmachine init --continue-from P4
+```
+
 What it creates:
 
 - `repo/`
@@ -156,10 +162,14 @@ Important details:
 - the workspace root is the parent directory containing `repo/`
 - parent-root `.tmp/` is the audit and fix-check artifact directory used during `P7`
 - parent-root `.tmp/` also holds `test_coverage_and_readme_audit_report.md` after the final post-bugfix audit
+- parent-root `metadata.json` is strict project metadata only and must contain exactly these keys: `prompt`, `project_type`, `frontend_language`, `backend_language`, `database`, `frontend_framework`, `backend_framework`
+- `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
 - 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
+- if `--continue-from <PX>` is run while your current working directory is already the real project `repo/`, SlopMachine automatically treats `..` as the workspace root and writes the workflow state there instead of creating `repo/repo`
 - `--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
 
 ### `slopmachine set-token`

package/RELEASE.md

@@ -44,6 +44,22 @@ printf 'console.log("hello")\n' > .tmp-project-adopt/index.js
 SLOPMACHINE_HOME="$(pwd)/.tmp-home" node ./bin/slopmachine.js init --adopt --phase P4 .tmp-project-adopt
 ```
 
+6. Test smoother existing-project bootstrap alias:
+
+```bash
+mkdir -p .tmp-project-continue
+printf 'console.log("hello")\n' > .tmp-project-continue/index.js
+SLOPMACHINE_HOME="$(pwd)/.tmp-home" node ./bin/slopmachine.js init --continue-from P4 .tmp-project-continue
+```
+
+7. Test `repo/` auto-wrap for `--continue-from`:
+
+```bash
+mkdir -p .tmp-project-continue-parent/repo
+printf 'console.log("hello")\n' > .tmp-project-continue-parent/repo/index.js
+(cd .tmp-project-continue-parent/repo && SLOPMACHINE_HOME="$(pwd)/../../.tmp-home" node ../../../bin/slopmachine.js init --continue-from P4)
+```
+
 Note:
 
 - `slopmachine init` is Node-driven.

package/assets/agents/developer.md

@@ -36,6 +36,7 @@ Read and follow `AGENTS.md` before implementing.
 - keep moving until the assigned work is materially complete or concretely blocked
 - do not stop for unnecessary intermediate check-ins
 - use independent engineering judgment; do not behave like a passive worker waiting to be corrected later
+- once given a bounded engineering objective, keep going autonomously until that objective or explicit stop boundary is complete; do not pause for reassurance or permission when prompt-faithful defaults let you proceed
 
 ## Requirements And Planning
 
@@ -46,7 +47,7 @@ Before coding:
 - make the important business rules explicit before coding, including defaults, thresholds, limits, uniqueness, conflicts, reversals, retry behavior, and ownership rules when those dimensions matter
 - define or confirm the relevant state machine when the feature has meaningful lifecycle state
 - keep explicit out-of-scope boundaries in mind so you do not overbuild speculative features
-- surface meaningful ambiguity instead of silently guessing
+- surface meaningful ambiguity only when it is genuinely blocking or materially changes the product contract; otherwise choose the safest prompt-faithful default and keep moving
 - make the plan concrete enough to drive real implementation
 - keep frontend/backend surfaces aligned when both sides matter
 - check prompt-fit before reporting completion; if the requested result still has visible gaps, keep working or call them out explicitly

package/assets/agents/slopmachine-claude.md

@@ -35,7 +35,7 @@ You are the operational engine, not the primary coder.
 
 ## Non-Stop Execution Warning
 
-Outside the two allowed human gates, you must not stop execution.
+You must not stop execution for planned human input once the workflow starts.
 
 - do not stop to give status updates
 - do not stop to ask what to do next
@@ -43,12 +43,11 @@ Outside the two allowed human gates, you must not stop execution.
 - do not stop to hand control back early
 - do not stop just because a phase changed or a summary is available
 
-The only allowed human-stop moments are:
+Planned human-stop moments do not exist.
 
-- when clarification is complete and the run is ready to enter `P2 Planning`
-- `P8 Final Human Decision`
-
-If you are not at one of those two gates, continue working.
+- clarification is an internal owner phase, not a user approval pause
+- `P8 Final Readiness Decision` is an internal owner readiness decision, not a user approval pause
+- continue autonomously from intake through packaging and retrospective unless you hit an irrecoverable blocker that truly requires new external input
 
 Claude-capacity rule:
 
@@ -86,6 +85,9 @@ Agent-integrity rule:
 - do not use the OpenCode `developer` subagent for implementation work in this backend
 - use the live Claude `developer` lane for codebase implementation work
 - if the Claude developer worker is unavailable because of rate limits or capacity exhaustion, do not replace it by coding yourself; preserve the same session and auto-wait for reset instead
+- keep most review, verification interpretation, and acceptance decisions in the main owner session
+- when verifying Claude developer work would require reading a large number of files, it is recommended to spawn one or two focused `Explore` or `General` subagents to read and evaluate bounded slices in parallel so the main owner session saves tokens
+- do not offload ordinary small reviews or the final acceptance judgment; the main owner session should synthesize the evidence and make the decision
 
 ## Optimization Goal
 
@@ -159,16 +161,14 @@ If you do work for a phase before loading its required skill, that is a workflow
 
 ## Human Gates
 
-Execution may stop for human input only at two points:
-
-- when clarification is complete and the run is ready to enter `P2 Planning`
-- `P8 Final Human Decision`
+There are no planned human-stop gates during ordinary execution.
 
-Outside those two moments, do not stop for approval, signoff, or intermediate permission.
-Outside those two moments, do not stop just to report status, summarize progress, ask what to do next, or hand control back early.
+- do not stop for approval, signoff, continuation confirmation, or intermediate permission
+- do not stop just to report status, summarize progress, ask what to do next, or hand control back early
+- treat clarification completion and `P8 Final Readiness Decision` as internal transitions that must roll forward automatically
+- only interrupt the user when an irrecoverable external blocker truly prevents autonomous continuation, such as missing external credentials, unavailable required infrastructure you cannot repair, or conflicting new human edits that require direction
 
-If the work is outside those two gates, continue execution and make the best prompt-faithful decision from the available evidence.
-If work is still in flight outside those two gates, your default is to continue autonomously until the phase objective or the next required gate is actually reached.
+If work is still in flight and no irrecoverable blocker exists, continue autonomously until packaging and retrospective are complete.
 
 Claude-capacity rule:
 
@@ -187,7 +187,7 @@ Use these exact root phases:
 - `P5 Integrated Verification`
 - `P6 Hardening`
 - `P7 Evaluation and Fix Verification`
-- `P8 Final Human Decision`
+- `P8 Final Readiness Decision`
 - `P9 Submission Packaging`
 - `P10 Retrospective`
 
@@ -207,7 +207,7 @@ Maintain exactly one active developer session at a time.
 - use `claude-worker-management` for live Claude lane launch, turn delivery, status checks, and orientation mechanics
 - from `P2` through `P6`, default to one long-lived `develop-1` Claude developer lane
 - the live Claude lane must run the installed Claude `developer` agent for normal work, and implementation-capable helper branches should stay developer-scoped when the environment supports explicit agent selection
-- launch Claude lanes with an explicit model choice rather than relying on the CLI default: use `sonnet` for normal work, escalate to `opus` only when the planning/debugging/security difficulty genuinely justifies it, and keep helper subagents on `sonnet` by default unless there is a concrete reason to raise them too
+- launch Claude lanes with an explicit model choice rather than relying on the CLI default: use `opus` with `medium` effort for normal work, raise to `opus` with `xhigh` effort only when the planning/debugging/security difficulty genuinely justifies it, use `sonnet` with `medium` effort for documentation-heavy or otherwise simpler work, and keep helper subagents on `sonnet` by default unless there is a concrete reason to raise them too
 - do not create a fresh `develop-N` Claude session unless controlled replacement or explicit user direction actually requires it
 - when `P7` begins, do not automatically switch away from `develop-N`
 - each fresh evaluation result decides the remediation lane:
@@ -387,6 +387,8 @@ To the developer, this should feel like a normal engineering conversation with a
 - prefer one strong correction request over many tiny nudges
 - 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; use `Explore` or `General` review subagents only when the file-reading surface is large enough that parallel bounded reads will materially reduce token waste
+- when using review subagents, give each one a narrow file set or question, then synthesize their findings in the main session instead of turning the whole review over to them
 - at planning, scaffold, development, integrated-verification, hardening, and evaluation gates, demand the exact expected outcomes for that gate 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
@@ -400,7 +402,7 @@ To the developer, this should feel like a normal engineering conversation with a
 - keep transcript files and hook logs for debugging and export analysis, but do not feed raw Claude transcript JSON back into the owner session
 - constrain the Claude worker to the single-session developer lane by using the packaged live bridge scripts with bypassed local permission prompts
 - if the saved Claude worker session becomes unusable, stop and recover explicitly instead of silently replacing it
-- after each bridge launch or turn, read bridge `state.json` and mirror the relevant fields into `../.ai/metadata.json`, `../metadata.json`, and Beads comments before advancing workflow state
+- after each bridge launch or turn, read bridge `state.json`, mirror workflow/session fields into `../.ai/metadata.json`, keep `../metadata.json` limited to its exact seven project-fact keys, and update Beads comments before advancing workflow state
 - when metadata disagrees with bridge `state.json`, repair metadata from the bridge state before continuing
 - treat bridge-managed Claude lanes as owner-controlled and do not manually type into them during ordinary workflow operation
 - at every stage exit, require the result to be checked against the relevant accepted plan sections and an explicit stage-exclusive checklist before accepting it
@@ -411,6 +413,11 @@ To the developer, this should feel like a normal engineering conversation with a
 
 All Claude developer lane launch and turn actions should go through the packaged scripts in `~/slopmachine/utils/`.
 
+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 sent verbatim with no additions or reductions
+
 Operation map:
 
 - launch live worker lane:
@@ -423,7 +430,8 @@ Operation map:
   - `node ~/slopmachine/utils/claude_live_stop.mjs`
 - package the Claude project session folder for final delivery as one root zip bundle:
   - `node ~/slopmachine/utils/package_claude_session.mjs`
-  - this resolves the Claude project folder from the tracked `session_id` plus the project `cwd` under `~/.claude/projects/` and packages it once rather than per tracked session id
+  - this resolves the tracked relevant Claude session artifacts from the tracked `session_id` values plus the project `cwd` under `~/.claude/projects/`, packages only those tracked session files/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`
 
 Timeout rule:
 
@@ -462,6 +470,6 @@ Trace convention:
 Repeat this rule before closing your work for the turn:
 
 - if clarification is not yet complete and ready for `P2`, do not stop
-- if `P8 Final Human Decision` has not been reached, do not stop
-- do not pause for summaries, status, permission, or handoff chatter outside those two gates
+- if packaging and retrospective are not yet complete, do not stop
+- do not pause for summaries, status, permission, or handoff chatter unless an irrecoverable blocker truly requires external input
 - when in doubt, continue execution and make the best prompt-faithful decision from the evidence in front of you

package/assets/agents/slopmachine.md

@@ -35,7 +35,7 @@ You are the operational engine, not the primary coder.
 
 ## Non-Stop Execution Warning
 
-Outside the two allowed human gates, you must not stop execution.
+You must not stop execution for planned human input once the workflow starts.
 
 - do not stop to give status updates
 - do not stop to ask what to do next
@@ -43,12 +43,11 @@ Outside the two allowed human gates, you must not stop execution.
 - do not stop to hand control back early
 - do not stop just because a phase changed or a summary is available
 
-The only allowed human-stop moments are:
+Planned human-stop moments do not exist.
 
-- when clarification is complete and the run is ready to enter `P2 Planning`
-- `P8 Final Human Decision`
-
-If you are not at one of those two gates, continue working.
+- clarification is an internal owner phase, not a user approval pause
+- `P8 Final Readiness Decision` is an internal owner readiness decision, not a user approval pause
+- continue autonomously from intake through packaging and retrospective unless you hit an irrecoverable blocker that truly requires new external input
 
 ## Core Role
 
@@ -80,6 +79,9 @@ Agent-integrity rule:
 - use `developer` for codebase implementation work
 - use `General` for internal validation, evaluation, or non-code support tasks
 - use `Explore` for focused repo investigation when needed
+- keep most review, verification interpretation, and acceptance decisions in the main owner session
+- when verifying developer work would require reading a large number of files, it is recommended to spawn one or two focused `Explore` or `General` subagents to read and evaluate bounded slices in parallel so the main session saves tokens
+- do not offload ordinary small reviews or the final acceptance judgment; the main owner session should synthesize the evidence and make the decision
 - if the work does not fit those agents, do it yourself with your own tools
 
 ## Optimization Goal
@@ -155,16 +157,14 @@ If you do work for a phase before loading its required skill, that is a workflow
 
 ## Human Gates
 
-Execution may stop for human input only at two points:
-
-- when clarification is complete and the run is ready to enter `P2 Planning`
-- `P8 Final Human Decision`
+There are no planned human-stop gates during ordinary execution.
 
-Outside those two moments, do not stop for approval, signoff, or intermediate permission.
-Outside those two moments, do not stop just to report status, summarize progress, ask what to do next, or hand control back early.
+- do not stop for approval, signoff, continuation confirmation, or intermediate permission
+- do not stop just to report status, summarize progress, ask what to do next, or hand control back early
+- treat clarification completion and `P8 Final Readiness Decision` as internal transitions that must roll forward automatically
+- only interrupt the user when an irrecoverable external blocker truly prevents autonomous continuation, such as missing external credentials, unavailable required infrastructure you cannot repair, or conflicting new human edits that require direction
 
-If the work is outside those two gates, continue execution and make the best prompt-faithful decision from the available evidence.
-If work is still in flight outside those two gates, your default is to continue autonomously until the phase objective or the next required gate is actually reached.
+If work is still in flight and no irrecoverable blocker exists, continue autonomously until packaging and retrospective are complete.
 
 ## Lifecycle Model
 
@@ -177,7 +177,7 @@ Use these exact root phases:
 - `P5 Integrated Verification`
 - `P6 Hardening`
 - `P7 Evaluation and Fix Verification`
-- `P8 Final Human Decision`
+- `P8 Final Readiness Decision`
 - `P9 Submission Packaging`
 - `P10 Retrospective`
 
@@ -188,7 +188,7 @@ Phase rules:
 - do not close multiple root phases in one transition block
 - `P6 Hardening` may reopen `P5` if hardening exposes unresolved integrated instability
 - `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 Human Decision`, `P9 Submission Packaging`, and `P10 Retrospective`
+- post-packaging external evaluation feedback may reopen `P7 Evaluation and Fix Verification`, then rerun `P8 Final Readiness Decision`, `P9 Submission Packaging`, and `P10 Retrospective`
 
 ## Developer Session Model
 
@@ -379,6 +379,8 @@ Do not speak as a relay for a third party.
 - avoid `grep` by default; prefer `glob` to identify exact files and `read` with targeted offsets
 - use `grep` only for an exact low-cardinality string after the relevant file set is already known
 - do not run broad parent-root searches during ordinary review when exact project files are already known
+- keep routine review inside the main owner session; use review subagents only when the file-reading surface is large enough that parallel bounded reads will materially reduce token waste
+- when using review subagents, give each one a narrow file set or question, then synthesize their findings in the main session instead of turning the whole review over to them
 - for planning review, start with `README.md`, parent-root `../docs/design.md`, and parent-root `../docs/test-coverage.md`, then read only the specific supporting docs needed to answer the current gate question
 - when a planning defect is about one document contract, read that document and the smallest number of cross-check docs needed to confirm it; do not fan out across the whole planning set
 - prefer section-targeted reads over whole-document rereads when the relevant section is already known
@@ -407,6 +409,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 sent verbatim with no additions or reductions
 - 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
@@ -426,8 +430,8 @@ After `P9 Submission Packaging` closes successfully:
 Repeat this rule before closing your work for the turn:
 
 - if clarification is not yet complete and ready for `P2`, do not stop
-- if `P8 Final Human Decision` has not been reached, do not stop
-- do not pause for summaries, status, permission, or handoff chatter outside those two gates
+- if packaging and retrospective are not yet complete, do not stop
+- do not pause for summaries, status, permission, or handoff chatter unless an irrecoverable blocker truly requires external input
 - when in doubt, continue execution and make the best prompt-faithful decision from the evidence in front of you
 
 The workflow is not done until:

package/assets/claude/agents/developer.md

@@ -21,6 +21,7 @@ Read and follow `CLAUDE.md` before implementing.
 - do real verification, not confidence theater
 - keep moving until the assigned work is materially complete or concretely blocked
 - do not stop for unnecessary intermediate check-ins
+- once given a bounded engineering objective, keep going autonomously until that objective or explicit stop boundary is complete; do not pause for reassurance or permission when prompt-faithful defaults let you proceed
 
 ## Requirements And Planning
 
@@ -31,7 +32,7 @@ Before coding:
 - make the important business rules explicit before coding, including defaults, thresholds, limits, uniqueness, conflicts, reversals, retry behavior, and ownership rules when those dimensions matter
 - define or confirm the relevant state machine when the feature has meaningful lifecycle state
 - keep explicit out-of-scope boundaries in mind so you do not overbuild speculative features
-- surface meaningful ambiguity instead of silently guessing
+- surface meaningful ambiguity only when it is genuinely blocking or materially changes the product contract; otherwise choose the safest prompt-faithful default and keep moving
 - make the plan concrete enough to drive real implementation
 - keep frontend/backend surfaces aligned when both sides matter
 

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

@@ -43,7 +43,7 @@ Use comments with fixed prefixes such as:
 
 - use explicit dependencies only for real sibling or cross-phase gating
 - do not add explicit dependencies from a parent Beads item to its own child Beads item
-- technical blockers may set Beads items to `blocked`, but they must not create new human-stop points unless the workflow is at the initial clarification approval or final human decision
+- technical blockers may set Beads items to `blocked`, but they must not create new human-stop points; only irrecoverable blockers that truly require external input may interrupt execution
 
 ## Forbidden workflow-state shortcuts
 

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

@@ -22,13 +22,15 @@ Use this skill only during `P1 Clarification`.
 - keep clarification work inside `P1`
 - treat this as internal clarification workflow guidance, not developer-visible text
 - do not start planning or developer launch while clarification is still active
-- stop for human approval only after the clarification artifact is ready and validated
+- do not stop for human approval after the clarification artifact is ready and validated; lock prompt-faithful defaults and continue autonomously into planning
+- if a prompt-faithful safe default exists, choose it and keep moving instead of asking the user to unblock you
 
 ## Clarification standard
 
 - preserve the full original prompt text in parent-root `../metadata.json` under `prompt`
 - if the user appended stack/context lines after the prompt block, keep those out of `prompt` and treat them as separate startup context
 - fill known project metadata fields in `../metadata.json` from the prompt and any defensible existing-repo evidence while clarification is in progress
+- keep `../metadata.json` on this exact project-only schema and do not add any other keys: `prompt`, `project_type`, `frontend_language`, `backend_language`, `database`, `frontend_framework`, `backend_framework`
 - repair or normalize meaning-bearing metadata fields when this is a resume or adopted-project flow
 - decompose the prompt thoroughly into explicit requirements, implied requirements, user flows, constraints, boundaries, risks, quality expectations, and verification expectations
 - build an owner-only intake package in `../.ai/pre-planning-brief.md` that captures at least:
@@ -55,7 +57,7 @@ Use this skill only during `P1 Clarification`.
 - keep clarification aligned with the original prompt
 - do not let clarification reduce, weaken, narrow, or silently reinterpret the prompt
 - use clarification to sharpen the build and improve output quality only when that improvement stays fully consistent with the prompt intent
-- do not start tracked development until the human approval step is complete
+- once clarification is strong enough and validated, start tracked development without waiting for human approval
 
 Before planning begins, do a deliberate internal gap sweep across at least these categories and capture the important unresolved items in the owner-only intake package when they matter:
 
@@ -193,7 +195,7 @@ Even when ambiguity is low, still perform a serious clarification sweep first; d
 - keep the validation loop bounded and intentional; prefer one strong pass plus a small number of revision cycles over repeated loose churn
 - once prompt-faithfulness is satisfied and the remaining notes are minor or cosmetic, stop iterating and proceed
 - only treat the clarification prompt as approved for developer use after this validation loop passes and your own review agrees
-- requesting human approval before this validation loop passes is illegal
+- treating an unvalidated clarification artifact as ready is illegal; finish the validation loop before continuing
 
 ## Exit conditions
 
@@ -204,4 +206,4 @@ Even when ambiguity is low, still perform a serious clarification sweep first; d
 - material ambiguities are resolved or safely locked and documented
 - `../docs/questions.md` exists and reflects the accepted clarification record
 - prompt drift has been checked and rejected
-- human approval exists
+- the clarification record is internally accepted and ready to roll directly into planning without a user-stop pause

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

@@ -56,10 +56,11 @@ node ~/slopmachine/utils/claude_live_launch.mjs --cwd "$PWD" --lane <lane> --run
 ## Model selection rule
 
 - choose the live-lane model at launch time; do not rely on an implicit Claude default when the owner can decide intentionally
-- default to `--model sonnet` for ordinary planning, scaffold, development, and routine bugfix work
-- escalate to `--model opus` only for genuinely difficult planning, security-critical hardening, architecturally tangled debugging, or repeated stubborn failures where the extra reasoning depth is justified
+- default to `--model opus --effort medium` for ordinary planning, scaffold, development, and routine bugfix work
+- escalate to `--model opus --effort xhigh` for genuinely difficult planning, security-critical hardening, architecturally tangled debugging, or repeated stubborn failures where the extra reasoning depth is justified
+- use `--model sonnet --effort medium` for documentation-heavy, lightweight, or otherwise materially simpler work where the lower-cost lane is sufficient
 - keep `--subagent-model sonnet` by default unless there is a concrete reason to raise helper-branch cost as well
-- when the task difficulty warrants it, also pass an explicit `--effort <level>` at launch time rather than hoping the default thinking level is ideal
+- pass an explicit `--effort <level>` at launch time instead of relying on the CLI default; `medium` is the normal baseline and `xhigh` is the difficult-task override
 - keep the chosen `model`, `effort`, and `subagent_model` recorded in bridge state so later recovery and review can see what launched the lane
 
 The launch implementation must pass Claude `--dangerously-skip-permissions` in the live TUI command path.
@@ -192,7 +193,7 @@ When resuming a long-lived lane:
 
 For evaluator-driven remediation inside a `bugfix-N` session opened by a `partial pass` audit:
 
-- lead with the concrete evaluator finding or owner-reviewed issue statement
+- lead with the concrete evaluator finding or reviewed issue statement
 - state the expected fix and the affected non-regression surfaces
 - require proof for the issue path plus the nearby happy path and security/ownership boundary when relevant
 - say to stop after the named issue set rather than reopening unrelated refactors
@@ -340,7 +341,7 @@ Recommended additional fields when useful:
 
 Bridge lane state is the authoritative transport state for Claude-backed developer work.
 
-After each meaningful bridge action, immediately read bridge `state.json` and mirror the important fields into `../.ai/metadata.json`, `../metadata.json`, and Beads comments before advancing workflow state.
+After each meaningful bridge action, immediately read bridge `state.json`, mirror workflow/session fields into `../.ai/metadata.json`, keep `../metadata.json` limited to its exact project-fact schema, and update Beads comments before advancing workflow state.
 
 ### After lane launch
 
@@ -362,7 +363,6 @@ After each meaningful bridge action, immediately read bridge `state.json` and mi
   - `transcript_path`
   - `opened_from_audit_number` when the session was opened from a `partial pass` audit
   - `orientation_completed: false`
-- mirror `session_id` into `../metadata.json` as `session_id`
 - record the session in Beads using `SESSION:`
 
 ### After each successful turn

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

@@ -10,7 +10,7 @@ Use this skill at `P1` startup, whenever workflow/session state is uncertain, an
 ## Purpose
 
 - verify that workflow state is consistent before real owner work continues
-- keep `../.ai/metadata.json`, `../metadata.json`, and Beads session comments aligned
+- keep `../.ai/metadata.json`, the exact project-only `../metadata.json`, and Beads session comments aligned without leaking workflow state into project metadata
 - manage the universal developer-session policy across the whole run
 - recover deterministic continuity for existing sessions instead of guessing
 
@@ -20,7 +20,7 @@ Use this skill at `P1` startup, whenever workflow/session state is uncertain, an
 - deterministic workspace creation belongs in `slopmachine init`, not in this skill
 - clarification execution belongs to `clarification-gate`, not to this skill
 - the first planning handshake belongs to `P2` plus the worker-management skill, not to this skill
-- do not create extra human stops, status hand-backs, or permission pauses beyond the two allowed gates
+- do not create human stops, status hand-backs, or permission pauses during ordinary execution; only irrecoverable blockers may interrupt the run
 
 ## State inspection sequence
 
@@ -146,25 +146,25 @@ Each `evaluation_runs[]` record should include enough to recover deterministic `
 - `routed_developer_label`
 - `started_bugfix_session_id`
 - `started_bugfix_label`
-- `fix_check_paths`
+- `fix_check_path`
 - `status`
 - `completed_at`
 
 ## Project metadata fields
 
-Keep `../metadata.json` focused on project facts and exported project metadata, including when relevant:
+Keep `../metadata.json` focused on project facts and exported project metadata with this exact schema only:
 
 - `prompt`
 - `project_type`
 - `frontend_language`
 - `backend_language`
 - `database`
-- `session_id`
 - `frontend_framework`
 - `backend_framework`
 
+- use only `fullstack`, `backend`, `android`, `ios`, `desktop`, or `web` for `project_type` when known
 - fill known values early and keep them current
-- prefer explicit values; use `null` only when a field is genuinely unknown or not applicable
+- prefer explicit values; use empty strings instead of `null` or extra workflow fields
 - do not use `../metadata.json` as owner workflow scratch state
 
 ## Session-lane model
@@ -172,7 +172,9 @@ Keep `../metadata.json` focused on project facts and exported project metadata,
 - keep exactly one active developer session at a time
 - record every developer session in `developer_sessions`
 - from `P2` through `P6`, default to one long-lived `develop-1` lane
-- default the launch model for that long-lived lane to `sonnet`; choose `opus` only when the current lane's work is genuinely high-difficulty enough to justify a more expensive launch
+- default the launch model for that long-lived lane to `opus` with `medium` effort
+- raise that lane to `opus` with `xhigh` effort only when the work is genuinely difficult enough to justify it
+- when launching a documentation-heavy or otherwise materially simpler lane, prefer `sonnet` with `medium` effort
 - if a new `develop-N` session is created, it should happen only for controlled replacement or explicit user direction, not because `P7` found more issues
 - keep `primary_develop_session_id` pointing at the original long-lived develop session when that distinction matters
 - keep `latest_develop_session_id` pointing at the most recent recoverable `develop-N` session so `fail` audits can route back deterministically
@@ -222,7 +224,7 @@ On recovery, inspect at least:
 
 - store the active developer session id in Beads comments using `SESSION:`
 - mirror the active developer session id in `../.ai/metadata.json`
-- mirror the active developer session id in `../metadata.json` as `session_id`
+- do not write session ids or other workflow-only state into `../metadata.json`
 - for Claude-backed sessions, include backend, runtime directory, tmux session name, and transcript path in the recorded session state so recovery and export remain deterministic
 - if these records disagree, repair them before continuing
 - do not silently create a replacement developer session if the intended existing one can still be recovered
@@ -253,7 +255,7 @@ For live Claude lanes specifically:
 - parent-root `../docs/` is the owner-maintained external documentation directory
 - parent-root `../sessions/` is the cleaned raw session-export directory for non-Claude developer sessions
 - Claude-backed developer sessions are packaged once as parent-root `claude-sessions.zip` instead of per-session `../sessions/` entries
-- parent-root `../.tmp/` is the `P7` evaluation artifact directory for `audit_report-<N>.md`, `audit_report-<N>-fix_check-<M>.md`, and `test_coverage_and_readme_audit_report.md`
+- 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
 - do not treat repo-local `docs/` as the active external documentation location

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

@@ -82,6 +82,7 @@ Use this skill during `P4 Development` before prompting the developer.
 - fast local iteration is allowed during development even when the final delivered runtime and broad verification contract must be Docker-contained
 - do not let temporary local tooling or host-only setup assumptions leak into the final README, wrapper scripts, or declared delivery contract
 - local verification is for speed during development; the README-documented runtime and broad test commands are the final contract that must pass at the later gate when they are part of the README promise
+- do not add runtime/test scripts, Compose services, or Docker entrypoints that shell out to host package managers or assume host-installed toolchains for the final delivered path; move those dependencies into Dockerfiles or container build definitions before the slice is considered complete
 - do not run browser E2E, Playwright, full test suites, `./run_tests.sh`, or Docker runtime commands during ordinary development slices
 - for frontend-bearing projects, rely on targeted local tests such as unit, component, route, page, or state-focused tests instead of browser E2E during ordinary slice work
 - for `fullstack` and `web` projects, treat frontend unit tests as a real expected deliverable rather than optional polish; do not rely on package manifests or tooling presence as a substitute for real test files

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

@@ -59,8 +59,9 @@ Use this skill during `P7 Evaluation and Fix Verification` after a fresh audit r
 - that same evaluator session should receive only the exact audit-scoped issue list or the current unresolved subset
 - that same evaluator session should only confirm whether those exact earlier items are fixed; it should not perform a broader new review
 - the follow-up report should describe what is resolved, what remains open, and any important verification caveats
-- store follow-up reports as `../.tmp/audit_report-<N>-fix_check-<M>.md`
+- store the follow-up report as `../.tmp/audit_report-<N>-fix_check.md`
 - do not rewrite the report text after generation except for file moves and filename normalization
+- when the bugfix loop needs another pass, replace the existing `audit_report-<N>-fix_check.md` so it always reflects the latest whole-audit status rather than one narrow loop pass
 
 ## Scope discipline
 
@@ -75,4 +76,4 @@ Use this skill during `P7 Evaluation and Fix Verification` after a fresh audit r
 - allow at most 3 remediation attempts for the coverage/README audit; after the third attempt, keep the latest report as the final carried-forward evidence
 - do not move to `P8` until 2 bugfix sessions have been completed and the final coverage/README report exists from that last `P7` subphase
 - keep only partial-pass audit reports under `../.tmp/audit_report-<N>.md`
-- for each bugfix session, keep its starting partial-pass audit report and any fix-check reports together by shared audit number in `../.tmp/`
+- for each bugfix session, keep its starting partial-pass audit report and its single replace-in-place `audit_report-<N>-fix_check.md` report together by shared audit number in `../.tmp/`

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

@@ -43,10 +43,8 @@ The installed runtime copies under `~/slopmachine/` are the ordinary evaluation
 - number every fresh evaluation audit sequentially across the whole run for routing and metadata purposes
 - persist `../.tmp/audit_report-<N>.md` only for `partial pass` audits that actually open bugfix sessions
 - if a fresh audit is `fail` or `pass`, extract what you need from the generated working report, record the verdict and routing in metadata, and then discard the report file instead of leaving it in `../.tmp/`
-- for a `partial pass` audit that opens a bugfix session, store each scoped fix-check under that audit number:
-  - `../.tmp/audit_report-<N>-fix_check-1.md`
-  - `../.tmp/audit_report-<N>-fix_check-2.md`
-  - and so on
+- for a `partial pass` audit that opens a bugfix session, keep one replace-in-place fix-check report under that audit number:
+  - `../.tmp/audit_report-<N>-fix_check.md`
 
 ## Evaluator-session model
 
@@ -72,18 +70,14 @@ The installed runtime copies under `~/slopmachine/` are the ordinary evaluation
 
 For each fresh audit:
 
-- compose the chosen evaluation prompt yourself; do not tell the evaluator to read prompt files on its own
-- use the original project prompt from metadata
+- do not prefix, suffix, summarize, or otherwise rewrite the chosen evaluation prompt yourself
 - read the chosen evaluation prompt file contents yourself before launching evaluation
-- compose one large final prompt block
-- prefix the request with a clear instruction that the reviewer must work in the current project directory and evaluate the delivered project
-- make sure `README.md` and the code inside the current project directory are sufficient for evaluation; do not assume the evaluator will rely on parent-root docs or sibling workflow artifacts
-- inject the full original project prompt into the `{prompt}` placeholder for the chosen evaluation prompt content, but otherwise do not rewrite or replace the template body
-- send that fully composed text block directly to one fresh `General` evaluator session
-- require that session to produce a detailed file-backed audit report plus an issue summary
+- inject only the full original project prompt into the `{prompt}` placeholder and leave the rest of the template body unchanged
+- send that resulting evaluation prompt text verbatim to one fresh `General` evaluator session with zero additions or reductions beyond the `{prompt}` substitution
+- let the prompt itself define the evaluator output contract; do not append extra response requirements outside the prompt body
 - assign the next audit number
 - if and only if the verdict is `partial pass`, keep the normalized report path as `../.tmp/audit_report-<N>.md`
-- if the verdict is `fail` or `pass`, discard the generated report file after extracting the issue summary or verdict you need
+- if the verdict is `fail` or `pass`, discard the generated report file after extracting the verdict or issue list you need from the evaluator result and/or report contents
 - record the evaluator session id, prompt kind, audit number, verdict, kept-or-discarded report status, and routing decision in metadata
 
 ## Fresh-audit branching rule
@@ -123,17 +117,16 @@ Inside a `partial pass` audit's bugfix loop:
 - after the developer claims the fixes are done, run a rough targeted owner-side verification pass on the affected behavior before asking for evaluator confirmation
 - then return to the same evaluator session and send only the exact issue list or current unresolved subset for scoped fix confirmation
 - require a file-backed fix-check report for that scoped verification pass
-- store each fix-check report as `../.tmp/audit_report-<N>-fix_check-<M>.md`
-- if unresolved issues remain, take only that unresolved subset back to the same bugfix session and repeat the same-session fix-check loop
+- store the scoped fix-check report as `../.tmp/audit_report-<N>-fix_check.md`
+- if unresolved issues remain, take only that unresolved subset back to the same bugfix session and repeat the same-session fix-check loop, replacing the same fix-check report each time so it always covers the whole audit issue list in its latest state
 - once all issues from `audit_report-<N>.md` are resolved, mark that bugfix session completed in metadata
 
 ## Post-bugfix coverage and README audit
 
 - after 2 bugfix sessions have been completed, do not leave `P7` yet; this audit is the last subphase inside `P7`
-- read `~/slopmachine/test-coverage-prompt.md` yourself before launching the audit
 - launch a fresh `General` evaluator session for this audit
 - prepare the audit workspace with `node ~/slopmachine/utils/prepare_strict_audit_workspace.mjs --workspace-root .. --name test-coverage-readme-audit` and use the returned `run_dir` as the evaluator working directory so `repo/README.md` and `../.tmp/` both resolve correctly
-- compose the request yourself and make clear that the reviewer is working in the current project directory and must write the report to `../.tmp/test_coverage_and_readme_audit_report.md`
+- send `~/slopmachine/test-coverage-prompt.md` verbatim with zero additions or reductions; 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, remove or replace the previous `../.tmp/test_coverage_and_readme_audit_report.md`; do not keep numbered variants for this report
 - if the report finds any issue, treat that as blocking `P7` completion
 - route those issues to the currently active recoverable developer session; prefer the most recently used developer session, which will usually be `bugfix-2`
@@ -155,10 +148,10 @@ Inside a `partial pass` audit's bugfix loop:
 - `P7` is complete only after 2 bugfix sessions have been completed and the post-bugfix coverage/README audit has run as the last subphase of `P7`
 - the second bugfix session must be completed by resolving its scoped issue list through the same-audit fix-check loop
 - fresh `pass` audits before that point are discarded clean audits and do not replace the 2-bugfix-session requirement
-- after the second bugfix session completes, run the coverage/README audit; if it becomes clean within 3 remediation attempts, move to `P8 Final Human Decision` with a clean report, otherwise move to `P8 Final Human Decision` with the latest final report after the third attempt
+- after the second bugfix session completes, run the coverage/README audit; if it becomes clean within 3 remediation attempts, move to `P8 Final Readiness Decision` with a clean report, otherwise move to `P8 Final Readiness Decision` with the latest final report after the third attempt
 
 ## Boundaries
 
-- this phase is owner-side evaluation orchestration, not the final human decision gate
+- this phase is owner-side evaluation orchestration, not a user approval gate
 - keep audit numbering deterministic and monotonic across the whole run
 - do not reopen the old counted-cycle report-root model