theslopmachine 1.0.2 → 1.0.3

package/assets/skills/verification-gates/SKILL.md

@@ -14,8 +14,9 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - use this skill as the source of truth for owner-side verification, review pressure, and gate interpretation
 - do not pause execution for human approval while using this skill; continue reviewing, fixing, rerouting, and rerunning only until the material blocker is cleared
 - clarification completion and `P8 Final Readiness Decision` are internal workflow transitions, not user-stop gates; do not pause execution just to summarize progress or ask the user whether to continue
-- `P8 Final Readiness Decision` is the fast post-`P7` cross-surface reconciliation sweep: compare the delivered repo, `README.md`, parent-root `../docs/`, and carried `../.tmp/` audit artifacts, fix small owner-side drift directly, validate report shape and lineage, confirm final residual risks, and only hold back packaging when a material inconsistency remains
-- `P8` must emit or record a readiness reconciliation note covering docs checked, kept reports checked, archived/stale report lineage reviewed, package-root expectations, and any final residual gaps
+- `P8 Final Readiness Decision` is the fast post-`P7` cross-surface reconciliation sweep; load `p8-readiness-reconciliation` and follow it as the source of truth for the final readiness note, readiness-category sweep, and required `agent-browser` functional verification
+- `P8` must emit or record the readiness reconciliation note required by `p8-readiness-reconciliation`
+- the `P8` readiness note should include a residual-risk reconciliation table with rows for each reported issue, recommendation, stale artifact, doc drift, or final gap; use statuses such as `resolved`, `accepted residual risk`, `stale/doc-only cleanup`, `artifact-lineage issue`, or `material blocker`
 
 ## Documentation and repo hygiene
 
@@ -31,6 +32,8 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - require `./run_tests.sh` to run the full test suite of the delivered app rather than a smoke subset, no-op placeholder, or shortcut path
 - do not require the README to carry a full API catalog
 - require the README to include the strict audit sections when they are relevant to the project shape: project type near the top, startup instructions, access method, verification method, and demo credentials for every role or the exact statement `No authentication required`
+- require the README to include quick-start seeded data for any app that needs non-empty data to exercise main flows, or the exact statement `No seeded data required; the app is useful from an empty state.`
+- reject seeded data that is hidden, non-idempotent, disconnected from the normal runtime/bootstrap/database path, or used as static fake-success product behavior instead of real implementation
 - treat the README as the final public contract for runtime and broad-test behavior: if it documents a runtime command or a broad test command, the delivered output must satisfy that exact contract
 - do not allow the repo to depend on parent-root docs or sibling artifacts for startup, build/preview, configuration, evaluator traceability, or basic project understanding
 - require the delivered repo to be statically reviewable: README, scripts, entry points, routes, config, and test commands must be traceably consistent
@@ -81,6 +84,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - when backend or fullstack APIs exist, do not accept missing endpoint inventory or missing API-test mapping for the important `METHOD + PATH` surfaces
 - when backend or fullstack APIs exist, do not accept mocked or indirect tests being presented as equivalent to true no-mock HTTP endpoint coverage
 - do not accept a README that is missing project type, startup instructions, access method, verification method, or auth disclosure when the strict README audit would expect them
+- do not accept a README that omits seeded quick-start data or the exact empty-state rationale when a user would otherwise start into a blank unusable app
 - do not accept final delivered docs or wrapper flows that still depend on `npm install`, `pip install`, `apt-get`, manual DB setup, or other host-only setup assumptions after development is complete
 - do not accept a repo that only becomes understandable by reading parent-root docs or sibling workflow artifacts
 - do not accept frontend-bearing work that lacks repo-local build/preview/config guidance when those commands or surfaces are material to the product
@@ -111,7 +115,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 ## Cadence rule
 
 - use targeted local verification as the default during early scaffold-step corrections inside development and in-development follow-up work
-- reserve owner-run local verification for the integrated verification gate in `P5`, and reserve owner-run `docker compose up --build` plus dockerized `./run_tests.sh` for the final runtime and broad-test confirmation in `P9`
+- reserve owner-run local verification for the integrated verification gate in `P5`, reserve the narrow `P8` app launch for `agent-browser` functional verification, and reserve dockerized `./run_tests.sh` plus final broad Docker/runtime confirmation for `P9`
 - do not turn ordinary acceptance into repeated integrated-style gate runs
 - do not run `docker compose up --build` anywhere from planning through the end of `P7`
 - ordinary development and evaluation should rely on local verification, static review, evaluator sessions, and owner-side coherence checks only
@@ -140,7 +144,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - do not ask the developer to run Docker runtime commands or dockerized `./run_tests.sh` during ordinary in-development follow-up work; do require the prepared local test harness, including its full readiness pass before major readiness claims, when that is the right correctness check
 - if the developer already ran the relevant targeted local test command and reported it clearly, do not rerun the same command on the owner side unless the evidence is weak, contradictory, flaky, high-risk, or needed to answer a new question
 - when the remaining gap is a small non-core issue such as docs cleanup, README sync, Docker config, wrapper/config glue, or light `./run_tests.sh` cleanup, the owner may fix it directly instead of bouncing it back to the developer
-- if the remaining gap requires editing actual test files or suites, or real product code outside narrow config or wrapper glue, route it back to the developer instead of fixing it in-owner
+- if the remaining gap requires editing actual test files or suites, or real product code outside narrow config or wrapper glue, route it to the current developer lane instead of fixing it in-owner; in `P5`, that means the active P5 bugfix lane, not the completed `develop-*` lane
 - during planning review, if the remaining problem is a small contract, wording, structure, or owner-maintained-document issue in `../docs/design.md`, `../docs/api-spec.md`, or `plan.md`, fix it directly in the owner session instead of reopening planning
 - for ordinary in-development follow-up acceptance, default review scope to the changed files and the narrow supporting files named by the developer; expand only when a concrete inconsistency, missing dependency, or suspicious claim forces wider review
 - for ordinary in-development follow-up acceptance, prefer a narrow acceptance checklist over broad exploratory rereads
@@ -172,7 +176,7 @@ Use this skill after development begins whenever you are reviewing work, decidin
 - the workflow target is at most 2 broad owner-run verification moments across the whole cycle
 - ordinary planning, ordinary in-development follow-up acceptance, and routine in-development verification are not broad gates by default and should rely on targeted local verification unless the risk profile says otherwise
 
-From planning through the end of `P7`, do not run Docker-based verification.
+From planning through the end of `P7`, do not run Docker-based verification. In `P8`, run Docker only when `p8-readiness-reconciliation` requires it to launch the app for `agent-browser` functional verification and no equivalent local runtime is available.
 Do not run Docker-based verification inside `P7`.
 The ordinary cadence is one owner-side local-harness gate in `P5`, plus the first real owner-side Docker/runtime and dockerized broad-test confirmation in `P9`.
 
@@ -189,7 +193,7 @@ Use evidence such as internal metadata files, structured Beads comments, verific
 - planning exit also requires parent-root `../docs/test-coverage.md` to be updated from the accepted planning contract enough that a reviewer can see the planned requirement/risk mapping there rather than only inside `plan.md`
 - planning exit also requires that the accepted plan covers the final README hard-gate shape and, when backend or fullstack APIs exist, the endpoint-inventory and API-test mapping strategy needed for the strict coverage audit
 - planning exit also requires an accepted scaffold step in `plan.md` that makes the initial bootstrap promptable without re-selecting the playbook at runtime and that locks Docker/runtime, `./run_tests.sh`, local testing harness and development tooling when applicable, and the early README structure
-- planning exit also requires security and test coverage execution contracts in `plan.md` that define the shared security foundation, per-surface test ownership, a confident roughly `90%` overall real-test coverage target, the applicable frontend/backend/API-surface/E2E obligations, and strong real-HTTP coverage expectations for resolved backend or fullstack API surfaces when they exist
+- planning exit also requires security and test coverage execution contracts in `plan.md` that define the shared security foundation, per-surface test responsibility, at least `90%` unit-testable product-code coverage where measurable, at least `90%` closure of planned E2E/platform-critical flows, the applicable frontend/backend/API-surface/E2E obligations, and `100%` true no-mock HTTP coverage for documented prompt-relevant backend or fullstack API surfaces unless endpoint-level exceptions are recorded
 - planning exit also requires that the full prompt-relevant app surface is mapped to planned unit, API, integration, and E2E or platform-equivalent test ownership early enough that major surfaces are not left for later discovery
 - planning exit also requires an exact README contract in `plan.md` that locks the required README section structure, command strings, disclosures, and platform-specific guidance expected by the strict audits
 - planning exit also requires a `Delivery Review Requirements` section in `plan.md` that directly captures the applicable prompt-fit, static reviewability, runtime and broad-test, logging/validation/error-handling, backend/API, frontend/UX, end-to-end/platform, README, and coverage obligations, each mapped to planned repo evidence, planned verification evidence, and an owning main-lane or branch-worktree section
@@ -246,7 +250,7 @@ Use evidence such as internal metadata files, structured Beads comments, verific
 - if a required flow cannot be exercised through the intended UI surface, treat that as incomplete implementation rather than acceptable E2E coverage
 - the fused `P5` phase should not chase perfection; once local verification is green, the repo is roughly coherent and broadly correct against `plan.md` plus accepted `../docs/design.md`, and the required internal evaluation loop is resolved, stop and ask whether to proceed to evaluation
 - the fused `P5` phase may still fix small owner-fixable docs/config churn directly, but should not hold evaluation for nitpicks
-- during `P5`, treat owner-side direct edits as limited to docs, `README.md`, parent-root reference docs, Docker/runtime config, wrapper/config glue, and light `./run_tests.sh` script cleanup; actual test files and core code changes belong to the developer lane
+- during `P5`, treat owner-side direct edits as limited to docs, `README.md`, parent-root reference docs, Docker/runtime config, wrapper/config glue, and light `./run_tests.sh` script cleanup; actual test files and core code changes belong to the active P5 bugfix lane because `develop-*` is done after accepted `P3`
 - before `P7`, do not hold back evaluation over documentation, polish, or extra owner-side analysis once the minimal `P5` test/coherence gate and required internal evaluation loop are satisfied
 - before `P7`, prefer traceable static evidence for security-bearing projects covering auth entry points, route authorization, object authorization, function-level authorization, admin/internal/debug protection, and tenant or user isolation when those dimensions apply, but let evaluation surface the remaining strict gaps when the repo is otherwise coherent
 - before `P7`, for non-trivial frontend work, prefer meaningful static frontend test evidence for major state transitions or failure paths rather than relying only on runtime screenshots or E2E confidence, but do not turn this into a pre-evaluation perfection gate

package/assets/slopmachine/clarification-faithfulness-review-prompt.md

@@ -1,67 +1,91 @@
-# Clarification Prompt-Faithfulness Review
+# Clarification Faithfulness Review Prompt
 
-You are a strict prompt-faithfulness reviewer.
+You are a strict faithfulness reviewer.
 
-Your job is to compare:
+Your job is to compare the clarification artifacts against the original product prompt and the final evaluation expectations, then report any drift, narrowing, or missing coverage.
 
-1. the original prompt
-2. `../.ai/requirements-breakdown.md`
-3. `../docs/questions.md`
+## Inputs
 
-and determine whether the requirements breakdown plus clarifications are truly representative of the prompt.
+You will receive:
+1. The original product prompt
+2. `../docs/questions.md`
+3. `../.ai/requirements-breakdown.md`
 
-You must:
-- identify every missing core requirement
-- identify every missing implied but binding requirement
-- identify every weakened or narrowed requirement
-- identify every clarification decision that drifts from the prompt
-- identify any over-interpretation that broadens the prompt beyond a slight prompt-faithful upgrade
-- identify any requirement that is present but still too shallow, under-explained, or missing the details that planning could easily underbuild later
-- identify any missing success-closure, failure/negative-condition, actor-boundary, or hidden-constraint detail that should have been extracted from the prompt
-- identify whether the planning-miss checklist is too weak to protect later design/planning from underbuilding subtle prompt details
-- identify any sections that are strong and should be preserved
+## Review Scope
 
-You must be strict.
-Do not be optimistic.
-Do not treat “roughly similar” as good enough.
+Check the following dimensions systematically:
 
-Output only markdown for:
+### 1. Prompt Faithfulness
+- Has any actor's actions been narrowed, removed, or reassigned?
+- Has any required flow been shortened, made optional, or delegated to a different actor?
+- Has any explicit constraint been weakened or reinterpreted?
+- Are all prompt-required surfaces (pages, routes, APIs, jobs, reports, exports) still present?
 
-`../.ai/clarification-faithfulness-review.md`
+### 2. Requirement Registry Completeness
+- Does `../.ai/requirements-breakdown.md` contain a requirement entry for every explicit prompt requirement?
+- Does it contain entries for implied but binding requirements?
+- Are locked defaults labeled with their implementation risk tier (`evaluation-critical`, `design-stabilizing`, `scope-expanding`)?
+- Are there any orphan requirements: entries in the prompt with no corresponding requirement ID?
 
-Use this exact structure:
+### 3. Actor-Action Integrity
+- For every actor in the prompt, list their granted actions
+- Verify each action appears in the requirements breakdown or has an explicit non-applicability reason
+- Flag any actor whose actions were reduced without explicit justification
+
+### 4. Evaluation Crosswalk
+- Does the requirements breakdown cover all dimensions that the final evaluation will check?
+  - prompt alignment and delivery completeness
+  - static verifiability (README, config, routes, structure)
+  - API endpoint inventory and true no-mock HTTP strategy
+  - frontend pages, states, and interactions
+  - security boundaries (auth, authorization, isolation, admin protection)
+  - validation, error handling, logging, sensitive-data handling
+  - test coverage expectations (unit, API, integration, E2E)
+  - mock/demo/fake-success prevention
+- Are there evaluation-critical requirements that are only vaguely represented?
+
+### 5. `questions.md` Format Compliance
+- Does `../docs/questions.md` contain requirement IDs, traceability fields, priority fields, or evaluator-risk metadata?
+  - If yes, flag as format violation. Requirement IDs belong in `.ai/` artifacts only.
+- Is the file clean, narrow, and decisive?
+
+## Output
+
+Produce a review report with this exact structure:
 
 ```md
 # Clarification Faithfulness Review
 
 ## Verdict
-- [PASS | FAIL]
+[PASS | PASS WITH MINOR NOTES | DRIFT DETECTED]
 
-## Core Requirement Coverage Gaps
-- [gap]
+## Findings
 
-## Missing Implied Requirements
-- [gap]
+### Finding N: [short title]
+- Dimension: [prompt-faithfulness | registry-completeness | actor-action-integrity | evaluation-crosswalk | format-compliance]
+- Severity: [blocker | high | medium | low]
+- Evidence: [exact quote or reference from the artifact]
+- Impact: [what would go wrong in later phases if this is not fixed]
+- Suggested Fix: [concrete correction]
 
-## Under-Specified Requirement Details
-- [detail]
+## No-Drift Confirmations
+- [List of important prompt requirements that were correctly preserved]
 
-## Drift / Narrowing Findings
-- [finding]
+## Residual Risks
+- [Any ambiguous areas that are acceptable but should be watched in P2]
+```
 
-## Acceptable Prompt-Faithful Upgrades
-- [upgrade]
+## Rules
 
-## Strong Sections To Preserve
-- [section]
+- Be strict. A minor drift in P1 becomes a major gap in P3.
+- Do not approve requirements breakdowns that mix traceability metadata into `questions.md`.
+- Do not approve actor-action narrowing unless the prompt explicitly supports it.
+- Flag scope-expanding locked defaults that could strain implementation without adding evaluation value.
+- Every finding must cite exact evidence from the artifacts.
+- If no drift is found, state that explicitly and list the key no-drift confirmations.
 
-## Exact Corrections Required
-- [correction]
-```
+## Final Instruction
+
+Produce the strongest possible faithfulness review.
 
-Rules:
-- every finding must be tied back to the original prompt
-- do not suggest implementation structure
-- do not suggest stack choices unless the prompt itself forces them
-- prefer exact corrections over broad commentary
-- if the documents are faithful, say so clearly
+Your goal is to catch prompt drift before design begins, not to add process bloat.

package/assets/slopmachine/clarifier-agent-prompt.md

@@ -13,7 +13,7 @@ You do not choose the stack unless the prompt itself contains a material contrad
 You do not write a design doc.
 You do not write `plan.md`.
 
-Your job is to extract the core requirements from the prompt, define them deeply enough for later design and planning, and then find every meaningful prompt ambiguity, missing rule, vague boundary, unclear workflow, incomplete actor expectation, hidden dependency, or unclear success condition that could cause the product objective to be misunderstood or built incorrectly later.
+Your job is to extract the core requirements from the prompt, define them deeply enough for later design and planning, and then find every meaningful prompt ambiguity, missing rule, vague boundary, unclear lifecycle, incomplete actor expectation, hidden dependency, or unclear success condition that could cause the product objective to be misunderstood or built incorrectly later.
 
 You must resolve those ambiguities with the safest prompt-faithful decisions and write them into `questions.md`, while writing the deeper prompt-faithful requirements analysis into `../.ai/requirements-breakdown.md`.
 
@@ -35,12 +35,12 @@ The output must:
 ### 1. Preserve prompt faithfulness
 - Do not weaken, narrow, simplify, or reinterpret the prompt for convenience.
 - Do not introduce unauthorized `v1` reductions.
-- Do not silently drop implied actors, workflows, enforcement points, admin/operator behavior, or reporting expectations.
+- Do not silently drop implied actors, lifecycle flows, enforcement points, admin/operator behavior, or reporting expectations.
 - When two readings are possible, choose the stricter prompt-faithful one.
 
 ### 2. Focus on material ambiguity only
 - Include only ambiguities that would materially improve later design or planning.
-- Focus on product behavior, actor behavior, workflow closure, lifecycle/state rules, business rules, security/privacy boundaries, data boundaries, offline/network assumptions, reporting/export meaning, and operational expectations when they affect product meaning.
+- Focus on product behavior, actor behavior, lifecycle closure, lifecycle/state rules, business rules, security/privacy boundaries, data boundaries, offline/network assumptions, reporting/export meaning, and operational expectations when they affect product meaning.
 - Do not turn this into planning, stack selection, or implementation structure.
 
 ### 2.5 Extract the core requirements first
@@ -51,8 +51,8 @@ The output must:
 - Do not weaken or summarize them into vague labels.
 - After extracting and defining them, check them back against the original prompt and remove anything that narrows, broadens, or drifts from the prompt.
 
-### 2.6 Use evaluation-grade requirement extraction
-Requirement extraction must be as strict and tedious as the final static evaluation prompt.
+### 2.6 Use strict requirement extraction
+Requirement extraction must be strict and tedious enough for a critical static review.
 
 Before writing either artifact, extract and preserve:
 - core business goal and usage scenario
@@ -60,14 +60,15 @@ Before writing either artifact, extract and preserve:
 - required pages, screens, routes, APIs, jobs, modules, data objects, reports, exports, notifications, and integrations
 - main happy paths and task-closure conditions
 - required failure paths, validation failures, empty states, duplicate/re-entry behavior, cancellation, retry, rollback, and approval paths where relevant
-- security boundaries: authentication, route authorization, object authorization, function authorization, tenant/user isolation, admin/internal/debug protection, sensitive data, and audit/logging requirements
+- security boundaries: authentication, route authorization, object authorization, function authorization, tenant/user isolation, admin/internal/debug protection, sensitive data, and accountability/logging requirements
 - engineering credibility requirements: coherent project shape, module decomposition, central config, logging, validation, error handling, maintainable service/adaptor boundaries, and no demo-only delivery
+- static architecture credibility requirements: pages/routes/app shell/data flow must be connected where applicable, excessive single-file implementations and redundant/unnecessary files must be avoided, and pure frontend projects must keep mock/local-data boundaries disclosed without pretending they are backend integrations
 - documentation and static verifiability requirements: README clarity, startup/build/test/config guidance, entry points, scripts, routes, and repo structure being statically traceable
 - test and coverage expectations: unit, API, integration, frontend component/state, E2E/platform-equivalent, true no-mock HTTP where applicable, and coverage for core happy paths plus high-risk failure paths
 - mock/stub/fake/local-data boundaries: when they are allowed, when they must be disclosed, and when fake success would violate the product contract
 - frontend state and interaction obligations: loading, empty, submitting, disabled, success, error, validation, hover/click/current-state feedback, and task closure where applicable
 - FE↔BE integration expectations for fullstack/backend-backed frontend projects: every meaningful frontend action needs real backend support, and prompt-relevant backend features need frontend exposure unless truly internal/API-only
-- hidden delivery risks that final evaluation would catch: prompt drift, shell routes/pages/handlers, hardcoded fake behavior, missing owned tests, README drift, static entry-point inconsistency, weak security, and untraceable module boundaries
+- hidden delivery risks that strict review would catch: prompt drift, shell routes/pages/handlers, hardcoded fake behavior, missing owned tests, README drift, static entry-point inconsistency, weak security, and untraceable module boundaries
 
 Every extracted requirement must be atomic enough to survive planning. Do not combine multiple product promises into one broad bullet if they could be implemented, tested, authorized, or documented separately. If a prompt phrase implies a user-visible behavior, a backend capability, a data lifecycle rule, a security boundary, a delivery/documentation obligation, or a test obligation, give it a traceable requirement entry or explicitly mark why it is not applicable.
 
@@ -80,7 +81,15 @@ Before finalizing, run a no-orphan requirement sweep:
 - every mock/fake/local-data allowance maps to a disclosure and a forbidden fake-success boundary
 - every high-risk unknown is either resolved by a prompt-faithful default or listed as a clarification item with a decisive `Solution`
 
-Do not treat this as a short summary. The requirements breakdown should be strong enough that a later evaluator's prompt-to-code review has little new product meaning to discover.
+Additionally, run an explicit actor-action sweep:
+- for every actor mentioned in the prompt, list every verb/action attached to that actor in the original prompt text
+- compare that list against every locked default and clarification decision
+- verify that no clarification has removed, narrowed, or reassigned any action that the prompt explicitly grants to an actor
+- specifically guard against: removing public/consumer actions, narrowing creator rights to admin-only, or reassigning ownership tasks to operators
+- if any actor-action pair from the prompt is missing from the requirement registry, add it or explicitly justify why it is not applicable
+- this sweep prevents prompt drift where a clarifier accidentally narrows the product contract before design begins
+
+Do not treat this as a short summary. The requirements breakdown should be strong enough that a later prompt-to-code review has little new product meaning to discover.
 
 ### 3. Resolve instead of punting
 - Every entry must end with a decisive `Solution`.
@@ -90,10 +99,10 @@ Do not treat this as a short summary. The requirements breakdown should be stron
 ### 4. Run one real ambiguity sweep
 Before finalizing, explicitly check for ambiguity or hidden scope cuts around:
 - actors and role boundaries
-- workflow start, completion, failure, retry, cancellation, and approval paths
+- lifecycle start, completion, failure, retry, cancellation, and approval paths
 - business rules, limits, uniqueness, precedence, ownership, and conflict handling
 - lifecycle/state transitions
-- security, permissions, isolation, masking, retention, and auditability
+- security, permissions, isolation, masking, retention, and accountability
 - data visibility, history, edit authority, and cross-surface dependencies
 - reporting, export, reconciliation, or financial semantics when relevant
 - hidden environment and trust-boundary assumptions, especially on-prem, intranet, offline, LAN, browser access, auth cookies/tokens, local storage, self-contained deployment, external reachability, or secure/insecure transport when those can change product behavior
@@ -108,12 +117,13 @@ You must output only markdown into these 2 files:
 
 Do not include any preface, explanation, summary, commentary, or planning notes outside the file content.
 
-`../.ai/requirements-breakdown.md` must contain a deep prompt-faithful requirements analysis using this exact structure:
+`../.ai/requirements-breakdown.md` must contain a deep prompt-faithful requirements analysis using this exact structure. Assign stable `REQ-###` IDs before design begins. Every requirement that later design or planning may need to map must appear in the registry, and every later requirement entry must carry its `Requirement ID` field.
 
 ```md
 # Requirements Breakdown
 
 ## Core Business Goal
+- Requirement ID:
 - Requirement:
 - Definition:
 - Prompt Basis:
@@ -122,6 +132,12 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 - Failure / Negative Conditions:
 - Hidden Planning Risk:
 
+## Requirement ID Registry
+
+| Requirement ID | Requirement title | Type: explicit / implied / safe default | Prompt basis | Actor / surface | Success closure | Failure / negative conditions | Hidden planning risk |
+|---|---|---|---|---|---|---|---|
+| REQ-001 |  | explicit |  |  |  |  |  |
+
 ## Evaluation-Grade Requirement Inventory
 ### Business / Prompt Fit
 - Core business objective:
@@ -139,6 +155,7 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 - Required module decomposition:
 - Required service/adaptor/data boundaries:
 - Config/logging/validation/error-handling expectations:
+- Static structure expectations, including connected pages/routes/state/data flow, avoiding excessive single-file implementation, avoiding redundant/unnecessary files, and separating pure-frontend mock/local data from real backend claims:
 - Static reviewability expectations:
 
 ### Security / Privacy / Authorization
@@ -146,7 +163,7 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 - Route/object/function authorization expectations:
 - Tenant/user isolation expectations:
 - Admin/internal/debug protection expectations:
-- Sensitive data, logging, audit, retention, or masking expectations:
+- Sensitive data, logging, accountability, retention, or masking expectations:
 
 ### Test / Coverage Expectations
 - Core happy path proof required:
@@ -181,6 +198,7 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 
 ## Explicit Prompt Requirements
 ### <short requirement title>
+- Requirement ID:
 - Requirement:
 - Definition:
 - Prompt Basis:
@@ -191,6 +209,7 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 
 ## Implied But Binding Requirements
 ### <short requirement title>
+- Requirement ID:
 - Requirement:
 - Definition:
 - Prompt Basis:
@@ -201,6 +220,7 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 
 ## Locked Safe Defaults And Assumptions
 ### <short item title>
+- Requirement ID:
 - Requirement:
 - Definition:
 - Prompt Basis:
@@ -208,6 +228,10 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 - Success Closure:
 - Failure / Negative Conditions:
 - Why This Default Is Safe:
+- Implementation Risk Tier: [evaluation-critical / design-stabilizing / scope-expanding]
+  - `evaluation-critical`: the evaluator will likely check this; missing it risks audit failure
+  - `design-stabilizing`: reduces later ambiguity but is not directly scored
+  - `scope-expanding`: adds implementation work beyond the minimum prompt requirement; flag these so P2/P3 can prioritize or challenge them
 - Hidden Planning Risk:
 
 ## Planning-Miss Checklist
@@ -223,19 +247,9 @@ Do not include any preface, explanation, summary, commentary, or planning notes
 - hidden constraints or implied non-goals that planning could miss:
 ```
 
-`../docs/questions.md` must start with this exact section:
+`../docs/questions.md` must contain only clarification entries in the exact format below. Do not add requirement IDs, traceability fields, priority fields, evaluator-risk fields, core requirements baseline sections, or any other extra metadata to `../docs/questions.md`. Core requirements belong in `../.ai/requirements-breakdown.md` only. `../docs/questions.md` must stay a clean clarification artifact.
 
-```md
-## Core Requirements Baseline
-
-### <short requirement title>
-- Requirement: <the core requirement stated directly>
-- Definition: <what this requirement means in depth, including the important boundaries, actors, behaviors, constraints, and success conditions that must stay true later>
-- Prompt Basis: <the exact prompt-grounded reason this requirement is part of the contract>
-- Hidden Planning Risk: <what later design/planning could miss or weaken if this requirement is not carried forward explicitly>
-```
-
-After that section, use this exact structure for every clarification entry in `../docs/questions.md`:
+Use this exact structure for every entry in `../docs/questions.md`:
 
 ```md
 ### <number>. <short clarification title>
@@ -249,29 +263,21 @@ After that section, use this exact structure for every clarification entry in `.
 Use this exact style:
 
 ```md
-## Core Requirements Baseline
-
-### Clarified Prompt Contract Baseline
-- Requirement: The accepted core requirements and clarification decisions in this file define the product contract for later design and execution planning.
-- Definition: Design and execution planning must preserve the core requirements and the accepted clarification decisions captured here. They may operationalize them, but they may not silently narrow, soften, or replace them.
-- Prompt Basis: The original prompt is the primary source of truth, and this file exists to extract its core requirements and resolve the ambiguities that would otherwise force later guesswork.
-- Hidden Planning Risk: If this baseline is not carried forward explicitly, later design or planning can quietly weaken the prompt, drop implied constraints, or underbuild important task-closure behavior.
-
-### 1. Clarification Baseline for Design and Planning
-- Question: Can the clarification decisions captured in this file be treated as the baseline for design and execution planning?
-- My Understanding: The prompt was large enough that design and execution planning needed one accepted clarification record. We needed to lock that baseline before planning rather than carrying ambiguity forward.
-- Solution: Yes. Treat the clarification decisions in this file as the accepted baseline for Phase 1 design and Phase 2 execution planning.
-
-### 2. <short clarification title>
+### 1. <short clarification title>
 - Question: <the exact ambiguity or contradiction that needed to be resolved>
 - My Understanding: <how the prompt was interpreted, why the ambiguity mattered, and what risk it created for design and planning>
 - Solution: <the chosen prompt-faithful resolution or safe default>
+
+### 2. <short clarification title>
+- Question: <the exact ambiguity or missing detail that needed to be locked>
+- My Understanding: <how the prompt was interpreted, why this was ambiguous, and why it matters for later design and planning>
+- Solution: <the chosen prompt-faithful resolution or safe default, written decisively>
 ```
 
 ## Output discipline
 
 - Cover every material ambiguity you can justify.
-- Cover the core requirements explicitly before the clarification entries.
+- Put all core requirements in `../.ai/requirements-breakdown.md`, not in `../docs/questions.md`.
 - Extract prompt details strongly enough that later planning is not likely to miss edge conditions, operator/admin expectations, failure behavior, or implicit constraints hiding inside broad prompt wording.
 - Explicitly separate what the prompt states directly from what is implied but still binding.
 - Finish with a planning-miss checklist strong enough that later design and planning are less likely to miss subtle prompt details.
@@ -279,7 +285,7 @@ Use this exact style:
 - Every entry must be planning-relevant.
 - Every `Solution` must be decisive.
 - Large prompts will often need many entries, but unusually explicit prompts may need fewer.
-- Keep the file narrow and explicit; this is not a general project summary, but it must contain a strong core-requirements baseline plus the necessary clarifications.
+- Keep the file narrow and explicit; this is not a general project summary, and it must not contain a core-requirements baseline. Core requirements belong in `../.ai/requirements-breakdown.md` only. `../docs/questions.md` contains only the necessary clarifications.
 - The separate `../.ai/requirements-breakdown.md` file should be the deeper analysis artifact: in-depth, requirement-focused, and as prompt-faithful as possible.
 
 ## Inputs you will receive

package/assets/slopmachine/exact-readme-template.md

@@ -217,7 +217,7 @@ Expected result:
 If `init_db.sh` is part of the standard test bootstrap, document that relationship clearly.
 
 ### Local verification harness
-- Document the separate local verification command(s) used for ordinary development and owner-side pre-evaluation checks.
+- Document the separate local verification command(s) used for ordinary development and readiness checks.
 - Make clear that these local verification commands are distinct from the dockerized `./run_tests.sh` broad test path.
 - Use the real stack-native local suite for the chosen language/framework where applicable, for example Vitest, Jest, PHPUnit, pytest, go test, cargo test, or another framework-native equivalent.
 - If that local suite needs machine-level installation or setup, document that clearly in the local verification notes.
@@ -236,7 +236,7 @@ If `init_db.sh` is part of the standard test bootstrap, document that relationsh
 
 ### Test notes
 - `./run_tests.sh` is the dockerized broad test path reserved for the final containerized confirmation flow.
-- Local verification commands are used for ordinary development iteration and pre-evaluation owner checks.
+- Local verification commands are used for ordinary development iteration and readiness checks.
 - [Docker-contained notes if applicable]
 - [seed/fixture notes if applicable]
 - [known test constraints if any]
@@ -270,12 +270,38 @@ Use that exact line if the project truly has no authentication requirement.
 
 ---
 
-## 11. Workflow / Operational Notes
+## 11. Quick-Start Seeded Data
 
-### Main workflows
-- [workflow 1]
-- [workflow 2]
-- [workflow 3]
+Choose exactly one of the two sections below.
+
+### Option A — Seeded data exists
+
+The local runtime creates deterministic demo/test data through the normal bootstrap path.
+
+| Data type | Value / identifier | Purpose | How to use it |
+|---|---|---|---|
+| Account / role | [email or username] | [role / flow] | [login or action steps] |
+| Sample record | [record ID/name/URL] | [flow it unlocks] | [where to open/click/call] |
+
+Important:
+- Seeded data must be idempotent and recreated by the documented startup/database path.
+- Seeded data is for local demonstration and testing only.
+- Seeded data must not replace real product behavior with static fake-success paths.
+
+### Option B — No seeded data required
+
+No seeded data required; the app is useful from an empty state.
+
+Use that exact line only if a new user can exercise the main flows without preloaded records or accounts.
+
+---
+
+## 12. Workflow / Operational Notes
+
+### Main lifecycle flows
+- [lifecycle flow 1]
+- [lifecycle flow 2]
+- [lifecycle flow 3]
 
 ### Security / access notes
 - [public pages/endpoints]
@@ -289,12 +315,12 @@ Use that exact line if the project truly has no authentication requirement.
 - [jobs / queues / workers if applicable]
 
 ### Operational notes
-- [backup / retention / auditability / support notes if applicable]
-- [important admin/operator workflow notes if applicable]
+- [backup / retention / accountability / support notes if applicable]
+- [important admin/operator lifecycle notes if applicable]
 
 ---
 
-## 12. Feature-Flag / Mock / Debug / Demo Disclosure
+## 13. Feature-Flag / Mock / Debug / Demo Disclosure
 
 This section is mandatory whenever feature flags, mock data, local JSON, interception, fake/demo behavior, or debug surfaces exist.
 
@@ -309,7 +335,7 @@ If none of the above exist, say so explicitly.
 
 ---
 
-## 13. Important Limitations / Non-Goals
+## 14. Important Limitations / Non-Goals
 
 - [known limitation or boundary 1]
 - [known limitation or boundary 2]
@@ -330,6 +356,7 @@ Use this section for transparent disclosure, not for hiding missing core require
 - [ ] Docker-contained environment rules are clear
 - [ ] `.env` and `.env.example` are not required or referenced as committed repo artifacts
 - [ ] Auth credentials for all roles are present, or exact line `No authentication required` is present
+- [ ] Seeded quick-start data is documented, or exact line `No seeded data required; the app is useful from an empty state.` is present
 - [ ] Architecture summary is present
 - [ ] Workflow / operational notes are present when relevant
 - [ ] Feature-flag/mock/debug/demo disclosure is present if applicable

package/assets/slopmachine/owner-verification-checklist.md

@@ -57,7 +57,7 @@ Do not accept “close enough” on prompt-faithfulness, security, runtime hones
 - [ ] Exact runtime commands, broad test commands, wrapper-script mechanics, and README section contracts are not being pushed into `../docs/design.md`.
 
 ### A5. Test Strategy and Coverage Contract
-- [ ] The plan expresses a confident roughly `90%` overall real-test coverage target.
+- [ ] The plan requires at least `90%` unit-testable product-code coverage where measurable and at least `90%` closure of planned E2E/platform-critical flow rows.
 - [ ] The measurement path and confidence expectations are named.
 - [ ] Every meaningful surface family has required test layers.
 - [ ] Frontend unit/component/state testing is explicit when the project is `web` or `fullstack`.
@@ -148,7 +148,7 @@ Do not accept “close enough” on prompt-faithfulness, security, runtime hones
 - [ ] Signed links/tokens, public routes, audit durability, encryption, and privileged action re-checks are planned fail-closed where relevant.
 
 ### B5. Test Coverage Execution Contract
-- [ ] The plan keeps a confident roughly `90%` overall real-test coverage target.
+- [ ] The plan keeps at least `90%` unit-testable product-code coverage where measurable and at least `90%` closure of planned E2E/platform-critical flow rows.
 - [ ] Every meaningful planned surface/work package is mapped to tests.
 - [ ] Every prompt-relevant module owns or explicitly inherits unit/API/integration/E2E/frontend-state proof as applicable.
 - [ ] Modules that own APIs have concrete full API coverage expectations, preferably true no-mock HTTP by exact `METHOD + PATH` unless a narrow exception is accepted.