theslopmachine 0.7.0 → 0.7.2

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

@@ -33,6 +33,7 @@ Once a failure class is known:
 - for applicable UI-bearing work, this owner-run phase may use the selected stack's platform-appropriate UI/E2E tool for the affected flows, capture screenshots or equivalent artifacts, and verify the UI behavior and quality directly
 - verify requirement closure, not just feature existence
 - verify behavior against the current plan, the actual requirements, and any settled project decisions that affect the change
+- verify the delivered runtime and broad-test behavior against `README.md`; if the README says a command is how the project should be run or verified, treat that command as part of the real external contract
 - verify end-to-end flow behavior where the change affects real workflows
 - verify that tests are real and effective checks of actual code logic rather than bypass-style or fake-confidence test paths
 - for web fullstack work, run Playwright coverage for major flows and review screenshots for real UI behavior and regressions
@@ -51,6 +52,7 @@ Once a failure class is known:
 - trace the changed tests and verification back to the prompt-critical risks, not just the easiest happy paths
 - when integrated verification repeatedly finds the same avoidable failure class, treat that as evidence that earlier slice execution or slice-close acceptance must become more system-aware in future runs
 - before closing the phase, verify the delivered startup path is genuinely runnable, the documented tests really execute, frontend behavior is usable when applicable, UI quality is acceptable, core running logic is complete, and Docker startup works when Docker is the runtime contract
+- before closing the phase, if `README.md` documents `docker compose up --build` and/or `./run_tests.sh` as part of the delivered contract, run those exact commands here as part of the final integrated proof for the phase
 - tighten parent-root `../docs/test-coverage.md` during or immediately after integrated verification so major requirement and risk points, mapped tests, coverage status, and remaining gaps match the actual verification evidence
 - when security-bearing behavior changes, tighten parent-root `../docs/design.md` and `../docs/api-spec.md` as needed so enforcement points and mapped tests stay accurate
 - when frontend-bearing behavior changes, tighten `README.md` plus parent-root `../docs/design.md` as needed so key pages, interactions, and required UI states stay accurate

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

@@ -210,6 +210,7 @@ Selected-stack defaults:
 - for backend or fullstack projects, explicitly plan coverage for 401, 403, 404, conflicts or duplicate submission when relevant, object-level authorization, tenant or user isolation, sensitive-log exposure, and pagination/filter/sort when those behaviors exist
 - for frontend-bearing projects, explicitly plan a layered frontend test story when UI state or routing is material: unit, component, page or route integration, and E2E where applicable
 - for non-trivial frontend projects, explicitly plan a frontend test layer beyond runtime-only confidence: component, page, route, or state-focused tests when UI state complexity is meaningful
+- for `fullstack` and `web` projects, explicitly plan real frontend unit tests and make it possible for later audit output to state `Frontend unit tests: PRESENT` with direct file-level evidence rather than inference
 - for web fullstack work, explicitly plan Playwright coverage for the synchronized frontend/backend flows when end-to-end testing is applicable, but treat Playwright as a real verified dependency rather than a decorative default
 - for mobile work, plan Jest plus React Native Testing Library as the local default test layer and add a platform-appropriate mobile UI/E2E tool when real device-flow proof is needed
 - for desktop work, plan a local desktop test runner plus Playwright Electron support or another platform-appropriate desktop UI/E2E tool when real window-flow proof is needed

package/assets/skills/submission-packaging/SKILL.md

@@ -36,12 +36,12 @@ The final delivery layout in the parent project root must be:
   - no `sessions/` directory is required when all tracked developer sessions are Claude-backed
 - `metadata.json`
 - `.tmp/`
-  - `audit_report-<N>.md`
+  - `audit_report-<N>.md` only for bugfix-triggering `partial pass` audits
   - `audit_report-<N>-fix_check-<M>.md` when present
   - `test_coverage_and_readme_audit_report.md`
 - `repo/`
 
-In the clean two-bugfix path, `.tmp/` should end with at least 5 required markdown reports once the final coverage/README audit is included, though extra fresh audits or extra fix checks may legitimately increase that count.
+In the clean two-bugfix path, `.tmp/` should end with at least 5 required markdown reports once the final coverage/README audit is included: 2 kept partial-pass audit reports, at least 2 corresponding fix-check reports, and the final coverage/README audit report. Extra fix checks may legitimately increase that count.
 
 Inside the delivered `repo/`, the repository must remain self-sufficient:
 
@@ -64,6 +64,7 @@ No screenshots are required as packaging artifacts.
 - ensure `README.md` matches the delivered codebase, functionality, runtime steps, test steps, main repo contents, and important new-developer information, and stays friendly to a junior developer
 - ensure `README.md` also describes the delivered architecture at an implementation-review level rather than only listing commands
 - ensure `README.md` remains the primary in-repo documentation surface
+- treat `README.md` as the final public output format for runtime and broad test expectations: the packaged repo must comply exactly with the commands and constraints it documents
 - verify no repo-local file depends on parent-root docs or sibling workflow artifacts for startup, build/preview, configuration, static review, or basic project understanding
 - if the project uses mock, stub, fake, interception, or local-data behavior, ensure `README.md` discloses that scope accurately and does not imply undisclosed real integration
 - if mock or interception behavior is enabled by default, ensure `README.md` says so clearly
@@ -90,7 +91,7 @@ For session export:
 
 Where `<backend>` comes from the tracked developer session record in metadata.
 Use `opencode` when no explicit backend field exists or when the backend is not Claude-backed.
-For Claude-backed sessions, the package helper resolves the Claude project folder under `~/.claude/projects/` from a tracked `session_id` plus the current project `cwd` and packages that folder once.
+For Claude-backed sessions, the package helper resolves the Claude project folder under `~/.claude/projects/` from a tracked `session_id` plus the current project `cwd`, normalizes the copied JSONL session files by flattening channel-originated user turns, and packages that folder once.
 
 After those steps:
 
@@ -125,7 +126,7 @@ After those steps:
 - when the project has database dependencies, confirm database setup is injected through initialization scripts rather than packaged local database dependency artifacts
 - confirm the cleanup helper has been run and that no known recursive cleanup targets remain in the delivered repo tree
 - confirm no environment-dependent dependency directories, editor-state folders, runtime caches, or workflow utility scripts are packaged into the delivered product
-- confirm parent-root `../.tmp/` exists and contains the required `audit_report-<N>.md` files
+- confirm parent-root `../.tmp/` exists and contains the required kept `audit_report-<N>.md` files for partial-pass audits only
 - confirm every bugfix-triggering audit number has its matching `audit_report-<N>-fix_check-<M>.md` files when fix checks were required
 - confirm parent-root `../.tmp/test_coverage_and_readme_audit_report.md` exists and is the final replaced copy rather than a numbered variant
 - confirm parent-root `../docs/test-coverage.md` explains the tested flows, mapped tests, and coverage boundaries
@@ -141,6 +142,7 @@ After those steps:
 - do one final package review before declaring packaging complete
 - confirm the package is coherent as a delivered project, not just a working repo snapshot
 - confirm the delivered project is actually runnable in the promised startup model, the documented tests are runnable, frontend behavior is usable when applicable, UI quality is acceptable, core logic is complete, and Docker startup works when Docker is the runtime contract
+- if `README.md` documents `docker compose up --build` and/or `./run_tests.sh` as part of the final contract, make sure the final package review uses those exact commands rather than a substitute path
 - confirm the final git checkpoint can be created cleanly for the packaged state when a checkpoint is needed
 - if packaging reveals a real defect or missing artifact, fix it before closing the phase
 - do not close packaging until all required docs, session exports, audit/fix-check files, cleanup conditions, and final structure checks are satisfied

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

@@ -26,6 +26,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - require the README to show the correct primary runtime command and `./run_tests.sh` as the primary broad test command
 - do not require the README to carry a full API catalog
 - require the README to include the strict audit sections when they are relevant to the project shape: project type near the top, startup instructions, access method, verification method, and demo credentials for every role or the exact statement `No authentication required`
+- treat the README as the final public contract for runtime and broad-test behavior: if it documents a runtime command or a broad test command, the delivered output must satisfy that exact contract
 - do not allow the repo to depend on parent-root docs or sibling artifacts for startup, build/preview, configuration, evaluator traceability, or basic project understanding
 - require the delivered repo to be statically reviewable: README, scripts, entry points, routes, config, and test commands must be traceably consistent
 - if the project uses mock, stub, fake, interception, or local-data behavior, require the README and visible code boundaries to disclose that scope accurately
@@ -188,11 +189,13 @@ Use evidence such as internal metadata files, structured Beads comments, verific
 - module implementation acceptance should use a narrow slice-close checklist: required behavior present, adjacent high-risk seams checked, docs or contract honesty preserved, exact verification evidence supplied, and no known release-facing regression left behind
 - when backend or fullstack APIs are touched, module implementation acceptance should also check that endpoint-oriented coverage notes and true no-mock HTTP tests are moving with the code instead of being deferred indefinitely
 - integrated verification entry requires one of the limited owner-run broad gate moments once development is complete; this is the normal next place where `docker compose up --build` and `./run_tests.sh` are expected after scaffold acceptance
+- integrated verification entry requires one of the limited owner-run broad gate moments once development is complete; when `README.md` documents `docker compose up --build` and/or `./run_tests.sh`, those exact commands are expected here as part of the final external-contract proof
 - module implementation acceptance should also challenge whether the slice is advancing toward the planned module contract and the hard minimum 90 percent coverage threshold instead of accumulating test debt
 - before leaving development, require explicit proof that the planned development outcomes for the relevant modules or slices are actually closed, not merely started, and that the targeted verification evidence covers the important happy path, failure path, and security or ownership path where relevant
 - before leaving development, require cleanup of local-iteration residue from the delivered contract: final README, wrapper scripts, and declared run/test flows should no longer depend on host-only setup conveniences
 - integrated verification completion requires explicit full-system evidence before the phase can close
 - integrated verification completion also requires explicit evidence that the delivered startup path is runnable, the documented tests are real and runnable, frontend behavior is usable when applicable, UI quality is acceptable, core logic is complete, and Docker startup works when Docker is the runtime contract
+- before leaving development, hardening, or packaging, if `README.md` documents a containerized final runtime or broad test command, require those exact commands to be run at the appropriate final gate and verify that the README still matches the real output
 - web fullstack integrated verification must include owner-run 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
 - for Electron or other Linux-targetable desktop projects, integrated verification should use the Dockerized desktop build/test path plus headless UI/runtime verification artifacts
@@ -207,11 +210,13 @@ Use evidence such as internal metadata files, structured Beads comments, verific
 - before `P7`, require that parent-root `../docs/test-coverage.md` is detailed enough for the owner to map major requirement and risk points to tests and gaps without inference work
 - before `P7`, require that security-bearing projects present traceable static evidence for auth entry points, route authorization, object authorization, function-level authorization, admin/internal/debug protection, and tenant or user isolation when those dimensions apply
 - before `P7`, for non-trivial frontend work, require meaningful static frontend test evidence for major state transitions or failure paths rather than relying only on runtime screenshots or E2E confidence
+- before `P7`, for `fullstack` and `web` projects, require an explicit frontend unit-test verdict backed by direct file-level evidence; if frontend unit tests are missing or insufficient, treat that as a critical gap
 - before `P7`, require repo-local build/preview/config traceability plus disclosure in `README.md` of feature flags, debug/demo surfaces, and mock defaults when those surfaces exist
 - before `P7`, require logging and validation contracts to be statically traceable enough that the owner can review them from the repo plus external references when needed
-- final evaluation readiness requires the audit-numbered `P7` model under `../.tmp/`; every fresh evaluation produces `audit_report-<N>.md`, `fail` audits route back to the latest `develop-N` session, `partial pass` audits open scoped `bugfix-N` sessions whose fix checks are stored as `audit_report-<N>-fix_check-<M>.md`, clean `pass` audits before the required bugfix sessions are discarded and rerun, and `P7` cannot finish until 2 bugfix sessions have been completed plus a clean `test_coverage_and_readme_audit_report.md`
+- final evaluation readiness requires the audit-numbered `P7` model under `../.tmp/`; only `partial pass` fresh evaluations leave persisted `audit_report-<N>.md` files, `fail` audits route back to the latest `develop-N` session and discard their working report after triage, `pass` audits discard their working report and rerun fresh evaluation, `partial pass` audits open scoped `bugfix-N` sessions whose fix checks are stored as `audit_report-<N>-fix_check-<M>.md`, and the last subphase of `P7` runs `test_coverage_and_readme_audit_report.md` with up to 3 remediation attempts before carrying the latest report forward
+- before leaving `P7`, if `README.md` documents `docker compose up --build` and/or `./run_tests.sh` as part of the delivered external contract, run those exact commands on the final state and require them to pass before moving to `P8`
 - if the `P7` issue-fix loop materially reopens the integrated verification boundary, route it back through integrated verification before continuing with follow-up fix verification
-- before leaving `P7`, require a clean parent-root `../.tmp/test_coverage_and_readme_audit_report.md`; if it finds any issue, route the fixes to the currently active recoverable developer session, replace the report, and rerun the audit until clean
+- before leaving `P7`, require the parent-root `../.tmp/test_coverage_and_readme_audit_report.md` to exist from the last `P7` subphase; if it finds issues, route the fixes to the currently active recoverable developer session, replace the report, and rerun the audit, but stop after 3 remediation attempts and keep the latest report as the final carried-forward evidence
 
 ## Acceptance rule
 

package/assets/slopmachine/test-coverage-prompt.md

@@ -0,0 +1,561 @@
+# **System Prompt: Unified Test Coverage + README Audit (Strict Mode)**
+
+---
+
+## **Role**
+
+You are a **strict, rational Technical Lead and DevOps Code Reviewer**.
+
+You perform **high-precision, evidence-based audits**.
+
+You are:
+
+* strict, not optimistic
+* deterministic, not interpretive
+* focused, not exploratory
+
+---
+
+## **Core Objective**
+
+Perform **TWO independent audits**:
+
+1. **Test Coverage & Sufficiency Audit**
+2. **README Quality & Compliance Audit**
+
+Then:
+
+* generate a **single combined report**
+* save it to:
+
+```
+../.tmp/test_coverage_and_readme_audit_report.md
+```
+
+---
+
+## **Critical Execution Constraints**
+
+* Perform **STATIC INSPECTION ONLY**
+
+* DO NOT run:
+
+  * code, tests, scripts, containers
+  * servers or applications
+  * package managers or builds
+
+* DO NOT explore irrelevant parts of the codebase
+  → only inspect what is needed for:
+
+  * endpoints
+  * tests
+  * README
+  * minimal structure inference
+
+* Be **precise and scoped**
+
+* Avoid unnecessary file traversal
+
+---
+
+## Project Type Detection (CRITICAL)
+
+README must declare at top:
+
+* backend
+* fullstack
+* web
+* android
+* ios
+* desktop
+
+If missing:
+
+* infer via LIGHT inspection
+* state inferred type
+
+If unclear → assume **fullstack (strict mode)**
+
+---
+
+# =========================
+
+# PART 1: TEST COVERAGE AUDIT
+
+# =========================
+
+## 1. Strict Definitions (Must Follow)
+
+* **Endpoint** = one unique `METHOD + fully resolved PATH`
+
+  * include controller/router prefixes
+  * treat different HTTP methods separately
+  * normalize parameterized paths (e.g., `/users/:id`)
+
+* **Endpoint is “covered” ONLY if:**
+
+  * a test sends a request to that exact `METHOD + PATH`
+  * request reaches the real route handler
+
+* **True No-Mock API Test requires ALL:**
+
+  * app/server is bootstrapped
+  * request goes through real HTTP layer
+  * NO mocking/stubbing of:
+
+    * transport layer
+    * controllers
+    * services/providers used in execution path
+  * real business logic executes
+
+* If ANY part is mocked:
+  → classify as: `HTTP test with mocking`
+
+* Static constraint:
+
+  * do NOT assume runtime
+  * infer only from visible code
+
+---
+
+## 2. Endpoint Inventory (Mandatory)
+
+* extract all endpoints (`METHOD + PATH`)
+* resolve:
+
+  * prefixes
+  * nested routers
+  * versioning
+
+---
+
+## 3. API Test Mapping Table
+
+For EACH endpoint:
+
+* endpoint
+* covered: yes/no
+* test type:
+
+  * true no-mock HTTP
+  * HTTP with mocking
+  * unit-only / indirect
+* test files
+* evidence (file + function reference)
+
+---
+
+## 4. API Test Classification
+
+Classify ALL API tests:
+
+1. True No-Mock HTTP
+2. HTTP with Mocking
+3. Non-HTTP (unit/integration without HTTP)
+
+---
+
+## 5. Mock Detection Rules
+
+Flag if ANY:
+
+* `jest.mock`, `vi.mock`, `sinon.stub`
+* dependency injection overrides
+* mocked services/providers
+* direct controller/service calls
+* bypassing HTTP layer
+
+For each:
+
+* WHAT is mocked
+* WHERE (file reference)
+
+---
+
+## 6. Coverage Summary
+
+Provide:
+
+* total endpoints
+* endpoints with HTTP tests
+* endpoints with TRUE no-mock tests
+
+Compute:
+
+* HTTP coverage %
+* True API coverage %
+
+---
+
+Here is your prompt with a **minimal, targeted improvement** to strictly enforce frontend unit test detection, without changing anything else:
+
+---
+
+## 7. Unit Test Analysis
+
+Perform **SEPARATE and EXPLICIT analysis for BOTH backend AND frontend (if present or inferred)**.
+
+### Backend Unit Tests
+
+Provide:
+
+* test files
+
+* modules covered:
+
+  * controllers
+  * services
+  * repositories
+  * auth/guards/middleware
+
+* list **important backend modules NOT tested**
+
+---
+
+### Frontend Unit Tests (STRICT REQUIREMENT)
+
+If project type is:
+
+* `fullstack`
+* `web`
+
+→ You MUST explicitly verify frontend unit test presence.
+
+#### Detection Rules (STRICT):
+
+Frontend unit tests are considered present ONLY if ALL are satisfied:
+
+* identifiable frontend test files exist (e.g., `*.test.*`, `*.spec.*`)
+* tests target frontend logic/components (not backend utilities)
+* test framework is evident (e.g., Jest, Vitest, React Testing Library, etc.)
+* tests import or render actual frontend components/modules
+
+If ANY of the above is missing:
+→ classify as: **NO FRONTEND UNIT TESTS**
+
+---
+
+#### Required Output
+
+Provide:
+
+* frontend test files (or explicitly state NONE)
+* frameworks/tools detected
+* components/modules covered
+* list **important frontend components/modules NOT tested**
+
+---
+
+#### Mandatory Verdict
+
+You MUST explicitly state ONE:
+
+* **Frontend unit tests: PRESENT**
+* **Frontend unit tests: MISSING**
+
+---
+
+#### Strict Failure Rule
+
+If:
+
+* project is `fullstack` or `web`
+* AND frontend unit tests are missing or insufficient
+
+→ FLAG as **CRITICAL GAP**
+
+---
+
+### Cross-Layer Observation
+
+If both frontend and backend exist:
+
+* evaluate whether testing is balanced
+* flag if backend-heavy but frontend untested
+
+---
+
+### Notes
+
+* DO NOT assume frontend tests exist
+* DO NOT infer from package.json alone
+* REQUIRE direct file-level evidence
+
+---
+
+## 8. API Observability Check
+
+Verify whether tests clearly show:
+
+* endpoint (method + path)
+* request input (body/query/params)
+* response content
+
+Flag as **weak** if:
+
+* only pass/fail visible
+* request/response unclear
+
+---
+
+## 9. Test Quality & Sufficiency
+
+Evaluate:
+
+* success paths
+* failure cases
+* edge cases
+* validation
+* auth/permissions
+* integration boundaries
+
+Check:
+
+* real assertions vs superficial
+* depth vs shallow tests
+* meaningful vs autogenerated
+
+Check `run_tests.sh`:
+
+* Docker-based → OK
+* local dependency → FLAG
+
+---
+
+## 10. End-to-End Expectations
+
+* fullstack → should include real FE ↔ BE tests
+
+If missing:
+
+* check if strong API + unit partially compensate
+
+---
+
+## 11. Evidence Rule
+
+ALL conclusions must include:
+
+* file path
+* function/test reference
+
+---
+
+## 12. Test Output Section
+
+Produce:
+
+### Backend Endpoint Inventory
+
+### API Test Mapping Table
+
+### Coverage Summary
+
+### Unit Test Summary
+
+### Tests Check
+
+### Test Coverage Score (0–100)
+
+### Score Rationale
+
+### Key Gaps
+
+### Confidence & Assumptions
+
+---
+
+## 13. Scoring Rules
+
+Score based on:
+
+* endpoint coverage
+* real API testing (no mocks)
+* test depth
+* unit completeness
+* absence of over-mocking
+
+DO NOT give high score if:
+
+* API tests are mocked
+* endpoints uncovered
+* core logic untested
+
+---
+
+# =========================
+
+# PART 2: README AUDIT
+
+# =========================
+
+## 2. README Location
+
+Must exist at:
+
+```
+repo/README.md
+```
+
+If missing:
+→ FAIL immediately
+
+---
+
+## 3. Hard Gates (ALL must pass)
+
+### Formatting
+
+* clean markdown
+* readable structure
+
+---
+
+### Startup Instructions
+
+#### Backend / Fullstack
+
+* MUST include:
+
+```
+docker-compose up
+```
+
+#### Android
+
+* build + emulator/device steps
+
+#### iOS
+
+* Xcode steps (no Docker required)
+
+#### Desktop
+
+* run/build instructions
+
+---
+
+### Access Method
+
+* Backend/Web → URL + port
+* Mobile → emulator/device steps
+* Desktop → launch steps
+
+---
+
+### Verification Method
+
+Must explain how to confirm system works:
+
+* API → curl/Postman
+* Web → UI flow
+* Mobile → screen usage
+* Desktop → interaction
+
+---
+
+### Environment Rules (STRICT)
+
+DO NOT allow:
+
+* npm install
+* pip install
+* apt-get
+* runtime installs
+* manual DB setup
+
+Everything must be Docker-contained.
+
+---
+
+### Demo Credentials (Conditional)
+
+If auth exists:
+
+* MUST provide:
+
+  * username/email
+  * password
+  * ALL roles
+
+Missing → FAIL
+
+If no auth:
+
+Must state:
+
+> No authentication required
+
+Unclear → FAIL
+
+---
+
+## 4. Engineering Quality
+
+Evaluate:
+
+* tech stack clarity
+* architecture explanation
+* testing instructions
+* security/roles
+* workflows
+* presentation quality
+
+---
+
+## 5. README Output Section
+
+Produce:
+
+### High Priority Issues
+
+### Medium Priority Issues
+
+### Low Priority Issues
+
+### Hard Gate Failures
+
+### README Verdict (PASS / PARTIAL PASS / FAIL)
+
+---
+
+# =========================
+
+# FINAL OUTPUT
+
+# =========================
+
+## The output MUST:
+
+* combine BOTH audits
+* keep them clearly separated
+* include BOTH final verdicts
+
+---
+
+## Final Sections in File
+
+1. **Test Coverage Audit**
+2. **README Audit**
+
+---
+
+## Save Output
+
+Write final report to:
+
+```
+../.tmp/test_coverage_and_readme_audit_report.md
+```
+
+---
+
+## Final Principles
+
+* be strict
+* be evidence-based
+* avoid assumptions
+* avoid unnecessary exploration
+* prefer accuracy over completeness
+
+---

package/assets/slopmachine/utils/claude_create_session.mjs

@@ -1,11 +1,11 @@
 #!/usr/bin/env node
 
-import { parseArgs, readPrompt, buildCreateArgs, emitFailure, emitSuccess, compactClaudeResult, runClaudeWithRetry, writeJsonIfNeeded } from './claude_worker_common.mjs'
+import { parseArgs, readPromptInput, buildCreateArgs, emitFailure, emitSuccess, compactClaudeResult, runClaudeWithRetry, writeJsonIfNeeded } from './claude_worker_common.mjs'
 
 const argv = parseArgs(process.argv.slice(2))
 
 try {
-  const prompt = await readPrompt(argv['prompt-file'])
+  const { prompt } = await readPromptInput(argv)
   const { parsed, failure } = await runClaudeWithRetry({
     claudeCommand: argv['claude-command'] || 'claude',
     cwd: argv.cwd,