theslopmachine 1.0.2 → 1.0.3

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

@@ -1,15 +1,15 @@
-# Phase 2 Execution Planning Prompt
+# Execution Planning Prompt
 
-You are the execution planning lead for a software delivery that already has an accepted Phase 1 design document.
+You are the execution planning lead for a software delivery that already has an accepted design document.
 
 Your task is to convert the accepted design into the authoritative execution plan.
 
-This phase produces:
+This planning pass produces:
 `plan.md`
 
-When applicable, this phase must also write or update parent-root `../docs/test-coverage.md` so the external coverage reference already reflects the accepted planning-time coverage contract rather than remaining a blank seed or stale placeholder.
+When applicable, this planning pass must also write or update parent-root `../docs/test-coverage.md` so the external coverage reference already reflects the accepted planning-time coverage contract rather than remaining a blank seed or stale placeholder.
 
-This phase is the critical execution contract.
+This plan is the critical execution contract.
 It must operationalize the accepted design without reinterpreting it.
 
 ---
@@ -18,13 +18,13 @@ It must operationalize the accepted design without reinterpreting it.
 
 ### Design Contract Obedience
 
-The accepted Phase 1 design is binding.
+The accepted design is binding.
 
 You must:
 - treat the accepted design as the locked product contract
 - preserve the original prompt plus the accepted requirements-and-clarification baseline as already resolved by the design
 - convert the design into a concrete execution plan
-- make the plan actionable, test-complete, and merge-safe
+- make the plan actionable, test-complete, and integration-safe
 - carry forward all design-level runtime, security, coverage, README, and review obligations into execution form
 
 You must not:
@@ -34,7 +34,7 @@ You must not:
 - defer critical delivery obligations to “cleanup later”
 - separate implementation work from its required tests
 - allow shared files to become uncontrolled churn
-- leave the final verification/hardening phase vague
+- leave final verification and hardening vague
 
 If you discover a contradiction, gap, or impossible dependency in the design:
 - flag it explicitly as a handoff exception
@@ -42,13 +42,13 @@ If you discover a contradiction, gap, or impossible dependency in the design:
 - propose the narrowest correction
 - do not silently rewrite the contract
 
-When an execution-planning decision depends on framework, library, API, platform, or tool specifics, verify the decision against authoritative documentation first and targeted current research second. Do not guess about important stack behavior.
+When an execution-planning decision depends on framework, library, API, platform, or tool specifics, verify the decision with the Context7 CLI/skill first and targeted current research second. Use `npx ctx7@latest library <name> "<question>"` before `npx ctx7@latest docs <libraryId> "<question>"` unless a valid Context7 library id is already known. Do not guess about important stack behavior.
 
 ---
 
-## Phase Boundary
+## Planning Boundary
 
-This is an execution-planning phase.
+This is an execution-planning task.
 
 Do not:
 - write implementation code
@@ -59,7 +59,7 @@ Do not:
 - invent new product meaning
 - bypass the design by making convenience decisions that should have been locked earlier
 
-This phase must decide exactly how the system will be built and verified.
+This plan must decide exactly how the system will be built and verified.
 
 ---
 
@@ -74,36 +74,41 @@ Produce `plan.md` as an ordered, section-addressable, resume-friendly execution
 - collision-safe Compose/runtime assumptions where relevant
 - explicit security execution contract
 - explicit prompt-critical rule matrix derived from exact prompt language and accepted clarifications
+- explicit prompt verb acceptance matrix derived from action verbs in the prompt and accepted clarifications
 - explicit role surface matrix for any role-sensitive project
 - explicit test coverage execution contract
-- explicit core semantic path proof target and expected `P5` evidence
+- explicit core semantic path proof target and expected local readiness evidence
 - explicit delivery-review requirement matrices
-- explicit module-first decomposition before any file/path ownership details
-- a minimal file/location ownership map only where it is needed to make module packets executable
+- explicit module-first decomposition before any file/path responsibility details
+- a minimal file/location responsibility map only where it is needed to make module packets executable
 - shared-file contract that lands before module execution
-- ordered module packets derived from the module ownership map rather than only abstract feature buckets
+- canonical cross-surface contracts for shared schemas, payloads, imports, exports, notifications, reports, clipboard content, templates, and adapter boundaries where applicable
+- ordered module packets derived from the module responsibility map rather than only abstract feature buckets
 - optional independent helper work only when it is clearly safer than normal sequential execution
-- file/location ownership by module wherever realistically useful
+- file/location responsibility by module wherever realistically useful
 - tests traveling with implementation
 - per-module integration targets and final cross-module verification
-- final integrated verification and hardening plan that gets the workflow to evaluation quickly rather than creating a long pre-evaluation fix loop
-- cleanup before final delivery review
+- final integrated verification and hardening plan that gets the repo to truthful readiness quickly rather than creating a long fix loop
+- plan-section closure evidence that the developer must cite in major completion claims
+- cleanup before final delivery
 
 ---
 
 ## Non-Negotiable Rules
 
-### 0. Plan must operationalize the final evaluator prompts exactly
-The plan must turn the accepted design into concrete repo evidence for the final static evaluation prompts and the unified test-coverage/README prompt. Keep this compact and implementation-facing; do not add process-only bloat.
+### 0. Plan must operationalize the delivery contract exactly
+The plan must turn the accepted design into concrete repo evidence for strict product, security, test, and README verification. Keep this compact and implementation-facing; do not add process-only bloat.
 
-The plan must explicitly require these evaluator-judged deliverables when applicable:
+The plan must explicitly require these delivery-critical artifacts when applicable:
 - repo-root `README.md` with project type near the top using exactly one of `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop`
+- static consistency across README/docs/scripts/routes/config/examples/manifests/env examples, with entry points and project structure traceable without running the app
 - README startup instructions containing `docker compose up --build` as the primary runtime contract and the exact legacy compatibility string `docker-compose up` without making it primary
 - README access method: URL/port for backend/web/fullstack, emulator/device steps for mobile, launch steps for desktop
 - README verification method: API curl/Postman, UI flow, mobile screen usage, or desktop interaction as applicable
 - README auth disclosure: credentials for every role if auth exists, otherwise exact statement `No authentication required`
+- README quick-start seeded data disclosure: for any app that is not useful from an empty state, the delivered runtime must create deterministic local demo/test data through the normal bootstrap path and the README must list the seeded accounts, sample records, URLs, IDs, or steps needed to exercise the main flows quickly
 - no README/runtime dependence on `npm install`, `pip install`, `apt-get`, manual DB setup, runtime installs, `.env`, or `.env.example`
-- repo-root dockerized `./run_tests.sh`; local dependency based broad-test scripts may exist only as developer convenience, not the final audit contract
+- repo-root dockerized `./run_tests.sh`; local dependency based broad-test scripts may exist only as developer convenience, not the broad delivery contract
 - API endpoint inventory for every backend/fullstack route as exact `METHOD + fully resolved PATH`, including prefixes/versioning/nested routers
 - API test plan per endpoint: covered yes/no target, test type (`true no-mock HTTP`, `HTTP with mocking`, or `unit-only / indirect`), planned files, request input, response content/side effect, and key assertion
 - API coverage summary must be computable from the plan when APIs exist: total endpoints, endpoints with HTTP tests, endpoints with true no-mock HTTP tests, HTTP coverage percentage, true API coverage percentage, and mocked/indirect exceptions
@@ -112,20 +117,22 @@ The plan must explicitly require these evaluator-judged deliverables when applic
 - frontend unit/component/state tests for `fullstack` and `web` projects that import/render actual frontend modules; do not let package.json alone count as evidence
 - frontend state coverage for loading, empty, error, submitting, disabled, success/failure, validation, duplicate/re-entry, and prompt-critical search/filter/sort/pagination
 - frontend static quality coverage for web/fullstack/frontend work: layout hierarchy, spacing/alignment consistency, theme/content fit, font/icon consistency, and static support for hover/click/disabled/current-state styling where applicable
+- frontend structure credibility for web/fullstack/frontend work: connected pages/routes/app shell, organized state/data flow, credible service/adaptor/mock/storage boundaries, and no excessive single-file or fragmented-snippet delivery
 - fullstack major-flow FE↔BE tests or platform-equivalent proof; if missing, the plan must name the compensating API/unit proof and residual risk
 - security test/proof rows for authentication, route authorization, object-level authorization, tenant/user isolation, and admin/internal/debug protection
 - logging/observability and sensitive-data leakage checks for logs, responses, console, analytics, storage, and visible UI where applicable
 - mock/local/demo/debug disclosure and fake-success prevention in README, UI, and tests
+- pure-frontend mock/local-data boundary honesty: for `web` projects with no backend service, mock/local data is allowed when disclosed, but docs/UI must not imply real backend integration and fake-success paths must not hide missing failure handling
 
-Every item above must map to a module packet, README task, API coverage row, frontend coverage row, or final verification row. If not applicable, state `Not Applicable` with a short reason. Do not leave evaluator obligations only in broad prose.
+Every item above must map to a module packet, README task, API coverage row, frontend coverage row, or final verification row. If not applicable, state `Not Applicable` with a short reason. Do not leave delivery obligations only in broad prose.
 
 ### 1. Every planned element must travel with tests
 For every meaningful planned element, the plan must state:
 - what is being implemented
 - where it will live
 - which tests must exist
-- which module or owner owns those tests
-- what proof is expected before merge
+- which module or responsible implementer owns those tests
+- what proof is expected before integration
 
 Plan the whole prompt-relevant app surface early.
 Do not stop at only major modules or a sample of happy paths.
@@ -137,7 +144,7 @@ When frontend surfaces exist, plan explicit flow-by-flow state coverage for load
 No orphan requirements are allowed in `plan.md`. Every requirement ID from the accepted requirements breakdown, every accepted clarification that affects delivery, every design no-orphan row, and every API spec route must map to at least one module packet and one proof path. If a requirement is intentionally not implemented, the plan must name the exact accepted out-of-scope or non-applicability rationale; vague `not needed`, `later`, `covered generally`, or `internal` language is a planning defect.
 
 ### 1.5 Module-first planning before files and execution order
-Before writing module execution order or any file/location ownership details, identify the real modules/domains/product units from the accepted design, API spec, prompt requirements, and current repo tree.
+Before writing module execution order or any file/location responsibility details, identify the real modules/domains/product units from the accepted design, API spec, prompt requirements, and current repo tree.
 
 The module map is not a naming exercise. It is the acceptance skeleton for implementation. Each module row must describe the behavior that will make the prompt-required product real, the surfaces that expose that behavior, the state/artifact/config changes that prove it happened, and the tests that would fail if the implementation only preserved current placeholder behavior.
 
@@ -150,7 +157,7 @@ For each module, the plan must name:
 - shared contracts and dependencies
 - required API, unit, integration, E2E/platform, and frontend component/state tests
 - required FE↔BE wiring proof when UI and backend both exist
-- required main-lane module verification after fan-in before development exit
+- required integrated module verification before development exit
 - failure paths, security boundaries, and lazy/shell-only partial-completion risks
 - exact acceptance proof: the observable state change, persisted row, artifact, byte provenance, UI task closure, or external effect that proves the module is not a shell
 - current-behavior trap: any tempting test that would merely prove the incomplete implementation rather than the prompt-required behavior, with the corrected assertion named
@@ -158,15 +165,29 @@ For each module, the plan must name:
 - adjacent requirements explicitly not owned by this module, with the module that does own them, so no requirement disappears between modules
 
 Only after this module map exists should the plan derive:
-- the minimal file/location ownership needed for executable module packets
+- the minimal file/location responsibility details needed for executable module packets
 - shared-file stabilization order
 - ordered module packets
 
 If the plan starts with files before modules, it is incomplete. A full optimistic file tree is no longer required as a standalone planning artifact; the plan should name files, directories, routes, tests, and shared surfaces only to the extent needed to make module packets concrete and verifiable.
 
 Coverage target:
-- plan meaningful tests for every evaluator-relevant endpoint, core flow, security boundary, and major failure path
+- plan meaningful tests for every delivery-relevant endpoint, core flow, security boundary, and major failure path
 - do not use an abstract percentage target as a substitute for endpoint-by-endpoint, flow-by-flow, and risk-by-risk coverage mapping
+- when the stack has measurable coverage tooling, set the minimum clean-development target to at least `90%` line/branch coverage for unit-testable product code and at least `90%` completion of planned E2E/platform-critical flow coverage; if the stack cannot measure one of these honestly, the plan must name the exact reason and substitute a concrete file/flow/assertion coverage ledger
+- when backend/fullstack APIs exist, require `100%` of documented prompt-relevant `METHOD + PATH` surfaces to have true no-mock HTTP tests unless a narrow accepted exception is recorded per endpoint with compensating proof
+
+### 1.6 Vertical implementation requirement
+The plan must enforce vertical implementation over breadth-first coverage:
+- build one complete user/operator flow end-to-end before starting the next
+- for every form, implement template + route + handler + service + persistence + response together
+- for every page link, register and render the target page before claiming the source page complete
+- for every background job, wire it from startup and verify it is reachable before claiming it complete
+- for every security control, enforce it at the correct layer (service, middleware, DB, template, runtime) before claiming it complete
+- do not allow module completion claims based on file counts, route counts, template counts, or test counts alone
+- a feature is complete only when the intended actor can perform the task end-to-end through the real app path, or it is explicitly marked incomplete with a named residual risk
+- when planning module execution, order modules so that core vertical flows are completed before peripheral surfaces are added
+- prohibit completion language such as "all X endpoints implemented", "Y modules complete", or "Z tests passing" unless each surface has been verified as a working vertical flow
 
 For all `web` projects:
 - require explicit Playwright or equivalent real in-browser E2E coverage planning in `plan.md`
@@ -182,32 +203,34 @@ For all `fullstack` projects:
 - reject generic internal/API-only reasons; each accepted internal-only backend capability must name its real actor/consumer, invocation path, authorization boundary, evidence path, and why frontend exposure would be contrary to or unnecessary for the prompt
 - do not allow placeholders to satisfy the map: no fake-success API clients, static demo data pretending to be backend data, disconnected forms, TODO integration stubs, or shell handlers returning hardcoded success
 - require backend verification to prove frontend-called backend operations are real: they reach real handlers/services, perform the planned read/mutation/side effect, and are not merely registered routes or 200 responses
+- require exact form field name contracts: for every form-backed endpoint, the plan must document the exact frontend form field names and the exact backend handler field names, and require a test that submits the rendered form through the real handler path to prove the contract works
+- a form-to-backend contract is broken if the template uses `name="price"` and the handler reads `price_value`; the plan must prevent this through shared constants, typed request structs, or explicit field-name mapping
 
 Core semantic path:
 - identify the single task centerpiece path that would prove the product is real rather than a shell
 - define its exact user/API route, persisted input fixture or realistic data setup, required config/rule path, expected state transition or artifact, expected failure behavior, and test/manual proof path
-- make this proof mandatory before evaluation unless a named residual risk is explicitly accepted
+- make this proof mandatory before readiness handoff unless a named residual risk is explicitly accepted
 
 Prompt-critical rules:
 - extract exact rules from the original prompt and accepted clarifications into a matrix
 - include dates, thresholds, limits, state names, actor identity, retries, timing/scheduling, public/private boundaries, security constraints, and operator promises
-- assign each rule an implementation owner, test owner, README/doc implication, and `P5` proof expectation
+- assign each rule an implementation responsibility, test responsibility, README/doc implication, and local proof expectation
 
 Prompt-critical interaction defaults:
 - for every prompt-critical form, modal, wizard, approval/share flow, import/export flow, or configuration screen, define initial visible state, default field values, untouched submit behavior, first normal action behavior, duplicate/re-entry behavior, and the planned proof path
 - do not let default-state or untouched-submit semantics remain implied for critical user-facing flows
 
 Role/permission surfaces:
-- for any auth, role, ownership, public/private route, admin, viewer/read-only, audit, export, or notification behavior, build a role surface matrix
+- for any auth, role, ownership, public/private route, admin, viewer/read-only, accountability logging, export, or notification behavior, build a role surface matrix
 - cover route/page/API/action/data object/notification/export/report/admin surfaces
-- include role access, read/write scope, ownership, admin override, viewer/read-only behavior, audit/logging, frontend route/nav expectation, and required test evidence
+- include role access, read/write scope, ownership, admin override, viewer/read-only behavior, accountability/logging, frontend route/nav expectation, and required test evidence
 - do not allow design, API spec, router, backend, frontend, README, or tests to contradict the matrix
 
 The plan must not allow:
 - a surface to be implemented now and tested “later"
 - central test cleanup as the default for normal feature work
 - workstreams that claim completeness without their matching tests
-- large prompt-relevant surfaces with no planned test ownership
+- large prompt-relevant surfaces with no planned test responsibility
 - shell/demo/placeholder workstreams being presented as full implementation
 - route/page/module shells being treated as equivalent to closed user-facing or operator-facing behavior
 - risk-path coverage to remain implied when the prompt or implementation clearly suggests validation failures, edge cases, authorization failures, concurrency-sensitive behavior, or partial-failure behavior that later planning could miss
@@ -223,22 +246,24 @@ The plan must enforce:
 
 ### 3. The plan must support module-packet execution with optional safe parallelism
 Default to:
-- a small shared foundation in the main lane first
+- a small shared foundation first
 - then ordered module packets executed one by one by default
-- optional independent helper work only when a module, discovery, or verification task is clearly safer outside the main sequence
+- optional independent helper work only when a module, discovery, test-coverage task, or verification task is clearly safer outside the main sequence
 - explicit per-module integration points
 - explicit post-module and final cross-module verification
 - explicit justification for any optional concurrent module batch
 
 Planning must make module execution launch-ready, not merely theoretically ordered. The plan must include a concrete module packet sequence: which module starts first, which modules depend on it, which files/tests each module owns, which shared files it must not edit, what FE↔BE and file-existence proof is required, what verification commands must run before moving to the next module, and what completion report is expected.
 
+The plan must also include a plan-row execution ledger that turns every actionable `plan.md` row into a completion item with responsible module/work package, repo evidence, verification evidence, status, and blocker/risk field. This ledger is the development execution scoreboard: no actionable row may be left `planned`, vague, or unassigned before clean development completion.
+
 Each module packet must be complete enough to execute without invention. A module packet must name the module capsule, requirement IDs, owned files/tests, shared-file restrictions, frontend/backend/data/security/failure-state scope, real FE↔BE wiring proof where applicable, real file/import/route/service/data proof, verification commands, and the standard module completion checklist.
 
 Each module packet must include an explicit `Requirement Closure Checklist` with one row per requirement or sub-requirement it owns. Each row must include implementation surface, test/assertion surface, negative/edge proof if applicable, documentation/README implication if applicable, and completion status. A module packet cannot be marked complete while any owned row is unchecked, delegated without a target module, or proven only by generic smoke coverage.
 
-The primary developer/integration lane remains responsible for sequencing, shared-file foundation, module implementation, integration decisions, and final cross-module verification. It may use helper work only when the plan names a safe independent packet or verification task.
+The primary implementation sequence remains responsible for sequencing, shared-file foundation, module implementation, integration decisions, and final cross-module verification. Helper work may be used only when the plan names a safe independent packet or verification task.
 
-The primary developer/integration lane must consume module completion evidence after each module: inspect ownership, reject incomplete module packets, wire shared surfaces, rerun targeted module tests in the integrated checkout, and record integrated evidence before moving to the next module.
+The primary implementation sequence must consume module completion evidence after each module: inspect file responsibility, reject incomplete module packets, wire shared surfaces, rerun targeted module tests in the integrated checkout, and record integrated evidence before moving to the next module.
 
 The execution order must be explicit and module-first:
 - scaffold step first
@@ -258,8 +283,9 @@ Each planned module packet must specify:
 - real file/import/route/service/data existence proof
 - verification commands that must pass before moving to the next module
 - required standard module completion checklist
+- coverage contribution: endpoints, unit-testable product-code areas, and E2E/platform-critical flows this module must close
 
-If helper work is planned, the plan must state only: task/module, why it is safer outside the main sequence, owned files/tests, shared-file restrictions, verification commands, and integration rule. Do not add branch/worktree launch mechanics to the general plan unless the owner explicitly asks.
+If helper work is planned, the plan must state only: task/module, why it is safer outside the main sequence, owned files/tests, shared-file restrictions, verification commands, and integration rule. Do not add branch/worktree launch mechanics unless explicitly required for implementation.
 
 Do not leave module packet creation as optional follow-up.
 If the plan cannot produce a launch-ready ordered module packet sequence after the shared foundation, it is not ready for development.
@@ -270,12 +296,12 @@ If the plan cannot produce a launch-ready ordered module packet sequence after t
 - ordered
 - resume-friendly
 - section-addressable
-- explicit about prerequisites, owners, and merge targets
-- explicit about what is main-sequence work vs independently safe helper work
+- explicit about prerequisites, responsible modules, and integration targets
+- explicit about what is primary-sequence work vs independently safe helper work
 
 ### 5. Shared files must be isolated early
 The plan must stabilize a small shared-file contract before broader module implementation.
-Typical main-lane-owned files include:
+Typical primary-sequence shared files include:
 - `plan.md`
 - `README.md`
 - root config files
@@ -288,16 +314,20 @@ Typical main-lane-owned files include:
 Independent helper work must not touch shared files casually.
 
 ### 6. Final convergence must be planned explicitly
-The plan must define `P5` as a minimal gate, not a perfection phase.
+The plan must define integrated readiness hardening as a minimal delivery-readiness condition, not a perfection pass.
 
 It must define:
-- the owner-run `P5` local-harness check
+- the local-harness readiness check
 - that Docker runtime and dockerized `./run_tests.sh` are prepared but deferred to final packaging confirmation
 - the rough repo-to-`plan.md` coherence check
-- that the owner should stop and ask whether to proceed to evaluation once those are satisfied
-- that only narrow config/wrapper/README/docs/light-script glue may be fixed directly in `P5`
-- that real code or actual test-file changes go back to the developer
-- that final packaging confirmation is the first real Docker/runtime confirmation point
+- the readiness handoff once those checks are satisfied
+- that only narrow config/wrapper/README/docs/light-script glue may be fixed directly by whoever is assigned that cleanup
+- that real code or actual test-file changes are handled as implementation corrections after initial implementation is accepted
+- that final runtime confirmation in packaging is the broad Docker/runtime confirmation point, while P8 may launch the app only for `agent-browser` functional verification when no equivalent local runtime is available
+
+This stop boundary applies only when the active instruction asks for an implementation-readiness handoff.
+
+If implementation is explicitly scoped end to end in one autonomous execution run, it must not stop at rough local readiness. 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.
 
 ---
 
@@ -330,40 +360,69 @@ State the rules for:
 - test-with-implementation
 - no `.env` files
 - Docker/runtime/test honesty
-- merge discipline
-- final rough coherence-to-evaluation handoff discipline
+- integration discipline
+- final rough coherence-to-readiness handoff discipline
 - no Docker execution before final packaging confirmation
 
+External planning documents under `../docs/` are planning/reference inputs only.
+
+Delivery evidence must exist inside the delivered repo through:
+- `README.md`
+- code structure
+- route/app/server registration
+- tests
+- scripts
+- config/manifests
+- Docker/runtime files
+- 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.
+
+The README contract must include a Configuration and Environment Model section or equivalent content explaining:
+- whether any configuration is required for local use
+- where runtime defaults come from
+- how Docker/Compose receives local-development configuration
+- whether seeded data is created automatically
+- whether auth exists and what credentials are available
+- that no committed `.env` or `.env.example` is required
+- that no manual package/runtime/database setup is required beyond documented host prerequisites
+- how config-sensitive behavior can be verified
+
+If no configuration is required, require the README to state: `No manual environment configuration is required for local Docker startup. The delivered local runtime uses repo-controlled Docker/Compose defaults and bootstrap paths.`
+
 ### C. Scaffold Step At The Start Of Development
 Lock:
 - exact starter/playbook/baseline
 - exact bootstrap command
 - baseline files and directories expected after the scaffold step lands
 - language/framework bootstrap notes that must be preserved
+- frontend defaults if prompt/repo are silent: Vue 3 + Vite + TypeScript, Tailwind CSS, and shadcn/ui when compatible
 - minimal proof surface that should exist immediately after bootstrap and before real feature work
 - exact Docker/runtime setup to land first, with `docker compose up --build` honestly wired for later final confirmation without local dependency guesswork
+- exact seeded-data strategy to land early when the product needs non-empty data: what is seeded, where the seed lives, how it runs through Docker/init paths, how it stays deterministic/idempotent, and what README quick-start information exposes it
 - exact repo-root `./run_tests.sh` setup to land first as the dockerized full-app test-suite path reserved for final confirmation, and it must not be planned as a smoke-only, no-op, or shortcut command
-- exact separate local test harness setup to land first for development and owner-side `P5`, using the real stack-native local suite for the chosen language/framework such as Vitest, Jest, PHPUnit, pytest, go test, cargo test, or the closest framework-native equivalent, with clear local prerequisites, deterministic execution, and useful failure output
+- exact separate local test harness setup to land first for development and later readiness checks, using the real stack-native local suite for the chosen language/framework such as Vitest, Jest, PHPUnit, pytest, go test, cargo test, or the closest framework-native equivalent, with clear local prerequisites, deterministic execution, and useful failure output
 - exact requirement that missing local-suite tooling be installed and configured on the local machine before local verification is treated as available
 - exact reliability contract those commands must satisfy later: for the local harness, no hidden setup steps, no hidden shell state, clear local prerequisites, deterministic execution, and useful failure output; for Docker/runtime and dockerized `./run_tests.sh`, no manual exports, no hidden prep, real readiness gating and healthchecks instead of arbitrary sleeps where practical, and useful failure output
 - exact expectation that Docker/runtime files and dockerized `./run_tests.sh` are set up but not executed before final packaging confirmation, while the local harness is prepared for development use from scaffold onward
+- exact expectation that seeded quick-start data is not fake completion: seeded data may provide fixtures/accounts/sample records, but product flows must still use real code paths, persistence, validation, authorization, and tests
 - local development environment/tooling and testing harness contract if available
 - exact README structure/template that must land early
 - stop boundary if the scaffold step is intentionally isolated
 - completion evidence for the scaffold step
-- explicit statement that development continues immediately after this step unless the owner says otherwise
+- explicit statement that development continues immediately after this step unless the active instruction says otherwise
 
 The scaffold step must stay strict and minimal:
 - no prompt-specific business features
 - no deep domain implementation
 - no release polish beyond the startup/test/documentation baseline
 - no host-side dependency setup beyond the documented local development prerequisites plus the deferred Docker/runtime contract
-- no Docker execution or dockerized `./run_tests.sh` execution before final packaging confirmation, while the separate local harness is available for development use and later `P5` verification
+- no Docker execution or dockerized `./run_tests.sh` execution before explicit final runtime confirmation, while the separate local harness is available for development use and later readiness checks
 - scaffold placeholders must be explicitly labelled as scaffold-only and must not be counted as product surface completion
-- scaffold scripts may not use no-op, echo-only, or pass-with-no-tests behavior for a surface that the final product claims as implemented; if a temporary scaffold wrapper exists, the plan must name the later replacement owner and proof before development completion
+- scaffold scripts may not use no-op, echo-only, or pass-with-no-tests behavior for a surface that the final product claims as implemented; if a temporary scaffold wrapper exists, the plan must name the later replacement responsibility and proof before development completion
 - product-facing pages, routes, services, jobs, and handlers are incomplete until they close the actor task through real code paths and owned tests, not merely because the repo can build
 
-For those deferred Docker/runtime/test commands, the plan must still demand an implementation shape that is highly likely to pass on the first owner-side execution later:
+For those deferred Docker/runtime/test commands, the plan must still demand an implementation shape that is highly likely to pass on the first explicit final runtime check later:
 - container build inputs and startup paths must be fully repo-controlled and reviewable
 - Compose services must use real healthchecks and readiness-gated startup rather than sleep-based sequencing where practical
 - runtime and broad-test paths must be non-interactive and must not depend on hidden shell state
@@ -374,7 +433,7 @@ Use matrix form and map each applicable requirement to:
 - source requirement ID(s)
 - planned repo evidence
 - planned verification evidence
-- owning module/main-sequence section
+- responsible module/section
 
 Required matrices:
 0. core semantic path proof and prompt-critical proof ledger
@@ -391,13 +450,13 @@ Required matrices:
 Define:
 - security-sensitive surfaces
 - shared security foundations that must land before broader module implementation
-- any dedicated security lane if needed
+- any dedicated security work package if needed
 - required negative-path tests
-- required merge gates
+- required integration checks
 - sensitive-data and logging rules
 - auth/authorization/isolation enforcement map
-- role surface matrix when auth, roles, ownership, public/private routes, admin, viewer/read-only behavior, audit, exports, or notifications are relevant
-- exact fail-closed expectations for privileged actions, signed links/tokens, audit durability, encryption, object ownership, and public-route boundaries where applicable
+- role surface matrix when auth, roles, ownership, public/private routes, admin, viewer/read-only behavior, accountability logging, exports, or notifications are relevant
+- exact fail-closed expectations for privileged actions, signed links/tokens, durable activity logs, encryption, object ownership, and public-route boundaries where applicable
 
 ### F. Test Coverage Execution Contract
 Map every meaningful planned surface/work package to:
@@ -406,10 +465,10 @@ Map every meaningful planned surface/work package to:
 - exact planned test files, suites, or test modules when they can already be named honestly
 - expected coverage evidence
 - owning module/main-sequence section
-- merge proof
+- integration proof
 
-This section must be broad enough that a reviewer can trace how the full prompt-relevant app surface is expected to approach near-complete coverage before implementation starts.
-It must also be concrete enough that a reviewer can tell which specific tests are intended to be written, not just which abstract test layer labels apply.
+This section must be broad enough that the full prompt-relevant app surface can be traced to coverage before implementation starts.
+It must also be concrete enough to show which specific tests are intended to be written, not just which abstract test layer labels apply.
 
 Must include, where applicable:
 - backend unit tests
@@ -417,7 +476,7 @@ Must include, where applicable:
 - frontend unit/component/state tests
 - frontend unit/component/state tests planned early by real routes/screens/flows
 - prompt-critical interaction-default tests for untouched/default-path semantics where forms, modals, wizards, approval/share flows, imports/exports, or configuration screens matter
-- frontend unit-test audit readability for `web` / `fullstack`, including a plan strong enough that later review can state `Frontend unit tests: PRESENT` or `Frontend unit tests: MISSING` from file-level evidence
+- frontend unit-test readability for `web` / `fullstack`, including a plan strong enough that later review can state `Frontend unit tests: PRESENT` or `Frontend unit tests: MISSING` from file-level evidence
 - API tests
 - API tests planned directly from accepted `../docs/api-spec.md` when applicable
 - integration tests
@@ -433,20 +492,20 @@ Must include, where applicable:
 - endpoint evidence categories: handler-reaching success, handler-reaching error, authorization short-circuit, mocked client evidence, unit-only evidence, documentation-only claim
 - behavioral proof categories: core semantic path proven, shallow status/enqueue only, artifact/state side effect proven, failure path proven, frontend-to-backend/browser proven, manually verified only
 
-During this phase, also write or update parent-root `../docs/test-coverage.md` from the accepted coverage contract so it already captures the planned requirement/risk mapping, API coverage strategy when applicable, and the honest current status as a planning-time baseline rather than waiting until packaging.
+During planning, also write or update parent-root `../docs/test-coverage.md` from the accepted coverage contract so it already captures the planned requirement/risk mapping, API coverage strategy when applicable, and the honest current status as a planning-time baseline rather than waiting until final delivery.
 
 ### G. README Execution Contract
-The plan must include the exact README structure to be implemented and the lane/main-lane ownership model for keeping it current.
+The plan must include the exact README structure to be implemented and the responsible module/primary-sequence model for keeping it current.
 
 ### H. Shared-File Contract
 Define:
 - which files are shared
-- which module or main lane owns each shared file
+- which module or primary sequence owns each shared file
 - which files must be stabilized before module execution
 - which later workstreams may reference but not edit them without explicit reason
 
 ### I. Ordered Module Packet Map
-Build this from the module map plus concrete file/location ownership details where needed. Do not invent workstreams as abstract feature buckets first.
+Build this from the module map plus concrete file/location responsibility details where needed. Do not invent workstreams as abstract feature buckets first.
 
 For each module packet define:
 - module order
@@ -474,7 +533,7 @@ For each major module or domain define:
 - source requirement IDs
 - exact frontend pages/components/actions owned
 - exact backend endpoints/services/jobs owned
-- exact planned files/directories before lane assignment
+- exact planned files/directories before work assignment
 - supporting contracts
 - dependencies
 - required unit, API, integration, E2E/platform, and frontend component/state test files/layers
@@ -482,7 +541,7 @@ For each major module or domain define:
 - proof that backend capabilities are exposed in the frontend when required
 - failure paths that must be covered
 - what would count as a lazy or shell-only partial implementation that must not be accepted
-- merge criteria
+- integration criteria
 
 Module planning rules:
 - identify modules before the file tree
@@ -491,11 +550,12 @@ Module planning rules:
 - every prompt-relevant module must have full API coverage when it owns APIs, meaningful unit coverage, integration proof where it crosses boundaries, E2E/platform proof for major actor paths, and frontend wiring proof where UI exists
 - every module must include frontend loading, empty, submitting, disabled, success, error, and duplicate-action states where those states matter
 - every module must name the exact backend operations its frontend calls and the exact frontend surfaces that expose its backend features
-- every module must include a development-exit verification row requiring the main lane to reread its planned files, confirm those files are real and integrated, run the module's assigned tests, confirm FE↔BE/API wiring, and record the result before development is declared complete
+- every module must include a development-exit verification row requiring integrated reread of its planned files, confirmation that those files are real and wired, the module's assigned tests, FE↔BE/API wiring confirmation, and recorded results before development is declared complete
 - do not accept module plans that leave API coverage, frontend wiring, or E2E proof to generic final cleanup
 
 ### J1. Development Exit Verification Plan
-Before development can be reported complete, the primary integration lane must:
+Before development can be reported complete, the primary implementation sequence must:
+- update the plan-row execution ledger so every actionable plan row is `complete`, `not applicable`, or explicitly `risk accepted`; any `planned`, `in progress`, `delegated without receiver`, or unverified row blocks a clean completion claim
 - collect each module's standard completion checklist
 - compare planned module packets against completed module packets and record any skipped or blocked module with a blocker and revised sequencing
 - reject broad summary claims as sufficient evidence when module files, tests, FE↔BE proof, or file-existence proof are missing
@@ -503,7 +563,9 @@ Before development can be reported complete, the primary integration lane must:
 - run each module's assigned tests after module integration using the non-Docker local harness or targeted stack-native commands
 - run the full non-Docker local test suite available for development before exit, while still deferring Docker and dockerized `./run_tests.sh` to final packaging confirmation
 - confirm every module's FE↔BE surface, API coverage, unit coverage, integration coverage, and E2E/platform proof status against the plan
-- update the module verification matrix in `plan.md` before handing the repo to owner-side integrated verification
+- confirm API coverage targets: every documented prompt-relevant `METHOD + PATH` has true no-mock HTTP proof or a per-endpoint accepted exception with compensating evidence
+- confirm coverage floors: measured unit-testable product-code coverage is at least `90%` where tooling supports it, and planned E2E/platform-critical flow coverage is at least `90%` complete; if measurement is unavailable, the plan's substitute coverage ledger must be fully closed
+- update the module verification matrix in `plan.md` before claiming integrated readiness
 
 ### K. API Inventory and Coverage Plan (if applicable)
 Build this section directly from the accepted `../docs/api-spec.md` and classify the expected tests as:
@@ -544,22 +606,22 @@ Define:
 - platform proof caveats honestly where required
 
 ### N. Integrated Verification and Hardening Plan
-This must be a real final phase in the plan.
+This must be a real final readiness section in the plan.
 
 It must define:
-- the minimal `P5` gate: the local test harness passes and the repo is roughly coherent with `plan.md`
-- the required internal `P5` issue-discovery loop: one fresh evaluator subagent session, exact prepared evaluation packet sent once, four same-session additional scan requests explicitly asking for additional prompt-fit/compliance, security, and delivery issues not already reported, no inter-round remediation, exactly five total reports saved under `../.ai/p5-evaluation/`, Blocker/High findings extracted after each round, consolidated, owner-analyzed, routed to the developer in one remediation brief, fixed, and verified before `P5` can close
-- the default proceed rule: once that minimal gate is satisfied, move to evaluation
-- every owner `P5` 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
-- normal `P5` should cap at 3 owner sweeps total: the opening sweep plus up to two follow-up full sweeps when needed
+- the minimal readiness condition: the local test harness passes and the repo is roughly coherent with `plan.md`
+- independent readiness expectation: the repo must withstand strict prompt-fit/compliance, security, delivery, test-coverage, README/static-verifiability, mock/demo/fake-success, and frontend state/interaction verification before final handoff
+- the default proceed rule: once that minimal condition is satisfied, produce a truthful readiness handoff
+- every 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
+- normal readiness hardening should cap at 3 full sweeps total: the opening sweep plus up to two follow-up full sweeps when needed
 - narrow rerun strategy after known failures
-- issue-batching rule for integrated verification: collect all issues that directly block the minimal gate, then either fix the small owner-side churn directly or route one consolidated major fix list back to implementation
-- when a consolidated fix list contains independent items, the default is ordered remediation in the main developer lane; use helper work only where genuinely safer, and require per-bundle verification plus integrated proof before accepting completion
-- explicit statement that `P5` should not become an iterative development-completion mini-loop
+- issue-batching rule for integrated verification: collect all issues that directly block readiness, then handle small docs/config/script churn directly if assigned or return one consolidated major fix list to implementation
+- when a consolidated fix list contains independent items, the default is ordered remediation in the active correction workstream; use helper work only where genuinely safer, and require per-bundle verification plus integrated proof before accepting completion
+- explicit statement that readiness hardening should not become an iterative development-completion mini-loop
 - doc tightening only when needed to keep the delivered state roughly coherent with `plan.md`
 - what must be true before completion is reported
 
-The integrated verification plan must explicitly say that shell/demo/placeholder implementations are reopened as incomplete work rather than accepted as partial success, but it should still be a rough release-alignment pass rather than an exhaustive final perfection gate. It must also explicitly say that a separate local test harness is prepared in scaffold and used during development plus owner-side `P5`, while Docker execution and dockerized `./run_tests.sh` remain deferred until final packaging confirmation.
+The integrated verification plan must explicitly say that shell/demo/placeholder implementations are reopened as incomplete work rather than accepted as partial success, but it should still be a rough release-alignment pass rather than exhaustive final perfection. It must also explicitly say that a separate local test harness is prepared in scaffold and used during development plus later readiness checks, while Docker execution and dockerized `./run_tests.sh` remain deferred until explicit final runtime confirmation.
 
 ### O. Cleanup Before Final Review
 Define the cleanup step that removes:
@@ -609,18 +671,24 @@ Produce `plan.md` in this order:
 
 ---
 
+## Section-by-Section Delivery Rule
+
+Write `plan.md` one template section at a time, appending each completed section to the file on disk. Do not paste full section text in chat and do not dump the accumulated document text in the final response.
+
+---
+
 ## Planning Quality Bar
 
 The execution plan is acceptable only if:
 - it obeys the accepted design
 - it does not reinterpret product meaning
-- it names only the files, routes, tests, and shared surfaces needed for evaluator-relevant implementation and proof
+- it names only the files, routes, tests, and shared surfaces needed for delivery-relevant implementation and proof
 - it makes shared files explicit
 - it avoids helper structure unless it is clearly safer for an independent task
 - it attaches tests to implementation work
 - it defines exact runtime/test/README obligations
-- it defines exact merge and fan-in verification
-- it defines the real final convergence/hardening gate
+- it defines exact integration and fan-in verification
+- it defines the real final convergence/hardening condition
 - it is specific enough that implementation can follow it with minimal reinvention
 
 If a section is not applicable, mark it `Not Applicable` and explain why.