theslopmachine 1.0.2 → 1.0.3

package/assets/slopmachine/scaffold-playbooks/selection-matrix.md

@@ -17,7 +17,7 @@ This library replaces the old framework-default playbooks. It is organized by in
    - `type-mobile-android.md`
    - `type-desktop.md`
 4. Select independent tech modules for the exact stack pieces:
-   - frontend: `tech-frontend-vue.md`, `tech-frontend-react.md`
+    - frontend: `tech-frontend-vue.md`, `tech-frontend-react.md`
    - backend: `tech-backend-go.md`, `tech-backend-koa.md`, `tech-backend-laravel.md`, `tech-backend-gin-templ.md`
    - database: `tech-db-mysql.md`, `tech-db-postgres.md`, `tech-db-room.md`, `tech-db-localdb.md`
    - language/workspace: `tech-rust-workspace.md`
@@ -33,6 +33,13 @@ This library replaces the old framework-default playbooks. It is organized by in
 6. If no full-stack profile matches, use `stack-generic.md` plus the selected type and tech modules.
 7. Restate the relevant directives in the developer prompt; do not ask the developer to read files outside `repo/`.
 
+## Default frontend stack policy
+
+- If the prompt and adopted repo do not specify a frontend JavaScript framework for a web/frontend surface, default to Vue 3 with Vite and TypeScript and include `tech-frontend-vue.md`.
+- If the prompt and adopted repo do not specify a styling library for a web/frontend surface, default to Tailwind CSS.
+- If the prompt and adopted repo do not specify a UI component library for a frontend surface, prefer shadcn/ui when it is compatible with the selected frontend framework and does not add disproportionate complexity. If shadcn/ui is not compatible or is too heavy for the prompt, record the reason and choose the smallest compatible component approach.
+- Do not override an explicit prompt, existing repo, or platform constraint to force these defaults.
+
 ## Scaffold categories
 
 Classify scaffold gaps using this shared vocabulary:

package/assets/slopmachine/scaffold-playbooks/tech-frontend-vue.md

@@ -6,6 +6,8 @@ Use this with `type-web-spa.md` when the frontend is Vue.
 
 - Vue 3 with Vite and TypeScript unless the prompt or adopted repo requires otherwise
 - Composition API and `<script setup>` for new Vue components
+- Tailwind CSS as the default styling library when the prompt does not specify styling
+- shadcn/ui preferred for reusable UI components when compatible with Vue/project constraints; otherwise record the reason and use the smallest compatible component approach
 - Vitest for unit/component/state tests
 - Playwright for required browser flows
 

package/assets/slopmachine/scaffold-playbooks/type-web-spa.md

@@ -9,6 +9,7 @@ Use this when the product has a browser UI, whether backend-backed or browser-on
 - production build command
 - browser E2E framework when the project type is `web` or the prompt-critical UI flow needs browser proof
 - README access URL and auth/mock disclosure
+- default stack when prompt/repo are silent: Vue 3 + Vite + TypeScript, Tailwind CSS for styling, and shadcn/ui preferred for component primitives when compatible
 
 ## Runtime contract
 

package/assets/slopmachine/templates/AGENTS.md

@@ -5,17 +5,17 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 ## Scope
 
 - Treat the current working directory as the project.
-- Ignore parent-directory workflow files unless explicitly asked to use them, except accepted planning/reference docs under `../docs/` that this rulebook or the accepted project plan explicitly designates, especially `../docs/design.md`.
-- Do not treat workflow research, session exports, or sibling directories as hidden implementation instructions.
+- Ignore parent-directory process files unless explicitly asked to use them, except accepted planning/reference docs under `../docs/` that this rulebook or the accepted project plan explicitly designates, especially `../docs/design.md`.
+- Do not treat research notes, session exports, or sibling directories as hidden implementation instructions.
 - Do not make the repo depend on parent-directory docs or sibling artifacts for startup, build/preview, configuration, verification, or basic project understanding.
 
 ## Repo-Local Documentation Discipline
 
-- Keep the repo self-sufficient through code plus `README.md`, with repo-local `plan.md` as the deliberate execution-plan exception only during planning, development, and `P5`.
-- Inside the repo, `README.md` is the primary documentation file and repo-local `plan.md` is the explicit execution-plan exception only until `P5` closes.
+- Keep the repo self-sufficient through code plus `README.md`, with repo-local `plan.md` as the temporary execution-plan exception while active work is underway.
+- Inside the repo, `README.md` is the primary documentation file and repo-local `plan.md` is the explicit temporary execution-plan exception.
 - Do not create additional repo-local documentation files by default.
 - Do not add files such as `ASSUMPTIONS.md`, `NOTES.md`, `DESIGN.md`, or extra doc trees inside the repo unless explicitly asked.
-- Do not make normal project use or evaluation readiness depend on extra repo-local documentation beyond `README.md` and repo-local `plan.md` during active implementation; after `P5`, the preserved reference copy lives in `../docs/plan.md` instead.
+- Do not make normal project use or readiness depend on extra repo-local documentation beyond `README.md` and repo-local `plan.md` during active implementation; archived reference copies may live under `../docs/` when the owner provides them.
 
 ## Working Style
 
@@ -23,14 +23,14 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - Read the code before making assumptions.
 - Work in meaningful end-to-end workstreams.
 - Do not call work complete while it is still shaky.
-- Treat `plan.md` as the definitive repo-local execution plan once planning is accepted and until `P5` closes.
-- Use `../docs/design.md` for system design and architecture, and use repo-local `plan.md` for module packet execution order, file/location ownership details where needed, and completion tracking until `P5` closes.
+- Treat `plan.md` as the definitive repo-local execution plan once planning is accepted.
+- Use `../docs/design.md` for system design and architecture, and use repo-local `plan.md` for module packet execution order, file/location ownership details where needed, and completion tracking while active work is underway.
 - At the start of implementation, treat section 3 of the accepted `plan.md` as binding; do not re-choose the playbook, starter, or bootstrap path unless planning is explicitly reopened.
 - During development, treat the security execution contract, `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, `Runtime Lifecycle Checklist`, `Delivery Review Requirements`, `README Contract`, and the test coverage execution contract in `plan.md` as binding; do not leave security, release-readiness obligations, documentation, or tests as cleanup if the plan attached them to the current surface.
 - For fullstack or backend-backed frontend projects, treat the FE↔BE Integration Map in `plan.md` as binding; frontend surfaces must perform real backend-backed operations, and prompt-relevant backend features must be exposed through required frontend surfaces unless the accepted plan says they are internal/API-only.
 - Update `plan.md` in place from the main developer lane as implementation items are completed.
 - If work is interrupted, resume from the current state of `plan.md` instead of inventing a new hidden plan.
-- Once `P5` closes, the owner preserves the final truthful execution record in `../docs/plan.md` and removes repo-local `plan.md`; do not make later evaluation or packaging depend on a repo copy still existing.
+- If the owner later archives the execution record under `../docs/plan.md` and removes repo-local `plan.md`, continue using `README.md`, code, tests, scripts, and config as the repo-local source of delivery truth.
 - Respect the module packet order, file/location ownership details, and shared-file contract from `plan.md`.
 - When `plan.md` assigns a shared security foundation, finish that foundation before broader module work begins.
 - When a module packet owns a surface, it should also own the matching tests and coverage work for that surface unless `plan.md` explicitly centralizes shared harness work first.
@@ -50,9 +50,9 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - 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.
+- When the product has meaningful lifecycle 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.
+- Do not introduce convenience-based `v1` scope cuts, role simplifications, or lifecycle omissions unless they were explicitly authorized.
 
 ## Phase Boundary Discipline
 
@@ -85,10 +85,10 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - 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.
-- From planning through the end of `P7`, never run Docker runtime commands.
-- Do not run `docker compose up --build` or any equivalent Docker-based runtime command under any circumstances during planning, development, or `P7`, even if the repo documents it, a playbook suggests it, `plan.md` seems to call for it, or the owner explicitly asks.
+- During ordinary implementation, use the accepted local verification harness and targeted checks.
+- Only run Docker-based runtime or broad dockerized test commands when the active instruction or accepted plan says this is the current verification step.
 - During ordinary implementation work, do not run browser E2E or Playwright by default.
-- Use targeted local tests during ordinary implementation work, and use the prepared local test harness before major readiness claims; the owner reruns that harness in `P5`, and Docker plus dockerized `./run_tests.sh` remain deferred to `P9`.
+- Use targeted local tests during ordinary implementation work, and use the prepared local test harness before major readiness claims.
 - 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.
@@ -142,16 +142,17 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 - 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 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`.
+- README.md must include a Configuration and Environment Model section or equivalent content explaining local configuration, Docker/Compose defaults, seeded/bootstrap data, auth/no-auth, and the absence of committed `.env` requirements.
 - 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 repo-root `./run_tests.sh` as the full-app 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 primary documentation file inside the repo; repo-local `plan.md` is the explicit execution-plan exception only through `P5`, after which the preserved plan record is `../docs/plan.md`.
+- Keep `README.md` as the primary documentation file inside the repo; repo-local `plan.md` is the temporary execution-plan exception while active work is underway.
 - 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.
-- Before reporting development complete, do one deliberate reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so obvious contract drift is closed before `P5`.
+- Before reporting development complete, do one deliberate reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so obvious contract drift is closed before handoff.
 - Before reporting development complete, perform main-lane module-by-module fan-in verification: inspect each module's delivered files, confirm they are real and integrated, run the module's assigned tests after merge, confirm FE↔BE/API wiring where applicable, and update `plan.md` with the verification result.
-- Before reporting development complete, run the full non-Docker local test suite available for development after targeted module checks pass; Docker and dockerized `./run_tests.sh` remain deferred to `P9`.
+- Before reporting development complete, run the full local test suite available for development after targeted module checks pass unless the active instruction explicitly scopes verification differently.
 - Before reporting development complete, close the common late-failure classes inside development: `README.md` drift, API-spec drift, missing auth/authorization/ownership enforcement, weak validation or normalized error handling, missing owned tests, startup/test wrapper dishonesty, and partial user-facing or admin-facing flow closure.
 - Before reporting development complete, explicitly prove the core semantic path and report prompt-critical rule, role surface, lifecycle, and residual-risk status from `plan.md`.
 - If the project uses mock, stub, fake, interception, or local-data behavior, the README must disclose that scope accurately.
@@ -196,5 +197,5 @@ This file is the repo-local engineering rulebook for `slopmachine` projects.
 
 ## Rulebook Files
 
-- Do not edit `AGENTS.md` or other workflow/rulebook files unless explicitly asked.
+- Do not edit `AGENTS.md` or other rulebook files unless explicitly asked.
 - Do not rewrite or bypass `plan.md` casually once it has been accepted as the implementation checklist.

package/assets/slopmachine/templates/CLAUDE.md

@@ -5,17 +5,17 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 ## Scope
 
 - Treat the current working directory as the project.
-- Ignore parent-directory workflow files unless explicitly asked to use them, except accepted planning/reference docs under `../docs/` that this rulebook or the accepted project plan explicitly designates, especially `../docs/design.md`.
-- Do not treat workflow research, session exports, or sibling directories as hidden implementation instructions.
+- Ignore parent-directory process files unless explicitly asked to use them, except accepted planning/reference docs under `../docs/` that this rulebook or the accepted project plan explicitly designates, especially `../docs/design.md`.
+- Do not treat research notes, session exports, or sibling directories as hidden implementation instructions.
 - Do not make the repo depend on parent-directory docs or sibling artifacts for startup, build/preview, configuration, verification, or basic project understanding.
 
 ## Repo-Local Documentation Discipline
 
-- Keep the repo self-sufficient through code plus `README.md`, with repo-local `plan.md` as the deliberate execution-plan exception only during planning, development, and `P5`.
-- Inside the repo, `README.md` is the primary documentation file and repo-local `plan.md` is the explicit execution-plan exception only until `P5` closes.
+- Keep the repo self-sufficient through code plus `README.md`, with repo-local `plan.md` as the temporary execution-plan exception while active work is underway.
+- Inside the repo, `README.md` is the primary documentation file and repo-local `plan.md` is the explicit temporary execution-plan exception.
 - Do not create additional repo-local documentation files by default.
 - Do not add files such as `ASSUMPTIONS.md`, `NOTES.md`, `DESIGN.md`, or extra doc trees inside the repo unless explicitly asked.
-- Do not make normal project use or evaluation readiness depend on extra repo-local documentation beyond `README.md` and repo-local `plan.md` during active implementation; after `P5`, the preserved reference copy lives in `../docs/plan.md` instead.
+- Do not make normal project use or readiness depend on extra repo-local documentation beyond `README.md` and repo-local `plan.md` during active implementation; archived reference copies may live under `../docs/` when the owner provides them.
 
 ## Working Style
 
@@ -23,14 +23,14 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 - Read the code before making assumptions.
 - Work in meaningful end-to-end workstreams.
 - Do not call work complete while it is still shaky.
-- Treat `plan.md` as the definitive repo-local execution plan once planning is accepted and until `P5` closes.
-- Use `../docs/design.md` for system design and architecture, and use repo-local `plan.md` for module packet execution order, file/location ownership details where needed, and completion tracking until `P5` closes.
+- Treat `plan.md` as the definitive repo-local execution plan once planning is accepted.
+- Use `../docs/design.md` for system design and architecture, and use repo-local `plan.md` for module packet execution order, file/location ownership details where needed, and completion tracking while active work is underway.
 - At the start of implementation, treat section 3 of the accepted `plan.md` as binding; do not re-choose the playbook, starter, or bootstrap path unless planning is explicitly reopened.
 - During development, treat the security execution contract, `Core Semantic Path Proof`, `Prompt-Critical Rule Matrix`, `Role Surface Matrix`, `Runtime Lifecycle Checklist`, `Delivery Review Requirements`, `README Contract`, and the test coverage execution contract in `plan.md` as binding; do not leave security, release-readiness obligations, documentation, or tests as cleanup if the plan attached them to the current surface.
 - For fullstack or backend-backed frontend projects, treat the FE↔BE Integration Map in `plan.md` as binding; frontend surfaces must perform real backend-backed operations, and prompt-relevant backend features must be exposed through required frontend surfaces unless the accepted plan says they are internal/API-only.
 - Update `plan.md` in place from the main developer lane as implementation items are completed.
 - If work is interrupted, resume from the current state of `plan.md` instead of inventing a new hidden plan.
-- Once `P5` closes, the owner preserves the final truthful execution record in `../docs/plan.md` and removes repo-local `plan.md`; do not make later evaluation or packaging depend on a repo copy still existing.
+- If the owner later archives the execution record under `../docs/plan.md` and removes repo-local `plan.md`, continue using `README.md`, code, tests, scripts, and config as the repo-local source of delivery truth.
 - Respect the module packet order, file/location ownership details, and shared-file contract from `plan.md`.
 - When `plan.md` assigns a shared security foundation, finish that foundation before broader module work begins.
 - When a module packet owns a surface, it should also own the matching tests and coverage work for that surface unless `plan.md` explicitly centralizes shared harness work first.
@@ -49,9 +49,9 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 - 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.
+- When the product has meaningful lifecycle 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.
+- Do not introduce convenience-based `v1` scope cuts, role simplifications, or lifecycle omissions unless they were explicitly authorized.
 
 ## Phase Boundary Discipline
 
@@ -84,10 +84,10 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 - 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.
-- From planning through the end of `P7`, never run Docker runtime commands.
-- Do not run `docker compose up --build` or any equivalent Docker-based runtime command under any circumstances during planning, development, or `P7`, even if the repo documents it, a playbook suggests it, `plan.md` seems to call for it, or the owner explicitly asks.
+- During ordinary implementation, use the accepted local verification harness and targeted checks.
+- Only run Docker-based runtime or broad dockerized test commands when the active instruction or accepted plan says this is the current verification step.
 - During ordinary implementation work, do not run browser E2E or Playwright by default.
-- Use targeted local tests during ordinary implementation work, and use the prepared local test harness before major readiness claims; the owner reruns that harness in `P5`, and Docker plus dockerized `./run_tests.sh` remain deferred to `P9`.
+- Use targeted local tests during ordinary implementation work, and use the prepared local test harness before major readiness claims.
 - 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.
@@ -141,16 +141,17 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 - 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 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`.
+- README.md must include a Configuration and Environment Model section or equivalent content explaining local configuration, Docker/Compose defaults, seeded/bootstrap data, auth/no-auth, and the absence of committed `.env` requirements.
 - 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 repo-root `./run_tests.sh` as the full-app 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 primary documentation file inside the repo; repo-local `plan.md` is the explicit execution-plan exception only through `P5`, after which the preserved plan record is `../docs/plan.md`.
+- Keep `README.md` as the primary documentation file inside the repo; repo-local `plan.md` is the temporary execution-plan exception while active work is underway.
 - 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.
-- Before reporting development complete, do one deliberate reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so obvious contract drift is closed before `P5`.
+- Before reporting development complete, do one deliberate reread against the accepted `plan.md`, `../docs/design.md`, accepted `../docs/api-spec.md` when applicable, `README.md`, and the integrated repo so obvious contract drift is closed before handoff.
 - Before reporting development complete, perform main-lane module-by-module fan-in verification: inspect each module's delivered files, confirm they are real and integrated, run the module's assigned tests after merge, confirm FE↔BE/API wiring where applicable, and update `plan.md` with the verification result.
-- Before reporting development complete, run the full non-Docker local test suite available for development after targeted module checks pass; Docker and dockerized `./run_tests.sh` remain deferred to `P9`.
+- Before reporting development complete, run the full local test suite available for development after targeted module checks pass unless the active instruction explicitly scopes verification differently.
 - Before reporting development complete, close the common late-failure classes inside development: `README.md` drift, API-spec drift, missing auth/authorization/ownership enforcement, weak validation or normalized error handling, missing owned tests, startup/test wrapper dishonesty, and partial user-facing or admin-facing flow closure.
 - Before reporting development complete, explicitly prove the core semantic path and report prompt-critical rule, role surface, lifecycle, and residual-risk status from `plan.md`.
 - If the project uses mock, stub, fake, interception, or local-data behavior, the README must disclose that scope accurately.
@@ -195,5 +196,5 @@ This file is the repo-local engineering rulebook for `slopmachine-claude` projec
 
 ## Rulebook Files
 
-- Do not edit `CLAUDE.md` or other workflow/rulebook files unless explicitly asked.
+- Do not edit `CLAUDE.md` or other rulebook files unless explicitly asked.
 - Do not rewrite or bypass `plan.md` casually once it has been accepted as the implementation checklist.

package/assets/slopmachine/templates/plan.md

@@ -32,7 +32,8 @@ This file is the authoritative execution checklist inside the repo.
 - Tests travel with implementation
 - Shared files are main-lane controlled
 - Runtime/test must remain honest and portable
-- Final integrated verification and hardening is mandatory
+- Final integrated local verification and hardening is mandatory
+- External planning documents under `../docs/` are planning/reference inputs only. Delivery evidence must exist inside the repo through `README.md`, code structure, route/app/server registration, tests, scripts, config/manifests, Docker/runtime files, and seeded/bootstrap paths where applicable. Do not rely on parent-directory docs as the only evidence for any final delivery, runtime, README, API, frontend, security, or test obligation.
 
 ### 1.3 Handoff exceptions
 | Exception | Why it exists | Impact | Required owner decision |
@@ -49,13 +50,17 @@ This file is the authoritative execution checklist inside the repo.
 - Shared-foundation-first rule:
 - Parallelization rule:
 - Merge discipline rule:
-- Final convergence rule: `P5` is one minimal gate that includes the owner-run local test harness. If that passes and the repo is roughly coherent with `plan.md`, stop and ask whether to proceed to evaluation. Fix only owner-side local-harness/config/wrapper/README/docs/light-script churn there, reroute any real code or actual test-file work back to the developer, and defer Docker/runtime plus dockerized `./run_tests.sh` to final packaging confirmation.
+- Final convergence rule: once implementation is complete, run the accepted local harness, reconcile the repo against `plan.md`, fix narrow docs/config/wrapper/light-script issues directly when assigned, route real code or test-file fixes through the active correction workstream, and leave Docker/runtime plus dockerized `./run_tests.sh` for the explicit final runtime confirmation step.
+
+If your active instruction asks only for implementation readiness, report readiness after integrated local verification and a truthful handoff.
+
+If an implementation agent is explicitly asked to complete the product end to end in one autonomous execution run, it must not stop at the rough local gate. It must continue through all implementation, assigned tests, README/runtime/script reconciliation, integrated local verification, and final truthful handoff unless the active instruction explicitly says to stop earlier.
 
 ---
 
 ## 3. Scaffold Step at the Start of Development
 
-This section is planned during `P2` and then executed as the first step of development. It is not a separate lifecycle phase or owner gate.
+This section is planned before implementation and then executed as the first step of development. It is not a separate product feature.
 
 This scaffold step should be strict and straightforward. Its job is only to establish the minimal honest delivery baseline before real feature development starts.
 
@@ -64,10 +69,12 @@ This scaffold step should be strict and straightforward. Its job is only to esta
 - Exact bootstrap command:
 - Expected directories/files immediately after bootstrap:
 - Language/framework bootstrap notes to preserve:
+- Frontend defaults applied if prompt/repo are silent: Vue 3 + Vite + TypeScript, Tailwind CSS, and shadcn/ui when compatible:
 - Minimal bootstrap proof surface to land now (for example a hello-world route/page/app shell):
 - Docker/runtime setup required in this step so the owner can later run `docker compose up --build` during final packaging confirmation:
+- Seeded quick-start data strategy required in this step, or `Not Applicable` with reason:
 - `./run_tests.sh` setup required in this step as the dockerized broad-test path reserved for final packaging confirmation:
-- Local test harness setup required in this step so development and owner-side `P5` can use it:
+- Local test harness setup required in this step so implementation and later local readiness checks can use it:
 This should name the stack-native local suite explicitly, for example Vitest, Jest, PHPUnit, pytest, go test, cargo test, or another framework-native equivalent.
 - Reliability rules the local test harness and deferred Docker/runtime plus dockerized broad-test path must satisfy later:
 Include what must be installed/configured locally if the stack-native local suite is not already available on the machine.
@@ -82,10 +89,11 @@ Include what must be installed/configured locally if the stack-native local suit
 
 - bootstrap the project for the selected language/framework/runtime with only a minimal hello-world-style proof surface
 - set up the real Docker/runtime path required by the project so the owner can run `docker compose up --build` later during final packaging confirmation
+- set up deterministic, idempotent seeded quick-start data through the normal bootstrap/database/runtime path when the product is not useful from an empty state
 - set up repo-root `./run_tests.sh` as the real dockerized broad-test entrypoint for the later final packaging confirmation run
 - make the local test harness and deferred Docker/runtime plus dockerized broad-test path reviewably reliable: no hidden setup steps, no manual exports for Docker, no hidden shell state for local tests, deterministic execution, and useful failure output
 - do not run Docker or dockerized `./run_tests.sh` during the scaffold step; prepare the local harness for immediate development use
-- set up the local testing harness/tooling used for ordinary development and owner-side `P5`
+- set up the local testing harness/tooling used for ordinary development and later local readiness checks
 - set up `README.md` to the exact required template/section shape
 - keep the scaffold free of prompt-specific business logic, deep domain implementation, or polish work beyond the baseline needed to prove startup and test wiring
 - require the scaffold to avoid local dependency setup beyond Docker and the documented host minimums
@@ -127,14 +135,17 @@ Required for any role-sensitive project. If not applicable, state `Not Applicabl
 |---|---|---|---|---|---|---|---|---|---|
 |  |  |  |  |  |  |  |  |  |  |
 
-Any contradiction between this matrix and `../docs/design.md`, `../docs/api-spec.md`, router/frontend behavior, backend checks, README, or tests is a planning defect before development and a release-alignment defect before evaluation.
+Any contradiction between this matrix and `../docs/design.md`, `../docs/api-spec.md`, router/frontend behavior, backend checks, README, or tests is a planning defect before development and a release-alignment defect before handoff.
 
 ---
 
 ## 5. Test Coverage Execution Contract
 
 ### 5.1 Coverage target and floor
-- Coverage target: meaningful mapped tests for every evaluator-relevant endpoint, core flow, security boundary, and major failure path
+- Coverage target: meaningful mapped tests for every delivery-relevant endpoint, core flow, security boundary, and major failure path
+- Unit coverage floor: at least `90%` line/branch coverage for unit-testable product code where stack tooling can measure this honestly; otherwise name the exact measurement limitation and substitute a complete file/function/assertion ledger
+- E2E/platform coverage floor: at least `90%` of planned prompt-critical E2E/platform flow rows complete before clean development completion; otherwise name the exact accepted exception and compensating proof
+- API coverage floor when APIs exist: `100%` of documented prompt-relevant `METHOD + PATH` surfaces have true no-mock HTTP tests unless a per-endpoint narrow exception and compensating proof are recorded
 - Measurement path:
 - Confidence notes / expected weak spots if any:
 
@@ -170,7 +181,7 @@ Any contradiction between this matrix and `../docs/design.md`, `../docs/api-spec
 ### 5.5 Frontend coverage obligations
 If applicable:
 - frontend unit tests required? [yes/no]
-- Frontend unit tests verdict for later audit: [PRESENT | MISSING]
+- Frontend unit tests status for later review: [PRESENT | MISSING]
 - frontend unit-test file-level evidence plan:
 - important frontend components/modules that must not remain untested:
 - component/state tests:
@@ -294,9 +305,10 @@ The final `README.md` must include these sections exactly:
 8. verification method
 9. testing
 10. authentication and roles
-11. workflow / operational notes if applicable
-12. feature-flag/mock/debug/demo disclosure if applicable
-13. important limitations or non-goals if material
+11. quick-start seeded data
+12. lifecycle / operational notes if applicable
+13. feature-flag/mock/debug/demo disclosure if applicable
+14. important limitations or non-goals if material
 
 ### 6.1 Required command strings
 - `docker compose up --build`
@@ -309,6 +321,13 @@ Choose one:
 - credentials table for every relevant role
 - exact statement `No authentication required`
 
+### 6.2.1 Quick-start seeded data rule
+Choose one:
+- seeded accounts/sample records/fixture data table with values, roles, IDs, URLs, and steps needed to exercise the main flows quickly
+- exact statement `No seeded data required; the app is useful from an empty state` with a short reason
+
+Seeded data must be deterministic and idempotent. It must be created by the normal runtime/bootstrap/database path, not by hidden manual setup. It may provide local demo/test fixtures, but it must not replace real product behavior with fake success paths or static demo-only UI.
+
 ### 6.3 Ownership rule
 - Main-lane owner:
 - Parallel lanes may propose updates through:
@@ -395,12 +414,29 @@ Each module packet must carry this checklist into development. A module may not
 |  |  |  |  |  |  | planned |
 
 ### 9.6 Development exit module verification matrix
-Complete this before leaving development for owner-side integrated verification. Use the stack-native local suite and targeted module tests; Docker and dockerized `./run_tests.sh` remain deferred to final packaging confirmation.
+Complete this before claiming development readiness. Use the stack-native local suite and targeted module tests; Docker and dockerized `./run_tests.sh` remain deferred to the explicit final runtime confirmation step.
 
 | Module | Files reviewed by main lane | Module tests run | FE↔BE wiring verified | API/route coverage verified | E2E/platform proof status | Integration issues found/fixed | Exit status |
 |---|---|---|---|---|---|---|---|
 |  |  |  |  |  |  |  | pending |
 
+### 9.7 Plan-Row Execution Ledger
+Every actionable plan row must appear here or in an equivalent section-specific checklist. This ledger is the source of truth for whether `plan.md` was actually executed, not merely referenced.
+
+| Plan section / row | Required implementation evidence | Required verification evidence | Responsible module/work package | Status | Blocker / risk / exception |
+|---|---|---|---|---|---|
+|  |  |  |  | planned |  |
+
+Clean development completion requires every row to be `complete`, `not applicable`, or explicitly `risk accepted` with evidence. Rows left `planned`, `in progress`, `delegated without receiver`, or `unverified` block completion.
+
+### 9.8 Coverage Closure Ledger
+
+| Coverage surface | Required floor | Measured / closed result | Evidence path | Exception / compensating proof | Status |
+|---|---|---|---|---|---|
+| API true no-mock HTTP coverage for documented prompt-relevant endpoints | 100% |  |  |  | planned |
+| Unit-testable product-code line/branch coverage | >=90% where measurable |  |  |  | planned |
+| Planned E2E/platform-critical flow coverage | >=90% closed rows |  |  |  | planned |
+
 ---
 
 ## 9.7 In-Scope Domains / Modules Summary
@@ -471,10 +507,17 @@ Every accepted requirement, clarification, design no-orphan row, and API spec ro
 ### 13.1 Prompt-Critical Rule Matrix
 Every prompt-critical rule must have an owner and a proof path. Include dates, thresholds, limits, states, scheduling/timing, retries, security constraints, public/private boundaries, actor identity, and operator promises.
 
-| Source prompt phrase / accepted clarification | Normalized rule | Implementation owner | Test owner | README/doc implication | P5 proof expectation | Status |
+| Source prompt phrase / accepted clarification | Normalized rule | Implementation owner | Test owner | README/doc implication | Local proof expectation | Status |
 |---|---|---|---|---|---|---|
 |  |  |  |  |  |  | planned |
 
+### 13.1.1 Prompt Verb Acceptance Matrix
+Every action verb in the original prompt or accepted clarification that implies product behavior must have an acceptance row. Use this to prevent broad nouns such as `dashboard`, `lifecycle`, `approval`, `export`, or `sync` from hiding missing actor actions.
+
+| Source phrase / verb | Actor | Starting state / fixture | Action performed | Required state change or side effect | Observable UI/API/artifact result | Negative or edge behavior | Proof path | Owning module |
+|---|---|---|---|---|---|---|---|---|
+|  |  |  |  |  |  |  |  |  |
+
 ### 13.2 Scaffold Versus Product Completion Matrix
 
 Use this to prevent setup shells from being mistaken for delivered behavior. A row may move to `done` only when the product-facing path is wired to real behavior and tests.
@@ -491,7 +534,7 @@ Use this to prevent setup shells from being mistaken for delivered behavior. A r
 
 ## 14. State / Lifecycle Rules
 
-| Entity / workflow | States | Valid transitions | Invalid transitions | Required cleanup |
+| Entity / lifecycle | States | Valid transitions | Invalid transitions | Required cleanup |
 |---|---|---|---|---|
 |  |  |  |  |  |
 
@@ -563,12 +606,22 @@ Complete only when the product has background work, timed behavior, async jobs,
 - If yes, where it is called:
 - If no, why not applicable:
 
+### 18.4 Seeded quick-start data
+- Seeded data applicable? [yes/no]
+- If yes, seed entrypoint and when it runs:
+- Idempotency rule:
+- Seeded accounts / roles:
+- Seeded sample records / IDs / URLs:
+- Main flows the seeded data unlocks:
+- README quick-start section owner:
+- If no, why the app is useful from empty state:
+
 ---
 
 ## 19. Delivery Review Requirement Matrices
 
 ### 19.0 Core Semantic Path Proof
-This is the centerpiece path that proves the product is not only a shell. `P5` cannot close unless this path is explicitly proven or the user accepts a named residual risk.
+This is the centerpiece path that proves the product is not only a shell. Do not claim implementation readiness unless this path is explicitly proven or the user accepts a named residual risk.
 
 | Field | Required value |
 |---|---|
@@ -580,10 +633,10 @@ This is the centerpiece path that proves the product is not only a shell. `P5` c
 | Expected failure-mode behavior |  |
 | Test file(s) proving the path |  |
 | Manual/runtime proof if automated proof is not feasible |  |
-| P5 acceptance evidence expected |  |
+| Local readiness evidence expected |  |
 
 ### 19.0.1 Prompt-critical proof ledger
-Use this ledger during development and `P5` to prevent planned-but-missing drift.
+Use this ledger during development and readiness hardening to prevent planned-but-missing drift.
 
 | Planned claim | Required proof | Current proof location | Gap | Decision |
 |---|---|---|---|---|
@@ -606,7 +659,10 @@ Use this ledger during development and `P5` to prevent planned-but-missing drift
 | entry points visible |  |  |  |
 | route registration visible |  |  |  |
 | config path centralized |  |  |  |
+| README/docs/scripts/routes/config/examples/manifests/env examples statically consistent |  |  |  |
 | module boundaries visible |  |  |  |
+| no excessive single-file implementation or fragmented snippets |  |  |  |
+| redundant/unnecessary files removed or justified |  |  |  |
 | mock/local-data boundary visible |  |  |  |
 
 ### 19.3 Runtime and broad-test contract obligations matrix
@@ -646,12 +702,16 @@ Use this ledger during development and `P5` to prevent planned-but-missing drift
 | Obligation | Planned repo evidence | Planned verification evidence | Owning lane |
 |---|---|---|---|
 | pages/routes/screens complete |  |  |  |
+| pages/routes/app shell connected |  |  |  |
 | core interactions complete |  |  |  |
+| state/data flow organized and traceable |  |  |  |
+| service/adaptor/mock/storage boundaries clear |  |  |  |
 | task closure real |  |  |  |
 | UI states complete |  |  |  |
 | validation/disclosure explicit |  |  |  |
 | frontend test obligations explicit |  |  |  |
 | static visual/interaction quality evidence planned |  |  |  |
+| pure-frontend mock/local data disclosed without implying backend integration where applicable |  |  |  |
 
 ### 19.7 End-to-end and platform verification obligations matrix
 | Obligation | Planned repo evidence | Planned verification evidence | Owning lane |
@@ -671,9 +731,13 @@ Use this ledger during development and `P5` to prevent planned-but-missing drift
 | access method documented |  |  |  |
 | verification method documented |  |  |  |
 | credentials/no-auth disclosure correct |  |  |  |
+| quick-start seeded data or empty-state rationale documented |  |  |  |
+| Configuration and Environment Model explains local config, runtime defaults, Docker/Compose defaults, seeded/bootstrap data, auth/no-auth, no committed `.env` requirement, no manual package/runtime/database setup beyond documented host prerequisites, and config-sensitive verification |  | static README/config check |  |
 | no manual install/runtime setup dependency (`npm install`, `pip install`, `apt-get`, manual DB setup, `.env`, `.env.example`) |  | static README/config check |  |
 | mock/debug/demo disclosure honest |  |  |  |
 
+If no configuration is required, the README should state: `No manual environment configuration is required for local Docker startup. The delivered local runtime uses repo-controlled Docker/Compose defaults and bootstrap paths.`
+
 ---
 
 ## 20. Shared-File Contract
@@ -682,6 +746,13 @@ Use this ledger during development and `P5` to prevent planned-but-missing drift
 |---|---|---|---|---|
 |  |  |  |  |  |
 
+### 20.0 Canonical Cross-Surface Contracts
+Use this when data crosses boundaries between UI, API, jobs, imports, exports, notifications, files, reports, clipboard payloads, templates, or third-party adapters. If not applicable, state `Not Applicable`.
+
+| Contract / payload | Surfaces using it | Canonical schema or fields | Validation / normalization rule | Producer | Consumer | Tests / proof | README or docs implication |
+|---|---|---|---|---|---|---|---|
+|  |  |  |  |  |  |  |  |
+
 ### 20.1 Shared foundation to land before module execution
 -
 -
@@ -731,6 +802,13 @@ Each module must produce this packet before the next module starts:
 - Shared integration required from main lane
 - Known risks or `none`
 
+### 21.1.1.1 Plan Section Closure Evidence
+Every major completion claim must cite the accepted `plan.md` sections it closes. A development-complete report is incomplete if it only summarizes work without mapping back to section-addressable plan evidence.
+
+| Plan section / matrix row | Closure evidence | Test or verification result | Residual risk or blocker | Decision |
+|---|---|---|---|---|
+|  |  |  |  |  |
+
 ### 21.1.2 Module Integration Consumption Rule
 
 - Inspect each module completion checklist before moving to the next module
@@ -805,36 +883,37 @@ For `web` and `fullstack`, frontend unit/component/state tests are required unle
 - Platform honesty notes:
 - Rerun triggers after major merges:
 
-This section is about overall delivery verification planning. It must not imply that such proof runs before evaluation or before the owner-side pre-submission step.
+This section is about overall delivery verification planning. It must not imply that every broad proof runs during ordinary implementation unless the active instruction asks for it.
 
 ---
 
 ## 26. Integrated Verification and Hardening Plan
 
-### 27.1 Broad final proof
-- Static/non-Docker checks to use before evaluation:
-- Proceed-to-evaluation rule when those checks pass:
+### 26.1 Broad final proof
+- Static/non-Docker checks to use before readiness handoff:
+- Readiness handoff rule when those checks pass:
 - Major flow proof required:
 - Security/auth proof required:
 - Runtime/README contract proof required:
 - Coverage proof required:
-- Required internal `P5` issue-discovery loop: one evaluator subagent session; send the exact prepared evaluation packet once; run four additional same-session scans for additional prompt-fit/compliance, security, delivery, test-coverage, README/static-verifiability, mock/demo/fake-success, and frontend state/interaction issues not already reported; do not remediate between rounds; save five reports and extracted Blocker/High findings under `../.ai/p5-evaluation/`; consolidate, owner-analyze, route one developer remediation brief, verify fixes, then continue to the proceed-to-evaluation pause
-- Development-completion audit before `P5`: reread original prompt, approved requirements breakdown, accepted clarifications, accepted design, accepted API spec when applicable, accepted `plan.md`, `../docs/test-coverage.md`, `README.md`, code, tests, and current proof in one sweep; every module row must be marked complete, blocked, or explicitly risk-accepted before handoff
-- P3 Development Completion Report must include: modules completed, requirements closed, files/routes/tests changed, unit/API/integration/E2E/frontend-state commands run, FE↔BE/API/data proof, edge/failure/security proof, remaining risks, and exact handoff status for `P5`
+- Independent readiness review expectation: after implementation, the repo must withstand a strict prompt-fit, security, delivery, test-coverage, README/static-verifiability, mock/demo/fake-success, and frontend state/interaction review. Fix all concrete Blocker/High-equivalent issues before handoff unless the user explicitly accepts the risk.
+- Development-completion review: reread original prompt, approved requirements breakdown, accepted clarifications, accepted design, accepted API spec when applicable, accepted `plan.md`, `../docs/test-coverage.md`, `README.md`, code, tests, and current proof in one sweep; every module row must be marked complete, blocked, or explicitly risk-accepted before handoff
+- Development Completion Report must include: modules completed, requirements closed, files/routes/tests changed, unit/API/integration/E2E/frontend-state commands run, FE↔BE/API/data proof, edge/failure/security proof, remaining risks, and exact readiness handoff status
+- Development Completion Report must include Plan Section Closure Evidence for every major plan section or matrix row that claims completion
 
-### 27.2 Narrow rerun strategy after discovered failures
-- Owner pass scope rule: every `P5` owner pass must reread the accepted design, accepted `../docs/api-spec.md` when applicable, `plan.md`, `README.md`, repo state, and current evidence in one full sweep rather than reducing follow-up passes to targeted sections only
+### 26.2 Narrow rerun strategy after discovered failures
+- Review scope rule: each integrated readiness pass must reread the accepted design, accepted `../docs/api-spec.md` when applicable, `plan.md`, `README.md`, repo state, and current evidence in one full sweep rather than reducing follow-up passes to targeted sections only
 - Known failure class isolation rule:
 - Narrow rerun examples:
 - When to stop broad reruns:
 - Issue-batching rule for integrated verification:
 - Owner-side fixes allowed directly before reroute:
-- Remediation expectation: default to ordered fixes through the main developer lane; use helper work only for genuinely independent fixes where that is safer, and require per-bundle verification plus integrated proof before accepting completion
-- Maximum owner sweep expectation from `P5` before evaluation: 3
-- Maximum developer reroute expectation from `P5` before evaluation:
+- Remediation expectation: default to ordered fixes through the active correction workstream, use helper work only for genuinely independent fixes where that is safer, and require per-bundle verification plus integrated proof before accepting completion
+- Maximum integrated readiness sweep expectation before handoff: 3
+- Maximum correction reroute expectation before handoff:
 
-### 27.3 Optional UI/platform sanity checks before evaluation
-- When extra UI/platform sanity is actually needed before evaluation:
+### 26.3 Optional UI/platform sanity checks before handoff
+- When extra UI/platform sanity is actually needed before handoff:
 - Screenshot review requirements if used:
 - Web/fullstack Playwright sanity if used:
 - Desktop Playwright Electron/Xvfb or equivalent sanity if used:
@@ -843,15 +922,15 @@ This section is about overall delivery verification planning. It must not imply
 - Visual regression notes if used:
 - Artifact storage notes if used:
 
-### 27.4 Doc tightening after verification
+### 26.4 Doc tightening after verification
 - `README.md`:
 - `../docs/design.md` if applicable:
 - `../docs/api-spec.md` if applicable:
 - `../docs/test-coverage.md` if applicable:
 
-### 27.5 Final close conditions
-- No major prompt, product, security, or runtime breakage remains obvious enough to make evaluation premature
-- Development-completion audit is done and the handoff to `P5` names exact passed checks, skipped/deferred checks, and residual risks
+### 26.5 Final close conditions
+- No major prompt, product, security, or runtime breakage remains obvious enough to make handoff premature
+- Development-completion review is done and the handoff names exact passed checks, skipped/deferred checks, and residual risks
 - Docker execution remains deferred until final packaging confirmation
 
 ---
@@ -863,7 +942,7 @@ This section is about overall delivery verification planning. It must not imply
 - Confirm mock/debug/demo disclosure:
 - Confirm shared-file coherence:
 - Confirm coverage docs and README match reality:
-- Confirm Docker files and dockerized `./run_tests.sh` are ready for final packaging confirmation, and confirm the separate local test harness is ready for ordinary development plus owner-side `P5`:
+- Confirm Docker files and dockerized `./run_tests.sh` are ready for explicit final runtime confirmation, and confirm the separate local test harness is ready for ordinary development plus later readiness checks:
 
 ---