theslopmachine 0.4.0 → 0.4.2

package/assets/skills/verification-gates/SKILL.md

@@ -1,134 +1,122 @@
 ---
 name: verification-gates
-description: Owner-side review, verify-fix loop, heavy-gate interpretation, and runtime acceptance rules for repo-cwd blueprint-driven projects.
+description: Owner-side review, acceptance, rejection, and gate-interpretation rules for slopmachine.
 ---
 
 # Verification Gates
 
-Use this skill after development begins whenever you are reviewing developer work, deciding acceptance, interpreting phase exits, or enforcing hard verification boundaries.
+Use this skill after development begins whenever you are reviewing work, deciding acceptance, or interpreting phase exits.
 
 ## Usage rules
 
-- Load this skill before review, acceptance, rejection, runtime gate interpretation, hardening readiness decisions, or heavy-gate decisions.
-- Treat it as owner-side review and gate guidance, not developer-visible text.
-- Use `get-overlays` as the source of truth for developer-facing execution guidance.
-- Use this skill as the source of truth for owner-side verification, review pressure, and gate interpretation.
-- outside the final evaluation decision, do not pause execution for human approval while using this skill; continue reviewing, rejecting, fixing, and rerunning until the work qualifies
+- load this skill before review, acceptance, rejection, runtime gate interpretation, hardening readiness decisions, or broad-gate decisions
+- treat it as owner-side review and gate guidance, not developer-visible text
+- use this skill as the source of truth for owner-side verification, review pressure, and gate interpretation
+- outside the final human decision, do not pause execution for human approval while using this skill; continue reviewing, rejecting, fixing, and rerunning until the work qualifies
 
-## Documentation And Repo Hygiene
+## Documentation and repo hygiene
 
 - maintain the owner-managed external docs in parent-root `../docs/` from accepted clarification, accepted planning, accepted major implementation changes, and hardening verification
 - keep `README.md` codebase-specific, junior-friendly, and separate from the external docs set
 - do not allow `.env` files or env-file variants anywhere in the repo tree
 - do not allow a project that requires a preexisting `.env` file in the repo or package to start from scratch
-- if env-file format is needed at runtime, it must be generated ephemerally from Docker-provided runtime variables rather than stored in the repo or package
+- if env-file format is needed at runtime, it must be generated ephemerally from the selected runtime environment rather than stored in the repo or package
+- require the README to show the correct primary runtime command and `./run_tests.sh` as the primary broad test command
+- for Dockerized web backend/fullstack projects, that runtime command may be `docker compose up --build` directly
+- when `docker compose up --build` is not the runtime contract, require `./run_app.sh` to be the documented primary runtime wrapper
+- require `./run_tests.sh` to be self-sufficient enough to run from a clean environment, including any required install/setup steps when applicable
+- for Dockerized web backend/fullstack projects, require `./run_tests.sh` to be the Dockerized broad test path used for final broad verification rather than a local-only test wrapper
+- for non-web or non-Docker projects, require `./run_tests.sh` to be the platform-equivalent broad test path used for final broad verification
 
 ## Review standard
 
-- do not accept weak tests
+- do not accept fake tests, weak evidence, documentation drift, missing real surfaces, or unresolved release-facing failures
+- do not accept mocked APIs as integration evidence
+- do not accept placeholder or demo UI in product-facing flows
+- do not accept `.env` files or similar env-file artifacts
 - do not accept shallow Docker verification
-- do not accept documentation drift
 - do not accept happy-path-only implementation when failure paths matter
 - do not accept unsupported claims
 - do not accept work that looks complete but is not resilient
 - do not accept committed secrets, hardcoded sensitive values, or sloppy env handling
 - do not accept frontend/backend drift in fullstack work
 - do not accept missing end-to-end coverage for major fullstack flows
-- do not accept UI claims without screenshot-backed Playwright evidence when the change affects real frontend behavior
-- do not accept frontend placeholder, demo, setup, or debug messaging in product-facing UI
+- do not accept UI claims without screenshot-backed or platform-equivalent visual evidence when the change affects real UI behavior
 - do not accept prototype residue such as seeded credentials, weak demo defaults, login hints, or unsanitized user-facing error behavior
 - do not accept multi-tenant or cross-user security claims without negative isolation evidence when that boundary matters
 - do not accept file-bearing flows without path confinement and traversal-style validation when that boundary matters
-- do not accept partial `foundation` work for complex features when the prompt implies broader usable scope, infrastructure depth, or security depth than what was actually delivered
-- do not accept known user-facing, release-facing, production-path, or build failures as compatible with completion unless explicitly scoped out
+- do not accept partial foundation work for complex features when the prompt implies broader usable scope, infrastructure depth, or security depth than what was actually delivered
 - do not accept frontend-bearing slice completion without checking production build health when the change materially affects frontend code or tooling
 - do not accept module completion that ignores integration seams or cross-cutting consistency with the existing system
 - do not accept end-to-end evidence that bypasses a required user-facing or admin-facing surface with direct API shortcuts
-- do not accept mocked APIs as integration evidence; integration verification must use real HTTP requests against the actual running service surface
+
+## Cadence rule
+
+- use targeted local verification as the default during scaffold corrections, development, hardening, and remediation
+- reserve the selected stack's broad verification path for the limited owner-run gate moments in the workflow budget
+- do not turn ordinary acceptance into repeated integrated-style gate runs
+- for Dockerized web backend/fullstack projects, the owner must run `docker compose up --build` and `./run_tests.sh` once after scaffold completion to confirm the scaffold baseline
+- after that scaffold confirmation, the next Docker-based run should be at development completion or integrated-verification entry unless a real blocker forces earlier escalation
 
 ## Verify-fix loop
 
-- inspect the result and the evidence, not just the developer's confidence
+- inspect the result and evidence, not just the developer claim
 - review technical quality, prompt alignment, architecture impact, and verification depth of the current work
-- during normal implementation iteration, always prefer fast local language-native or framework-native verification for the changed area instead of `docker compose up --build` or `run_tests.sh`
+- during normal implementation iteration, always prefer fast local language-native or framework-native verification for the changed area instead of the selected stack's broad gate path
 - require the developer to set up and use the project-appropriate local test environment in the current working directory when normal local verification is needed
-- require local runtime proof when relevant by starting the server locally and exercising the changed behavior directly rather than jumping to Docker-based proof
-- if the local toolchain is missing, require the developer to install or enable it first; do not jump to `run_tests.sh` during ordinary iteration just because local setup is inconvenient
+- require local runtime proof when relevant by starting the app or service through the selected stack's local run path and exercising the changed behavior directly rather than jumping to the broad gate path
+- if the local toolchain is missing, require the developer to install or enable it first; do not jump to the broad gate path during ordinary iteration just because local setup is inconvenient
 - do not accept hand-wavy claims that local verification is unavailable without a real setup attempt and clear explanation
-- for applicable fullstack or UI-bearing work, require local Playwright on affected flows plus screenshot review and explicit UI validation
+- for applicable UI-bearing work, require the selected stack's local UI/E2E tool on affected flows plus screenshot review or equivalent platform artifacts and explicit UI validation
 - if verification is weak, missing, or failing, require fixes and reruns before acceptance
 - if documentation or repo hygiene drifts, secrets leak, contracts drift, or frontend integrity is compromised, require cleanup before acceptance
 - keep looping until the current work is genuinely acceptable
 
-## Heavy-gate definition
-
-- a heavy gate is an owner-run integrated verification boundary, not every ordinary phase change
-- a phase change alone does not automatically require a heavy gate unless that phase's exit criteria explicitly call for one
-- a heavy gate normally means some combination of full clean runtime proof, full `run_tests.sh`, and Playwright plus screenshot evidence when UI or fullstack flows exist
-- heavy gates are required only at these milestone boundaries:
-  - scaffold acceptance
-  - when development/coding is complete and the project enters integrated verification
-  - when integrated verification is complete and the project is ready to leave that phase
-  - when hardening is complete and the project is ready for final evaluation
-  - once more on the final qualified state before submission packaging
-- planning acceptance, ordinary module acceptance, and routine in-phase verification are not heavy gates by default and should rely on targeted local verification unless the risk profile says otherwise
-
-## Testing cadence interpretation
-
-- the first required `run_tests.sh` pass happens in scaffold once the clean foundation exists
-- after scaffold, do not force `docker compose up --build` or `run_tests.sh` on normal development steps
-- prefer local targeted or native test commands during module implementation and ordinary verify-fix iteration
-- prefer local runtime startup and direct local behavior checks instead of Docker whenever runtime proof is needed during ordinary work
-- local verification should run inside the current working directory using the project's own environment and tooling rather than hidden global assumptions
-- during applicable fullstack or UI-bearing implementation work, require local Playwright on affected flows and review screenshots
-- during integrated verification, do not rerun `docker compose up --build` or `run_tests.sh` on every small fix inside the phase; use local verification until the next milestone boundary is reached
-- reserve `docker compose up --build` and `run_tests.sh` for these owner-run milestone checks only:
-  - scaffold acceptance
-  - development/coding complete -> integrated verification entry
-  - integrated verification complete -> hardening entry
-  - hardening complete -> final evaluation readiness
-  - final qualified state -> submission packaging readiness
-- the workflow owner handles those expensive critical-gate runs; do not require the developer to duplicate them during normal phase progression
-- each integrated-verification milestone run must also include Playwright for major flows and screenshot review when UI or fullstack flows exist
-- after post-evaluation remediation, prefer local reruns, affected local runtime checks, and affected Playwright checks
-- after remediation, return the project to the appropriate milestone boundary and run the next owner-run gate there rather than turning every remediation fix into an immediate Docker and `run_tests.sh` rerun
+## Broad-gate definition
+
+- a broad gate is an owner-run integrated verification boundary, not every ordinary phase change
+- a phase change alone does not automatically require a broad gate unless that phase exit explicitly calls for one
+- a broad gate normally means some combination of full clean runtime proof, `./run_tests.sh`, and platform-appropriate UI/E2E evidence when UI-bearing flows exist
+- in v2, the workflow target is at most 3 broad owner-run verification moments across the whole cycle
+- ordinary planning, ordinary slice acceptance, and routine in-phase verification are not broad gates by default and should rely on targeted local verification unless the risk profile says otherwise
+
+For Dockerized web backend/fullstack projects, the default Docker cadence is:
+
+1. one owner-run `docker compose up --build` plus one owner-run `./run_tests.sh` after scaffold completion
+2. no more Docker-based runs during ordinary development work
+3. the next Docker-based run at development completion or integrated-verification entry
+
+Any earlier extra Docker run needs a concrete blocker-based justification.
 
 ## Runtime gate interpretation
 
-Use evidence such as internal metadata files, structured tracker comments, verification command results, and file/project-state checks.
+Use evidence such as internal metadata files, structured Beads comments, verification command results, and file/project-state checks.
 
 - clarification requires the `clarification-gate` conditions plus explicit approval record
-- development bootstrap requires the `developer-session-lifecycle` conditions plus a fresh planning-oriented start and the required documentation and repo hygiene state when relevant
-- scaffold requires evidence for `docker compose up --build`, `run_tests.sh`, baseline logging/config, and when relevant the chosen frontend stack and UI approach being set intentionally
-- scaffold also requires safe env/config handling, no persisted local secrets, real migration/runtime foundations, and a usable local test environment in the current working directory when practical
+- planning requires the `developer-session-lifecycle` and planning-gate conditions plus a fresh planning-oriented start and the required documentation and repo hygiene state when relevant
+- scaffold requires evidence for the bounded scaffold gate, baseline logging/config, and when relevant the chosen frontend stack and UI approach being set intentionally
+- scaffold also requires safe env/config handling, no persisted local secrets, real migration/runtime foundations, a usable local test environment in the current working directory, and the correct primary runtime command plus `./run_tests.sh` documented and working when practical
+- scaffold also requires `./run_tests.sh` to handle its own required setup from a clean environment when applicable
+- local tests should still exist for ordinary development work even when the primary broad test command is Dockerized
 - when scaffold includes prompt-critical security controls, acceptance requires real runtime or endpoint verification of the protection rather than helper-only or shape-only proof
 - for security-bearing scaffolds, require applicable rejection evidence such as stale replay rejection, nonce reuse rejection, CSRF rejection on protected mutations, lockout triggering when lockout is in scope, or equivalent proof that the control is truly enforced
-- Dockerized scaffold acceptance also requires self-contained Compose namespacing, no unnecessary fragile `container_name` usage, and clean startup plus teardown behavior in the intended shared-environment model
-- module implementation requires module planning notes, module definition of done, relevant local verification for the changed area, and for applicable fullstack or UI work local Playwright evidence with screenshots, plus docs sync and review acceptance
-- module implementation also requires integration-seam verification against adjacent modules and cross-cutting concerns where relevant, and known release-facing or build failures block acceptance unless explicitly scoped out
-- module implementation acceptance should also challenge tenant isolation, path confinement, sanitized error behavior, and prototype residue when those concerns are in scope
-- integrated verification entry requires owner-run `docker compose up --build`, owner-run `run_tests.sh`, end-to-end, Playwright, prompt-alignment, README/runtime, and cross-module evidence once development/coding is complete
-- integrated verification completion requires one more owner-run `docker compose up --build`, one more owner-run `run_tests.sh`, and the corresponding end-to-end and screenshot evidence before the phase can close
-- fullstack integrated verification must include Playwright coverage for every major flow, plus screenshots used to evaluate frontend behavior and UI quality along the flow using `frontend-design`
+- scaffold acceptance also requires clean startup and teardown behavior in the selected runtime model; for Dockerized web projects this includes self-contained Compose namespacing and no unnecessary fragile `container_name` usage
+- for Dockerized web backend/fullstack projects, scaffold acceptance is not complete until the owner has actually run `docker compose up --build` and `./run_tests.sh` once successfully after scaffold completion
+- module implementation requires platform-appropriate local verification and selected-stack UI/E2E evidence when UI-bearing flows are material
+- module implementation acceptance should challenge tenant isolation, path confinement, sanitized error behavior, prototype residue, integration seams, and cross-cutting consistency when those concerns are in scope
+- integrated verification entry requires one of the limited owner-run broad gate moments once development is complete
+- integrated verification completion requires explicit full-system evidence before the phase can close
+- web fullstack integrated verification must include Playwright coverage for every major flow, plus screenshots used to evaluate frontend behavior and UI quality along the flow using `frontend-design`
+- mobile and desktop integrated verification must include the selected stack's platform-appropriate UI/E2E coverage for every major user flow when UI-bearing flows are material
 - if a required flow cannot be exercised through the intended UI surface, treat that as incomplete implementation rather than acceptable E2E coverage
 - hardening requires security, maintainability, exploratory, and release-freeze evidence
-- hardening completion requires one owner-run `docker compose up --build` and one owner-run `run_tests.sh` on the hardened state before final evaluation begins
 - hardening must explicitly re-check secret handling, redaction, and frontend/backend observability hygiene
 - hardening must explicitly satisfy the documentation and repo hygiene policy in this file before final evaluation can begin
 - final evaluation readiness requires automated evaluation to be complete and triaged, with a clear go-to-packaging vs return-to-fixes decision
-- submission packaging readiness requires one final owner-run `docker compose up --build` and one final owner-run `run_tests.sh` on the final qualified state immediately before packaging
-- remediation requires accepted issue records plus rerun local verification and affected Playwright where applicable; if remediation materially reopens the integrated verification boundary, route it back through integrated verification before re-evaluation
-
-## Hardening and pre-evaluation discipline
-
-When all planned modules are complete:
-
-- run the owner-run milestone gate for development/coding completion and enter integrated verification
-- run hardening and exploratory testing
-- for fullstack applications, rerun Playwright coverage for major flows and inspect screenshots for frontend regressions or weak UX
-- run the documentation and repo-hygiene verification required by this file before final evaluation
-- close integrated verification only after its completion milestone gate has passed
-- close hardening only after its completion milestone gate has passed
-- enforce release-candidate freeze
-- allow only fixes, verification improvements, doc corrections, and packaging work
-- prepare the package and evidence cleanly before the final evaluation decision gate
+- remediation requires accepted issue records plus rerun local verification and affected platform-appropriate UI/E2E proof where applicable; if remediation materially reopens the integrated verification boundary, route it back through integrated verification before re-evaluation
+
+## Acceptance rule
+
+- inspect the result and evidence, not just the developer claim
+- prefer one strong rejection with a concrete correction request over many small nudges
+- keep looping until the current work is genuinely acceptable

package/assets/slopmachine/templates/AGENTS.md

@@ -1,117 +1,93 @@
-# Developer Rulebook
+# Developer Rulebook v2
 
-This file is the developer-facing operating rulebook for project execution.
+This file is the repo-local engineering rulebook for `slopmachine` projects.
 
 ## Scope
 
 - Treat the current working directory as the project.
-- Ignore files outside the current working directory unless the user explicitly asks you to use them.
-- Do not use unrelated parent-directory files as hidden requirements.
+- Ignore parent-directory workflow files unless the user explicitly asks you to use them.
+- Do not treat workflow research, session exports, or sibling directories as hidden implementation instructions.
 
 ## Working Style
 
-- Operate like a senior software engineer with strong judgment and attention to detail.
-- Plan before coding when the work is non-trivial.
-- Build in meaningful vertical slices instead of scattering half-finished work across the codebase.
-- Prefer reading the actual code and project state over inventing assumptions.
-- Surface weak spots, risks, and missing information honestly.
-- Do not call work complete when it is still shaky.
-- Reuse and extend established cross-cutting patterns for errors, audit/logging, permissions, auth/session behavior, and state transitions where relevant instead of reinventing them per module.
-- For complex security, offline, authorization, storage, or data-governance features, define what done means across all promised dimensions before implementing.
-- When a requirement implies enforcement, persistence, statefulness, or rejection behavior, assume that behavior needs to be real unless it is explicitly scoped down.
-- Before reporting foundational work complete, challenge whether the behavior is real at runtime or only present in visible shape through constants, headers, helper wiring, or partial middleware.
-- Treat module completion as system-compatible completion, not isolated happy-path completion.
-- If you discover a meaningful failing user-facing, release-facing, production-path, or build check, do not treat the slice as complete unless that check was explicitly scoped out.
-- If a required user-facing or admin-facing flow cannot be exercised through its real surface, treat that as missing implementation rather than something to bypass with API shortcuts or test-only workarounds.
-
-## Runtime And Verification Rules
-
-- Treat Docker as the main runtime contract.
-- `docker compose up --build` must work when the project expects Dockerized execution, but it is not the default per-turn verification command during normal iteration.
-- `run_tests.sh` is a required project test entrypoint and must exist and work.
-- After scaffold is established, do not rerun full `docker compose up --build` and `run_tests.sh` on every small implementation step.
-- During normal iteration, prefer the fastest meaningful local verification inside the current working directory using the project-appropriate test environment and tooling.
-- When runtime proof is needed during ordinary work, prefer starting and exercising the app locally instead of using Docker gate commands.
-- If the local test toolchain is missing, try to install or enable it; do not jump to `run_tests.sh` on ordinary turns just because local setup takes work.
-- The workflow owner runs `run_tests.sh` only at milestone boundaries: after scaffold, after development/coding is complete, after integrated verification is complete, after hardening is complete, and once more before final submission.
-- Do not rerun `docker compose up --build` or `run_tests.sh` on every small fix inside integrated verification; use local verification until the next milestone boundary is reached.
-- After post-evaluation remediation, strengthen local verification and affected Playwright checks rather than rerunning full gate commands yourself unless explicitly required.
-- Do not let unverified work accumulate.
+- Operate like a strong senior engineer.
+- Read the code before making assumptions.
+- Work in meaningful vertical slices.
+- Do not call work complete while it is still shaky.
+- Reuse and extend shared cross-cutting patterns instead of inventing incompatible local ones.
+
+## Verification Rules
+
+- During ordinary iteration, prefer the fastest meaningful local verification for the changed area.
+- Prefer targeted unit, integration, module, route-family, or platform-appropriate local UI/E2E checks over broad reruns.
+- Do not rerun full Dockerized startup and the full test suite on every small change.
+- The broad owner-run project-standard verification path should be used sparingly, with a target budget of at most 3 times across the whole workflow cycle.
+- If you run a Docker-based verification command sequence, end it with `docker compose down` unless containers must remain up.
+
+Every project must expose:
+
+- one primary documented runtime command
+- one primary documented broad test command: `./run_tests.sh`
+- follow the original prompt and existing repository first for the runtime stack; `./run_tests.sh` should exist regardless of project type
+- the primary full-test command should install or prepare what it needs first when that setup is required for a clean environment
+
+For web backend/fullstack projects, those are usually:
+
+- `docker compose up --build`
+- `./run_tests.sh`
+
+For Dockerized web backend/fullstack projects:
+
+- `./run_tests.sh` must run the broad full-test path through Docker
+- local non-Docker tests should still exist for normal development work
+- final broad verification should use the Dockerized `./run_tests.sh` path, not only local test commands
+
+When `docker compose up --build` is not the runtime contract, provide `./run_app.sh` as the single primary runtime wrapper.
+
+For mobile, desktop, CLI, library, or other non-web projects, `./run_app.sh` should own the selected stack's runtime flow, while `./run_tests.sh` remains the single broad test wrapper calling the platform-equivalent full test path.
 
 ## Testing Rules
 
-- Tests must be real, meaningful, and tied to actual behavior.
-- Cover happy paths, failure paths, and realistic edge cases.
-- For API-bearing projects, prefer real endpoint invocation where practical.
-- Do not mock APIs for integration testing; integration evidence must use real HTTP requests against the actual running service surface.
-- For backend integration tests, prefer production-equivalent infrastructure when practical instead of a weaker substitute that can hide real defects.
-- For applicable frontend or fullstack work, run local Playwright against affected end-to-end flows during implementation and inspect screenshots to verify the UI actually matches.
-- Do not pad the test suite with superficial or fake tests.
-- If verification is weak, say so plainly and fix it.
+- Tests must be real and tied to actual behavior.
+- Do not mock APIs for integration testing.
+- Use real HTTP requests against the actual running service surface for integration evidence.
+- For UI-bearing work, use the selected stack's local UI/E2E tool on affected flows and inspect screenshots or equivalent artifacts when practical.
 
-## Frontend Product Integrity
+Selected-stack defaults:
 
-- Unless the prompt, existing repository, or established stack clearly dictates otherwise, default frontend work to Tailwind CSS for styling and `shadcn/ui` for component primitives.
-- If the existing project already uses a different UI system, preserve and extend that system instead of forcing Tailwind CSS or `shadcn/ui` into it.
-- Do not place development, setup, scaffold, seed, or debug information in the product UI.
-- Do not add demo banners, `database is working` messages, scaffold-password hints, setup reminders, or similar developer-facing content to frontend screens.
-- If a screen exists, it should serve the real user or operator purpose it was created for.
-- Keep setup and debug instructions in docs or operator tooling, not in the frontend interface.
+- follow the original prompt and existing repository first; use the defaults below only when they do not already specify the platform or stack
+- web frontend/fullstack: Playwright for browser E2E/UI verification when applicable
+- mobile: Expo + React Native + TypeScript by default, with Jest plus React Native Testing Library for local tests and a platform-appropriate mobile UI/E2E tool when the flow needs it
+- desktop: Electron + Vite + TypeScript by default, with a project-standard local test runner plus Playwright's Electron support or another platform-appropriate desktop UI/E2E tool when the flow needs it
 
 ## Documentation Rules
 
-- Keep docs aligned with the current implementation.
-- Do not add or keep tests that only assert that docs directories or docs files exist.
-- Documentation structure outside the repo is not application behavior and should not be tested as application logic.
-- Keep `README.md` and any codebase-local docs accurate when behavior, runtime steps, or verification expectations change.
-- The README must explain what the project is, what it does, how to run it, and how to test it in a way that is friendly to a junior developer.
-- The README must stand on its own for basic codebase use and must not depend on separate external documentation for run/test basics.
-- Do not leave misleading docs in place after changing behavior.
-
-## Engineering Quality Rules
-
-- Keep architecture intentional and boundaries clean.
-- Avoid giant mixed-responsibility files and tangled logic.
-- Treat validation, security boundaries, secret handling, and logging hygiene as baseline concerns.
-- Fix obvious quality problems early instead of stacking them for later.
-
-## Secret Handling Rules
-
-- Do not create, keep, or rely on `.env` files anywhere in the codebase.
-- Treat `.env`, `.env.local`, `.env.example`, and similar env-file variants as forbidden artifacts.
-- Do not persist local secrets anywhere in the repository.
-- Do not hardcode credentials, API keys, tokens, signing material, database passwords, certificate private keys, or similar sensitive values in code.
-- Do not use env files even for placeholders or setup examples.
-- The delivered repo and package must not require any preexisting `.env` file to start from scratch.
-- If environment variables are needed, rely on Docker-provided runtime variables or generate any required env-file format ephemerally at runtime from those variables.
-- If runtime generation is used, the generated env file must not be committed, packaged, or treated as a persistent project artifact.
-- Do not leak raw secrets into logs, docs, screenshots, telemetry, or operator-facing UI.
-- Treat frontend and backend observability paths as secret-sensitive by default and redact accordingly.
-
-## Prototype Cleanup Rules
-
-- Remove seeded credentials, weak demo defaults, login hints, test-account residue, and other prototype-only artifacts before reporting work complete.
-- Do not leave login forms prefilled with credentials or keep obvious demo usernames/passwords in UI, config, or docs.
-- Keep error surfaces sanitized for users and operators; do not leak internal paths, stack traces, database details, or hidden account-state details unless explicitly required.
-
-## Communication Rules
-
-- Be direct, honest, and technically clear.
-- When reporting progress, explain what changed, what you verified, and what still looks weak or unfinished.
-
-## Skills
-
-- Before implementing against a library, framework, API, or tool, lean toward checking Context7 documentation first.
-- If you need targeted outside research on a specific issue, behavior, example, or current fact, use Exa web search next.
-- Then use the most relevant skill for the matter you are actively working on, or `find-skills` if the right skill is unclear.
-- Use Context7, Exa, and skills to improve implementation quality, not as a substitute for engineering judgment.
-
-## Avoid
-
-- coding before thinking
-- fake confidence
-- fake tests
-- shallow verification
-- hidden setup
-- documentation drift
-- using files outside the current working directory as hidden requirements
+- Keep `README.md` and any codebase-local docs accurate.
+- The README must explain what the project is, what it does, how to run it, and how to test it.
+- The README must clearly document whether the primary runtime command is `docker compose up --build` or `./run_app.sh`.
+- The README must clearly document `./run_tests.sh` as the broad test command.
+- The README must stand on its own for basic codebase use.
+
+## Secret And Runtime Rules
+
+- Do not create or keep `.env` files anywhere in the repo.
+- Do not rely on `.env`, `.env.local`, `.env.example`, or similar files for project startup.
+- Do not hardcode secrets.
+- If runtime env-file format is required, generate it ephemerally and do not commit or package it.
+
+Selected-stack secret/config defaults:
+
+- follow the original prompt and existing repository first; use the defaults below only when they do not already specify the platform or stack
+- web Dockerized services: use Docker/runtime-provided variables, never committed env files
+- mobile apps: do not bundle real secrets into the client; use app config only for non-secret public configuration and keep real secrets server-side or in platform-appropriate secure storage when user/device secrets must be stored at runtime
+- desktop apps: keep sensitive values in main-process/runtime configuration or platform-appropriate secure storage, and do not expose them to the renderer by default
+
+## Product Integrity Rules
+
+- Do not leave placeholder, setup, debug, or demo content in product-facing UI.
+- If a real user-facing or admin-facing surface is required, build that surface instead of bypassing it with API shortcuts.
+- Treat missing real surfaces as incomplete implementation.
+
+## Rulebook Files
+
+- Do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked.

package/assets/slopmachine/{workflow-init-v2.js → workflow-init.js}

@@ -9,11 +9,11 @@ const target = path.resolve(process.cwd(), targetInput)
 const beadsCommand = process.env.BR_COMMAND || 'br'
 
 function log(message) {
-  console.log(`[workflow-init-v2] ${message}`)
+  console.log(`[workflow-init] ${message}`)
 }
 
 function die(message) {
-  console.error(`[workflow-init-v2] ERROR: ${message}`)
+  console.error(`[workflow-init] ERROR: ${message}`)
   process.exit(1)
 }
 

package/package.json

@@ -1,25 +1,25 @@
 {
-    "name": "theslopmachine",
-    "version": "0.4.0",
-    "description": "SlopMachine installer and project bootstrap CLI",
-    "license": "MIT",
-    "type": "module",
-    "bin": {
-        "slopmachine": "bin/slopmachine.js"
-    },
-    "scripts": {
-        "start": "node ./bin/slopmachine.js",
-        "check": "node ./bin/slopmachine.js --help"
-    },
-    "engines": {
-        "node": ">=18"
-    },
-    "files": [
-        "bin",
-        "src",
-        "assets",
-        "README.md",
-        "RELEASE.md",
-        "MANUAL.md"
-    ]
+  "name": "theslopmachine",
+  "version": "0.4.2",
+  "description": "SlopMachine installer and project bootstrap CLI",
+  "license": "MIT",
+  "type": "module",
+  "bin": {
+    "slopmachine": "bin/slopmachine.js"
+  },
+  "scripts": {
+    "start": "node ./bin/slopmachine.js",
+    "check": "node ./bin/slopmachine.js --help"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "files": [
+    "bin",
+    "src",
+    "assets",
+    "README.md",
+    "RELEASE.md",
+    "MANUAL.md"
+  ]
 }

package/src/constants.js

@@ -25,30 +25,23 @@ export function buildPaths() {
 
 export const REQUIRED_SKILL_DIRS = [
   'clarification-gate',
-  'clarification-gate-v2',
   'developer-session-lifecycle',
-  'developer-session-lifecycle-v2',
-  'session-rollover-v2',
+  'session-rollover',
   'final-evaluation-orchestration',
-  'final-evaluation-orchestration-v2',
   'beads-operations',
-  'beads-operations-v2',
-  'get-overlays',
-  'planning-guidance-v2',
+  'planning-guidance',
   'planning-gate',
-  'planning-gate-v2',
-  'scaffold-guidance-v2',
-  'development-guidance-v2',
+  'scaffold-guidance',
+  'development-guidance',
   'verification-gates',
-  'verification-gates-v2',
-  'integrated-verification-v2',
-  'hardening-gate-v2',
-  'evaluation-triage-v2',
-  'remediation-guidance-v2',
+  'integrated-verification',
+  'hardening-gate',
+  'evaluation-triage',
+  'remediation-guidance',
   'submission-packaging',
-  'submission-packaging-v2',
-  'owner-evidence-discipline-v2',
-  'report-output-discipline-v2',
+  'retrospective-analysis',
+  'owner-evidence-discipline',
+  'report-output-discipline',
   'frontend-design',
 ]
 
@@ -59,10 +52,8 @@ export const REQUIRED_SLOPMACHINE_FILES = [
   'quality-document.md',
   'engineering-results.md',
   'implementation-comparison.md',
-  'tracker-init.js',
-  'workflow-init-v2.js',
+  'workflow-init.js',
   'templates/AGENTS.md',
-  'templates/AGENTS-v2.md',
   'utils/strip_session_parent.py',
   'utils/convert_ai_session.py',
 ]