theslopmachine 0.4.9 → 0.5.0

package/README.md

@@ -1,234 +1,256 @@
 # theslopmachine
 
-`theslopmachine` is an installer and bootstrap CLI for the SlopMachine OpenCode workflow. It installs the packaged owner/developer agents, required skills, workflow support files, and project bootstrap logic needed to start a new SlopMachine-managed repository.
+`theslopmachine` installs and bootstraps the SlopMachine workflow for OpenCode.
 
-## Features
+It configures:
 
-- installs packaged OpenCode agents into `~/.config/opencode/agents/`
-- installs packaged skills into `~/.agents/skills/`
-- installs packaged workflow support files into `~/slopmachine/`
-- bootstraps a new project workspace with `repo/`, `docs/`, `sessions/`, `metadata.json`, `AGENTS.md`, and initialized `br` state
-- configures required OpenCode plugins and MCP entries without overwriting existing `context7` or `exa` configuration
-
-## Installation
+- the `slopmachine` owner agent
+- the `developer` implementation agent
+- required skills under `~/.agents/skills/`
+- workflow support files under `~/slopmachine/`
+- OpenCode MCP entries for `context7` and `exa`
 
-Requirements:
+## Requirements
 
 - Node.js 18+
 - `git`
-- Docker running on the machine
-- `curl` on Unix-like systems for automatic `br` installation
+- Docker
+- `python3`
+- `opencode`
+- `br` (`beads_rust`)
+
+`slopmachine setup` verifies or installs what it can.
+
+## Install
 
-Build and install the package:
+From this package directory:
 
 ```bash
 npm install
 npm run check
 npm pack
-npm install -g ./theslopmachine-<version>.tgz
+npm install -g ./theslopmachine-0.5.0.tgz
 ```
 
-`package.json` is the package-version source of truth. The packed tarball name and CLI version banner both derive from that version.
-
-For local package development instead of global install:
+For local development instead:
 
 ```bash
 npm link
 ```
 
-The published package is intentionally source-only. It packages only `bin/`, `src/`, `assets/`, `README.md`, `RELEASE.md`, and `MANUAL.md`.
+## Commands
 
-## Setup
+### `slopmachine setup`
 
-Run machine setup:
+Use this once per machine, then rerun any time you want to refresh packaged assets.
 
 ```bash
 slopmachine setup
 ```
 
-`setup` does the following:
+What it does:
 
-- installs `opencode-ai@latest` when missing and refreshes it to `@latest` when already present
-- installs or verifies `br` (`beads_rust`)
-- installs or refreshes packaged agents
-- installs or refreshes packaged skills
-- installs or refreshes packaged workflow files into `~/slopmachine/`
+- verifies or installs `opencode`
+- verifies `br`, `git`, `python3`, and Docker
+- installs packaged agents into `~/.config/opencode/agents/`
+- installs packaged skills into `~/.agents/skills/`
+- installs workflow files into `~/slopmachine/`
 - updates `~/.config/opencode/opencode.json`
-- prompts for missing MCP API keys when needed
+- ensures packaged MCP entries for `context7` and `exa`
+- optionally asks for an upload token if one is not already stored
+
+Notes:
 
-To refresh an existing machine install to the latest published package in one step:
+- existing upload token is preserved and setup skips that prompt when one already exists
+- existing `context7` and `exa` entries are preserved if already configured
+- package-managed assets are refreshed on rerun
+
+### `slopmachine init`
+
+Use this in a new or empty project directory to create a SlopMachine workspace.
 
 ```bash
-slopmachine upgrade
+mkdir my-project
+cd my-project
+slopmachine init
 ```
 
-`slopmachine upgrade` installs `theslopmachine@latest` globally and then runs `slopmachine setup` automatically.
+Or open OpenCode immediately after bootstrap:
 
-If `opencode` was newly installed, open a fresh terminal before running OpenCode commands.
+```bash
+slopmachine init -o
+```
 
-MCP API keys:
+What it creates:
 
-- Context7: `https://context7.com`
-- Exa: `https://exa.ai`
+- `repo/`
+- `docs/`
+- `sessions/`
+- `metadata.json`
+- `.ai/metadata.json`
+- root `.beads/`
+- `repo/AGENTS.md`
 
-Codex login with OpenCode:
+Important details:
 
-```bash
-opencode auth login -p codex
-```
+- `run_id` is created in `.ai/metadata.json`
+- the workspace root is the parent directory containing `repo/`
+- Beads lives in the workspace root, not inside `repo/`
+
+### `slopmachine set-token`
 
-Optional verification:
+Stores the upload token used by `send-data`.
 
 ```bash
-opencode auth list
+slopmachine set-token
 ```
 
-## Startup
+Behavior:
 
-Create and initialize a new project workspace in a new or empty directory:
+- prompts for the plaintext upload token
+- stores it in `~/.config/slopmachine/config.json`
+- replaces an existing token if one is already stored
+- does not validate the token over the network during entry
 
-```bash
-mkdir my-project
-cd my-project
-slopmachine init
-```
+### `slopmachine send-data <owner-session-id>`
 
-Or initialize and open OpenCode immediately:
+Exports workflow artifacts and uploads them to the configured Supabase endpoint.
 
 ```bash
-mkdir my-project
-cd my-project
-slopmachine init -o
+slopmachine send-data <owner-session-id>
 ```
 
-If you used plain `slopmachine init`, then continue with:
+Supported options:
+
+- `--dry-run`
+- `--yes`
+- `--label <text>`
+- `--project-id <id>`
+- `--output <path>`
+- `--endpoint <url>`
+
+Examples:
 
 ```bash
-cd repo
-opencode
+slopmachine send-data ses_abc123
+slopmachine send-data ses_abc123 --dry-run
+slopmachine send-data ses_abc123 --yes --label sprint-12
+slopmachine send-data ses_abc123 --endpoint "https://<project-ref>.supabase.co/functions/v1/slopmachine-upload"
 ```
 
-Inside OpenCode, select the `slopmachine` agent to start the workflow.
+Where to run it:
 
-Bootstrapped workspace layout:
+- preferred: workspace root
+- also supported: `repo/`
 
-- `repo/` for the working codebase
-- `docs/` for workflow documentation and evidence
-- `sessions/` for exported session artifacts
-- `metadata.json` for project workflow metadata
-- `repo/AGENTS.md` for the repo-local agent instructions
+If run from `repo/`, the command resolves the parent workspace root automatically.
 
-`slopmachine init` creates the initial git commit so the workspace starts from a clean tree.
+What it exports live:
 
-## Testing
+- owner session from the positional `owner-session-id`
+- developer sessions from `.ai/metadata.json`
+- `beads-export.json` from root `.beads/`
 
-Package-level checks:
+What it includes when present:
 
-```bash
-npm run check
-npm pack --dry-run
-```
+- `self-test-run.md`
+- `self-test-fixes.md`
+- `retrospective-<run_id>.md`
+- `improvement-actions-<run_id>.md`
+- `metadata.json`
+- `ai-metadata.json`
+- `manifest.json`
 
-Generated project conventions:
+Fail-fast conditions:
 
-- every bootstrapped project must expose one primary runtime command
-- every bootstrapped project must expose one primary broad test command: `./run_tests.sh`
-- for Dockerized web backend or fullstack projects, the expected broad runtime command is `docker compose up --build`
-- for non-Docker runtime cases, the expected broad runtime command is usually `./run_app.sh`
+- missing owner session id argument
+- missing `.ai/metadata.json`
+- missing `run_id`
+- missing tracked developer session ids
+- owner session export failure
+- developer session export failure
 
-Verification policy:
+Warn-only conditions:
 
-- use local fast verification during normal development
-- treat `./run_tests.sh` as a broad gate, not an ordinary every-step verification command
-- for Dockerized web backend and fullstack projects, scaffold acceptance should establish both `docker compose up --build` and `./run_tests.sh`
+- missing `self-test-run.md`
+- missing `self-test-fixes.md`
+- missing retrospective files
 
-## Architecture
+Output behavior:
 
-Operating model:
+- creates a flat zip archive
+- keeps the local zip by default
+- default zip path:
+  - `~/slopmachine/retrospectives/send-data-<run_id>.zip`
+- shows a preview before upload unless `--yes` is passed
 
-- `slopmachine` is the owner and orchestrator
-- `developer` is the implementation worker
-- detailed workflow behavior is primarily carried by loaded skills rather than one monolithic owner prompt
+## Config Files
 
-High-level lifecycle:
+Machine-level config:
 
-1. `P0 Intake and Setup`
-2. `P1 Clarification`
-3. `P2 Planning`
-4. `P3 Scaffold`
-5. `P4 Development`
-6. `P5 Integrated Verification`
-7. `P6 Hardening`
-8. `P7 Evaluation and Fix Verification`
-9. `P8 Final Human Decision`
-10. `P9 Submission Packaging`
-11. `P10 Retrospective`
+- `~/.config/slopmachine/config.json`
 
-Design constraints:
+Current schema:
 
-- keep the owner shell small and load phase-specific skills when needed
-- prefer targeted reads and focused local verification during implementation
-- keep environment-specific state out of the package
-- do not package local runtime artifacts, caches, editor folders, or generated dependency environments
-
-Database dependency rule:
+```json
+{
+  "upload": {
+    "endpoint": "https://<project-ref>.supabase.co/functions/v1/slopmachine-upload",
+    "token": "sm_u_...",
+    "timeoutMs": 30000
+  }
+}
+```
 
-- database dependencies must be provisioned by initialization scripts, migrations, container startup hooks, or equivalent runtime setup
-- do not hardcode database-specific environment state into packaged assets
-- do not ship database files such as `.db`, `.sqlite`, dumps, or seeded local database artifacts in the package
+OpenCode config managed by setup:
 
-For this package specifically, the installer ships workflow logic and templates only. It does not ship database dependency files or packaged database state.
+- `~/.config/opencode/opencode.json`
 
-## Installed Configuration
+Packaged MCPs managed by setup:
 
-Main locations:
+- `context7`
+- `exa`
 
-- agents: `~/.config/opencode/agents/`
-- skills: `~/.agents/skills/`
-- OpenCode config: `~/.config/opencode/opencode.json`
-- packaged workflow files: `~/slopmachine/`
+## Installed Assets
 
-Installed agents:
+Agents:
 
 - `~/.config/opencode/agents/slopmachine.md`
 - `~/.config/opencode/agents/developer.md`
 
-Installed skills:
-
-- `~/.agents/skills/clarification-gate/`
-- `~/.agents/skills/developer-session-lifecycle/`
-- `~/.agents/skills/final-evaluation-orchestration/`
-- `~/.agents/skills/beads-operations/`
-- `~/.agents/skills/planning-guidance/`
-- `~/.agents/skills/planning-gate/`
-- `~/.agents/skills/scaffold-guidance/`
-- `~/.agents/skills/development-guidance/`
-- `~/.agents/skills/verification-gates/`
-- `~/.agents/skills/integrated-verification/`
-- `~/.agents/skills/hardening-gate/`
-- `~/.agents/skills/evaluation-triage/`
-- `~/.agents/skills/submission-packaging/`
-- `~/.agents/skills/retrospective-analysis/`
-- `~/.agents/skills/owner-evidence-discipline/`
-- `~/.agents/skills/report-output-discipline/`
-- `~/.agents/skills/frontend-design/`
-
-Installed workflow files under `~/slopmachine/`:
-
-- `backend-evaluation-prompt.md`
-- `frontend-evaluation-prompt.md`
-- `templates/AGENTS.md`
-- `workflow-init.js`
-- `utils/strip_session_parent.py`
-- `utils/convert_ai_session.py`
-- `utils/cleanup_delivery_artifacts.py`
-
-OpenCode config entries ensured by `setup`:
-
-- plugin: `oc-chatgpt-multi-auth`
-- MCP server: `chrome-devtools`
-- MCP server: `context7`
-- MCP server: `exa`
-- MCP server: `shadcn` disabled by default
-
-These are the user-editable locations if you want to customize agents, skills, plugins, or MCP configuration after setup.
+Skills:
+
+- installed under `~/.agents/skills/`
+
+Workflow files:
+
+- installed under `~/slopmachine/`
+
+## Verification
+
+Package-level check:
+
+```bash
+npm run check
+```
+
+Basic machine verification:
+
+```bash
+slopmachine --help
+slopmachine set-token
+slopmachine setup
+```
+
+`send-data` verification:
+
+```bash
+slopmachine send-data <owner-session-id> --dry-run --endpoint "https://<project-ref>.supabase.co/functions/v1/slopmachine-upload"
+```
+
+## Notes
+
+- the upload token is machine-level state and is not stored in the repo
+- the owner session id is currently supplied manually to `send-data`
+- developer session ids come from `.ai/metadata.json`
+- broad workflow files and session exports live at workspace root, not inside `repo/`

package/assets/agents/developer.md

@@ -32,6 +32,7 @@ Read and follow `AGENTS.md` before implementing.
 - do real verification, not confidence theater
 - keep moving until the assigned work is materially complete or concretely blocked
 - do not stop for unnecessary intermediate check-ins
+- use independent engineering judgment; do not behave like a passive worker waiting to be corrected later
 
 ## Requirements And Planning
 
@@ -41,6 +42,7 @@ Before coding:
 - surface meaningful ambiguity instead of silently guessing
 - make the plan concrete enough to drive real implementation
 - keep frontend/backend surfaces aligned when both sides matter
+- check prompt-fit before reporting completion; if the requested result still has visible gaps, keep working or call them out explicitly
 
 Do not narrow scope for convenience.
 
@@ -53,6 +55,7 @@ Do not narrow scope for convenience.
 - keep repo-local docs and code structure statically reviewable; do not rely on runtime success alone to make the project understandable
 - keep the repo self-sufficient; do not make it depend on parent-directory docs or sibling artifacts for startup, build/preview, configuration, verification, or basic understanding
 - do not touch workflow or rulebook files such as `AGENTS.md` unless explicitly asked
+- if the work changes acceptance-critical docs or contracts, review those docs yourself before replying instead of assuming the owner will catch inconsistencies later
 
 ## Verification Cadence
 
@@ -97,6 +100,19 @@ Selected-stack defaults:
 - use a shared validation/error-handling path when validation materially affects the flow
 - do not hide missing failure handling behind fake-success paths
 
+## Completion Preflight
+
+Before reporting a planning package, scaffold, implementation slice, or fix round as ready, run this preflight yourself:
+
+- prompt-fit: does the result still satisfy the original request without silent narrowing?
+- consistency: do code, docs, route contracts, security notes, and runtime/test commands agree?
+- flow completeness: are the user-facing and operator-facing flows touched by this work actually covered end to end?
+- security and permissions: are auth, RBAC, object-level checks, sensitive actions, and audit implications handled where relevant?
+- verification: did you run the strongest targeted checks that are appropriate without using owner-only broad gates?
+- reviewability: can the owner review this work by reading the changed files and a small number of directly related files?
+
+If any answer is no, fix it before replying or call out the blocker explicitly.
+
 ## Skills
 
 - use relevant framework or language skills when they materially help the current task
@@ -109,3 +125,13 @@ Selected-stack defaults:
 - always name the exact verification commands you ran and the concrete results they produced
 - if you ran no verification command for part of the work, say that explicitly instead of implying broader proof than you have
 - if a problem needs a real fix, fix it instead of explaining around it
+
+Use this reply shape for substantive work:
+
+1. `Changed files` — exact files changed
+2. `What changed` — the concrete behavior/contract updates in those files
+3. `Why this should pass review` — prompt-fit and consistency check in 2-5 bullets
+4. `Verification` — exact commands run and exact results
+5. `Remaining risks` — only the real unresolved weaknesses, if any
+
+Keep the reply compact. Point to the exact changed files and the narrow supporting files the owner should read next.

package/assets/agents/slopmachine.md

@@ -244,6 +244,8 @@ When talking to the developer:
 - keep prompts natural, sharp, and compact unless the moment really needs more context
 - translate workflow intent into normal software-project language
 - for each development slice or follow-up fix request, require the reply to state the exact verification commands that were run and the concrete results they produced
+- require the developer to point to the exact changed files and the narrow supporting files worth review
+- require the developer to self-check prompt-fit, consistency, and likely review defects before claiming readiness
 
 Do not leak workflow internals such as:
 
@@ -265,6 +267,11 @@ Do not speak as a relay for a third party.
 - read only what is needed to answer the current decision
 - keep comments and metadata auditable and specific
 - keep external docs owner-maintained as reference copies and repo-local docs developer-maintained for the repo's self-sufficient source of truth
+- default review scope to the changed files and the specific supporting files named by the developer
+- expand review scope only when a concrete inconsistency or missing dependency forces it
+- avoid `grep` by default; prefer `glob` to identify exact files and `read` with targeted offsets
+- use `grep` only for an exact low-cardinality string after the relevant file set is already known
+- do not run broad parent-root searches during ordinary review when exact project files are already known
 
 ## Review Posture
 

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

@@ -100,14 +100,17 @@ If nothing material was unclear, still create `questions.md` and keep it minimal
 
 - compare the original prompt and the prepared clarification prompt using one dedicated `General` validation session, never the developer session
 - do not create a new validation session for every retry unless the session became unusable or a fundamental misunderstanding requires a clean restart
-- on the first validation pass, build one self-contained validation prompt block for that `General` session
-- on that first pass, include the full original prompt text, the full current questions or clarification record, and the full current `../.ai/clarification-prompt.md`
-- do not use placeholders such as `same as previous`, `from context`, `see above`, or `latest artifact`
+- on the first validation pass, prefer a file-based validation request that points the validator to `../metadata.json`, `../docs/questions.md`, and `../.ai/clarification-prompt.md` and asks it to read those files directly
+- in that first pass, use `../metadata.json` as the source of truth for the original prompt instead of re-inlining the full prompt body when file access is available
+- if file access is unavailable or blocked, fall back to one self-contained validation prompt block that includes the full original prompt text, the full current questions record, and the full current `../.ai/clarification-prompt.md`
+- do not use placeholders such as `same as previous`, `from context`, `see above`, or `latest artifact` when you are in the inline fallback mode
 - ask that `General` session whether the clarification prompt deviates from, weakens, narrows, or violates the original prompt in any way
 - require it to judge whether the clarification prompt is a genuine improvement in execution quality while remaining faithful to the original intent
 - if the validator suggests real fixes, patch the existing questions record and clarification prompt directly; do not restart the clarification phase from scratch unless the validator found a fundamental scope misunderstanding
 - treat validator output as a correction list, not as a reason to regenerate giant clarification blocks repeatedly
-- when rerunning validation in the same validator session, send only the improved clarification payload and the concrete fixes you made; do not resend the original prompt block if the session already has that context
+- when rerunning validation in the same validator session, send only the updated file path(s), the concrete fixes you made, and a request to confirm that those fixes resolve the previously reported issues
+- on reruns, do not resend the original prompt block if the validator session already has that context
+- on reruns, do not resend unchanged file bodies; point to the updated clarification file and, when useful, the narrow changed section in `questions.md`
 - rerun validation only after applying the concrete fixes that matter
 - keep the validation loop bounded and intentional; prefer one strong pass plus a small number of revision cycles over repeated loose churn
 - once prompt-faithfulness is satisfied and the remaining notes are minor or cosmetic, stop iterating and proceed

package/assets/slopmachine/templates/AGENTS.md

@@ -17,63 +17,15 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - Do not call work complete while it is still shaky.
 - Reuse and extend shared cross-cutting patterns instead of inventing incompatible local ones.
 
-## Verification Rules
+## Runtime And Verification
 
-- During ordinary iteration, prefer the fastest meaningful local verification for the changed area.
-- Prefer targeted unit, integration, module, route-family, or platform-appropriate local UI/E2E checks over broad reruns.
-- Do not rerun full Dockerized startup and the full test suite on every small change.
-- The broad owner-run project-standard verification path should be used sparingly, with a target budget of at most 3 times across the whole workflow cycle.
-- If you run a Docker-based verification command sequence, end it with `docker compose down` unless containers must remain up.
-
-Every project must expose:
-
-- one primary documented runtime command
-- one primary documented broad test command: `./run_tests.sh`
-- follow the original prompt and existing repository first for the runtime stack; `./run_tests.sh` should exist regardless of project type
-- the primary full-test command should install or prepare what it needs first when that setup is required for a clean environment
-
-For web projects, those are usually:
-
-- `docker compose up --build`
-- `./run_tests.sh`
-
-For web projects using the default Docker-first runtime model:
-
-- `./run_tests.sh` must run the broad full-test path through Docker
-- local non-Docker tests should still exist for normal development work
-- final broad verification should use the Dockerized `./run_tests.sh` path, not only local test commands
-- keep Compose isolation safe for shared machines: no unnecessary `container_name`, unique `COMPOSE_PROJECT_NAME`, and Compose-scoped image/network/volume naming
-- expose only the primary app-facing port to host by default, bind it to `127.0.0.1`, and keep databases/cache/internal services off host ports unless truly required
-- prefer random host-port assignment by default so parallel local projects do not collide; if a fixed host port is truly required, support override plus free-port fallback in the runtime or test wrapper
-- add healthchecks and wait for service readiness before tests or dependent startup steps proceed
-
-For web projects, default the runtime contract to `docker compose up --build` unless the prompt or existing repository clearly dictates another model.
-
-When `docker compose up --build` is not the runtime contract, provide `./run_app.sh` as the single primary runtime wrapper.
-
-For mobile, desktop, CLI, library, or other non-web projects, `./run_app.sh` should own the selected stack's runtime flow, while `./run_tests.sh` remains the single broad test wrapper calling the platform-equivalent full test path.
-
-## Testing Rules
-
-- Tests must be real and tied to actual behavior.
-- Do not mock APIs for integration testing.
-- Use real HTTP requests against the actual running service surface for integration evidence.
-- For UI-bearing work, use the selected stack's local UI/E2E tool on affected flows and inspect screenshots or equivalent artifacts when practical.
-- Prefer TDD when the behavior is well defined and practical to drive test-first.
-- Where TDD is not practical, define the expected tests before implementation so coverage is intentional rather than retrofitted.
-- Keep repo-local `./docs/test-coverage.md` aligned with the real test surface. It should map major requirement or risk points to concrete tests, key assertions, coverage status, and remaining gaps.
-- For backend or fullstack projects, cover 401, 403, 404, conflict or duplicate submission when relevant, object-level authorization, tenant or user isolation, and sensitive-log exposure when those risks exist.
-- For frontend-bearing projects, build and use a layered frontend test story where relevant: unit, component, page/route integration, and E2E.
-- For non-trivial frontend projects, do not rely only on runtime or E2E proof; add component, page, route, or state-focused tests when UI state complexity is meaningful.
-- For frontend-bearing flows, keep required UI states statically visible and tested where relevant: loading, empty, submitting, disabled, success, error, and duplicate-action protection.
-- The project should normally reach roughly 90 percent meaningful coverage of the relevant behavior surface.
-
-Selected-stack defaults:
-
-- follow the original prompt and existing repository first; use the defaults below only when they do not already specify the platform or stack
-- web frontend/fullstack: Playwright for browser E2E/UI verification when applicable
-- mobile: Expo + React Native + TypeScript by default, with Jest plus React Native Testing Library for local tests and a platform-appropriate mobile UI/E2E tool when the flow needs it
-- desktop: Electron + Vite + TypeScript by default, with a project-standard local test runner plus Playwright's Electron support or another platform-appropriate desktop UI/E2E tool when the flow needs it
+- Keep one primary documented runtime command and one primary broad test command: `./run_tests.sh`.
+- Follow the original prompt and existing repository first for the runtime stack.
+- Prefer the fastest meaningful local verification for the changed area during ordinary iteration.
+- Do not rerun broad runtime/test commands on every small change.
+- For web projects, default the runtime contract to `docker compose up --build` unless the prompt or existing repository clearly dictates another model.
+- When `docker compose up --build` is not the runtime contract, provide `./run_app.sh` as the single primary runtime wrapper.
+- If the project has database dependencies, keep `./init_db.sh` as the only project-standard database initialization path.
 
 ## Documentation Rules
 
@@ -82,11 +34,7 @@ Selected-stack defaults:
 - The README must clearly document whether the primary runtime command is `docker compose up --build` or `./run_app.sh`.
 - The README must clearly document `./run_tests.sh` as the broad test command.
 - The README must stand on its own for basic codebase use.
-- The README should summarize important API or service surfaces when useful, but the full API catalog belongs in repo-local `./docs/api-spec.md` when that doc applies.
 - Keep repo-local docs under `./docs/` when relevant, especially `./docs/reviewer-guide.md`, `./docs/test-coverage.md`, `./docs/security-boundaries.md`, `./docs/frontend-flow-matrix.md`, and `./docs/api-spec.md`.
-- `./docs/reviewer-guide.md` should make build/preview/config, app entry points, routes, major module boundaries, feature flags, debug/demo surfaces, mock/interception defaults, and logging/validation overview traceable from inside the repo.
-- `./docs/security-boundaries.md` should exist when auth, authorization, admin/debug, or isolation boundaries matter.
-- `./docs/frontend-flow-matrix.md` should exist when frontend pages, interactions, and state transitions are material.
 - The repo should be statically reviewable by a fresh reviewer: entry points, routes, config, test commands, and major module boundaries should be traceable from repository artifacts.
 - If the project uses mock, stub, fake, interception, or local-data behavior, the README must disclose that scope accurately.
 - If mock or interception behavior is enabled by default, the README must say so clearly.
@@ -94,31 +42,13 @@ Selected-stack defaults:
 - Do not let a mock-only or local-data-only project look like undisclosed real backend or production integration.
 - Do not hide missing failure handling behind fake-success paths.
 
-## Logging And Validation Rules
-
-- Establish and use a shared logging path rather than random print-style debugging.
-- Logging should have meaningful categories or levels, support troubleshooting, and avoid sensitive-data leakage.
-- Establish and use a shared validation path when validation matters instead of inventing ad hoc rules in scattered files.
-- Keep validation and normalized user-facing error behavior traceable in repo-local code or docs.
-
 ## Secret And Runtime Rules
 
 - Do not create or keep `.env` files anywhere in the repo.
 - Do not rely on `.env`, `.env.local`, `.env.example`, or similar files for project startup.
 - Do not hardcode secrets.
 - If runtime env-file format is required, generate it ephemerally and do not commit or package it.
-- If the project has database dependencies, create and maintain `./init_db.sh` as the only project-standard database initialization path.
-- If the project has database dependencies, create `./init_db.sh` during scaffold and keep expanding it as the real schema, migrations, bootstrap data, and other database dependencies become known.
-- If the project has database dependencies, use `./init_db.sh` from runtime and test entrypoints whenever database preparation is required.
 - Do not hardcode database connection values or database bootstrap values anywhere in the repo.
-- When auth or access control matters, keep the real security boundaries statically traceable in code and docs: auth entry points, route authorization, object authorization, function-level authorization, admin/debug protection, and tenant or user isolation where applicable.
-
-Selected-stack secret/config defaults:
-
-- follow the original prompt and existing repository first; use the defaults below only when they do not already specify the platform or stack
-- web Dockerized services: use Docker/runtime-provided variables, never committed env files
-- mobile apps: do not bundle real secrets into the client; use app config only for non-secret public configuration and keep real secrets server-side or in platform-appropriate secure storage when user/device secrets must be stored at runtime
-- desktop apps: keep sensitive values in main-process/runtime configuration or platform-appropriate secure storage, and do not expose them to the renderer by default
 
 ## Product Integrity Rules
 

package/package.json

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