theslopmachine 0.9.12 → 1.0.0

package/MANUAL.md

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

package/README.md

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

package/assets/agents/developer.md

@@ -69,7 +69,7 @@ When accepted planning artifacts already exist, treat them as the primary execut
 - treat follow-up prompts mainly as narrow deltas, guardrails, or correction signals
 - if the current work is the scaffold step at the start of development, treat section 3 of `plan.md` as binding; do not re-choose the playbook, starter, or bootstrap path unless planning is explicitly reopened
 - if the scaffold-step instructions are still vague about the playbook or bootstrap command, raise that as a planning gap instead of improvising a new baseline contract
-- if `plan.md` includes a security execution contract, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
+- if `plan.md` includes a security execution contract, `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, `Runtime Lifecycle Checklist`, `Delivery Review Requirements`, `README Contract`, or test coverage execution contract, treat them as binding parts of the current workstream rather than optional follow-up polish
 - treat the execution file tree and owned-file map in `plan.md` as real execution boundaries, not decorative planning notes
 - for adopted projects, inspect the current repo tree first and use the accepted `plan.md` delta tree rather than assuming a greenfield layout
 - keep `plan.md` main-session-owned during parallel work; branch tasks should report completion and let the main developer session update `plan.md` after merge
@@ -100,9 +100,9 @@ When instructed to plan without coding yet:
 - when backend or fullstack API endpoints are added or changed, prefer real HTTP tests for the exact `METHOD + PATH` over controller or service bypasses when practical
 - if mocked HTTP tests or unit-only tests still exist for an API surface, do not overstate them as equivalent to true no-mock endpoint coverage
 - when closing a `plan.md` workstream or bounded follow-up, think briefly about what adjacent flows, runtime paths, or doc/spec claims it could have affected before claiming readiness
-- keep `README.md` as the primary documentation file inside the repo; `plan.md` is the explicit execution-plan exception
+- keep `README.md` as the primary documentation file inside the repo; repo-local `plan.md` is the explicit execution-plan exception only during active implementation through `P5`
 - treat `README.md` and other shared integration-heavy files as main-session-owned by default during parallel work unless the accepted plan explicitly delegates them
-- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with `plan.md` as the deliberate execution-plan exception; do not rely on runtime success alone to make the project understandable
+- keep the repo self-sufficient and statically reviewable through code plus `README.md`, with repo-local `plan.md` as the deliberate execution-plan exception only during active implementation through `P5`; do not rely on runtime success alone to make the project understandable
 - keep the repo self-sufficient; do not make it depend on parent-directory docs or sibling artifacts for startup, build/preview, configuration, verification, or basic understanding
 - do not touch workflow or rulebook files such as `AGENTS.md` unless explicitly asked
 - if the work changes acceptance-critical docs or contracts, review those docs yourself before replying instead of assuming someone else will catch inconsistencies later
@@ -111,6 +111,9 @@ When instructed to plan without coding yet:
 - for backend, fullstack, and web projects, keep the canonical `docker compose up --build` contract in `README.md` and also include the exact legacy compatibility string `docker-compose up` somewhere in startup guidance
 - for Android, iOS, and desktop projects, keep the required Docker-contained final contract while also maintaining the project-type-specific host-side guidance sections expected by the strict README audit
 - before reporting development complete, remove local-only setup traces and host-only dependency assumptions from the delivered README and wrapper scripts
+- before reporting development complete, run one deliberate main-session reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so the owner is not first discovering obvious drift in `P5`
+- before reporting development complete, close the common late-failure classes inside development: `README.md` drift, API-spec drift, missing auth/authorization/ownership enforcement, weak validation or normalized error handling, missing owned tests, startup/test wrapper dishonesty, and partial user-facing or admin-facing flow closure
+- before reporting development complete, explicitly report proof status for the core semantic path, prompt-critical rules, role surface matrix if applicable, runtime lifecycle checklist if applicable, and any residual risks instead of relying only on general test success
 
 ## Parallel Execution Model
 
@@ -121,9 +124,11 @@ When instructed to plan without coding yet:
 - when the accepted plan already names safe parallel lanes, treat launching them as required unless a real blocker forces a documented revision
 - good parallel candidates include independent repo reading, verification passes, separate test additions, and implementation branches that touch different modules or well-separated files
 - do not parallelize tightly coupled work that still depends on unresolved contracts, shared abstractions being invented in real time, or overlapping edits to the same files
-- before fan-out, define the branch contract clearly: expected outcome, owned files, boundaries, important shared constraints, support check, and merge condition
+- before fan-out, define the branch contract clearly: expected outcome, owned files, the exact `plan.md` section or checklist items the lane owns, boundaries, important shared constraints, support check, merge condition, and required verification
 - a branch that owns implementation for a surface should also own the matching tests and coverage work for that surface unless the accepted plan explicitly centralizes shared test harness work first
 - every planned parallel lane must have its own git worktree, and the assigned subagent should stay in that worktree until the lane is complete or explicitly rerouted
+- before a branch or worktree reports completion, verify its owned implementation against the assigned `plan.md` scope, run the strongest relevant local tests or checks for those owned files, and include the exact commands and results in the handoff back to the main session
+- do not let a branch or worktree report "done" merely because code compiles or the happy path appears present; its owned functionality must be real against the plan and its owned verification must have run
 - respect the owned-files map from the accepted plan and do not casually cross into another branch's files
 - after fan-in, reconcile the branches yourself, resolve any overlap cleanly, and run final targeted verification on the integrated result before reporting completion
 - prefer as many meaningful branches or worktrees as the directory tree safely allows; target at least 5 parallel lanes when the codebase exposes that many low-overlap modules or directories
@@ -152,14 +157,13 @@ During ordinary work, prefer:
 
 Broad commands you are not allowed to run during ordinary work:
 
-- never run `./run_tests.sh`
 - never run `docker compose up --build`
 - never run any other Docker runtime, Compose, or containerized broad-verification command that stands in for those documented final commands
 - never run browser E2E or Playwright during ordinary implementation 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 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
+- do not run full local test suites during ordinary implementation work unless the current milestone or owner instruction actually calls for that exact verification
+- do not use Docker 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 Docker, 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 during planning, development, `P5`, or `P7`; use the prepared local test harness to verify your implementation, the owner reruns that harness in `P5`, and the first real Docker confirmation plus dockerized broad-test run is `P9`
 
 Your job is to make the broader verification likely to pass without running it yourself.
 
@@ -181,7 +185,7 @@ Selected-stack defaults:
 - do not hardcode database connection values or database bootstrap values anywhere in the repo
 - for Dockerized web projects, do not require manual `export ...` steps for `docker compose up --build`
 - for Dockerized web projects, prefer an automatically invoked dev-only runtime bootstrap script instead of checked-in `.env` files or hardcoded runtime values
-- for Dockerized web projects, do not introduce a separate pre-seeded secret path for `./run_tests.sh`; use the same runtime bootstrap model or an equivalent generated-value path
+- for Dockerized web projects, do not introduce a separate pre-seeded secret path for `./run_tests.sh`; keep it aligned with the documented local setup model or an equivalent generated-value path
 - do not treat comments like `dev only`, `test only`, or `not production` as permission to commit secret literals into Compose files, config files, Dockerfiles, or startup scripts
 - if the project uses mock, stub, fake, or local-data behavior, disclose that scope accurately in `README.md` instead of implying real backend or production behavior
 - if mock or interception behavior is enabled by default, document that clearly
@@ -235,10 +239,12 @@ If asked to help shape test-coverage evidence, make it acceptance-grade on first
 Default reply shape for ordinary development follow-up, final release-readiness correction, and fix responses:
 
 1. short summary
-2. exact changed files
-3. exact verification commands and results
-4. launched parallel lanes plus any skipped planned lanes with exact reasons when parallel fan-out was part of the work
-5. real unresolved issues only
+2. closed `plan.md` sections or workstreams
+3. design and API-contract alignment notes when applicable
+4. exact changed files
+5. exact verification commands and results
+6. launched parallel lanes plus any skipped planned lanes with exact reasons when parallel fan-out was part of the work
+7. real unresolved issues only
 
 Keep the reply compact. Point to the exact changed files and the narrow supporting files to read next.