cabloy 5.1.149 → 5.1.151

package/.claude/skills/cabloy-spec-generation/references/repo-aware-discovery.md

@@ -0,0 +1,101 @@
+# Repository-Aware Discovery
+
+Use this reference before putting repository-specific paths or commands into a suite planning record.
+
+## Read-only discovery
+
+Run from the active repository root when needed:
+
+```bash
+git rev-parse --show-toplevel
+git status --short
+find . -maxdepth 1 \( -name '__CABLOY_BASIC__' -o -name '__CABLOY_START__' \) -print
+find repo-specs -maxdepth 2 -type f -name 'README.md' -print
+npm run vona
+npm run zova
+```
+
+Inspect the root `package.json` before documenting exact future commands. Read the active edition marker first:
+
+- only `__CABLOY_BASIC__` present means Cabloy Basic;
+- only `__CABLOY_START__` present means Cabloy Start;
+- both markers mean the checkout is invalid or ambiguous and must not receive edition-specific assumptions;
+- neither marker means the edition is unresolved and must not receive edition-specific assumptions.
+
+For a Start repository, resolve flavor names, sites, public paths, generated-output locations, and command wrappers from that repository. Do not inherit Basic examples by analogy.
+
+## Site-strategy discovery
+
+Use two passes when the proposed suite has a Web, Admin, or another user-facing site audience.
+
+1. **Before strategy selection**, inspect the active edition only far enough to identify observed shared Web/Admin hosts, their composition owners and extension points, and any independent-site conventions. Read current `SsrSite` registrations, Zova site/flavor configuration, root scripts, and representative shared-site or site-owner modules as needed. Do not turn an example suite’s layout into the new suite’s target.
+2. **After the high-level strategy is selected**, inspect only the affected source/configuration surfaces to establish exact facts: `SsrSite` registrations, shared-shell contribution patterns, site IDs, public paths, bundle/flavor names, environment/configuration files, asset-copy targets, paired development/SSR-build/REST-build commands, and dependency-sync procedures.
+
+Cite every observed site/runtime fact by source path in the planning record. Describe a selected strategy as a confirmed input, proposed target, or accepted ADR boundary—not as a source-confirmed fact. Keep each unobserved identifier as `TODO(confirm from active source)`; never derive it from a suite/module name or symmetry between Web and Admin.
+
+When selecting Web/Admin strategy, evaluate each audience separately. A normal choice may combine shared or independent composition for each audience, but a custom combination, an audience with no site, or deferral remains valid. If strategy or required identifiers are deferred, make only affected frontend/site implementation work `blocked`; a source-discovery task can remain `not-started`, and backend, known shared-site, or unrelated-audience work remains accurately statused.
+
+Basic identifiers and commands are not portable Start facts, and neither Basic nor Start example-suite details are portable to another suite without active-source inspection.
+
+## Suite-first source topology
+
+For a confirmed suite short name `<suite>`, the intended source layout is normally:
+
+```text
+vona/src/suite/<suite>/modules/<module>/
+zova/src/suite/<suite>/modules/<module>/
+```
+
+This is a planning target, not proof that the directories already exist. State whether a path is observed or proposed.
+
+## CLI-first planning
+
+No known Cabloy CLI currently generates the complete repository Markdown planning set. Once the baseline is confirmed, create the planning records manually under `repo-specs/`. Use Vona/Zova CLI discovery to plan eventual code scaffolding, metadata, OpenAPI generation, dependency synchronization, or verification; do not invent a command family.
+
+Potential Cabloy Basic root commands observed in the active repository include:
+
+```bash
+npm run vona
+npm run zova
+npm run tsc
+npm run test
+npm run build
+npm run test:e2e
+npm run build:zova:admin
+npm run build:zova:web
+npm run deps:vona
+```
+
+These are prospective commands only until actually executed for the relevant change. A test plan must label them as planned procedures. A command in a document is not evidence of a passing run.
+
+For a fullstack contract change, record the appropriate checkpoint:
+
+- forward chain: backend contract truth, OpenAPI inspection, generated Zova consumers, then thin model/page follow-up;
+- reverse chain: matching Zova flavor SSR plus REST build, then `npm run deps:vona`;
+- if generated artifacts are correct but installed consumers remain stale, diagnose local dependency drift before editing generated files.
+
+Hand actual implementation-time synchronization to `cabloy-contract-loop`.
+
+## Documentation boundaries
+
+| Content | Home |
+| --- | --- |
+| Product requirements, SRS contracts, WBS, ATPs, suite ADRs, delivery status | `repo-specs/<suite>/` |
+| Reusable user-facing or agent-facing framework guidance | `repo-docs/` |
+| Cross-suite maintainer architecture, rationale, and engineering ADRs | An established internal-documentation home, when present; do not create one implicitly |
+| Short durable AI operating rules | `CLAUDE.md` |
+| Reusable Claude procedure | `.claude/skills/` |
+
+Do not place suite product specifications in public docs, or copy repository-wide process rationale into every suite. Link to authoritative framework records instead.
+
+## Safe execution boundary
+
+While authoring planning records, do not automatically:
+
+- run `npm run init`;
+- reset or recreate a database;
+- scaffold source code;
+- run deployment or external-provider operations;
+- claim test, browser, CI, build, migration, or generated-artifact results.
+
+If the user explicitly asks for a verification command to be run and the result is intended as retained evidence, execute only after confirming the scope and then record the actual revision, environment, exact procedure, result, and redacted artifact location. Otherwise keep the command as a future WBS/test-plan procedure.

package/.claude/skills/cabloy-spec-generation/references/repo-specs-document-set.md

@@ -0,0 +1,267 @@
+# Repository-Native Spec Document Set
+
+This reference defines the standard generated by `cabloy-spec-generation`. It is distilled from the suite records in `repo-specs/a-commerce`, `repo-specs/home-user`, and Cabloy Start's `repo-specs/cabloy-admin`.
+
+## Default directory
+
+For a new long-lived business suite:
+
+```text
+repo-specs/<suite-short-name>/
+├── README.md
+├── prd.md
+├── srs.md
+├── pdp-wbs.md
+├── test-plan.md
+├── progress.md
+├── implementation-gantt.svg
+├── implementation-burndown.svg
+└── decisions/
+    └── 0001-<suite-boundary-slug>.md
+```
+
+The directory is repository-native, suite-local, and maintainer-facing. It is not a second public documentation tree and not a parallel change-management authority.
+
+## Authority map
+
+| Document | Authority |
+| --- | --- |
+| `README.md` | Index, reading order, baseline summary, topology, authority map, and related-record links. It does not replace the other documents. |
+| `prd.md` | Product outcomes, personas, scope, journeys, business rules, product requirements, and product acceptance. |
+| `srs.md` | System contracts, capability/data ownership, APIs/DTOs, authorization, state, transactions, invariants, frontend/SSR boundaries, and technical acceptance. |
+| `pdp-wbs.md` | Delivery sequencing, dependencies, implementation tasks, completion checks, and delivery traceability. |
+| `test-plan.md` | Quality priorities, executable acceptance scenarios, fixtures, evidence format, verification procedures, and release proof. |
+| `progress.md` | Derived execution status, blockers, decisions needed, next proof, and evidence pointers. It never redefines requirements or contracts. |
+| `implementation-gantt.svg` | Deterministic derived WBS view of phases, task order, dependencies, status, and optional ATP labels. It is not schedule or planning authority. |
+| `implementation-burndown.svg` | Deterministic derived scope/status view. Without dated history, it is a scope-count reference, not a time-series, velocity trend, or forecast. |
+| `decisions/*.md` | Durable suite-local scope, architecture, security, ownership, migration, or integration decisions. |
+| `runbooks/*.md` | Operational procedures subordinate to the relevant SRS, ADR, WBS, and test plan. |
+
+When records disagree, update the authoritative record first, then update downstream summaries, mappings, and derived status. After any change to `pdp-wbs.md`, `test-plan.md`, or `progress.md`, run `npm run spec:charts -- <suite>` followed by `npm run spec:charts:check -- <suite>`.
+
+The implementation charts are generated records, not authorities. The Gantt reads formal WBS phases/tasks/dependencies and progress status, with ATP labels only when they resolve in `test-plan.md`; absent authoritative dates or estimates must be shown as relative/illustrative order. The burndown reads active/deferred scope and verified status; without immutable dated snapshots it must be a scope-count reference rather than a calendar trend or forecast. Neither chart may add scope, dependencies, evidence, or completion claims. Both SVGs use the README-derived language consistently, including visible labels, accessibility text, and metadata.
+
+## README template contract
+
+Use the following sections:
+
+1. `# <Suite> Internal Planning`
+2. introductory statement that this is maintainer-facing planning material;
+3. `## Reading Order` with ordered links to every core document and justified extension;
+4. `## Product and Technical Baseline` with a compact table for suite identity, scope, tenancy, audiences, sites/flavors, and major constraints;
+5. `## Current or Intended Topology` with Vona/Zova paths and capability ownership;
+6. `## Document Authority` with the authority map and conflict rule;
+7. `## Traceability Chain and Status Rules`;
+8. `## Related Framework Records`.
+
+The `## Reading Order` section must also link `implementation-gantt.svg` and `implementation-burndown.svg` as derived delivery views. Their language defaults to the language used by this README, and the generator applies that choice consistently to labels, accessibility text, and metadata.
+
+The README is an index and baseline summary. Keep detailed business requirements in the PRD and detailed contracts in the SRS. For each Web, Admin, or other site audience, summarize the selected shared/independent/no-site strategy and its certainty as a confirmed input, observed current-source fact, proposed target, or `TODO(confirm)` decision. README may summarize cited identifiers but does not establish their authority. The README must not call a proposed target or durable boundary confirmed/accepted while its governing ADR remains `Proposed`; only explicitly accepted decisions may use that wording.
+
+## PRD template contract
+
+Use:
+
+1. `## Purpose`;
+2. `## Product Goals`;
+3. `## Personas`;
+4. `## Scope` with `In Scope`, `Deferred`, and, where useful, `Out of Scope`;
+5. `## Primary User Journeys`;
+6. `## Product Requirements`, grouped by capability;
+7. `## Business Rules`;
+8. `## Launch Criteria`;
+9. `## Requirement Traceability`;
+10. `## Related Records`.
+
+Requirements state observable business outcomes and use stable identifiers. Preferred forms are `PRD-<DOMAIN>-01` or `PRD-<DOMAIN>-<CAPABILITY>-01`. When site strategy affects the product, describe the intended audience/channel scope and journey, not site IDs, route mechanics, flavors, configuration, lock strategy, DTO syntax, table names, or test commands. Those belong downstream.
+
+A typical requirement should identify actor, allowed outcome, key boundary, and observable acceptance without dictating implementation:
+
+```text
+- **PRD-<DOMAIN>-<CAP>-01**: An authorized <actor> can <outcome> within the active tenant.
+```
+
+## SRS template contract
+
+Use:
+
+1. `## Purpose and Authority`;
+2. `## Current-Source Facts and Target Contracts`;
+3. `## System Context`;
+4. `## Capability and Persistence Ownership`;
+5. `## Tenant, Identity, Privacy, and Authorization Contracts`;
+6. `## Data, Relationship, and Money Contracts` when relevant;
+7. `## State Machines` when lifecycle states exist;
+8. `## Transactional, Concurrency, Idempotency, Audit, and Recovery Requirements` as applicable;
+9. `## API, DTO, OpenAPI, and Contract-Loop Contracts`;
+10. `## Frontend State, Route, Site, and SSR Contracts` when applicable;
+11. `## Non-Functional and Migration Requirements`;
+12. `## Acceptance Mapping`;
+13. `## Related Records`.
+
+Use identifiers such as `SRS-<DOMAIN>-*`. Define the technical facts needed to implement and test the product requirement:
+
+- who owns persistence, services, DTOs, and UI state;
+- which fields/identities are server-authoritative;
+- how instance/tenant and resource ownership are enforced;
+- legal state transitions and final states;
+- transaction boundaries, contention behavior, idempotency, rollback, audit, and recovery;
+- generated API consumers and forward/reverse contract-loop obligations;
+- frontend model/resource ownership, audience-specific contracts, route names/params, SSR privacy, and hydration behavior when applicable.
+
+For each user-facing audience, the SRS owns the shared-versus-independent site topology, its relation to the domain/persistence boundary, and the audience-specific API/DTO, server-scope, state/page/route, and SSR contracts. List shared targets and exact independent-site identifiers only when observed and cited. Keep unobserved site IDs, public paths, bundles, flavors, environment/configuration files, `SsrSite` registrations, output locations, and command pairs as `TODO(confirm from active source)`. An independent site does not establish a separate tenant, identity, authorization, persistence, or business-rule authority.
+
+Mark observed repository facts separately from confirmed inputs and proposed target contracts. Every exact SRS ID named in PRD/WBS/test-plan traceability must have one explicit SRS contract definition here; a matrix mention, wildcard, or range is not a definition. Never pretend an unverified path, operation, flavor, or module exists.
+
+## PDP/WBS template contract
+
+Use:
+
+1. `## Delivery Objective`;
+2. `## Delivery Principles`;
+3. `## Work Breakdown Structure`;
+4. phased `### Phase <number>: ...` sections;
+5. per-task `#### WBS-<DOMAIN>-<PHASE>-<TASK>: ...` entries;
+6. `## Dependency and Contract-Loop Rules`;
+7. `## Traceability Matrix`;
+8. `## Completion and Evidence Rules`;
+9. `## Related Records`.
+
+For new long-lived suite baselines, both `implementation-gantt.svg` and `implementation-burndown.svg` are mandatory generated records. They must be regenerated after source changes with `npm run spec:charts -- <suite>` and checked with `npm run spec:charts:check -- <suite>`.
+
+Every WBS entry should state:
+
+- dependencies;
+- primary source areas or ownership boundaries;
+- bounded tasks;
+- acceptance/completion checks;
+- linked PRD, SRS, and ATP identifiers;
+- whether it is planned, implemented, or awaiting evidence.
+
+Begin with a documentation/decision implementation gate before feature work. For differing Web/Admin strategies, split shared-site integration and independent-site delivery into separate frontend tasks when their source facts, dependencies, or proof differ. An unresolved strategy or exact runtime identifier may block only the affected implementation task; preserve runnable discovery work and unaffected backend or audience work as accurately actionable. Prefer vertical, verifiable increments. Include migration and release hardening as explicit work. Keep `implementation-complete` distinct from `verified`.
+
+## Test-plan template contract
+
+Use:
+
+1. `## Purpose and Authority`;
+2. `## Scope, Quality Priorities, and Risk`;
+3. `## Verification Model` with narrow, contract, and full closure levels;
+4. `## Test Levels and Ownership Locations`;
+5. `## Fixtures, Cleanup, Privacy, and Data Minimization`;
+6. `## Evidence Record`;
+7. `## Acceptance Scenario Catalogue`;
+8. `## Contract, SSR, Browser, and Integration Procedures` as applicable;
+9. `## Commands`;
+10. `## Release Closure Gate`;
+11. `## Related Records`.
+
+Use `ATP-<DOMAIN>-<CAPABILITY>-01` identifiers. Each scenario links to PRD/SRS/WBS records and defines scope, setup, procedure, expected result, and minimum retained proof. Every exact ATP ID named in WBS or traceability records must have one scenario declaration here; a matrix mention, wildcard, range, or evidence-format example is not a scenario. Include appropriate negative, authorization, tenant-isolation, state-transition, rollback, concurrency, idempotency, contract-generation, SSR/hydration, migration, and browser tests for the confirmed risk profile.
+
+Every evidence record should retain, at minimum:
+
+- requirement and contract links;
+- source revision;
+- database/environment/flavor where relevant;
+- exact command or procedure;
+- fixture and interleaving details where relevant;
+- pass/fail result;
+- redacted log, response, screenshot, CI job, or artifact location;
+- waiver owner, reason, and expiry when a temporary exception exists.
+
+A command listed in a new test plan is a prospective procedure, not a result. For independent sites, define SSR/REST/build/browser proof only with source-confirmed site/flavor/command facts; for shared sites, define composition/integration and shared-site proof against the observed owner. Unresolved identifiers remain planned confirmation gates, never successful verification claims.
+
+## Progress template contract
+
+Use:
+
+1. `## Purpose and Authority`;
+2. `## Status Definitions`;
+3. `## Current Delivery Overview`;
+4. `## WBS Execution Register`;
+5. `## Open Decision Register`;
+6. `## Current Evidence Index`;
+7. `## Update Rules and Next Steps`;
+8. `## Related Records`.
+
+Initialize a new suite with statuses such as `not-started`, `deferred`, or explicitly `blocked`; do not mark planning work as verified. Use this vocabulary:
+
+| Status | Meaning |
+| --- | --- |
+| `not-started` | Defined, but implementation or acceptance evidence has not started. |
+| `in-progress` | Work started, but closure checks are incomplete. |
+| `implementation-complete` | Source work is reported complete, but required ATP evidence or release gates are incomplete. |
+| `verified` | Required ATP evidence is observed and retained with revision, environment, procedure, result, and redacted artifact location. |
+| `blocked` | A dependency, unresolved decision, or failed gate prevents closure. |
+| `waived` | A temporary exception with owner, reason, and expiry; expiry makes it a release blocker. |
+| `deferred` | Explicitly postponed scope, not completed scope. |
+
+Progress must remain a derived register. It may point to evidence but must not become a second requirements document. Include a decision-register entry for each material site strategy and show strategy/identifier deferral as a blocker only on affected frontend/site WBS branches; source reading, planning, or a selected strategy alone is not implementation evidence.
+
+## ADR 0001 template contract
+
+Use:
+
+```markdown
+# ADR 0001: Establish <Suite> Boundaries
+
+## Status
+
+Proposed
+
+## Background
+
+<Why this suite needs a durable boundary.>
+
+## Problem
+
+<What would go wrong without the decision.>
+
+## Decision
+
+<Accepted or proposed suite, ownership, tenancy, security, site, and scope decisions.>
+
+## Alternatives Deferred
+
+<Explicitly deferred or rejected alternatives.>
+
+## Consequences
+
+<Operational and architectural consequences.>
+
+## Implementation Decision Gates
+
+<TODO(confirm) items that must close before implementation.>
+
+## Related Records
+
+<Links to README, PRD, SRS, WBS, test plan, and framework records.>
+```
+
+Use `Accepted` only for explicitly confirmed durable decisions; otherwise use `Proposed`. Record material shared/independent site strategy, alternatives, and consequences in the ADR, including the condition for a future independent Web or Admin boundary and the requirement for a superseding ADR if that boundary changes. Later ADRs should narrowly state what prior decision they supersede. Do not use an ADR as a duplicate SRS or status log.
+
+## Optional extensions
+
+Generate only when the confirmed scope requires them:
+
+| Extension | Generate when |
+| --- | --- |
+| `presentation-contracts.md` | Multiple Admin/resource scenes need stable audience, task, information-area, editability, snapshot, or renderer decisions. Keep it subordinate to PRD/SRS. |
+| `semantic-presentation-rollout.md` | Presentation/metadata work is staged, serial, resumable, and needs handoff gates. It does not replace WBS or test plan. |
+| `runbooks/<provider-or-operation>.md` | Real external provider/webhook, sandbox/live operation, reconciliation, cutover, incident, or deployment procedure is in scope. Never include secrets. |
+| Additional ADRs | A separate durable boundary or trade-off exists after ADR 0001. |
+| `evidence/` | Actual ATP execution has produced retained redacted evidence. Do not create empty evidence to simulate progress. |
+
+For a presentation matrix, record audience, task, resource/scene, business information areas, field boundaries, renderer choice, and linked PRD/SRS/ATP records. It must not redefine API authority, persistence, validation, authorization, page/state ownership, or SSR privacy.
+
+For an operational runbook, record environment boundaries, secret-management rules, configuration prerequisites, callback/webhook procedure, reconciliation/idempotency checks, troubleshooting, rollback/cutover constraints, and authoritative record links. It must not redefine business lifecycle authority.
+
+## Required cross-links
+
+Every core document links to the README and relevant peers. Maintain a compact matrix like:
+
+| Product area | PRD | SRS | WBS | ATP | Evidence/status |
+| --- | --- | --- | --- | --- | --- |
+| `<capability>` | `PRD-...` | `SRS-...` | `WBS-...` | `ATP-...` | `progress.md` / evidence link |
+
+Every material product requirement needs at least one technical contract, delivery item, and executable acceptance scenario. Before reporting generation complete, statically audit exact-ID referential integrity and README/ADR decision-status consistency across the planning authority set. Exclude `evidence/` from this static audit: evidence is added only after execution.

package/.claude/skills/cabloy-spec-generation/references/traceability-and-status-rules.md

@@ -0,0 +1,135 @@
+# Traceability and Status Rules
+
+These rules protect the distinction between planning authority, delivery sequencing, executable proof, and derived status.
+
+## Identifier conventions
+
+Choose one concise domain prefix and use it consistently:
+
+```text
+PRD-<DOMAIN>-<CAPABILITY>-01
+SRS-<DOMAIN>-<CAPABILITY>-01
+WBS-<DOMAIN>-<PHASE>-01
+ATP-<DOMAIN>-<CAPABILITY>-01
+EVD-<DOMAIN>-<CAPABILITY>-01   # only after evidence is observed
+```
+
+A shorter `PRD-<DOMAIN>-01` / `SRS-<DOMAIN>-01` form is acceptable for a small capability. IDs must be stable: do not renumber existing records merely to make a table look tidy. If an existing suite already has a convention, preserve it.
+
+## Identifier registry and reference validation
+
+Before reporting a generated baseline or an authority update complete, build a temporary registry. Collect formal definitions from their owning documents (`prd.md`, `srs.md`, `pdp-wbs.md`, and `test-plan.md`) and scan every generated non-evidence Markdown record for references, including core records, `decisions/*.md`, presentation/rollout records, phase indexes, and `runbooks/*.md`.
+
+- A **formal definition** is one atomic requirement, contract, WBS task, or ATP scenario declaration in its owning document. A prose mention, matrix cell, evidence-record format example, range, wildcard, template placeholder such as `<DOMAIN>`, or generic ellipsis is not a definition.
+- A **concrete reference** names one complete instantiated ID, such as `SRS-<DOMAIN>-CAT-01` or `ATP-<DOMAIN>-CON-01`. It must resolve to exactly one formal definition in its owning document. Do not create duplicate definitions or dangling concrete references.
+- A wildcard or range, such as `SRS-<DOMAIN>-CAT-*` or `ATP-<DOMAIN>-01`–`03`, is aggregation notation only. It may summarize already-defined records, but cannot define them or satisfy an exact reference/traceability requirement.
+- Preserve an existing suite's ID convention when extending it. For a new baseline, use the chosen convention consistently across definitions and references.
+- Report missing owners, duplicate definitions, and orphaned material definitions separately; correct the authoritative records before completion.
+- Validate the canonical PRD -> SRS -> WBS -> ATP chain by exact defined IDs, while allowing a many-to-many relationship where the matrices make it explicit.
+- This static audit covers generated planning records only. Exclude `evidence/`: evidence is created after observed execution and cannot establish or repair planning authority.
+- Generated implementation charts must contain only formal WBS/ATP identifiers and current progress statuses; run `npm run spec:charts:check -- <suite>` after generation to verify freshness and reconciliation.
+
+## Canonical chain
+
+Maintain this chain across the core records:
+
+```text
+PRD requirement -> SRS contract -> PDP/WBS task -> ATP scenario -> observed evidence
+```
+
+Minimum cardinality for a material in-scope requirement:
+
+- one PRD requirement;
+- at least one SRS contract;
+- at least one WBS task;
+- at least one ATP scenario;
+- zero evidence records before execution, and at least one retained evidence record before `verified`.
+
+A single ATP may prove several related requirements, but the matrices must make the relationship explicit. A WBS item may cover several contracts, but it still needs bounded completion checks.
+
+## Authority-first updates
+
+When a requirement or durable boundary changes:
+
+1. update the authoritative PRD, SRS, or ADR first;
+2. update traceability matrices;
+3. update WBS dependencies and completion checks;
+4. update ATP procedures and expected proof;
+5. update progress and evidence pointers;
+6. reassess prior evidence and statuses whose assumptions changed;
+7. regenerate `implementation-gantt.svg` and `implementation-burndown.svg` with `npm run spec:charts -- <suite>`;
+8. run `npm run spec:charts:check -- <suite>` and reconcile generated WBS/ATP/status references.
+
+Downstream records summarize or operationalize authority; they do not silently override it. The SVGs are derived views only: they cannot authorize scope, dependencies, dates, evidence, or status. Their language follows the suite `README.md`.
+
+## Status semantics
+
+| Status | Meaning |
+| --- | --- |
+| `not-started` | Defined, but implementation or acceptance evidence has not started. |
+| `in-progress` | Work or verification has started, but closure checks are incomplete. |
+| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete. |
+| `verified` | Applicable WBS checks and ATPs passed, and durable evidence contains revision, environment, exact procedure, result, and redacted artifact location. |
+| `blocked` | A failed gate, dependency, or unresolved decision prevents closure. |
+| `waived` | A temporary exception explicitly approved with owner, reason, and expiry. |
+| `deferred` | Explicitly postponed scope; it is not complete or verified. |
+
+For a newly created plan, initialize delivery rows as `not-started`, `deferred`, or `blocked` as appropriate. Creating Markdown files never makes implementation `implementation-complete` or `verified`.
+
+### README and ADR decision-status consistency
+
+Keep the status domain explicit:
+
+- **Observed current-source facts** are repository facts that have been inspected and cited.
+- **Confirmed inputs** are values explicitly supplied or confirmed by the user.
+- **Proposed targets** and durable boundaries remain proposed while their governing ADR is `Proposed`.
+- **Accepted durable decisions** require explicit confirmation and an `Accepted` governing ADR.
+
+A README may summarize observed facts and confirmed inputs, but it must not label a proposed target baseline, topology, scope boundary, or durable decision as `Confirmed` or `Accepted` while its governing ADR remains `Proposed`. Use neutral wording such as “Product and Technical Baseline,” and label individual entries by their actual state. The ADR remains authoritative; a README summary never upgrades its status.
+
+## Evidence requirements
+
+A retained evidence entry should include:
+
+- linked PRD, SRS, WBS, and ATP IDs;
+- source revision or commit;
+- database, environment, and flavor/site when relevant;
+- exact command, API procedure, or browser procedure;
+- fixture and explicit concurrency interleaving when relevant;
+- observed pass/fail result;
+- durable log, response, screenshot, CI job, or artifact path;
+- redaction statement and any waiver metadata.
+
+Evidence must be synthetic or redacted. Never retain credentials, raw tokens, signed callback state, secrets, live provider identifiers, or real customer/payment data merely to prove a scenario.
+
+A planned command is not a result. A code reading, design review, manual walkthrough, or single screenshot is not by itself sufficient for `verified` unless the applicable test plan explicitly defines it as adequate proof and the result is retained.
+
+## Waivers
+
+Every temporary waiver names:
+
+- owner;
+- reason;
+- affected requirement/ATP/WBS;
+- expiry date or time;
+- compensating control, when relevant.
+
+An expired waiver automatically becomes a release blocker. Do not hide an unresolved waiver in prose.
+
+## Initial-plan safeguards
+
+Do not:
+
+- write `passed`, `verified`, `implemented`, or a fabricated evidence ID without an observed result;
+- copy example-suite module names, API paths, test counts, CI links, or state assertions into a new domain;
+- claim that a source path, API, flavor, generator, migration, test, build, or browser flow exists when it was not inspected;
+- create empty evidence records just to make the traceability chain appear complete;
+- mark progress `implementation-complete` because the planning set was generated;
+- place a new requirement only in `progress.md`;
+- reference an exact SRS or ATP ID that has no formal definition in `srs.md` or `test-plan.md`;
+- use a wildcard, range, prose mention, or evidence-format example as if it defined an atomic PRD, SRS, WBS, or ATP record;
+- describe a proposed target or durable boundary as confirmed/accepted in README while its governing ADR remains `Proposed`;
+- let an optional presentation matrix, runbook, or rollout record redefine PRD/SRS authority;
+- introduce OpenSpec or another parallel authority by duplicating these records without a repository-level decision defining ownership, migration, history, traceability, and duplicate-prevention rules.
+
+If a fact is unknown, write `TODO(confirm)` or a neutral placeholder and put the decision gate in the ADR, SRS, WBS, or progress register according to its authority.