theslopmachine 1.0.11 → 1.0.12

package/assets/agents/developer.md

@@ -56,6 +56,8 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 - Tests should prove behavior and side effects, not only existence or rendering.
 - Add or update tests for every implementation change. Target full meaningful coverage of delivered behavior, not just a smoke path.
 - Cover implementation at the strongest relevant layers: unit tests for business logic, API/integration HTTP tests for every endpoint or interface, and E2E/platform tests for user-facing flows.
+- API/integration tests should exercise the real route/interface and business logic without mocking the transport, controller, or execution-path services unless there is a documented reason this is not possible.
+- Frontend unit/component tests should be directly detectable and should import or render the real frontend components/modules they cover.
 - Include negative and boundary coverage when relevant: unauthenticated, unauthorized, not found, conflicts, invalid input, empty states, duplicate actions, object ownership, and sensitive data exposure.
 - For frontend work, test loading, empty, submitting, disabled, success, error, and re-entry states when those states are relevant.
 - For backend-backed frontend work, verify the frontend uses the real client/API path and the backend performs real handler/service/data work.

package/assets/agents/slopmachine-claude.md

@@ -211,6 +211,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Preserve reports, extract complete issue sets, and route fixes in broad human language.
 - After both audit cycles, close the bugfix lane and start a test-coverage/final-reconciliation lane.
 - Complete only when the coverage/README audit passes with at least 90% test score.
+- Treat README hard-gate failures, missing true endpoint coverage, missing frontend unit tests for web/fullstack, and missing FE-BE proof as reconciliation work for the active Claude lane before this phase closes.
 
 ### Phase 6: Final Readiness Decision
 
@@ -219,8 +220,9 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Run final runtime and test checks appropriate to the project.
 - Run `./repo/run_tests.sh` when present or required by the scaffold contract.
 - Run `docker compose up --build` for container-supported web/backend/fullstack projects unless explicitly out of scope.
+- Use `agent-browser` for browser-accessible apps to exercise the core prompt requirements, main user journeys, and every README-listed demo credential, role/state, seeded value, example ID/status, and documented default. Use API/platform-equivalent checks for non-browser projects.
 - If Docker, runtime, browser, or `run_tests.sh` fails, route the failure to the currently active Claude lane in broad human language, verify the fix, rerun the failed check, and repeat until green or explicitly risk-accepted by the user.
-- If the owner makes a direct safe fix, send a minimal note to the active Claude lane describing the changed surface and ask it to inspect/acknowledge before continuing.
+- Route final reconciliation work to the active Claude lane whenever it is more than a tiny, safe owner-side edit. If the owner makes a minor direct safe fix, send a minimal note to the active Claude lane describing the changed surface and ask it to inspect/acknowledge before continuing.
 - Use platform-equivalent checks for Android, iOS, desktop, or other native projects.
 - Do not pass readiness with unresolved blocker/high findings, unverified runtime claims, README drift, or known fake behavior.
 
@@ -232,6 +234,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Include only package docs: `docs/questions.md`, `docs/design.md`, and `docs/api-spec.md` when applicable.
 - Do not package workflow-private `../.ai`, `../.beads`, hidden session state, owner plans, raw evaluator workspaces, or task-root rulebooks unless the packaging spec explicitly requires them.
 - Run final package boundary checks before closing.
+- If packaging, cleanup, README edits, config, or seed/runtime changes could affect documented behavior, rerun the affected Docker/runtime, `run_tests.sh`, and browser/API seeded-value checks before closing.
 
 ### Phase 8: Retrospective
 
@@ -248,7 +251,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - API/integration HTTP tests belong under `API_tests/` where that convention exists.
 - Fullstack/backend-backed frontend work must prove real frontend-to-backend behavior through user-visible flows unless accepted design explicitly marks a capability internal/API-only.
 - Security, authorization, ownership, isolation, validation, error handling, logging, config, seeded data, and README claims must align with delivered behavior.
-- README must truthfully document startup, tests, configuration, access, demo credentials or `No authentication required`, seeded data or `No seeded data required; the app is useful from an empty state.`, and known limitations.
+- README must truthfully document project type near the top, startup, tests, configuration, access, demo credentials and all roles or `No authentication required`, seeded data or `No seeded data required; the app is useful from an empty state.`, mock/local/debug boundaries, and known limitations.
 
 ## Evidence Discipline
 

package/assets/agents/slopmachine.md

@@ -178,6 +178,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Preserve reports, extract complete issue sets, and route fixes in broad human language.
 - After both audit cycles, close the bugfix lane and start a test-coverage/final-reconciliation lane.
 - Complete only when the coverage/README audit passes with at least 90% test score.
+- Treat README hard-gate failures, missing true endpoint coverage, missing frontend unit tests for web/fullstack, and missing FE-BE proof as reconciliation work for the active lane before this phase closes.
 
 ### Phase 6: Final Readiness Decision
 
@@ -186,8 +187,9 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Run final runtime and test checks appropriate to the project.
 - Run `./repo/run_tests.sh` when present or required by the scaffold contract.
 - Run `docker compose up --build` for container-supported web/backend/fullstack projects unless explicitly out of scope.
+- Use `agent-browser` for browser-accessible apps to exercise the core prompt requirements, main user journeys, and every README-listed demo credential, role/state, seeded value, example ID/status, and documented default. Use API/platform-equivalent checks for non-browser projects.
 - If Docker, runtime, browser, or `run_tests.sh` fails, route the failure to the currently active developer session in broad human language, verify the fix, rerun the failed check, and repeat until green or explicitly risk-accepted by the user.
-- If the owner makes a direct safe fix, send a minimal note to the active developer session describing the changed surface and ask it to inspect/acknowledge before continuing.
+- Route final reconciliation work to the active developer session whenever it is more than a tiny, safe owner-side edit. If the owner makes a minor direct safe fix, send a minimal note to the active developer session describing the changed surface and ask it to inspect/acknowledge before continuing.
 - Use platform-equivalent checks for Android, iOS, desktop, or other native projects.
 - Do not pass readiness with unresolved blocker/high findings, unverified runtime claims, README drift, or known fake behavior.
 
@@ -199,6 +201,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - Include only package docs: `docs/questions.md`, `docs/design.md`, and `docs/api-spec.md` when applicable.
 - Do not package workflow-private `../.ai`, `../.beads`, hidden session state, owner plans, raw evaluator workspaces, or task-root rulebooks unless the packaging spec explicitly requires them.
 - Run final package boundary checks before closing.
+- If packaging, cleanup, README edits, config, or seed/runtime changes could affect documented behavior, rerun the affected Docker/runtime, `run_tests.sh`, and browser/API seeded-value checks before closing.
 
 ### Phase 8: Retrospective
 
@@ -215,7 +218,7 @@ Use these sequential names as the canonical workflow model. Legacy `P*` names ar
 - API/integration HTTP tests belong under `API_tests/` where that convention exists.
 - Fullstack/backend-backed frontend work must prove real frontend-to-backend behavior through user-visible flows unless accepted design explicitly marks a capability internal/API-only.
 - Security, authorization, ownership, isolation, validation, error handling, logging, config, seeded data, and README claims must align with delivered behavior.
-- README must truthfully document startup, tests, configuration, access, demo credentials or `No authentication required`, seeded data or `No seeded data required; the app is useful from an empty state.`, and known limitations.
+- README must truthfully document project type near the top, startup, tests, configuration, access, demo credentials and all roles or `No authentication required`, seeded data or `No seeded data required; the app is useful from an empty state.`, mock/local/debug boundaries, and known limitations.
 
 ## Evidence Discipline
 

package/assets/claude/agents/developer.md

@@ -42,6 +42,8 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 - Tests must prove behavior and side effects, not only existence or rendering.
 - Add or update tests for every implementation change. Target full meaningful coverage of delivered behavior, not just a smoke path.
 - Cover implementation at the strongest relevant layers: unit tests for business logic, API/integration HTTP tests for every endpoint or interface, and E2E/platform tests for user-facing flows.
+- API/integration tests should exercise the real route/interface and business logic without mocking the transport, controller, or execution-path services unless there is a documented reason this is not possible.
+- Frontend unit/component tests should be directly detectable and should import or render the real frontend components/modules they cover.
 - Cover negative and boundary paths when relevant: unauthenticated, unauthorized, not found, conflicts, invalid input, empty states, duplicate actions, object ownership, and sensitive data exposure.
 - For frontend work, test loading, empty, submitting, disabled, success, error, and re-entry states when those states are relevant.
 - For backend-backed frontend work, verify the frontend uses the real client/API path and the backend performs real handler/service/data work.

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

@@ -50,7 +50,7 @@ Do not say `the review found`, `the evaluation found`, or `the audit found`. The
 ## Development Sequence
 
 1. **Scaffold first.**
-   - Establish the framework/runtime/test/README baseline.
+   - Establish the framework/runtime/test/README baseline, including the strict README gates that final review will expect.
    - Keep it free of project-specific business logic except the minimum proof surface needed to verify the stack is wired.
    - Use `scaffold-guidance` and scaffold playbooks privately to shape the prompt.
 
@@ -100,11 +100,12 @@ For each scaffold/module, check:
 - no-orphan ledger items assigned to the module are closed
 - project-specific behavior is real, not placeholder/shell/demo-only behavior
 - tests exist for the implemented behavior or a concrete exception is recorded
-- planned API/interface proof is present when the module owns endpoints/interfaces
+- planned API/interface proof is present when the module owns endpoints/interfaces, with true no-mock HTTP/API endpoint tests where applicable
+- frontend unit tests are directly detectable and import/render real frontend components/modules when the module owns frontend behavior
 - planned FE-BE proof is present when the module crosses frontend/backend boundaries
 - failure, validation, authorization, ownership, empty, loading, error, and duplicate/re-entry cases are covered where relevant
 - frontend/backend wiring is real where applicable
-- README changes match delivered runtime, commands, auth/no-auth, seed/demo data, and verification behavior
+- README changes match delivered runtime, commands, auth/no-auth, seed/demo data, verification behavior, mock/local/debug boundaries, and strict startup/access gates
 - targeted checks ran or were clearly blocked
 
 ## Internal Plan Alignment

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

@@ -154,9 +154,9 @@ After the new reconciliation lane is established:
 2. Send `test-coverage-prompt.md` verbatim.
 3. Require `./.tmp/test_coverage_and_readme_audit_report.md`.
 4. Read the generated report.
-5. Require an overall Pass. Pass with caveats is acceptable.
+5. Require an overall Pass. Pass with caveats is acceptable only when caveats are explicit, bounded, non-blocking, and do not contradict README hard gates or required coverage surfaces.
 6. Require at least 90% test score.
-7. If verdict is not Pass or test score is below 90%, extract all missing items and send them to the reconciliation lane in broad human language.
+7. If verdict is not Pass or Pass with acceptable caveats, if test score is below 90%, or if the report identifies README hard-gate failures, mocked endpoint coverage presented as true API coverage, missing frontend unit tests for web/fullstack, or missing FE-BE proof, extract all missing items and send them to the reconciliation lane in broad human language.
 8. After fixes, start a new evaluator session and send the same full verbatim test coverage/README prompt again.
 9. Repeat until verdict is Pass or Pass with caveats and test score is at least 90%.
 

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

@@ -52,6 +52,7 @@ Check:
 - README gate matrix
 - risk/negative coverage matrix
 - runtime/test/config consistency
+- strict README gates: project type near the top, Docker/startup/access/verification commands, auth/no-auth, every documented demo credential/role and seeded value, mock/local/debug disclosure, and no hidden manual setup
 - security, authorization, ownership, validation, and data integrity
 - placeholder, shell, fake-success, disconnected UI, or static-demo behavior
 
@@ -117,6 +118,7 @@ Rules:
 - Use the startup commands and expected flows supplied at the end of development.
 - Verify the app starts locally when feasible.
 - Verify key expected flows manually/API-wise/platform-wise as appropriate.
+- For browser-accessible apps, manually exercise representative core prompt requirements and every README-listed seeded/demo account, role, and seeded value where feasible. Record any unverified surface and route failures to the bugfix lane.
 - Run relevant unit/API/integration/E2E/platform checks locally when available.
 - If a command or local runtime check cannot run, record the exact blocker and risk.
 - Any issue found goes back to the bugfix lane in human language.

package/assets/skills/p8-readiness-reconciliation/SKILL.md

@@ -36,14 +36,16 @@ Use these D1-D9 buckets for major issue classification:
 
 - Run the broad product test wrapper `./repo/run_tests.sh` when it exists and is applicable.
 - Run final runtime verification before packaging: `docker compose up --build` for web/backend/fullstack/container-supported projects, native/platform-equivalent startup for mobile/desktop projects, or a recorded not-applicable reason.
-- Use `agent-browser` for manual functionality verification where browser-accessible UI exists.
-- Exercise every relevant seeded/demo account and role/state where credentials or seeded data exist.
+- Use `agent-browser` for manual functionality verification where browser-accessible UI exists. The browser pass must walk the core prompt requirements and main user journeys, not just confirm that the app loads.
+- Exercise every relevant seeded/demo account, role/state, and README-listed seeded value. Confirm that documented credentials, seeded records, examples, IDs, statuses, roles, permissions, and expected default states are present, usable, and consistent with README claims.
+- For backend/API-only projects, replace browser checks with equivalent API/manual checks for every README-listed credential, seeded value, role/state, and core requirement.
 - If any final runtime, test, browser, account, or platform check cannot run, readiness cannot be `Pass` unless the user explicitly risk-accepts the unverified surface.
 
 ## Failure Routing Loop
 
 - Phase 6 is the primary green gate for broad Docker/runtime and `./repo/run_tests.sh` verification.
-- If `docker compose up --build`, native/platform startup, browser checks, account checks, or `./repo/run_tests.sh` fails, do not move to packaging.
+- Final reconciliation work belongs in the currently active developer/Claude implementation lane whenever it is more than a tiny, safe owner-side edit. Route product behavior, tests, README/runtime drift, Docker/runtime failures, browser/account issues, and coverage gaps to that lane in broad human language.
+- If `docker compose up --build`, native/platform startup, browser/API manual checks, account/seeded-value checks, or `./repo/run_tests.sh` fails, do not move to packaging.
 - Route the failure to the currently active developer/Claude implementation lane in broad human language: describe the failing behavior, command, and user-visible/runtime impact without exposing evaluator or owner-private mechanics.
 - After the lane reports a fix, the owner verifies the changed surface and reruns the failed check.
 - Repeat fix, verify, and rerun until the check is green, not applicable for a documented reason, or explicitly risk-accepted by the user.
@@ -51,7 +53,8 @@ Use these D1-D9 buckets for major issue classification:
 
 ## Owner Direct Fixes
 
-- The owner may directly fix narrow docs, wrapper, config, cleanup, or light glue issues when the fix is safe and does not require product-design judgment.
+- The owner may directly fix only minor, safe docs, wrapper, config, cleanup, or light glue issues when the change does not require product-design judgment, new tests, behavioral changes, or non-trivial debugging.
+- If the reconciliation issue is large enough to need real implementation work, meaningful test updates, runtime debugging, README/runtime restructuring, or product judgment, do not fix it owner-side. Send it to the currently active developer/Claude lane.
 - After any direct owner fix, send a minimal note to the currently active developer/Claude lane describing the changed surface and ask it to inspect/acknowledge the change before readiness continues.
 - The note should be concise and developer-facing, not a workflow report.
 - Still rerun the affected command or check after acknowledgement.

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

@@ -25,7 +25,8 @@ Accept `./docs/design.md` only if it:
 - defines modules as product/system responsibilities, not file-by-file work packets
 - handles auth, authorization, ownership/isolation, validation, logging/redaction, admin/debug boundaries, and sensitive data where relevant
 - defines frontend states and FE-BE expectations where relevant
-- visibly defines the testing contract in the design itself: 90%+ unit coverage target for meaningful business logic, API/interface tests for every endpoint with positive and negative cases, and full E2E/platform coverage for main user journeys in user-facing apps
+- visibly defines the testing contract in the design itself: 90%+ unit coverage target for meaningful business logic, true HTTP/API tests for every runtime endpoint with positive and negative cases, identifiable frontend unit tests that import/render real components/modules where a frontend exists, fullstack FE-BE proof, and full E2E/platform coverage for main user journeys in user-facing apps
+- defines strict README/runtime obligations: project type near the top, primary `docker compose up --build` for container-supported deliveries, legacy compatibility string `docker-compose up` without making it primary, access and verification method, all auth/demo credentials and roles or exact `No authentication required`, seeded data values or empty-state statement, no manual runtime installs/manual DB setup/hidden `.env` dependency, mock/local/debug disclosures, and known limitations
 - gives explicit not-applicable reasons and replacement proof layers for any missing unit/API/E2E coverage surface
 - avoids vague placeholders such as `TBD`, `later`, `standard CRUD`, `normal auth`, or `basic tests` for correctness-critical behavior
 
@@ -55,11 +56,13 @@ Accept `../.ai/plan.md` only if it is strong enough for the owner to drive devel
 - security execution obligations
 - API/interface implementation and proof obligations
 - API coverage matrix when APIs exist, including true HTTP/API proof and exception rationale
+- frontend unit-test detectability when frontend exists: direct test files, framework evidence, and imports/renders of real frontend components/modules
 - frontend state and integration obligations where applicable
 - FE-BE integration matrix and backend-to-frontend exposure check where applicable
 - README/runtime/test obligations
 - README gate matrix covering startup, access, verification, auth/no-auth, seeded/empty-state, config/no-secret handling, mock/local-data disclosure, and known limitations
-- test coverage map with unit/API/integration/E2E or platform-equivalent expectations
+- README gate matrix covering strict audit requirements: project type near top, `docker compose up --build`, legacy `docker-compose up` string, startup, access, verification, auth/no-auth, seeded values/empty-state, config/no-secret/no-hidden-env/no-manual-install handling, mock/local/debug disclosure, and known limitations
+- test coverage map with unit/API/integration/E2E or platform-equivalent expectations, including true no-mock HTTP/API endpoint proof where applicable
 - risk/negative coverage matrix for validation, authorization, ownership/isolation, empty/not-found, duplicate/conflict, re-entry, and sensitive-data leakage where relevant
 - final integrated verification and readiness preparation
 

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

@@ -45,7 +45,7 @@ Adjust the exact wording to the project. Do not over-format the message.
 - product repo root `./repo/run_tests.sh` when required by the project contract
 - runtime/Docker files when relevant, wired honestly for later verification
 - database/bootstrap/seed path when the product will require seeded data or persistent storage
-- README baseline with project type, stack, startup/access, verification, auth/no-auth, seeded/empty-state note, and repo layout
+- README baseline with project type near the top, stack, primary startup/access command, legacy `docker-compose up` compatibility string where applicable, verification method, auth/no-auth, seeded/empty-state note, mock/local/debug disclosures, known limitations, and repo layout
 - no committed secrets, `.env`, `.env.example`, hidden host setup, no-op tests, or fake-success integration paths
 
 ## Scaffold Should Not Deliver

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

@@ -39,7 +39,8 @@ Packaging must reject or remove stale workflow notes and scratch execution artif
 
 ## Packaging Checks
 
-- Confirm README, scripts, config, routes, docs, tests, and runtime instructions agree.
+- Confirm README, scripts, config, routes, docs, tests, browser/API manual evidence, and runtime instructions agree.
+- Confirm every README-listed demo credential, role, seeded value, documented example, and expected default state was verified in the final runtime/browser/API pass or explicitly risk-accepted by the user.
 - Confirm kept evaluation reports remain immutable evidence under `.tmp`, and that failed/stale/superseded reports are archived unchanged outside final `.tmp`.
 - Confirm Claude/session handoff artifacts are outside the product package path.
 - Confirm task-root rulebooks/settings are stripped from the final submission package when the packaging flow requires a product-only handoff.
@@ -55,7 +56,9 @@ Packaging must reject or remove stale workflow notes and scratch execution artif
 ## Final Runtime And Test Confirmation
 
 - Phase 7 owns the final Docker/runtime confirmation and dockerized broad `./repo/run_tests.sh` confirmation when those commands are part of the delivered contract or when late fixes/packaging changes could affect runtime/test behavior.
+- Phase 7 also owns final browser/API manual confirmation when late fixes, README edits, cleanup, package boundary changes, or seed/config changes could affect user-visible behavior or documented seeded values.
 - If `./repo/README.md` documents `docker compose up --build` or `./repo/run_tests.sh`, treat those as package contract commands, not aspirational notes.
+- If `./repo/README.md` documents demo accounts, roles, seeded data, example IDs, default statuses, or verification flows, treat those as package contract values that must be exercised through `agent-browser` or API/platform-equivalent checks before closure.
 - Fix owner-side Docker/config/wrapper/README/docs/light-script glue directly when safe; route real product-code or test-file defects back through the appropriate developer fix lane before packaging closes.
 - Never imply unrun Docker, runtime, browser, native/platform, or broad test commands passed.
 - End Docker verification with project-specific cleanup unless the user explicitly wants containers left running.
@@ -99,6 +102,7 @@ Phase 7 can close only when:
 - final package structure satisfies the allowlist;
 - stale visible execution artifacts are absent;
 - README, docs, scripts, config, routes, tests, audit artifacts, and repo behavior no longer contradict one another;
+- README-listed credentials, roles, seeded values, examples, default states, and verification flows have been exercised or explicitly risk-accepted;
 - runtime/test/package commands that were required have run or are explicitly risk-accepted by the user;
 - `.tmp` contains the final kept report set and no stale superseded reports;
 - session exports are complete and outside the package root;

package/assets/slopmachine/exact-readme-template.md

@@ -215,10 +215,10 @@ Expected result:
 If `init_db.sh` is part of the standard test bootstrap, document that relationship clearly.
 
 ### Local verification harness
-- Document the separate local verification command(s) used for ordinary development and readiness checks.
+- Document the separate local verification command(s) used for ordinary development and readiness checks only if they do not become required reviewer setup.
 - Make clear that these local verification commands are distinct from the dockerized `./repo/run_tests.sh` broad test path.
 - Use the real stack-native local suite for the chosen language/framework where applicable, for example Vitest, Jest, PHPUnit, pytest, go test, cargo test, or another framework-native equivalent.
-- If that local suite needs machine-level installation or setup, document that clearly in the local verification notes.
+- Do not require reviewers to run manual installs or machine-level setup for the standard packaged verification path.
 
 ### Test entry points
 - Unit tests: `[command/path]`

package/assets/slopmachine/owner-verification-checklist.md

@@ -18,7 +18,7 @@ Reject only for material defects that would mislead development, evaluation, or
 - [ ] `../.ai/plan.md` captures owner-private workstreams, module slices, tests, runtime rules, security obligations, and packaging checks.
 - [ ] `../.ai/plan.md` contains a no-orphan ledger mapping every accepted requirement, clarification, design trace row, API route, actor path, data object, security boundary, report/export/notification, and documentation obligation to a module/workstream and proof path.
 - [ ] `../.ai/plan.md` defines scaffold first, ordered module packets, owned files/tests, shared-file boundaries, FE<->BE/API proof, verification commands, completion checklist, and development-exit proof.
-- [ ] `../.ai/test-coverage.md` exists when meaningful coverage mapping is applicable and maps requirements/risks/API endpoints/frontend flows to planned tests, assertions, current status, and gaps.
+- [ ] `../.ai/test-coverage.md` exists when meaningful coverage mapping is applicable and maps requirements/risks/API endpoints/frontend flows to planned tests, assertions, current status, and gaps, including true no-mock HTTP/API classification and frontend unit-test detectability where applicable.
 - [ ] Private plan slices can be translated into normal developer prompts.
 - [ ] Developer prompts do not ask workers to read private workflow files.
 
@@ -32,6 +32,7 @@ Reject only for material defects that would mislead development, evaluation, or
 - [ ] A separate stack-native local harness exists for development/Phase 4, or the missing harness is explicitly user risk-accepted.
 - [ ] Tests prove behavior and side effects, not only route existence, component existence, mocked client returns, or status codes detached from state/artifact effects.
 - [ ] Fullstack/backend-backed frontend flows have real FE<->BE proof, not only separate backend and frontend tests.
+- [ ] Web/fullstack frontend unit tests are directly detectable and import/render real frontend components/modules.
 
 ## Development Completion
 
@@ -43,7 +44,7 @@ Reject only for material defects that would mislead development, evaluation, or
 ## Phase 4 And Phase 5
 
 - [ ] Phase 4 runs all available relevant tests except broad commands that require explicit user approval, asks the bugfix lane for verification guidance where useful, manually exercises relevant runtime/account surfaces, runs internal owner self-test cycles for issue discovery, and routes issues back to the bugfix lane.
-- [ ] Every provided seeded/demo account and every relevant role/state has been exercised or the unverified surface is explicitly user risk-accepted.
+- [ ] Every provided seeded/demo account, README-listed seeded value, example ID/status, and every relevant role/state has been exercised or the unverified surface is explicitly user risk-accepted.
 - [ ] Phase 5 uses fresh evaluator sessions for full self-test audits, evaluator subagent only, full prompt packets verbatim, no rerun footer, immutable reports, one bugfix/fix-check lane for issues from both final self-test audits, and same-evaluator scoped fix-check only for kept Partial Pass reports.
 - [ ] Every evaluator finding and recommendation is fixed and verified or explicitly risk-accepted by the user before Phase 5 closes.
 - [ ] Coverage/README/final reconciliation uses a dedicated developer session after Phase 5 findings.
@@ -52,7 +53,7 @@ Reject only for material defects that would mislead development, evaluation, or
 
 - [ ] Final runtime verification has run before packaging, or the unrun surface is explicitly risk-accepted.
 - [ ] `./repo/run_tests.sh` has run where applicable before packaging, or the unrun surface is explicitly risk-accepted.
-- [ ] `agent-browser` manual functionality verification has run for browser-accessible UI before packaging, or the unrun surface is explicitly risk-accepted.
+- [ ] `agent-browser` manual functionality verification has run through core prompt requirements, main user journeys, README-listed seeded values, demo credentials, and role/state behavior for browser-accessible UI before packaging, or the unrun surface is explicitly risk-accepted.
 - [ ] D1-D9 readiness categories are pass, not applicable, or explicitly risk-accepted.
 - [ ] Final docs, reports, repo state, and package-root expectations agree.
 
@@ -60,7 +61,7 @@ Reject only for material defects that would mislead development, evaluation, or
 
 - [ ] Final package root and docs allowlist are correct.
 - [ ] Workflow-private artifacts stay outside the product package.
-- [ ] README, scripts, config, tests, and runtime instructions agree.
+- [ ] README, scripts, config, tests, runtime instructions, browser/API manual evidence, and seeded/demo values agree.
 - [ ] Stale workflow notes and scratch execution artifacts are absent from final package.
 - [ ] `.tmp` contains final kept audit/fix-check/coverage reports only, with stale failed/superseded reports archived outside the package.
 - [ ] `repo/docker-compose.yml`, `repo/run_tests.sh`, and `repo/init_db.sh` where applicable match README claims.

package/assets/slopmachine/phase-1-design-prompt.md

@@ -23,7 +23,8 @@ The design must:
 - preserve the original business goal and required user outcomes
 - incorporate accepted clarifications and requirements without narrowing them
 - identify the project type, stack, actors, roles, main flows, modules, data, UI/API surfaces, security boundaries, assumptions, and verification strategy
-- define the testing contract as part of the visible design: every API/interface endpoint must have positive and negative tests, unit coverage must target 90%+ for meaningful business logic, and user-facing applications must include full E2E/platform coverage for the main user journeys unless a surface is genuinely not applicable
+- define the testing contract as part of the visible design: every API/interface endpoint must have positive and negative true HTTP/API tests where a runtime endpoint exists, unit coverage must target 90%+ for meaningful business logic, frontend unit tests must be identifiable and must import/render real frontend components where a frontend exists, fullstack/web apps must prove frontend-to-backend behavior, and user-facing applications must include full E2E/platform coverage for the main user journeys unless a surface is genuinely not applicable
+- define README/runtime obligations that satisfy strict review: project type near the top, `docker compose up --build` as the primary startup command for container-supported deliveries, the legacy compatibility string `docker-compose up` without making it primary, access URL/port or platform launch method, verification method, auth/demo credentials for every role or the exact statement `No authentication required`, seeded data or empty-state statement, no manual runtime installs, no hidden `.env` dependency, mock/local/debug disclosures, and known limitations
 - make meaningful assumptions explicit
 - mark unresolved items only when a real decision is still needed
 - identify API/interface surfaces that should be captured in `./docs/api-spec.md`

package/assets/slopmachine/phase-1-design-template.md

@@ -88,6 +88,8 @@ Cover where relevant: authentication, route authorization, object authorization,
 - Configuration model:
 - Persistent storage:
 - Seed/demo data need:
+- README startup/access expectation:
+- README auth/seed expectation:
 - Background jobs or scheduled work:
 - External integrations:
 
@@ -96,8 +98,10 @@ Cover where relevant: authentication, route authorization, object authorization,
 This is a design-level strategy, not an execution checklist.
 
 Required testing contract:
-- All API/interface endpoints must have test coverage for successful behavior and important negative/error cases. If there is no API/interface surface, state `Not Applicable` with the reason.
+- All API/interface endpoints must have true HTTP/API test coverage for successful behavior and important negative/error cases where a runtime endpoint exists. If a non-HTTP interface or accepted exception requires another proof layer, state the exception and replacement proof. If there is no API/interface surface, state `Not Applicable` with the reason.
 - Meaningful business logic must target 90%+ unit coverage. If a component cannot be unit-tested meaningfully, state the exception and the replacement proof layer.
+- Frontend unit tests must be identifiable by file pattern/framework evidence and must import or render real frontend components/modules when a frontend exists.
+- Fullstack or backend-backed frontend work must include proof that real frontend actions reach the intended backend/service behavior.
 - User-facing applications must have full E2E/platform coverage for the main user journeys, including success, validation/failure, and recovery states. If E2E/platform testing is not applicable, state why and what proof replaces it.
 
 | Surface / risk | Expected proof layer | Notes |
@@ -107,10 +111,24 @@ Required testing contract:
 | security boundaries |  |  |
 | API/interface behavior | endpoint tests for every endpoint, including positive and negative cases |  |
 | UI states / interactions |  |  |
-| integration paths |  |  |
+| frontend-to-backend integration paths |  |  |
 | unit coverage | 90%+ meaningful business-logic coverage |  |
+| frontend unit/component tests | identifiable tests importing/rendering real components/modules |  |
 | E2E/platform journeys | full main-journey coverage for user-facing apps |  |
 
+## 11.1 README / Runtime Gate Strategy
+
+| README/runtime gate | Required design outcome |
+|---|---|
+| project type | `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop` near the top of README |
+| startup | primary `docker compose up --build` for container-supported deliveries; include legacy compatibility string `docker-compose up` without making it primary |
+| access | URL + port, emulator/device steps, or desktop launch steps |
+| verification | concrete API/UI/mobile/desktop verification method |
+| environment | Docker-contained or platform-contained setup; no manual runtime installs, manual DB setup, hidden `.env`, or secret-bearing examples |
+| auth | all demo credentials and roles, or exact `No authentication required` statement |
+| seed/demo data | seeded values and how to exercise them, or an empty-state statement |
+| mock/local/debug | truthful disclosure of mock, stub, local-data, or debug boundaries |
+
 ## 12. API Spec Handoff
 
 - API spec required: [yes/no]

package/assets/slopmachine/phase-2-execution-planning-prompt.md

@@ -37,11 +37,11 @@ Create a practical implementation plan that can be translated into concise imple
 - Security work needs negative proof where relevant.
 - README/runtime/test obligations must be assigned.
 - Maintain a no-orphan ledger so no accepted requirement, clarification, API/interface, data object, actor path, security boundary, report/export/notification, README obligation, or test obligation disappears between design and implementation.
-- Include an API coverage matrix when APIs exist: endpoint/interface, expected implementation owner, true HTTP/API proof, mocked or unit-only exceptions, negative cases, and exact proof expectation.
+- Include an API coverage matrix when APIs exist: exact `METHOD + PATH` or interface, expected implementation owner, true no-mock HTTP/API proof where applicable, mocked or unit-only exceptions, negative cases, and exact proof expectation.
 - Include a FE-BE integration matrix for fullstack/backend-backed frontend work: frontend action, backend endpoint/service/job, payload/state input, response/side effect, UI states, and proof path.
 - Include a backend-to-frontend exposure check when backend capabilities exist: every prompt-relevant backend capability must have visible exposure or a specific accepted internal/API-only reason.
-- Include README/runtime gates: project type, startup/access, verification, auth/no-auth, seeded/empty-state, configuration/no-secret handling, test commands, known limitations, and mock/local-data disclosures.
-- Include coverage rigor: unit, API/interface, integration, E2E/platform, frontend component/state, security/negative, and final local verification expectations.
+- Include README/runtime gates that match the strict README audit: project type near the top, primary `docker compose up --build` for container-supported deliveries, legacy compatibility string `docker-compose up` without making it primary, startup/access, verification, auth/no-auth, all demo credentials/roles when auth exists, seeded values or empty-state statement, configuration/no-secret handling, no manual runtime installs or manual DB setup, test commands, known limitations, and mock/local-data/debug disclosures.
+- Include coverage rigor: 90%+ unit target for meaningful business logic, exact true no-mock HTTP/API endpoint tests, identifiable frontend unit tests that import/render real components/modules, fullstack FE-BE proof, E2E/platform proof, security/negative cases, and final local verification expectations.
 - Include module acceptance checks that prevent shell/demo completion: observable behavior, persisted state/artifact or UI/API outcome, relevant negative paths, tests, README impact, and integration evidence.
 
 ## Output Requirements

package/assets/slopmachine/phase-2-plan-template.md

@@ -68,6 +68,8 @@ If APIs exist, every accepted endpoint/interface must have a row.
 |---|---|---|---|---|---|---|
 |  |  |  | yes/no |  |  |  |
 
+True HTTP/API proof means a test sends a request to the exact runtime route/interface and reaches the real handler/business logic without mocking transport, controllers, services, or providers used in the execution path. If this is not possible or not applicable, record the accepted exception and replacement proof.
+
 ## 7. Frontend / Interaction Execution Plan
 
 If not applicable, state `Not Applicable` with the accepted reason.
@@ -76,6 +78,8 @@ If not applicable, state `Not Applicable` with the accepted reason.
 |---|---|---|---|---|
 |  |  | loading / empty / submitting / disabled / success / error |  |  |
 
+Frontend unit tests must be directly detectable by the final audit: test files must use the project test framework and import or render actual frontend components/modules, not only backend utilities or package scripts.
+
 ## 7.1 FE-BE Integration Matrix
 
 Required for fullstack or backend-backed frontend work. If not applicable, state `Not Applicable` with the accepted reason.
@@ -101,11 +105,12 @@ Required when backend capabilities exist. If not applicable, state `Not Applicab
 ## 9. README / Runtime / Configuration Plan
 
 - README obligations:
-- Startup/access documentation:
+- Startup/access documentation, including primary `docker compose up --build` where container-supported and legacy compatibility string `docker-compose up` without making it primary:
 - Test documentation:
-- Auth/no-auth documentation:
-- Seed/demo data documentation:
-- Config and no-secret handling:
+- Auth/no-auth documentation, including all demo credentials and roles when auth exists or exact `No authentication required` statement:
+- Seed/demo data documentation, including every seeded value the reviewer should be able to exercise or an empty-state statement:
+- Config and no-secret handling, including no hidden `.env` dependency and no secret-bearing examples:
+- Environment constraints, including no manual runtime installs or manual DB setup for packaged verification:
 - Known limitations documentation:
 
 ## 9.1 README Gate Matrix
@@ -113,13 +118,13 @@ Required when backend capabilities exist. If not applicable, state `Not Applicab
 | README requirement | Expected content | Owning work package | Proof / review point |
 |---|---|---|---|
 | project type near top |  |  |  |
-| startup command |  |  |  |
+| startup command | primary `docker compose up --build` where applicable, plus legacy compatibility string `docker-compose up` not presented as primary |  |  |
 | access method |  |  |  |
 | verification method |  |  |  |
 | broad test command |  |  |  |
 | auth credentials or no-auth statement |  |  |  |
 | seeded data or empty-state statement |  |  |  |
-| configuration / no secrets / no env-file dependency |  |  |  |
+| configuration / no secrets / no env-file dependency / no manual installs |  |  |  |
 | mock/local-data/debug disclosure |  |  |  |
 | known limitations |  |  |  |
 
@@ -147,6 +152,8 @@ Required when backend capabilities exist. If not applicable, state `Not Applicab
 - Integration coverage expectation:
 - E2E/platform coverage expectation:
 - Frontend state/component coverage expectation:
+- Final browser/manual core-flow expectation:
+- README seeded-value/account verification expectation:
 - Known accepted exceptions:
 
 ## 11. Integration And Hardening Plan

package/assets/slopmachine/templates/AGENTS.md

@@ -42,6 +42,7 @@ This file contains product engineering rules for the current project.
 - Use `unit_tests/` for unit tests and `API_tests/` for API/integration HTTP tests when those surfaces exist.
 - Every implementation change should include tests for the behavior it owns. Target full meaningful coverage across unit, API/integration, and E2E/platform layers where those surfaces exist.
 - API/interface endpoints should have real positive and negative tests for exact behavior. User-facing flows should have E2E/platform coverage for the main journeys and important failure/recovery states.
+- API/interface tests should hit the real route/interface and real business logic without mocking transport/controllers/execution-path services unless there is a documented exception. Frontend unit tests should import or render real components/modules so coverage is directly reviewable.
 - Prefer the fastest meaningful targeted checks during ordinary implementation.
 - Never claim a command passed unless you actually ran it and saw the result.
 - If required verification cannot run in the current environment, report it as unverified with the exact risk.

package/assets/slopmachine/templates/CLAUDE.md

@@ -42,6 +42,7 @@ This file contains product engineering rules for the current project.
 - Use `unit_tests/` for unit tests and `API_tests/` for API/integration HTTP tests when those surfaces exist.
 - Every implementation change should include tests for the behavior it owns. Target full meaningful coverage across unit, API/integration, and E2E/platform layers where those surfaces exist.
 - API/interface endpoints should have real positive and negative tests for exact behavior. User-facing flows should have E2E/platform coverage for the main journeys and important failure/recovery states.
+- API/interface tests should hit the real route/interface and real business logic without mocking transport/controllers/execution-path services unless there is a documented exception. Frontend unit tests should import or render real components/modules so coverage is directly reviewable.
 - Prefer the fastest meaningful targeted checks during ordinary implementation.
 - Never claim a command passed unless you actually ran it and saw the result.
 - If required verification cannot run in the current environment, report it as unverified with the exact risk.

package/package.json

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