theslopmachine 1.0.2 → 1.0.3

package/assets/slopmachine/phase-1-design-prompt.md

@@ -28,7 +28,7 @@ You must:
 - preserve the real business goal, required user outcomes, operational flows, and meaningful constraints
 - treat accepted core requirements as binding
 - treat accepted clarifications as binding
-- define stable requirement IDs inside the accepted design contract so later `api-spec.md` and `plan.md` can trace the same requirement surfaces consistently
+- preserve the stable requirement IDs from `../.ai/requirements-breakdown.md` so later `../docs/api-spec.md` and `plan.md` can trace the same requirement surfaces consistently
 - choose the stricter interpretation when ambiguity could cause under-delivery
 - keep all required roles, operator/admin flows, enforcement points, validations, and delivery surfaces visible
 - make assumptions explicit
@@ -45,7 +45,7 @@ You must not:
 
 If something truly cannot be locked honestly, isolate it in a very small unresolved-items section with impact and required owner decision.
 
-When a design 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 a design 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.
 
 ---
 
@@ -75,11 +75,11 @@ The accepted design document must be strong enough that:
 - Phase 2 can convert it into `plan.md` without reinterpreting the product
 - the original prompt and `../.ai/requirements-breakdown.md` have been decomposed into traceable requirement surfaces rather than summarized into broad feature labels
 - when backend/fullstack APIs exist, Phase 2 can convert `../docs/api-spec.md` directly into complete API-test planning
-- requirement IDs defined in the accepted design can still be traced through the API contract, planning, and coverage artifacts
+- requirement IDs from `../.ai/requirements-breakdown.md` can still be traced through the accepted design, API contract, planning, and coverage artifacts
 - starter/bootstrap/baseline decisions are already locked
 - security expectations and test strategy are already locked
 - runtime/bootstrap/README execution contracts are left for Phase 2 instead of being expanded inside `../docs/design.md`
-- required roles, pages, APIs, jobs, workflows, validations, permissions, and state transitions are already locked
+- required roles, pages, APIs, jobs, lifecycle flows, validations, permissions, and state transitions are already locked
 - prompt-relevant modules are identified before planning, with each module's frontend surfaces, backend/API/job/data surfaces, verification expectations, and FE↔BE wiring expectations visible
 - the owner can reject design drift early, before execution planning begins
 
@@ -87,8 +87,8 @@ The accepted design document must be strong enough that:
 
 ## Non-Negotiable Rules
 
-### 0. Design must target the final evaluator prompts directly
-The design must explicitly lock only the delivery obligations that the final static evaluation and test-coverage prompts will judge. Do not add broad process bloat; do add concrete design requirements for every applicable evaluator expectation below so Phase 2 can turn them into implementation and proof:
+### 0. Design must target the strict delivery contract directly
+The design must explicitly lock only the delivery obligations needed for a complete, reviewable product. Do not add broad process bloat; do add concrete design requirements for every applicable expectation below so Phase 2 can turn them into implementation and proof:
 - prompt alignment: business goal, required pages/screens, main user/operator flows, constraints, and task closure must remain visible and traceable
 - static delivery credibility: repo entry points, route/app wiring, configuration shape, project structure, and primary documentation must be statically consistent
 - README hard gates: repo-root `README.md`, project type near the top using one of `backend`, `fullstack`, `web`, `android`, `ios`, or `desktop`, `docker compose up --build`, legacy compatibility string `docker-compose up`, access method, verification method, no manual install/setup dependency, and auth demo credentials for every role or explicit `No authentication required`
@@ -98,9 +98,11 @@ The design must explicitly lock only the delivery obligations that the final sta
 - fullstack proof: major user flows must have planned FE↔BE proof, not only separate backend and frontend tests
 - security and governance: auth entry points, route authorization, object-level authorization, function-level authorization, tenant/user isolation, admin/internal/debug protection, sensitive-data handling, and log/response redaction must be designed where applicable
 - mock/demo/debug honesty: mock/local/fake/demo/debug behavior must be scoped and disclosed, and fake-success paths must not hide missing real behavior
-- engineering quality: module boundaries, maintainability, validation, error handling, logging categories, and avoidance of redundant/unrelated files must be planned only where they affect evaluator-visible delivery credibility
+- engineering quality: module boundaries, maintainability, validation, error handling, logging categories, and avoidance of redundant/unrelated files must be planned only where they affect delivery credibility
+- static architecture quality: avoid excessive single-file implementations, chaotic coupling, redundant/unnecessary files, disconnected pages/routes, disconnected state/data flow, and unclear service/adaptor/mock/storage boundaries where those would undermine static delivery credibility
+- pure frontend boundary: if the project is `web` with no backend service, mock/local JSON/localStorage/sessionStorage/IndexedDB data is allowed when honest and disclosed; the design must not imply real backend integration, fake-success behavior, backend idempotency, database consistency, or backend security guarantees that a pure frontend cannot own
 
-If an evaluator expectation is not applicable, the design must say why in one compact row or sentence. Do not create separate large matrices when an existing ledger/table can carry the same exact obligation.
+If a delivery expectation is not applicable, the design must say why in one compact row or sentence. Do not create separate large matrices when an existing ledger/table can carry the same exact obligation.
 
 ### 1. Coverage is a design obligation, not a cleanup task
 Every meaningful planned surface must have planned verification.
@@ -113,7 +115,7 @@ The design must lock the expected test layers for all meaningful behavior, inclu
 
 For all `web` projects, browser E2E is mandatory in planning scope: require Playwright or an equivalent real in-browser E2E approach in the accepted design so Phase 2 cannot leave browser E2E optional.
 
-The design target is evaluator-relevant coverage:
+The design target is delivery-relevant coverage:
 - meaningful planned tests for every accepted endpoint, core flow, security boundary, and major failure path
 
 The design must state:
@@ -131,7 +133,71 @@ For fullstack or backend-backed frontend projects, every module that has UI beha
 
 Internal/API-only reasons must be specific and prompt-faithful. Reject generic rationales such as `not needed in UI`, `admin only`, `backend only`, or `future work` unless the design names the actor, consumer, access path, security boundary, and why omitting frontend exposure does not weaken the prompt.
 
-If backend/fullstack APIs exist, this phase must also produce `../docs/api-spec.md` as an exact API contract by `METHOD + PATH` so Phase 2 can plan `100%` API test coverage from the accepted spec instead of rediscovering routes later.
+If backend/fullstack APIs exist, this phase must also produce `../docs/api-spec.md` as an exact API contract by `METHOD + fully resolved PATH` so Phase 2 can plan API proof from the accepted spec without losing route intent. The implemented routes and tests in the repo are the delivery truth, not this file alone; Phase 2 and implementation must keep repo route registration, tests, README, and this API spec consistent.
+
+For every form-backed endpoint (POST, PUT, PATCH), the API spec must also document:
+- the exact frontend form field names that will be rendered in templates
+- the exact backend handler field names that will read the request
+- a verification note that these names match, or a shared constant/typed request struct plan to prevent field-name drift
+- for browser-rendered forms: the CSRF token field name and how it is delivered
+
+For every security-critical feature, the design must specify the exact enforcement layer:
+- service-layer enforcement (business logic checks)
+- middleware-layer enforcement (route guards, rate limiting)
+- database-layer enforcement (triggers, RLS, constraints)
+- template-layer enforcement (CSRF tokens, hidden fields)
+- runtime-layer enforcement (background jobs, startup wiring)
+A security feature is incomplete if it exists only in the happy-path service code and not at the layer where bypass or mutation would occur.
+
+For every background job, scheduled task, or runtime lifecycle function, the design must state:
+- the exact entrypoint where it is started/stopped (e.g., `main.go`, startup hook, scheduler init)
+- the exact durable storage or configured path it uses (not temp directories)
+- the verification path that proves it is reachable from application startup
+
+For every data lifecycle feature (export, deletion, retention, retry, edit), the design must state:
+- whether exported values are decrypted, masked, redacted, or omitted
+- retry/edit/delete semantics and deduplication rules
+- whether display values and stored values are the same or separate
+- any masking rules that must not corrupt source-of-truth data on edit
+
+Write `../docs/api-spec.md` in this exact simple Markdown structure:
+
+```md
+# API Specification
+
+## API Scope
+- Project type:
+- API base prefix:
+- Versioning model:
+- Auth/session model:
+- Global error response shape:
+- Source requirement IDs:
+
+## Endpoint Inventory
+
+| Requirement ID | METHOD | Fully resolved PATH | Purpose | Actor / role | Auth required | Request params/body/query | Response shape | Side effect / persisted state | Validation / error codes | Planned test proof |
+|---|---|---|---|---|---|---|---|---|---|---|
+
+## Endpoint Details
+
+### `METHOD /fully/resolved/path`
+- Requirement IDs:
+- Purpose:
+- Actor / role:
+- Auth required:
+- Object ownership / tenant isolation:
+- Request:
+- Response:
+- Side effects:
+- Validation rules:
+- Error cases:
+- Idempotency / pagination / filtering / concurrency notes:
+- Planned API proof:
+  - true no-mock HTTP / HTTP with mocking / unit-only exception
+  - planned test file:
+  - key request input:
+  - key response or side-effect assertion:
+```
 
 ### 2. Design document boundary
 `../docs/design.md` is the system/repo design document only.
@@ -201,7 +267,9 @@ If the prompt and current repo do not already dictate the stack:
 - choose the starter/bootstrap path deliberately
 - choose the runtime/test baseline deliberately
 - prefer official or well-supported starters when they reduce setup waste and improve delivery credibility
-- if web frontend styling/component defaults are open, choose a mainstream documented path deliberately rather than improvising the UI system later
+- if a web/frontend prompt does not specify a frontend JavaScript framework, default to Vue 3 with Vite and TypeScript
+- if a web/frontend prompt does not specify a styling library, default to Tailwind CSS
+- if a frontend prompt does not specify a UI component library, prefer shadcn/ui where it is compatible with the selected framework and delivery constraints; if shadcn is not compatible or would add unnecessary complexity, record the reason and choose the smallest framework-compatible component approach
 - if mobile defaults are open, choose a modern mainstream stack deliberately rather than leaving it unresolved
 - if desktop defaults are open, choose a Linux-testable mainstream stack deliberately rather than leaving it unresolved
 - do not leave those decisions for scaffold-step improvisation during development
@@ -216,9 +284,9 @@ This phase must lock the contract that Phase 2 will operationalize.
 ### 9. Run an explicit design gap sweep before finalizing
 Before finalizing the design, explicitly check for and resolve or narrow-assume the important gaps that coding LLMs commonly miss:
 - business-rule gaps such as thresholds, limits, defaults, uniqueness, deadlines, idempotency, retry behavior, ownership, and override rules
-- workflow gaps such as start conditions, completion conditions, exception paths, approval paths, cancellation or rollback behavior, and actor handoffs
-- data-model gaps such as missing entities, missing relationships, missing history or audit records, and records that should be immutable
-- security or compliance gaps such as auth scope, permission boundaries, audit trails, retention, masking, lockout, and recovery policy
+- lifecycle gaps such as start conditions, completion conditions, exception paths, approval paths, cancellation or rollback behavior, and actor handoffs
+- data-model gaps such as missing entities, missing relationships, missing history or accountability records, and records that should be immutable
+- security or compliance gaps such as auth scope, permission boundaries, accountability trails, retention, masking, lockout, and recovery policy
 - offline, async, or reliability gaps where applicable, such as queueing, retries, resumability, conflict resolution, and observability
 - reporting or analytics gaps where applicable, such as KPI definitions, formulas, date grain, source of truth, and export semantics
 - config/runtime drift gaps where admin or user settings are stored but might not actually drive runtime behavior
@@ -269,10 +337,11 @@ Create a direct ledger of:
 Also include a no-orphan trace table with columns: `Requirement ID`, `Requirement summary`, `Design surface(s)`, `Owning module`, `API/data surface if applicable`, `UX/actor path if applicable`, `Security/failure case`, `Planned proof layer`, and `Status`. No row may remain `unmapped` when the design is accepted.
 
 ### B.1 Final Evaluation Target Contract
-Include a compact contract that maps the final evaluator prompts into design obligations. Required rows, with `Not Applicable` allowed only with a reason:
+Include a compact contract that maps strict delivery review concerns into design obligations. Required rows, with `Not Applicable` allowed only with a reason:
 - prompt-fit and core requirement coverage
 - end-to-end delivery/project shape
 - static startup/build/config/entrypoint traceability
+- static consistency across README/docs/scripts/routes/config/examples/manifests/env examples without relying on runtime execution
 - README hard gates and demo credentials/no-auth disclosure
 - API endpoint inventory and real HTTP test strategy where applicable
 - API coverage summary computability where applicable: total endpoints, endpoints with HTTP tests, endpoints with true no-mock HTTP tests, and mocked/indirect exceptions must be derivable from the accepted API/test plan
@@ -282,6 +351,7 @@ Include a compact contract that maps the final evaluator prompts into design obl
 - security/auth/authorization/isolation/admin-debug protection
 - validation, error handling, logging, and sensitive-data leakage controls
 - mock/local/demo/debug disclosure and fake-success prevention
+- pure-frontend mock/local-data disclosure and boundary honesty where applicable
 - unit/API/integration/E2E or platform-equivalent test expectations
 
 ### C. Actors, Roles, and Paths to Success
@@ -354,6 +424,7 @@ For each module define:
 - failure behavior
 - security considerations
 - planned verification layers
+- static architecture risks to avoid, including disconnected pages/routes/data flow, excessive single-file concentration, redundant/unnecessary files, and unclear adaptor/mock/storage boundaries
 
 Each module must also name `requirements explicitly not owned by this module but adjacent to it` so Phase 2 can catch cross-module gaps rather than assuming the neighbor owns them.
 
@@ -414,14 +485,14 @@ Define the required test layers and the major coverage expectations for:
 - logging redaction / sensitive-data exposure
 - pagination / sorting / filtering where relevant
 - frontend state and route coverage where applicable
-- frontend unit-test audit readability for `web` / `fullstack` so later review can state `Frontend unit tests: PRESENT` or `Frontend unit tests: MISSING` from file-level evidence
+- frontend unit-test readability for `web` / `fullstack` so later review can state `Frontend unit tests: PRESENT` or `Frontend unit tests: MISSING` from file-level evidence
 - E2E/platform proof where applicable, including Playwright for web/fullstack major flows when applicable, Playwright Electron/Xvfb or equivalent for Linux-targetable desktop flows, no-emulator-default broad verification for Android, and honest Linux proof boundaries for iOS
 - API test observability where applicable, including request input visibility and simple useful response evidence such as status-code and response-summary assertions
 - visibility of important untested module families where applicable, especially controllers, services, repositories, auth, guards, and middleware
 - `../docs/test-coverage.md` structure when applicable: requirement/risk point, mapped test files, key assertions/fixtures, current status, remaining gap, and minimum test addition
 
 This phase must define the test strategy strongly enough that Phase 2 can map every surface to owned tests.
-Requirement IDs defined in this design must be reusable by `../docs/api-spec.md` and `plan.md` rather than being renamed later.
+Requirement IDs from `../.ai/requirements-breakdown.md` must be reused by `../docs/api-spec.md` and `plan.md` rather than being renamed later.
 
 ### N. Definition of Done for Design
 State what must already be locked before the design can be accepted and handed into Phase 2.
@@ -456,6 +527,12 @@ Produce the design document in this order:
 
 ---
 
+## Section-by-Section Delivery Rule
+
+Write `../docs/design.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. When backend/fullstack APIs exist, write `../docs/api-spec.md` endpoint family by endpoint family using the same rule.
+
+---
+
 ## Design Quality Bar
 
 The design is acceptable only if:

package/assets/slopmachine/phase-1-design-template.md

@@ -3,6 +3,8 @@
 Use this template to produce the accepted design document.
 The output should normally be written to `../docs/design.md`.
 
+> Write this template section by section, appending each completed section to `../docs/design.md`. Do not paste full section text in chat or dump the accumulated document at the end.
+
 ---
 
 ## 1. Project Type and Delivery Shape
@@ -55,7 +57,7 @@ The output should normally be written to `../docs/design.md`.
 - 
 
 ### 2.6 Final Evaluation Target Contract
-Map only the final static evaluator and test-coverage/README expectations that apply. Use `Not Applicable` with a short reason when an item does not apply.
+Map only the strict delivery, test-coverage, and README expectations that apply. Use `Not Applicable` with a short reason when an item does not apply.
 
 | Evaluator expectation | Design obligation | Owning section/module | Planned proof layer | Status |
 |---|---|---|---|---|
@@ -73,6 +75,20 @@ Map only the final static evaluator and test-coverage/README expectations that a
 | mock/local/demo/debug disclosure and fake-success prevention |  |  |  | planned |
 | unit/API/integration/E2E or platform-equivalent test expectations |  |  |  | planned |
 
+### 2.7 No-Orphan Requirement Trace Table
+
+Every requirement ID from `../.ai/requirements-breakdown.md`, every accepted clarification that affects delivery, and every locked safe default must appear here.
+
+No row may remain `unmapped` when the design is accepted.
+
+Allowed statuses: `mapped`, `not applicable with accepted reason`, `blocked pending owner decision`.
+
+Disallowed statuses: `covered generally`, `later`, `TBD`, `unmapped`.
+
+| Requirement ID | Requirement summary | Design surface(s) | Owning module | API/data surface if applicable | UX/actor path if applicable | Security/failure case | Planned proof layer | Status |
+|---|---|---|---|---|---|---|---|---|
+| REQ-001 |  |  |  |  |  |  |  | mapped |
+
 ---
 
 ## 3. Accepted Clarification Ledger
@@ -163,7 +179,7 @@ List only items that do not shrink the prompt.
 |  |  |  |  |  |
 
 ### 8.2.1 Role Surface Matrix
-Use this matrix for every role-sensitive project. If the project has no role, auth, ownership, public/private route, admin, audit, or read-only distinction, state `Not Applicable` and explain why.
+Use this matrix for every role-sensitive project. If the project has no role, auth, ownership, public/private route, admin, accountability logging, or read-only distinction, state `Not Applicable` and explain why.
 
 | Route / page / API / action / data object / notification / export / admin function | Roles allowed | Read/write scope | Object ownership rule | Admin override rule | Viewer/read-only rule | Audit/logging requirement | Frontend route/nav expectation | Test evidence required later |
 |---|---|---|---|---|---|---|---|---|
@@ -223,6 +239,31 @@ Design must identify modules before Phase 2 plans execution order or file/locati
 |---|---|---|---|---|
 |  |  |  |  |  |
 
+### 10.5 Design-Level FE↔BE Integration Map
+
+Required for every fullstack or backend-backed frontend project. If not applicable, state `Not Applicable` and why.
+
+| Frontend page/component/action | Requirement ID | Backend endpoint/service/job | Payload/state input | Expected response/side effect | Required frontend states | Required proof layer |
+|---|---|---|---|---|---|---|
+|  |  |  |  |  | loading / empty / submitting / disabled / success / error / duplicate-action |  |
+
+For every form-backed frontend action in this map, also document:
+- Exact rendered form field names (as they will appear in HTML templates)
+- Exact backend handler field names (as they will be read from request)
+- CSRF token field name and delivery mechanism
+- Form submission success response (redirect, JSON, or rendered page)
+- Form submission failure response (validation errors, re-render, or JSON)
+
+A form is incomplete until the rendered fields match the handler's expected fields and a valid submit reaches the intended side effect.
+
+### 10.6 Backend-to-Frontend Exposure Check
+
+Every prompt-relevant backend capability must either be exposed through the required frontend/operator surface or explicitly accepted as internal/API-only.
+
+| Backend capability / endpoint / job / data feature | User-facing/frontend exposure | If internal/API-only, accepted reason | Actor/consumer | Invocation path | Authorization boundary | Proof required |
+|---|---|---|---|---|---|---|
+|  |  |  |  |  |  |  |
+
 Rules:
 - every prompt-relevant module must have real behavior, not a shell
 - every module must name its surfaces and verification expectations
@@ -270,8 +311,8 @@ Extract exact prompt-critical rules here so implementation cannot lose them late
 
 ## 11. State and Lifecycle Models
 
-### 11.1 Core entities/workflows with state
-| Entity / workflow | States | Valid transitions | Invalid transitions | Notes |
+### 11.1 Core entities/lifecycles with state
+| Entity / lifecycle | States | Valid transitions | Invalid transitions | Notes |
 |---|---|---|---|---|
 |  |  |  |  |  |
 
@@ -300,6 +341,18 @@ Extract exact prompt-critical rules here so implementation cannot lose them late
 ### 12.5 Function-level / admin / internal / debug protection
 - 
 
+### 12.5.1 Security Enforcement Layer Map
+For each security-critical feature, document the exact layer that enforces it:
+
+| Security feature | Service layer | Middleware layer | Database layer | Template layer | Runtime layer | Notes |
+|---|---|---|---|---|---|---|
+|  |  |  |  |  |  |  |
+
+Rules:
+- a security feature is incomplete if it exists only in happy-path service code
+- every security feature must have enforcement at the layer where bypass or mutation would occur
+- do not rely on route-level middleware alone for defense-in-depth; handler-level checks are required for privileged operations
+
 ### 12.6 Tenant/user isolation model if applicable
 - 
 
@@ -378,6 +431,18 @@ If not applicable, state `Not Applicable`.
 |---|---|---|---|---|
 |  |  |  |  |  |
 
+### 16.2.1 Runtime Entrypoint Wiring
+For every background job or scheduled task, document:
+
+| Job / worker | Entrypoint startup location | Entrypoint stop location | Durable storage/config path | Verification path |
+|---|---|---|---|---|
+|  |  |  |  |  |
+
+Rules:
+- every runtime job must be reachable from application startup
+- storage paths must be durable or explicitly configured, not temp defaults
+- a runtime job is incomplete until it is wired from the entrypoint
+
 ### 16.3 API design-level contracts
 - Resource families:
 - Request/response shape principles:
@@ -385,21 +450,46 @@ If not applicable, state `Not Applicable`.
 - Error-shape principles:
 
 ### 16.4 Companion `../docs/api-spec.md` requirement
-If backend/fullstack APIs exist, create `../docs/api-spec.md` as the accepted API contract with an exact `METHOD + PATH` inventory and enough detail that Phase 2 can plan `100%` API test coverage directly from it.
-
-Required `api-spec.md` fields:
-- Source requirement ID(s)
-- METHOD
-- PATH
-- Purpose
-- Auth / actor / role scope
-- Role surface matrix row reference when applicable
-- Object ownership, admin override, viewer/read-only, public/private, audit/logging, and signed-link/token rules when applicable
-- Request shape
-- Response shape
-- Validation and error codes
-- Important failure paths
-- Notes on idempotency / pagination / filtering / concurrency when relevant
+When backend/fullstack APIs exist, write `../docs/api-spec.md` in this exact simple Markdown structure.
+
+The implemented routes and tests in the repo are the delivery truth, not this file alone; Phase 2 and implementation must keep repo route registration, tests, README, and this API spec consistent.
+
+```md
+# API Specification
+
+## API Scope
+- Project type:
+- API base prefix:
+- Versioning model:
+- Auth/session model:
+- Global error response shape:
+- Source requirement IDs:
+
+## Endpoint Inventory
+
+| Requirement ID | METHOD | Fully resolved PATH | Purpose | Actor / role | Auth required | Request params/body/query | Response shape | Side effect / persisted state | Validation / error codes | Planned test proof |
+|---|---|---|---|---|---|---|---|---|---|---|
+
+## Endpoint Details
+
+### `METHOD /fully/resolved/path`
+- Requirement IDs:
+- Purpose:
+- Actor / role:
+- Auth required:
+- Object ownership / tenant isolation:
+- Request:
+- Response:
+- Side effects:
+- Validation rules:
+- Error cases:
+- Idempotency / pagination / filtering / concurrency notes:
+- Planned API proof:
+  - true no-mock HTTP / HTTP with mocking / unit-only exception
+  - planned test file:
+  - key request input:
+  - key response or side-effect assertion:
+```
 
 ---
 
@@ -421,6 +511,19 @@ If not applicable, state `Not Applicable`.
 ### 17.4 Indexing/partitioning/retention/performance rules if prompt-critical
 - 
 
+### 17.5 Data Lifecycle Semantics
+For every data feature involving export, deletion, retention, retry, or edit:
+
+| Data feature | Export format | Masking rule | Retry/edit semantics | Dedup rule | Source-of-truth vs display |
+|---|---|---|---|---|---|
+|  | decrypted / masked / redacted / omitted |  |  |  | same / separate |
+
+Rules:
+- display values and stored values must not be interchangeable
+- masked display fields must not be submitted back as source-of-truth values
+- retry flows must be explicitly designed, not just first-create flows
+- data export must specify whether values are decrypted, masked, or redacted
+
 ---
 
 ## 18. Documentation Artifact Expectations
@@ -472,7 +575,7 @@ If not applicable, state `Not Applicable`.
 ### 19.4 Frontend test requirement
 If project type is `web` or `fullstack`, frontend unit/component/state tests must be present and visible by file-level evidence.
 
-Required audit-readable fields:
+Required review-readable fields:
 - Frontend unit tests verdict: [PRESENT | MISSING]
 - Frameworks/tools detected or planned:
 - Frontend test files / locations:
@@ -481,7 +584,7 @@ Required audit-readable fields:
 ### 19.5 API test requirement
 If backend/fullstack APIs exist, all shipped/documented `METHOD + PATH` surfaces must be planned for true no-mock HTTP coverage unless a narrow explicit exception is accepted.
 
-Required audit-readable fields:
+Required review-readable fields:
 - Request/response observability expectations:
 - Useful response evidence expectations (status codes / response summaries):
 - Important backend module families that must not remain invisible if untested: