theslopmachine 0.6.2 → 0.7.1

package/assets/slopmachine/scaffold-playbooks/spring-boot-default.md

@@ -0,0 +1,182 @@
+# Spring Boot Default Scaffold Playbook
+
+Use this playbook when the prompt explicitly asks for Spring Boot, Java backend conventions, or a JVM-first backend baseline.
+
+## Goal
+
+Create a Spring Boot scaffold baseline that:
+
+- starts from the official Spring Initializr bootstrap path
+- keeps defaults pinned and boring
+- proves one real API plus one real persistence path
+- exposes `docker compose up --build` as the runtime contract
+- exposes `./run_tests.sh` as the broad containerized verification path
+- stays baseline-only and honest about exclusions
+
+Verified lab: `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline`
+
+## Chosen baseline defaults
+
+- Spring Boot `3.5.13`
+- Java `21`
+- Maven Wrapper `3.9.14`
+- dependencies: `web`, `actuator`, `data-jpa`, `validation`, `h2`
+- database pattern: file-backed H2 stored in Docker-managed volumes
+
+Why these defaults:
+
+- Spring Initializr is the official bootstrap path and yields the wrapper, parent BOM, and baseline Maven layout cleanly
+- Spring Boot `3.5.x` is the safer practical line than jumping straight to Boot `4.x` for a neutral baseline
+- Java `21` is a current LTS choice with wide container availability
+- H2 file mode gives real persistence without introducing credentials or a second infrastructure service
+
+## Official bootstrap command
+
+Use the official starter generator, then adapt only what is needed for Docker, DB wiring, tests, and README honesty:
+
+```bash
+curl -fsSL "https://start.spring.io/starter.zip?type=maven-project&language=java&bootVersion=3.5.13&baseDir=spring-boot-baseline&groupId=com.eaglepoint&artifactId=spring-boot-baseline&name=spring-boot-baseline&description=Verified%20Spring%20Boot%20baseline%20lab&packageName=com.eaglepoint.springbaseline&packaging=jar&javaVersion=21&dependencies=web,actuator,data-jpa,h2,validation" -o /tmp/spring-boot-baseline.zip
+unzip -q /tmp/spring-boot-baseline.zip -d .
+```
+
+## Safe config / database pattern
+
+- do not require `.env`
+- import optional runtime config from `/runtime/config/application-runtime.properties`
+- generate that file at container startup and before containerized tests
+- point Spring Data at `jdbc:h2:file:/runtime/db/spring-boot-baseline...`
+- keep runtime config and DB files in named Docker volumes
+- expose only the app port to loopback with a random host port
+
+This is the recommended local-only baseline when the prompt does not require Postgres/MySQL yet.
+
+## Docker / Compose pattern
+
+- `compose.yaml` with one `app` service and one `test` service behind the `test` profile
+- multi-stage Dockerfile: Maven test/build stages plus a smaller runtime stage
+- real app healthcheck against `http://127.0.0.1:8080/actuator/health`
+- host port binding: `127.0.0.1::8080`
+- named volumes for runtime config and file-backed H2 state
+
+## Minimum API surface
+
+At scaffold time include at least:
+
+- `GET /health` proving app boot and DB query success
+- `POST /items` creating one persisted record
+- `GET /items` listing persisted records
+
+This is enough to prove API routing, JSON handling, persistence, and Docker readiness without pretending the app is product-ready.
+
+## Minimum test floor
+
+- `./run_tests.sh` must start the app container, wait for health, and smoke the real routes with `curl`
+- the test container must run `./mvnw -q verify`
+- JUnit tests should use `@SpringBootTest(webEnvironment = RANDOM_PORT)` or equivalent so HTTP and DB wiring are both exercised
+
+## README requirements
+
+`README.md` must explicitly state:
+
+- that the scaffold is baseline-only
+- the pinned Spring Boot / Java / Maven defaults
+- required runtime command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- how the runtime config file is generated without `.env`
+- why H2 file mode is the chosen default database pattern
+- what is intentionally excluded
+
+## Verification commands actually run
+
+Experimentally verified: **yes**.
+
+Commands run in `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline`:
+
+```bash
+docker compose build
+docker compose up --build -d && docker compose ps && docker compose port app 8080
+python3 - <<'PY'
+import json, time, urllib.request
+base = 'http://127.0.0.1:32785'
+last_error = None
+for _ in range(60):
+    try:
+        with urllib.request.urlopen(base + '/health', timeout=5) as response:
+            payload = json.load(response)
+        if payload.get('status') == 'ok' and payload.get('database') == 'ok':
+            print('HEALTH', json.dumps(payload, separators=(',', ':')))
+            break
+    except Exception as exc:
+        last_error = exc
+        time.sleep(2)
+else:
+    raise SystemExit(f'Health endpoint never became ready: {last_error}')
+
+req = urllib.request.Request(base + '/items', data=b'{"name":"manual-smoke-item"}', headers={'Content-Type': 'application/json'}, method='POST')
+with urllib.request.urlopen(req, timeout=5) as response:
+    created = json.load(response)
+print('CREATE', json.dumps(created, separators=(',', ':')))
+with urllib.request.urlopen(base + '/items', timeout=5) as response:
+    items = json.load(response)
+print('LIST', json.dumps(items, separators=(',', ':')))
+PY
+docker compose down --volumes --remove-orphans
+./run_tests.sh
+python3 - <<'PY'
+import json
+import signal
+import subprocess
+import time
+import urllib.request
+
+cwd = '/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/spring-boot-baseline'
+proc = subprocess.Popen(['docker', 'compose', 'up', '--build'], cwd=cwd)
+error = None
+try:
+    deadline = time.time() + 240
+    while time.time() < deadline:
+        try:
+            port_output = subprocess.check_output(['docker', 'compose', 'port', 'app', '8080'], cwd=cwd, stderr=subprocess.DEVNULL, text=True).strip()
+            if port_output:
+                host, port = port_output.rsplit(':', 1)
+                base_url = f'http://127.0.0.1:{port}'
+                with urllib.request.urlopen(base_url + '/health', timeout=3) as response:
+                    payload = json.load(response)
+                if payload.get('status') == 'ok' and payload.get('database') == 'ok':
+                    print(f'interactive compose reached ready health at {base_url}')
+                    break
+        except Exception as exc:
+            error = exc
+        time.sleep(2)
+    else:
+        raise RuntimeError(f'interactive docker compose up --build never reached readiness: {error}')
+finally:
+    proc.send_signal(signal.SIGINT)
+    try:
+        proc.wait(timeout=30)
+    except subprocess.TimeoutExpired:
+        proc.kill()
+        proc.wait(timeout=30)
+    subprocess.run(['docker', 'compose', 'down', '--volumes', '--remove-orphans'], cwd=cwd, check=True)
+PY
+docker compose --profile test run --rm test sh -lc 'sh /workspace/scripts/bootstrap_config.sh && ./mvnw -U test'
+docker compose down --volumes --remove-orphans
+```
+
+Observed results:
+
+- `docker compose up --build -d` published the app on `127.0.0.1:32785`
+- smoke verification returned healthy JSON plus a persisted `manual-smoke-item`
+- `./run_tests.sh` passed and printed `Spring Boot baseline smoke and container tests passed at http://127.0.0.1:32787`
+- interactive `docker compose up --build` reached ready health at `http://127.0.0.1:32789`
+- `docker compose --profile test run --rm test ... ./mvnw -U test` reported `Tests run: 2, Failures: 0, Errors: 0, Skipped: 0` and `BUILD SUCCESS`
+
+## Acceptance checklist
+
+Baseline is acceptable when:
+
+- `docker compose up --build` works
+- `./run_tests.sh` works
+- a real API route and a real persistence route are verified
+- the Docker path does not require `.env`
+- the README is honest about scope and exclusions

package/assets/slopmachine/scaffold-playbooks/tauri-default.md

@@ -0,0 +1,80 @@
+# Tauri Default Scaffold Playbook
+
+Use this playbook only when the prompt explicitly requires Tauri or the existing repo is already Tauri-based.
+
+## Current status
+
+This family is now **experimentally verified** for an honest Linux Docker baseline.
+
+Verified lab:
+
+- `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/tauri-baseline`
+
+## What was achieved in the verified lab
+
+The verified lab now proves all of the following:
+
+- Tauri + Vite + TypeScript scaffold exists
+- Rust shell under `src-tauri/` exists
+- Dockerfile and Compose report-service strategy exist
+- `run_tests.sh` exists
+- built frontend assets exist under `dist/`
+- verification helper scripts exist under `.docker/`
+- README documents a plausible Linux Docker verification boundary
+- `docker compose up --build --wait` reaches a stable healthy report service
+- containerized `./run_tests.sh` passes
+- a Linux `.deb` bundle is generated and preserved under the verified artifact path
+- the packaged Tauri binary passes the documented headless smoke path
+
+## Safe default stack
+
+- Tauri `2.x`
+- Vite `8.x`
+- TypeScript `6.x`
+- Rust stable compatible with the chosen Tauri version
+
+## Runtime contract
+
+- required Docker command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both are now confirmed working in the verified lab
+
+## Intended Docker strategy
+
+This family should follow the desktop shared contract with a Tauri-specific interpretation:
+
+1. build frontend assets inside Docker
+2. compile the Rust/Tauri shell inside Docker
+3. produce a meaningful Linux-side artifact or bundle
+4. run one honest Linux smoke/proof path if feasible
+5. converge Compose to a stable report/support service rather than a one-shot exited container
+
+## Honest Linux proof boundary
+
+For the verified Linux baseline, Docker honestly proves only:
+
+- Tauri frontend builds
+- Rust shell compiles
+- Linux-side bundle/build path works
+- any documented smoke path actually runs
+
+It should **not** claim full cross-platform desktop UX proof outside Linux.
+
+## Verified rerun evidence
+
+The successful rerun established these concrete facts:
+
+- the multi-stage Docker build completed end-to-end
+- `npm run test:unit` passed
+- `npx tauri build --bundles deb --ci` passed
+- `cargo test --release --manifest-path src-tauri/Cargo.toml` passed
+- the headless smoke path passed under `dbus-run-session` + `Xvfb`
+- verification artifacts were copied out of the cache-mounted build target into `.verified/`
+- the final Compose service reached `Healthy`
+- `./run_tests.sh` returned a verified summary endpoint
+
+## Guidance
+
+- treat Tauri as explicit opt-in only
+- do not auto-select it for open-ended desktop work yet because Electron remains the lighter generic default
+- it is now safe to treat this family as experimentally verified rather than partial

package/assets/slopmachine/scaffold-playbooks/vue-vite-default.md

@@ -0,0 +1,162 @@
+# Vue Vite Default Scaffold Playbook
+
+Use this when the prompt explicitly wants a Vue frontend on top of Vite and does not already require a broader runtime such as Nuxt.
+
+## Decision summary
+
+- **chosen default:** Vue 3 + Vite + TypeScript via `create-vue`
+- **why:** official Vue-owned bootstrap path, easy to keep baseline-only, and straightforward to verify with Docker plus Vitest component tests
+- **verified runtime:** `docker compose up --build`
+- **verified broad test path:** `./run_tests.sh`
+- **experimentally verified lab:** `/Users/yohannesakd/code/eaglepoint/demonstration/scaffold-lab/vue-vite-baseline`
+
+## Official bootstrap matrix
+
+| Stack | Official/bootstrap path | Good fit | Why not the default prototype here |
+| --- | --- | --- | --- |
+| Vue + Vite via `create-vue` | `npm create vue@latest <project-name> -- --ts --vitest --eslint --bare` | Best Vue-first SPA baseline with first-party feature flags | Chosen default |
+| Vite Vue TypeScript template | `npm create vite@latest <project-name> -- --template vue-ts` | Good fallback when only a raw Vue/Vite template is needed | Slightly less aligned with Vue's recommended starter path |
+| Nuxt | `npm exec nuxi@latest init <project-name>` | Best when SSR, file routing, or server APIs are required | Larger runtime model than a baseline SPA needs |
+
+## Evidence basis for the matrix
+
+- Vue docs recommend `npm create vue@latest` for scaffolding a Vue SPA locally.
+- The `create-vue` repository describes itself as the recommended way to start a Vite-powered Vue project and documents feature flags such as `--ts`, `--vitest`, `--eslint`, and `--bare`.
+- Vite docs document `npm create vite@latest <project-name> -- --template vue` / `vue-ts` as the direct template path and surface the Vue starter as the official Vue option.
+
+For a **Vue-specific frontend baseline**, the safest verified prototype is the smallest official Vue-owned starter that still prewires type-checking, linting, and unit tests. That is `create-vue` with `--ts --vitest --eslint --bare` here.
+
+## Chosen default stack and version pins
+
+Verified prototype pins:
+
+- Node image: `node:22.21.1-alpine3.22`
+- Vue: `3.5.32`
+- Vite: `8.0.8`
+- TypeScript: `6.0.2`
+- `@vitejs/plugin-vue`: `6.0.6`
+- Vitest: `4.1.4`
+- `@vue/test-utils`: `2.4.6`
+- ESLint: `10.2.0`
+- `@vue/eslint-config-typescript`: `14.7.0`
+- `@vitest/eslint-plugin`: `1.6.15`
+- `oxlint`: `1.57.0`
+- `vue-tsc`: `3.2.6`
+- `jsdom`: `29.0.2`
+
+Compatibility pins used in this verified lab:
+
+- `@emnapi/core`: `1.9.2`
+- `@emnapi/runtime`: `1.9.2`
+- `@rolldown/binding-darwin-arm64`: `1.0.0-rc.15` as an optional dependency for current macOS arm64 local installs
+
+## Safe defaults
+
+- no `.env` file required
+- no secrets committed
+- baseline-only SPA, not a feature-complete product
+- no router, state store, API client, SSR, or E2E browser tooling by default
+- Docker host port bound to `127.0.0.1` with a random host port to reduce local collisions
+- healthcheck required before the smoke step proceeds
+- exact dependency versions pinned in `package.json` and `package-lock.json`
+
+## Docker / Compose pattern
+
+Recommended baseline pattern:
+
+1. **multi-stage Dockerfile**
+   - shared `npm ci` base
+   - `development` target runs `vite` on `0.0.0.0:5173`
+   - `verify` target runs `npm run verify`
+2. **Compose services**
+   - `web` service for `docker compose up --build`
+   - `test` service behind a `test` profile for containerized verification
+3. **port strategy**
+   - expose only the app port
+   - prefer `127.0.0.1::5173` so parallel local worktrees do not collide
+4. **health strategy**
+   - wait for `wget http://127.0.0.1:5173` healthcheck before curl smoke tests
+
+## Testing baseline
+
+Minimum real testing floor for this playbook:
+
+- Vitest component tests
+- Vue Test Utils rendering assertions
+- one small interaction test (`Show verification commands` toggle)
+- one containerized smoke check that confirms the app shell is served through Compose
+- one containerized broad path that runs lint + unit tests + production build
+
+Suggested scripts:
+
+- `npm run test:unit`
+- `npm run verify`
+- `./run_tests.sh`
+
+`./run_tests.sh` should:
+
+1. build Docker images
+2. start `web`
+3. wait for health
+4. `curl` the served HTML shell
+5. run the `test` profile container
+6. tear down cleanly
+
+## README requirements
+
+The scaffold `README.md` should explicitly state:
+
+- that this is a **baseline scaffold**
+- chosen stack and why it was picked
+- exact bootstrap command used
+- `docker compose up --build`
+- `./run_tests.sh`
+- any optional local iteration commands
+- what is included now vs intentionally deferred
+- no `.env` / no secrets policy
+- main files worth reusing later
+
+## Verification commands actually run in the verified prototype
+
+User-facing commands verified:
+
+```bash
+npm create vue@latest vue-vite-baseline -- --ts --vitest --eslint --bare
+npm install
+npm run verify
+docker compose up --build
+./run_tests.sh
+```
+
+Supporting commands used during verification:
+
+```bash
+docker compose port web 5173
+curl -fsS http://127.0.0.1:<mapped-port>
+docker compose down --remove-orphans
+```
+
+Observed verification results in the prototype lab:
+
+- local `npm run verify`: passed
+- containerized `./run_tests.sh`: passed
+- runtime `docker compose up --build`: passed and served the app shell
+
+## Known caveats
+
+- The curl smoke check validates the served HTML shell, not hydrated browser DOM behavior. Keep Vitest component tests for actual UI assertions.
+- `create-vue` is interactive by default; the verified baseline uses feature flags so the scaffold stays reproducible and baseline-only.
+- Nuxt remains a documented alternative, not the verified prototype, because its runtime model is intentionally broader than a baseline SPA.
+
+## What to reuse later
+
+Reuse these parts directly for later Vue frontend prompts:
+
+- the official `create-vue` bootstrap path with baseline-only flags
+- the multi-stage Dockerfile pattern
+- random localhost host-port mapping
+- healthcheck + curl smoke test flow
+- `./run_tests.sh` as the canonical broad-path wrapper
+- the README honesty checklist
+
+Do **not** treat this playbook as a signal to pre-add routing, Pinia, auth, API clients, or E2E browsers unless the prompt explicitly needs them.

package/assets/slopmachine/scaffold-playbooks/web-default.md

@@ -0,0 +1,96 @@
+# Web Default Scaffold Playbook
+
+Use this playbook for web frontend, backend, or fullstack requests unless the prompt or existing repo clearly requires a different runtime model.
+
+## Goal
+
+Create a simple web baseline that:
+
+- uses the requested framework or safest default bootstrap path
+- runs through one honest primary runtime contract
+- exposes one portable broad test command
+- wires required baseline technologies without starting product-specific feature work
+
+## Runtime contract
+
+- required runtime command: `docker compose up --build`
+- required broad test command: `./run_tests.sh`
+- both commands must be real and working
+
+## Bootstrap rule
+
+- use the official or best-known bootstrap command for the requested web framework
+- if the prompt leaves the framework open, choose the safest maintained default for the requested surface
+- after bootstrap, adapt only enough to make the runtime, test path, config path, and README honest
+
+## Required scripts
+
+- `./run_tests.sh`
+- `./init_db.sh` when the project has database dependencies
+
+## Safe defaults
+
+- no `.env` files in the repo
+- no hardcoded secrets
+- Docker runtime is mandatory for web delivery
+- only app-facing services exposed to host by default
+- internal services kept off host ports unless genuinely needed
+- `COMPOSE_PROJECT_NAME` namespaced cleanly when Docker is used
+
+## Baseline structure
+
+- app/runtime entrypoints are real
+- test tooling is installed
+- config flow is explicit
+- logging/validation baseline exists where the stack obviously needs it
+- repo `README.md` is honest from day one
+
+## `./run_tests.sh`
+
+For the default Docker-first model, `./run_tests.sh` should own the portable broad path and remain runnable on a clean Linux machine with Docker and curl.
+
+Typical baseline coverage:
+
+- install/build health
+- lint or typecheck when applicable
+- one or more real baseline tests
+- app or API smoke-level verification
+
+## Minimal real test floor
+
+At scaffold, include at least:
+
+- one real unit or route/component test
+- one real smoke-level proof that the chosen framework wiring works
+- one real broad-path build/test invocation in `./run_tests.sh`
+
+Do not leave the broad path mostly empty.
+
+## README floor
+
+`README.md` must already state:
+
+- scaffold status versus implemented scope
+- required Docker command: `docker compose up --build`
+- broad test command
+- main repo layout
+- any mock/local-only or scaffold honesty boundaries
+
+## Common pitfalls
+
+- pretending a non-Docker web runtime is acceptable as the final baseline contract
+- checked-in `.env` files
+- hardcoded secret literals in Compose or startup scripts
+- exposing every service port to host by default
+- generating a giant scaffold with almost no real tests
+
+## Acceptance checklist
+
+Scaffold is acceptable when:
+
+- `docker compose up --build` works
+- `./run_tests.sh` works
+- required baseline technologies are wired
+- minimal real tests exist
+- README is honest
+- no `.env` or hardcoded secret residue exists

package/assets/slopmachine/templates/AGENTS.md

@@ -16,6 +16,28 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - Work in meaningful vertical slices.
 - Do not call work complete while it is still shaky.
 - Reuse and extend shared cross-cutting patterns instead of inventing incompatible local ones.
+- Before coding, identify the actors or personas touched by the change and the concrete path to success for each one.
+- Make important business rules explicit before coding: defaults, limits, allowed transitions, uniqueness, conflicts, reversals, retries, and ownership rules when they matter.
+- When the product has meaningful workflow state, define or confirm the relevant state machine before treating the flow as implemented.
+- Keep a concrete out-of-scope boundary in mind so you do not overbuild speculative features.
+- Do not introduce convenience-based `v1` scope cuts, role simplifications, or workflow omissions unless they were explicitly authorized.
+- When backend or fullstack API endpoints are added or changed, prefer real HTTP tests for the exact `METHOD + PATH` over controller or service bypasses when practical.
+- If mocked HTTP tests or unit-only tests still exist for an API surface, do not overstate them as equivalent to true no-mock endpoint coverage.
+
+## Requirements Fidelity
+
+- Preserve the full prompt intent, including implied business constraints.
+- Do not weaken required actor models, operator flows, security controls, or lifecycle behavior for implementation convenience.
+- If a requirement is ambiguous, choose the safest prompt-faithful behavior or surface the ambiguity instead of guessing lazily.
+- If the feature depends on business rules, make those rules traceable in code, tests, and `README.md` rather than leaving them implicit.
+
+## Architecture Rules
+
+- For backend or fullstack projects, route configuration through a central config module instead of scattering direct environment reads through business logic.
+- Keep database operations, business logic, transport layers, and UI surfaces separated clearly enough for static review.
+- Use a shared logging path and shared validation/error-normalization path when the project is large enough for those concerns to matter.
+- When a third-party service is required but real integration is not explicitly demanded, prefer an internal stub or adaptor boundary over shipping brittle real credentials or uncontrolled external dependencies.
+- If a feature requires auth or privileged access, enforce it across route, controller or handler, and object scope where applicable.
 
 ## Runtime And Verification
 
@@ -26,8 +48,9 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - During ordinary development slices, do not run Docker runtime commands, browser E2E, Playwright, full test suites, or `./run_tests.sh`.
 - Use targeted local tests during ordinary development slices and leave browser E2E plus broad-gate commands for later comprehensive verification.
 - When API tests are material, make them hit real endpoints and print simple useful response evidence such as status codes and message/body summaries.
-- 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 web projects, require the runtime contract to be `docker compose up --build`.
+- For Android, mobile, desktop, and iOS-targeted projects, also require a meaningful `docker compose up --build` command even when platform-specific runtime proof differs from web semantics.
+- For non-web projects, `./run_app.sh` may exist as a helper wrapper, but it does not replace the required Docker command.
 - If the project has database dependencies, keep `./init_db.sh` as the only project-standard database initialization path.
 
 ## Documentation Rules
@@ -35,17 +58,21 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - Keep `README.md` accurate.
 - The README must explain what the project is, what it does, how to run it, how to test it, the main repo contents, and any important information a new developer needs immediately.
 - The README must also explain the delivered architecture and major implementation structure clearly enough for review and handoff.
-- The README must clearly document whether the primary runtime command is `docker compose up --build` or `./run_app.sh`.
+- The README must include project type near the top, startup instructions, access method, verification method, and demo credentials for every role or the exact statement `No authentication required`.
+- The README must clearly document the required Docker command `docker compose up --build` and any additional helper runtime wrapper such as `./run_app.sh` when present.
 - The README must clearly document `./run_tests.sh` as the broad test command.
+- For backend, fullstack, and web projects, the README should also contain the exact legacy compatibility string `docker-compose up` somewhere in startup guidance without replacing the canonical runtime contract.
 - The README must stand on its own for basic codebase use.
 - Keep `README.md` as the only documentation file inside the repo unless the user explicitly asks for something else.
 - Treat `README.md` as the primary documentation surface inside the repo.
 - 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.
+- The README should name the important actors, the main success paths, major limitations or out-of-scope boundaries, and any non-obvious business rules that affect usage.
 - 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.
 - Feature flags, debug/demo surfaces, default enabled states, and mock/interception defaults must be disclosed in `README.md` when they exist.
 - 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.
+- Before final delivery, remove local-only setup traces and host-only dependency assumptions from the README and wrapper scripts.
 
 ## Secret And Runtime Rules
 
@@ -67,6 +94,17 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - Do not leave placeholder, setup, debug, or demo content in product-facing UI.
 - If a real user-facing or admin-facing surface is required, build that surface instead of bypassing it with API shortcuts.
 - Treat missing real surfaces as incomplete implementation.
+- If multiple roles or personas exist, implement the real role-aware surfaces and permissions rather than collapsing them into a single generic flow.
+- Do not replace prompt-required interaction models, lifecycle behavior, or data-integrity rules with easier substitutes unless explicitly authorized.
+
+## Security And Reliability Rules
+
+- When multiple roles or privileged actions exist, use RBAC or stronger scoped authorization as required by the actual product behavior.
+- Enforce object-level authorization when users should only see or mutate their own records.
+- Keep sensitive data out of logs, errors, screenshots, and seeded runtime values.
+- Return normalized user-safe errors; do not expose raw stack traces or internal file paths in normal product surfaces.
+- Make request logging, exception logging, and background failure logging meaningful enough for operators to understand what failed without leaking secrets.
+- If offline, queueing, retries, jobs, or resumability matter, implement explicit states and recovery behavior instead of vague best-effort logic.
 
 ## Rulebook Files