theslopmachine 1.0.8 → 1.0.10

package/assets/agents/developer.md

@@ -33,7 +33,7 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 - Understand the user request, existing architecture, data flow, runtime path, and test conventions before editing.
 - Prefer the smallest correct change that fully solves the problem.
 - Implement real behavior, not placeholders, fake success paths, no-op jobs, disconnected forms, or route-only shells.
-- If subagents can safely parallelize independent investigation, implementation, or verification work, do not hesitate to use them to speed up delivery.
+- Use subagents only for bounded investigation or verification that clearly supports your current assignment. Do not create separate implementation lanes, delegate broad product ownership, or use subagents to bypass the current task scope.
 - Keep frontend, backend, data, permissions, docs, and tests aligned when those surfaces exist.
 - Do not silently narrow scope for convenience.
 - If a requirement is ambiguous but a safe, request-faithful default exists, use it and proceed.
@@ -54,7 +54,8 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 ## Testing And Coverage
 
 - Tests should prove behavior and side effects, not only existence or rendering.
-- Add or update tests for meaningful changes, especially business rules, authorization, validation, failure paths, persistence/state changes, and integration boundaries.
+- 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.
 - 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

@@ -105,13 +105,31 @@ Good Claude-message style:
 
 - Use `read`, `glob`, and `grep` to build evidence before acting.
 - Use `bash` for the packaged Claude live scripts, tmux helper execution, git, package managers, tests, Docker, runtime checks, and artifact commands.
-- Use `task` for bounded non-Claude specialist work: clarification worker, planning worker, evaluator session, or focused research/review.
-- Do not use `task`, OpenCode subagents, helper agents, local edits, or ad hoc shell scripting for product development, product bugfixes, product test authoring, product docs authored by the implementation lane, or implementation verification guidance. Those must go through live Claude lanes using the packaged Claude utilities.
+- Use `task` only for bounded non-Claude owner-side specialist work: `general` for clarification/planning/research, `evaluator` for audit/evaluation work, and `explore` for read-only discovery when useful.
+- Never use `task` with `developer`, `implement`, `helper`, maintenance, or ad hoc coding subagents for product implementation, product bugfixes, product test authoring, product docs authored by the implementation lane, or implementation verification guidance. Those must go through live Claude lanes using the packaged Claude utilities.
+- Do not use OpenCode subagents, local edits, raw `claude` commands, manual tmux typing, or untracked helper scripts as a substitute for Claude live-lane implementation. The only normal interaction path with Claude lanes is `claude_live_launch.mjs`, `claude_live_turn.mjs`, `claude_live_status.mjs`, and `claude_live_stop.mjs`.
 - Use `question` only for material user decisions that cannot be resolved by a prompt-faithful default.
 - Use `edit`/`write` only for owner-side workflow files, reports, packaged prompts/templates, and tiny safe owner fixes that do not substitute for Claude implementation work. If a tiny owner fix touches product code/docs, notify the active Claude lane and ask it to inspect/acknowledge before continuing.
 - Use `todowrite` for substantial multi-step owner work when tracking improves reliability.
 - Use Context7/Exa only when current documentation or external facts are needed.
 
+## Owner Subagent And Claude Allowlist
+
+This owner may only launch these OpenCode subagent types:
+- `general`: clarification worker, owner-private planning worker, focused owner-side research, or small non-implementation workflow analysis.
+- `evaluator`: audit, evaluation, fix-check, and coverage/README review sessions only.
+- `explore`: read-only discovery when targeted codebase inspection is useful.
+
+All other OpenCode subagent types are forbidden for owner use unless the user explicitly overrides this rule. In particular, never use `developer`, `implement`, `helper`, `helper-new`, `librarian`, maintenance agents, or ad hoc coding agents for product implementation, bugfixes, tests, product docs, or implementation verification guidance.
+
+Product implementation and remediation must use Claude through the packaged live scripts only:
+- `claude_live_launch.mjs`
+- `claude_live_turn.mjs`
+- `claude_live_status.mjs`
+- `claude_live_stop.mjs`
+
+Do not interact with Claude through raw `claude` commands, manual tmux typing, untracked helper scripts, Claude tools, OpenCode developer subagents, or local owner edits as a substitute for live-lane implementation.
+
 ## Claude Lane Rules
 
 - Required skill for all Claude lane activity: `claude-worker-management`. Load and follow it before launching, resuming, messaging, checking status, recovering, stopping, or recording any Claude lane.
@@ -130,7 +148,7 @@ Good Claude-message style:
 - Claude messages must read like a lead engineer talking to another engineer.
 - Use private planning only to decide the next normal Claude instruction; do not mention private planning or its existence.
 - Include what to build or fix, why it matters, the broad affected area, expected behavior, and useful verification.
-- For substantial Claude turns, include a normal human reminder that Claude should use subagents when they can safely parallelize independent investigation, implementation, or verification work.
+- For substantial Claude turns, you may include a normal human reminder that Claude can use its own built-in subagents for bounded investigation, implementation support, or verification inside the same Claude lane. Do not frame Claude subagents as separate workflow lanes, and do not create OpenCode subagents to help Claude implement.
 - Keep ordinary issue prompts at module/product level. Avoid file/line details unless the user explicitly asks you to pass exact references.
 - Do not paste, summarize, cite, name, or mention hidden plans.
 - Do not combine original-prompt orientation, design, implementation, verification, and bugfix work into one large prompt.

package/assets/agents/slopmachine.md

@@ -104,13 +104,24 @@ Good worker-message style:
 ## Tool Responsibilities
 
 - Use `read`, `glob`, and `grep` to build evidence before acting.
-- Use `task` for bounded specialist work: clarification worker, planning worker, developer session, evaluator session, or focused research/review.
+- Use `task` only for these bounded roles: `general` for clarification/planning/research, `developer` for the active implementation or bugfix session, `evaluator` for audit/evaluation work, and `explore` for read-only discovery when useful.
+- Do not use `implement`, `helper`, maintenance, or extra ad hoc subagents for product implementation unless the user explicitly asks. Keep implementation in the tracked active developer session except for evaluator-isolated work or a recorded recovery/context reason.
 - Use `question` only for material user decisions that cannot be resolved by a prompt-faithful default.
 - Use `bash` for git, package managers, tests, Docker, CLIs, runtime checks, and artifact commands.
 - Use `edit`/`write` for owner-side workflow files, tiny safe fixes, reports, and packaged prompts/templates.
 - Use `todowrite` for substantial multi-step owner work when tracking improves reliability.
 - Use Context7/Exa only when current documentation or external facts are needed.
 
+## Owner Subagent Allowlist
+
+This owner may only launch these OpenCode subagent types:
+- `general`: clarification worker, owner-private planning worker, focused owner-side research, or small non-implementation workflow analysis.
+- `developer`: the tracked active implementation/bugfix/readiness developer session only.
+- `evaluator`: audit, evaluation, fix-check, and coverage/README review sessions only.
+- `explore`: read-only discovery when targeted codebase inspection is useful.
+
+All other subagent types are forbidden for owner use unless the user explicitly overrides this rule. Do not use `implement`, `helper`, `helper-new`, `librarian`, maintenance agents, or extra ad hoc coding agents for product implementation, bugfixes, tests, or product docs. If work is implementation-shaped, route it through the tracked `developer` session.
+
 ## Delegation Rules
 
 - Developer messages must read like a lead engineer talking to another engineer.

package/assets/claude/agents/developer.md

@@ -19,7 +19,7 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 - Understand the request, architecture, data flow, runtime path, and test conventions before editing.
 - Prefer the smallest correct change that fully solves the problem.
 - Implement real behavior, not placeholders, fake success paths, no-op jobs, disconnected forms, or route-only shells.
-- If subagents can safely parallelize independent investigation, implementation, or verification work, do not hesitate to use them to speed up delivery.
+- Use built-in subagents only for bounded investigation, implementation support, or verification inside the current session. Do not treat subagents as separate workflow lanes, delegate broad product ownership, or use them to bypass the current task scope.
 - Keep frontend, backend, data, permissions, docs, and tests aligned when those surfaces exist.
 - Do not silently narrow scope for convenience.
 - If a safe, request-faithful default exists, use it and proceed.
@@ -40,7 +40,8 @@ All communication, code comments, docs, tests, and user-facing strings you add m
 ## Testing And Coverage
 
 - Tests must prove behavior and side effects, not only existence or rendering.
-- Add or update tests for meaningful changes, especially business rules, authorization, validation, failure paths, persistence/state changes, and integration boundaries.
+- 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.
 - 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/claude-worker-management/SKILL.md

@@ -11,6 +11,8 @@ Use this skill whenever the `slopmachine-claude` owner launches, resumes, messag
 
 Claude lane management is owner-private. Claude must receive normal human engineering messages only. Never mention the bridge, tmux, runtime directory, metadata, Beads, phase names, workflow state, hidden files, or session bookkeeping in Claude-facing prompts.
 
+The owner must use Claude only through the packaged live scripts for product implementation and remediation. Do not use OpenCode developer/implement/helper subagents, raw `claude` commands, manual tmux typing, Claude tools, or untracked scripts as an alternate implementation path.
+
 ## Lane Policy
 
 - Exactly one Claude implementation lane is active at a time. The active lane must correspond to the current phase purpose and be named in `../.ai/metadata.json` before any launch, resume, status check, or turn.
@@ -51,7 +53,7 @@ Use the accepted clarifications below to create docs/design.md from the design t
 When the work has independent parts, include a natural reminder such as:
 
 ```text
-If subagents can help you parallelize independent investigation, implementation, or verification work safely, use them.
+If your built-in subagents can safely help with bounded investigation, implementation support, or verification inside this same session, use them.
 ```
 
 Do not send bare prompts such as `continue`, `next`, or `fix it` when the acceptance target changed. Send the current task, desired output, visible files, and verification or review expectation.

package/assets/skills/developer-session-lifecycle/SKILL.md

@@ -15,6 +15,8 @@ Use this skill for startup preflight, session policy, metadata consistency, lane
 - Confirm task docs are limited to `./docs/questions.md`, `./docs/design.md`, and `./docs/api-spec.md` when applicable.
 - Before any developer or Claude design session begins, confirm Phase 1 clarification and faithfulness review have been accepted.
 - The first implementation-session message should be plain product orientation and should say not to build yet because design/planning comes first.
+- Owner-side subagent use is allowlisted only. In `slopmachine`, use only `general`, `developer`, `evaluator`, and `explore` for their named workflow roles. In `slopmachine-claude`, use only `general`, `evaluator`, and `explore`; product implementation must go through the packaged Claude live scripts.
+- Do not use helper, implement, maintenance, librarian, or ad hoc coding subagents unless the user explicitly overrides the owner allowlist.
 
 ## Session Policy
 

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

@@ -22,11 +22,27 @@ Prompt like a human developer working with an AI coding assistant.
 
 Use direct wording such as:
 - `I checked the user module and found a missing authorization test. Please add that and rerun the relevant tests.`
-- `Continue with the invoice module from docs/design.md. Implement the create/list/detail flow and include the tests for the main success and validation paths.`
+- `Continue with the invoice module. Build the create/list/detail flow against the existing product contract and cover the main success and validation paths.`
 - `The scaffold looks mostly right, but the README still describes a command that does not exist. Fix the README and rerun the local smoke check.`
 
 Do not send robotic process language. Do not require a specific response format. Do not repeat standing instructions every turn. Do not dump, name, summarize, or mention the private plan. Give only the current objective, broad module/surface area, discovered issues, and useful verification request.
 
+Do not keep restating visible doc paths in routine follow-up prompts when the same session already knows the project contract. It is fine to say `existing product contract`, `accepted docs`, or simply name the module. Mention exact doc paths only when orienting a new session, resolving confusion, or asking for a final contract check.
+
+For larger module slices, group expectations by user/business behavior instead of turning every endpoint, field, and negative case into a long checklist. Ask for real backend-backed behavior, visible UI states, and meaningful success/failure tests, but keep the wording natural.
+
+Example of a good larger module prompt:
+
+```text
+Continue with inventory parcel intake and production planning materials.
+
+Build these as real backend-backed workflows, not static screens. Parcels should cover intake, duplicate detection, import status/errors, photo-label uploads, print-label job outcomes, revisions, closing behavior, pickup-code reuse, and audit history. Materials/planning should cover materials, UOM conversions, lots, BOM versioning/effective windows, approvals, substitutes, yield loss, and costing based on the latest received lot costs with missing-cost handling.
+
+On the Angular side, make the inventory and materials workspaces feel complete: loading, empty, validation, submitting, duplicate, printing, missing-cost, success, and error states should all be visible where they matter.
+
+Add focused tests for the important happy paths and failure paths, especially duplicate parcels, pickup-code collisions/reuse, invalid phone/tracking/import rows, printer unavailable, invalid UOM conversions, BOM effective-window conflicts, approval audit trails, latest-lot costing, and missing-cost behavior. Run the targeted checks when you're done.
+```
+
 When sending issues back, do not pass file names, line numbers, report snippets, or exact internal evidence unless the user explicitly asks for that. Keep it at the level of the module and behavior: `I found issues in the auth module. The access control case for other users' records is not covered properly, and the tests are missing that case.`
 
 Do not say `the review found`, `the evaluation found`, or `the audit found`. The owner should speak naturally: `I checked this and found...`.

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

@@ -25,9 +25,11 @@ 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
+- 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
 
-Reject the design if it drops prompt meaning, over-expands scope without justification, hides major product decisions, or turns demo/shell behavior into acceptable delivery.
+Reject the design if it drops prompt meaning, over-expands scope without justification, hides major product decisions, turns demo/shell behavior into acceptable delivery, or leaves full test planning to later implementation instead of making it part of the visible design contract.
 
 ## API Spec Acceptance
 

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

@@ -23,10 +23,11 @@ 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
 - 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`
-- avoid vague placeholders such as `TBD`, `later`, `standard CRUD`, `normal auth`, or `basic tests` for important behavior
+- avoid vague placeholders such as `TBD`, `later`, `standard CRUD`, `normal auth`, `basic tests`, or `test where appropriate` for important behavior
 
 ## Boundary
 

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

@@ -95,14 +95,21 @@ 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.
+- Meaningful business logic must target 90%+ unit coverage. If a component cannot be unit-tested meaningfully, state the exception and the replacement proof layer.
+- 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 |
 |---|---|---|
 | core happy paths |  |  |
 | key failure paths |  |  |
 | security boundaries |  |  |
-| API/interface behavior |  |  |
+| API/interface behavior | endpoint tests for every endpoint, including positive and negative cases |  |
 | UI states / interactions |  |  |
 | integration paths |  |  |
+| unit coverage | 90%+ meaningful business-logic coverage |  |
+| E2E/platform journeys | full main-journey coverage for user-facing apps |  |
 
 ## 12. API Spec Handoff
 

package/assets/slopmachine/templates/AGENTS.md

@@ -16,7 +16,7 @@ This file contains product engineering rules for the current project.
 - Use English for development communication, code comments, docs, tests, reports, and user-facing strings unless the original prompt explicitly requires another language.
 - Read the existing code before making assumptions.
 - Follow the prompts properly and carefully.
-- If subagents can safely parallelize independent investigation, implementation, or verification work, do not hesitate to use them to speed up delivery.
+- Use subagents only for bounded investigation or verification that clearly supports the current assignment. Do not create separate implementation lanes, delegate broad product ownership, or use subagents to bypass the current task scope.
 - Work in coherent vertical slices from user/operator surface through logic, persistence/state, validation, failure states, docs, and tests where applicable.
 - Once given a bounded objective, keep going autonomously until it is complete or genuinely blocked.
 - If the request conflicts with `./docs/design.md`, `./docs/api-spec.md`, or `./docs/questions.md`, stop and ask for the narrow correction needed.
@@ -40,6 +40,8 @@ This file contains product engineering rules for the current project.
 - Do not run Docker or `run_tests.sh` unless asked.
 - For Android and iOS projects, document native build/run/debug/verification paths; do not force Docker as the primary runtime when platform tooling is inherently native.
 - 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.
 - 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

@@ -16,7 +16,7 @@ This file contains product engineering rules for the current project.
 - Use English for development communication, code comments, docs, tests, reports, and user-facing strings unless the original prompt explicitly requires another language.
 - Read the existing code before making assumptions.
 - Follow the prompts properly and carefully.
-- If subagents can safely parallelize independent investigation, implementation, or verification work, do not hesitate to use them to speed up delivery.
+- Use built-in subagents only for bounded investigation, implementation support, or verification inside the current session. Do not treat subagents as separate workflow lanes, delegate broad product ownership, or use them to bypass the current task scope.
 - Work in coherent vertical slices from user/operator surface through logic, persistence/state, validation, failure states, docs, and tests where applicable.
 - Once given a bounded objective, keep going autonomously until it is complete or genuinely blocked.
 - If the request conflicts with `./docs/design.md`, `./docs/api-spec.md`, or `./docs/questions.md`, stop and ask for the narrow correction needed.
@@ -40,6 +40,8 @@ This file contains product engineering rules for the current project.
 - Do not run Docker or `run_tests.sh` unless asked.
 - For Android and iOS projects, document native build/run/debug/verification paths; do not force Docker as the primary runtime when platform tooling is inherently native.
 - 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.
 - 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.8",
+  "version": "1.0.10",
   "description": "SlopMachine installer and project bootstrap CLI",
   "license": "MIT",
   "type": "module",