theslopmachine 0.7.2 → 0.7.3

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.3.tgz
 ```
 
 For local development instead:

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

@@ -192,7 +192,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

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/hardening-gate/SKILL.md

@@ -60,6 +60,7 @@ Hardening should treat these as the main review buckets before final evaluation
 - enforce env-file discipline during hardening
 - run documentation verification against the real codebase and runtime behavior, not just document existence
 - if `README.md` declares containerized runtime or broad test commands, verify that the final delivered output really supports those exact commands and that the docs do not overpromise beyond what the repo actually does
+- verify that every dependency needed by the README-documented `docker compose up --build` and `./run_tests.sh` paths is declared in Dockerfiles or other repo-controlled container build definitions rather than relying on host-installed packages or runtimes
 - audit README compliance against the strict post-bugfix README review shape:
   - project type near the top
   - startup instructions

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

@@ -163,6 +163,7 @@ Selected-stack defaults:
 - `./run_tests.sh` must exist for every project as the platform-independent broad test wrapper
 - `./run_tests.sh` must be able to run on a clean Linux VM that only has Docker and curl available by default
 - do not require host package managers, host language runtimes, or host test tooling for the broad test path unless the stack absolutely forces it and the exception is explicitly justified
+- define all runtime and broad-test dependencies in Dockerfiles, image build stages, or other repo-controlled container build definitions; do not rely on hidden host packages even when the developer machine happens to have them
 - `./run_tests.sh` must prepare or install anything required inside its own controlled execution path when that setup is needed for a clean environment
 - for web projects, `./run_tests.sh` must run the full test path through Docker rather than a purely local test invocation
 - when host-level setup would otherwise be required, prefer a Dockerized `./run_tests.sh` path even outside traditional web stacks so the broad verification remains portable

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

@@ -90,6 +90,7 @@ At scaffold time, do not require:
 - create `./run_tests.sh` during scaffold for every project
 - create `./run_app.sh` during scaffold for non-web platforms when it helps expose the host-side or platform-specific local flow, but keep `docker compose up --build` and containerized `./run_tests.sh` as required baseline commands
 - if the project has database dependencies, create `./init_db.sh` during scaffold as the only project-standard database initialization path
+- define the runtime and broad-test dependency set in Dockerfiles or other repo-controlled container build definitions during scaffold; do not assume host package managers, host SDKs, or host language runtimes beyond Docker and documented baseline prerequisites
 - make the scaffold handoff compact and checklist-driven rather than a long narrative dump
 
 ## Minimal real test floor

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

@@ -48,6 +48,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - for Android, mobile, desktop, and iOS-targeted projects, allow `./run_app.sh` as an additional platform helper but not as a replacement for the required Docker command
 - require `./run_tests.sh` to be self-sufficient enough to run from a clean Linux VM that only has Docker and curl available by default
 - do not accept a broad test path that depends on host package managers or preinstalled host language runtimes when Docker can provide the execution environment instead
+- do not accept Docker runtime/test paths that rely on undeclared host packages, SDKs, compilers, CLIs, or language runtimes; all such dependencies must be defined in Dockerfiles or other repo-controlled container build definitions
 - for web projects, require `./run_tests.sh` to be the Dockerized broad test path used only for the limited broad verification moments rather than as the ordinary development verification path
 - when host-level setup would otherwise be required, prefer a Dockerized `./run_tests.sh` path even outside traditional web stacks so the broad verification remains portable
 - for non-web projects, require `./run_tests.sh` to remain containerized and usable as the platform-equivalent broad test path used for final broad verification

package/assets/slopmachine/scaffold-playbooks/docker-shared-contract.md

@@ -49,6 +49,7 @@ That proof differs by family, but it must always be **meaningful**:
 At minimum, `docker compose up --build` must prove all of the following:
 
 - images build from source in the repo
+- all system packages, language runtimes, CLIs, compilers, and SDKs required by the runtime path are declared in Dockerfiles or image build stages rather than assumed from the host
 - declared runtime or support services start without hidden host setup
 - readiness can be observed through healthchecks, predictable logs, or explicit successful artifact production
 - the stack reaches a meaningful healthy state without manual container surgery
@@ -71,6 +72,9 @@ It must prove that the scaffold can be verified from a clean-enough developer or
 - run smoke checks against the actual baseline contract
 - clean up one-off test containers and temporary runtime state
 
+`docker compose up --build` and `./run_tests.sh` must never depend on host-installed language runtimes, package managers, CLIs, compilers, SDKs, or other local system packages beyond Docker and the documented baseline host prerequisites.
+If a dependency is needed for runtime or broad verification, define it in Dockerfiles, image build stages, or other repo-controlled container build definitions.
+
 `./run_tests.sh` must not be a fake wrapper that only prints TODOs, only runs lint when runtime proof is expected, or silently skips the meaningful part of verification.
 
 Minimum proof by family:

package/assets/slopmachine/templates/AGENTS.md

@@ -88,6 +88,7 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - `./run_tests.sh` should use the same startup-value model as `docker compose up --build` rather than a separate pre-seeded test-secret path.
 - If local-development runtime values must persist across restarts, keep them only in Docker-managed runtime state rather than committed repo files.
 - If such a bootstrap script exists, document in the script and in `README.md` that it is for local development bootstrap only and is not the production secret-management path.
+- Do not let `docker compose up --build` or `./run_tests.sh` depend on host-installed packages, SDKs, language runtimes, CLIs, or toolchains beyond Docker and the documented baseline host prerequisites; define those dependencies in Dockerfiles or other repo-controlled container build definitions.
 
 ## Product Integrity Rules
 

package/assets/slopmachine/templates/CLAUDE.md

@@ -88,6 +88,7 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 - `./run_tests.sh` should use the same startup-value model as `docker compose up --build` rather than a separate pre-seeded test-secret path.
 - If local-development runtime values must persist across restarts, keep them only in Docker-managed runtime state rather than committed repo files.
 - If such a bootstrap script exists, document in the script and in `README.md` that it is for local development bootstrap only and is not the production secret-management path.
+- Do not let `docker compose up --build` or `./run_tests.sh` depend on host-installed packages, SDKs, language runtimes, CLIs, or toolchains beyond Docker and the documented baseline host prerequisites; define those dependencies in Dockerfiles or other repo-controlled container build definitions.
 
 ## Product Integrity Rules
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "theslopmachine",
-  "version": "0.7.2",
+  "version": "0.7.3",
   "description": "SlopMachine installer and project bootstrap CLI",
   "license": "MIT",
   "type": "module",