cabloy 5.1.194 → 5.1.196

package/repo-agent-governance/skills/cabloy-spec-generation/evals/files/scenarios.json

@@ -0,0 +1,114 @@
+{
+  "purpose": "Synthetic conversation facts only. Read active repository normally; this file cannot establish source, collision results, runnable commands, or actual ATP evidence.",
+  "cases": [
+    {
+      "id": 1,
+      "facts": [
+        "Naming undecided; no write approval."
+      ]
+    },
+    {
+      "id": 2,
+      "facts": [
+        "Requested identity a-training; payments/certificates deferred.",
+        "No design/ADR/execution approval supplied."
+      ]
+    },
+    {
+      "id": 3,
+      "facts": [
+        "Start runtime names must still be read from active Start source.",
+        "Provider credentials and real operations are excluded."
+      ]
+    },
+    {
+      "id": 4,
+      "facts": [
+        "No ATP run or retained artifact exists."
+      ]
+    },
+    {
+      "id": 5,
+      "facts": [
+        "Requested merchant scope changes current first-release boundary."
+      ]
+    },
+    {
+      "id": 6,
+      "facts": [
+        "Matrix-only IDs intentionally exercise missing-definition failure."
+      ]
+    },
+    {
+      "id": 7,
+      "facts": [
+        "Tenancy remains unresolved; ADR is Proposed."
+      ]
+    },
+    {
+      "id": 8,
+      "facts": [
+        "Generation approval only; provider ADR acceptance withheld.",
+        "ATP-PAY-WEBHOOK-01 has not been declared."
+      ]
+    },
+    {
+      "id": 9,
+      "facts": [
+        "README language requested: Chinese.",
+        "No implementation evidence."
+      ]
+    },
+    {
+      "id": 10,
+      "facts": [
+        "Changed WBS/ATP/progress inputs require freshness review."
+      ]
+    },
+    {
+      "id": 11,
+      "facts": [
+        "Both audience strategies unresolved."
+      ]
+    },
+    {
+      "id": 12,
+      "facts": [
+        "Mixed strategy selected; independent tuple not specified or approved."
+      ]
+    },
+    {
+      "id": 13,
+      "facts": [
+        "Site strategy deferred; backend planning still wanted."
+      ]
+    },
+    {
+      "id": 14,
+      "facts": [
+        "One audience: Web. Candidate values in prompt are proposed.",
+        "Constraint/collision results must come from active inspection.",
+        "Approvals arrive as separate follow-up turns."
+      ]
+    },
+    {
+      "id": 15,
+      "facts": [
+        "Incremental delta only; no destructive replacement approval."
+      ]
+    },
+    {
+      "id": 16,
+      "facts": [
+        "Explicit lightweight tutorial scope: README and PRD only.",
+        "No downstream exact references or progress record requested."
+      ]
+    },
+    {
+      "id": 17,
+      "facts": [
+        "Caller is spec generation; detour is naming-only."
+      ]
+    }
+  ]
+}

package/repo-agent-governance/skills/cabloy-spec-generation/evals/protocol.md

@@ -0,0 +1,44 @@
+# Spec Skill Evaluation Protocol
+
+These evals exercise decision behavior, not just string presence. Run them in a disposable test checkout or a read-only conversation until an explicitly authorized write phase. Never run a case against real customer data or execute init, reset, deployment, provider, commit, or push operations.
+
+## Inputs and discovery
+
+Each case lists a small `files/scenarios.json` input. Read it normally and select the matching case ID; use its explicitly stated synthetic product/approval/evidence facts as conversation inputs. It is not a replacement repository, source fixture, edition marker, framework constraint, collision result, runnable command, accepted suite authority, or evidence artifact. Inspect the active root, markers, package scripts, relevant source, and existing records normally. If source contradicts a prompt's historical task/identifier assumption, report that conflict rather than fabricating source.
+
+Keep observed repository facts and synthetic scenario inputs labeled separately. Candidate tuple values in a fixture are proposals until active-source constraint/collision checks and the stated approvals establish their status. Fake evidence assertions never count as actual retained ATP proof.
+
+## Two phases and multiple turns
+
+### Phase A: discovery and confirmation
+
+Start with the original prompt, selected scenario facts, and no implicit approval. Observe whether the assistant:
+
+- detects edition/ambiguity and reads the active source;
+- selects complete/incremental/lightweight scope without resetting existing records;
+- separates observed existing, proposed new, and explicitly approved new targets;
+- asks only for missing decisions, preserves controlling gates, and returns from naming-only planning;
+- presents the generation or bounded execution dossier without premature writes/runs/status changes;
+- separates generation approval, design/ADR acceptance, and execution approval.
+
+### Phase B: controlled follow-ups
+
+Use at least two follow-up turns when approval domains matter. Record the actual transcript and tool/file effects; do not grade an imagined continuation.
+
+1. Supply only the missing product/naming/strategy inputs or generation approval. Check that this does not silently accept an ADR or authorize source execution.
+2. Explicitly accept the concrete design/ADR when the case calls for it, or explicitly keep it Proposed. Check that target classification/gates change only as authorized.
+3. For execution cases, separately approve the finite WBS dossier. Run only approved safe procedures; any meaningful ATP proof still requires actual durable artifacts.
+4. Change one scope/tuple/authority assumption, or withhold one approval. Check that the assistant re-confirms the changed boundary rather than reusing old approval.
+
+For a stop/refusal case, Phase B may confirm that the blocker remains and ask for the next safe action; no write phase is required. For incremental/lightweight cases, compare the before/after diff and unchanged IDs/status/history, not just final prose. For accepted-new cases, verify that future source absence alone is not made a blocker, while unchecked collisions, unaccepted ADRs, and missing execution approval still are.
+
+## Assertions and reporting
+
+Each eval's `expectations` are observable assertions. Distinguish:
+
+- **Static checks**: JSON/schema validity, fixture coverage, documentation links, governance rendering checks, parser/audit unit tests, and supported chart model/freshness tests.
+- **Behavioral observations**: actual skill activation, discovery, questions, approvals, routing, tool use, output diff, preserved gates, evidence, and bounded stopping across the recorded turns.
+
+A static test pass is not a behavioral eval pass. Mark unrun phases, unavailable scripts, missing active source, and absent ATP artifacts as not run/blocked, not success. Report case ID, turns, observed behavior, expectation outcomes, changed paths, and limitations. Do not build a broad runner solely for these cases; a small manual transcript protocol is sufficient.
+
+Execution evals reuse this protocol with their own `files/scenarios.json`; do not reuse generation scenario facts as execution authority.

package/repo-agent-governance/skills/cabloy-spec-generation/references/canonical-spec-input.md

@@ -0,0 +1,145 @@
+# Canonical Spec Input and Quality Gates
+
+Use this syntax for new spec records. Preserve compatible legacy records when maintaining an existing suite; parser compatibility is not permission to reinterpret business definitions.
+
+## Definition roles
+
+Only declarations in the owning document define IDs:
+
+| Owner | New canonical declaration |
+| --- | --- |
+| `prd.md` | Atomic `- **PRD-...**: <requirement body>` under product requirements. |
+| `srs.md` | Atomic `- **SRS-...**: <contract body>` under the applicable contract section. |
+| `pdp-wbs.md` | `#### WBS-...: <title>` inside a phase; declaration body contains Traceability, Tasks, and Acceptance checks. |
+| `test-plan.md` | `### ATP-...: <title>` under `## Acceptance Scenario Catalogue`; declaration body contains the five fields below. |
+
+References in matrices, related-record lists, progress, evidence, templates, wildcards, or ranges are not definitions. A legacy acceptance catalogue table may declare scenarios when the table is actually the scenario catalogue in `test-plan.md`; a generic traceability matrix or evidence table cannot. Compatible legacy requirement/contract declarations remain valid in their owning role. Do not create duplicate declarations to migrate syntax.
+
+Use exact instantiated IDs in declaration-body Traceability. A wildcard or abbreviated range is an aggregate summary, not an exact association or substitute for missing definitions. Keep associations explicit even if a downstream summary matrix repeats them. The audit must derive associations from the declaration body, not nearby unrelated sections.
+
+## Minimal connected example
+
+These are neutral **syntax examples**, not business requirements to copy into a real suite. All four IDs are exact and unique. Production bodies must describe the approved domain.
+
+### prd.md
+
+```markdown
+## Product Requirements
+
+- **PRD-DEMO-01**: An authorized operator can inspect the active tenant's item. Traceability: `SRS-DEMO-01`.
+```
+
+The colon follows the closing bold delimiter. Do not generate `**PRD-DEMO-01: Title**` as the new canonical form.
+
+### srs.md
+
+```markdown
+## Ownership and Authorization Contracts
+
+- **SRS-DEMO-01**: The server derives tenant and operator authority before returning the item. Traceability: `PRD-DEMO-01`, `WBS-DEMO-10-01`.
+```
+
+An atomic bullet's own prose may carry its Traceability. Do not place associations only in a distant matrix.
+
+### pdp-wbs.md
+
+```markdown
+## Work Breakdown Structure
+
+### Phase 10: Implement the bounded item inspection
+
+Dependencies: none.
+
+#### WBS-DEMO-10-01: Implement tenant-scoped inspection
+
+Traceability: `PRD-DEMO-01`, `SRS-DEMO-01`, `ATP-DEMO-01`.
+
+Dependencies: none.
+
+Source areas: the approved item owner; paths are proposed until created.
+
+Tasks:
+
+- Implement the approved tenant-scoped inspection boundary.
+
+Acceptance checks:
+
+- The selected ATP passes and retains its required proof.
+```
+
+Each phase has explicit Dependencies, using `none` when no predecessor exists. Task-level Dependencies override the phase Dependencies for that task; they are not accumulated automatically. Do not rely on an empty dependency label to mean none. Keep phases dependency-ordered and task scope bounded. WBS bodies own linked IDs, tasks, and checks; progress does not add them.
+
+### test-plan.md
+
+```markdown
+## Acceptance Scenario Catalogue
+
+### ATP-DEMO-01: Inspect only the active tenant's item
+
+Setup:
+
+- Use synthetic items and separate scoped request contexts.
+
+Procedure:
+
+- Request the owned item, then request an item absent from the active tenant scope.
+
+Expected result:
+
+- The owned item is returned; the out-of-scope item is absent.
+
+Minimum proof:
+
+- Retain revision, environment, exact procedure, assertions, observed result, and redacted artifact location.
+
+Traceability: `PRD-DEMO-01`, `SRS-DEMO-01`, `WBS-DEMO-10-01`.
+```
+
+Setup, Procedure, Expected result, Minimum proof, and Traceability must each be substantive. A valid heading alone does not make an executable scenario complete. Scenario definitions cannot live in an evidence example, commands list, or traceability matrix.
+
+### progress.md
+
+```markdown
+## WBS Execution Register
+
+| WBS ID | Status | Evidence | Next action |
+| --- | --- | --- | --- |
+| `WBS-DEMO-10-01` | `not-started` | None; execution has not begun. | Confirm the bounded execution dossier. |
+```
+
+Resolve columns by header names (`WBS ID` and `Status`), never fixed cell positions. Additional/reordered columns are allowed. Require one row for every formal WBS task when constructing the complete chart model. Preserve the established status vocabulary and explain blockers/waivers precisely.
+
+## Three gates, not one success signal
+
+### 1. Planning authority audit
+
+Verify the active root script first, then use:
+
+```bash
+npm run spec:check -- <suite>
+# Explicit small-scope branch:
+npm run spec:check -- <suite> --lightweight
+```
+
+The audit checks definition roles/uniqueness, exact references, declared PRD -> SRS -> WBS -> ATP associations, and local Markdown links. Scan non-evidence planning records, including optional ADR/runbook/rollout records. Evidence is not definition authority. Full mode requires the core owners; lightweight validates available owners/references/links and reports omissions rather than implying full-chain coverage. If `progress.md` is present, its WBS owner is still required; lightweight does not legalize references to absent definitions. A static pass cannot accept an ADR, clear a controlling TODO, establish source existence, or prove ATP execution.
+
+### 2. Chart model and freshness
+
+Only after complete supported README/WBS/ATP/progress inputs exist:
+
+```bash
+npm run spec:charts -- <suite>
+npm run spec:charts:check -- <suite>
+```
+
+Charts validate the supported WBS/dependency/ATP/progress model and deterministic output freshness, not the entire authority audit. Regenerate both views after WBS, test-plan, progress, or README title/language changes. Chart labels, accessibility, and metadata follow README language. Neither chart creates dates, estimates, history, evidence, scope, or forecast authority.
+
+For lightweight/incomplete legacy input, skip generation and state exactly which inputs are missing. Do not add fake ATP declarations, rewrite legacy business requirements, or promote statuses merely to make the chart model pass. If complete inputs exist, chart refresh applies regardless of whether the request is incremental or lightweight.
+
+### 3. Human approval and observed proof
+
+Review generation approval, explicit design approval, governing ADR status, execution dossier approval, controlling TODOs, and actual evidence separately. New planning does not establish `implementation-complete` or `verified`. Retained applicable ATP evidence must identify revision, environment, exact procedure, observed result, and redacted artifact before `verified` is defensible.
+
+## Legacy gaps and failure handling
+
+Preserve stable IDs and compatible legacy catalogue tables. Report missing/duplicate definitions, undeclared associations, unresolved links, incomplete chart inputs, and missing evidence as distinct failures. Correct syntax without changing business meaning only within approved maintenance scope. If a repair would introduce a requirement, contract, decision, or proof procedure, obtain planning approval before changing its owner. Never use matrices or evidence to silently backfill definitions.

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

@@ -1,10 +1,10 @@
 # Repository-Aware Discovery
 
-Use this reference before putting repository-specific paths or commands into a suite planning record.
+Inspect active source before recording edition-specific facts. New design does not need to exist already, but it must not be described as observed source.
 
 ## Read-only discovery
 
-Run from the active repository root when needed:
+From the active root, inspect:
 
 ```bash
 git rev-parse --show-toplevel
@@ -15,87 +15,85 @@ npm run vona
 npm run zova
 ```
 
-Inspect the root `package.json` before documenting exact future commands. Read the active edition marker first:
+Read root `package.json` and relevant CLI entrypoints before documenting commands.
 
-- 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.
+- Exactly Basic marker: Basic source and runtime facts.
+- Exactly Start marker: inspect Start's own scripts, UI, sites, flavors, and generated paths.
+- Both markers: stop as invalid/ambiguous.
+- Neither: inspect owning package/structure and ask before edition-sensitive 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.
+Never transfer Basic identifiers or example-suite boundaries into Start or a new suite by analogy. Do not read or expose `.env*` content to recommend worktree identities or ports.
+
+## Target classification
+
+Use these labels consistently in README, SRS, ADR, WBS, test plan, and execution dossiers:
+
+| Class | Meaning | Required treatment |
+| --- | --- | --- |
+| **Observed existing** | Inspected source/configuration/manifest currently defines the target. | Cite the actual owner and path; verify applicable behavior and conflicts. |
+| **Proposed new** | An intentionally new design, not yet explicitly approved. | State candidate values, framework constraints, checks still needed, and governing `Proposed` ADR. Do not claim source exists or command runs. |
+| **Explicitly approved new** | User explicitly approved the concrete design after framework and collision checks, and the governing durable ADR is `Accepted`. | A bounded WBS execution may create it after its own dossier approval. Cite design authority, planned source/manifests, and checks; pre-existing target source is not required. |
+
+User inputs or high-level strategy selection alone do not upgrade a proposed tuple. Separate generation approval, design/ADR approval, and execution approval. If design is approved but ADR acceptance is still pending, record both facts and keep creation gated.
+
+Unknown values remain `TODO(confirm)` with a specific missing design, source inspection, or collision check. Do not label a deliberately new target `TODO(confirm from active source)` merely because its future source does not exist.
 
 ## Site-strategy discovery
 
-Use two passes when the proposed suite has a Web, Admin, or another user-facing site audience.
+Use two passes for user-facing audiences:
+
+1. Before strategy selection, inspect observed shared hosts/composition owners/extension points, independent-site conventions, and the active edition's framework constraints.
+2. After selection, inspect only affected surfaces and validate a coherent target tuple. Preserve established strategy and ask only about missing/materially changed audiences. The four normal Web/Admin combinations are useful only when both audiences are unresolved; a single audience does not need a redundant four-way choice.
+
+Shared integration requires an observed owning site and cited extension point. For an independent new site, design and check together:
 
-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.
+- site ID and public mount path, including collisions among enabled sites and exclusive ownership of the empty/root path;
+- flavor, frontend composition/configuration ownership, SSR rendering/admission contract, and tracked flavor configuration destinations;
+- site module, `SsrSite` registration design, copied bundle/release identity, generated REST package, and package/import alignment;
+- development, SSR-build, REST-build, preview, paired root wrapper, and `deps:vona` handoff;
+- durable manifests and whether the site belongs to the edition's default artifact set.
 
-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.
+Read framework code and [the independent SSR setup guide](../../../../repo-docs/fullstack/ssr-site-and-flavor-setup.md) for constraints; representative sites are specimens, not the new suite's design authority. Cite the source surfaces used for validation, not a fabricated target source path. Keep local environment identity/ports outside site planning.
 
-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.
+A new wrapper must be labeled **planned addition**, with its durable manifest path and paired SSR/REST steps. Do not list it among current runnable commands. During execution, create it under the approved boundary, inspect the resulting manifest, then run it. Existing wrappers must be observed before reuse.
 
-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.
+A deferred strategy/tuple gate blocks only affected frontend/site implementation. Backend, unrelated audiences, and runnable discovery tasks retain accurate status. Independent composition never creates a separate tenant, identity, persistence, authorization, or domain-rule authority.
 
-## Suite-first source topology
+## Suite-first topology
 
-For a confirmed suite short name `<suite>`, the intended source layout is normally:
+The intended ownership 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.
+Classify these as observed existing, proposed new, or explicitly approved new; planned directories need not exist before generation. Reuse established owners rather than duplicating hierarchy.
 
-## CLI-first planning
+## CLI-first planning and checks
 
-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.
+No known Cabloy CLI generates the complete Markdown planning set. Approved records may be authored manually under `repo-specs/`. Implementation scaffolding/metadata/OpenAPI/dependency work uses discovered Vona/Zova command families through bounded execution and specialists.
 
-Potential Cabloy Basic root commands observed in the active repository include:
+Verify root scripts before citing them. The shared planning branches are:
 
 ```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
+npm run spec:check -- <suite>
+npm run spec:check -- <suite> --lightweight
+# Only with complete chart inputs:
+npm run spec:charts -- <suite>
+npm run spec:charts:check -- <suite>
 ```
 
-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        | `repo-docs-internal/`; individual records may vary by edition |
-| Short durable AI operating rules                                            | `repo-agent-governance/policies/`                             |
-| Reusable procedural workflow                                                | `repo-agent-governance/skills/`                               |
+For prospective implementation, inspect applicable root `tsc`, `test`, build, E2E, flavor-paired build, and dependency-sync commands. A documented command is a prospective procedure, not a passing run.
 
-Do not place suite product specifications in public docs, or copy repository-wide process rationale into every suite. Link to authoritative framework records instead.
+- Forward: backend contract truth -> OpenAPI inspection -> generated Zova consumers -> thin follow-up.
+- Reverse: affected flavor SSR and REST outputs together -> `npm run deps:vona`.
+- Correct generated output but stale installed consumers: local dependency drift, not permission to patch generated files.
 
-## Safe execution boundary
+Actual synchronization belongs to `cabloy-contract-loop` under execution.
 
-While authoring planning records, do not automatically:
+## Safe boundary
 
-- 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.
+Business planning belongs in `repo-specs/`; reusable guidance in `repo-docs/`; supporting cross-suite rationale in `repo-docs-internal/`; procedural behavior in authored governance skills. Do not introduce a parallel authority.
 
-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.
+Planning must not automatically run init, database reset/recreation, source scaffolding, acceptance tests, deployment, or provider operations. Static planning checks are not ATP evidence. Any meaningful retained verification needs a separately approved bounded scope and actual revision/environment/procedure/result/redacted artifact.

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

@@ -37,7 +37,9 @@ The directory is repository-native, suite-local, and maintainer-facing. It is no
 | `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>`.
+When records disagree, update authority first, then downstream mappings and derived status. Use `canonical-spec-input.md` for new declaration syntax and the three separate quality gates. Full baseline and complete incremental sets use `npm run spec:check -- <suite>`; explicitly lightweight sets use `--lightweight` and state omitted owners/chain coverage. An existing directory is an incremental destination, not an automatic conflict or reset request.
+
+Generate/check charts only with complete supported README/WBS/ATP/progress inputs. Regenerate after `pdp-wbs.md`, `test-plan.md`, `progress.md`, or README title/language changes. An incomplete lightweight/legacy set reports missing chart inputs rather than inventing business definitions to make the generator run.
 
 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.
 
@@ -109,7 +111,7 @@ Use identifiers such as `SRS-<DOMAIN>-*`. Define the technical facts needed to i
 - 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.
+For each audience, SRS owns topology and audience-specific API/DTO, scope, state/page/route, and SSR contracts. Apply the observed-existing/proposed-new/explicitly-approved-new semantics in `repo-aware-discovery.md`. Shared targets require a cited existing owner. A deliberately new independent tuple may be designed before source exists: validate framework constraints and collisions, obtain explicit design approval and an `Accepted` governing ADR, then permit creation only through bounded execution approval. Unknown/unchecked values stay `TODO(confirm)`; a planned new wrapper is not a current command. Independent composition does not create 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.
 
@@ -127,7 +129,7 @@ Use:
 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>`.
+Complete new long-lived baselines include both derived charts once their supported inputs are complete. Follow the conditional chart branch and freshness commands in `canonical-spec-input.md`; neither charts nor audit results are implementation proof.
 
 Every WBS entry should state:
 
@@ -169,7 +171,7 @@ Every evidence record should retain, at minimum:
 - 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.
+A listed command is prospective, not a result. Independent-site proof may target an explicitly approved new tuple and planned wrapper, with wrapper creation/manifest observation as a prerequisite to running it. Proposed/unchecked designs retain their gates. Shared-site proof uses the observed owner. Neither prospective procedures nor source reading establish successful verification.
 
 ## Progress template contract
 

package/repo-agent-governance/skills/cabloy-spec-generation/references/traceability-and-status-rules.md

@@ -27,7 +27,9 @@ Before reporting a generated baseline or an authority update complete, build a t
 - 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.
+- Run `npm run spec:check -- <suite>` for the planning authority audit; add `--lightweight` only for explicitly agreed limited scope. Derive chain associations from explicit declaration-body Traceability, not matrix co-occurrence.
+- `canonical-spec-input.md` specifies new declarations and compatible legacy catalogue roles. Matrix/evidence mentions cannot establish definitions.
+- With complete supported chart inputs, run `npm run spec:charts:check -- <suite>` after generation to verify model consistency and freshness. This is a separate gate, not the PRD/SRS audit or evidence review.
 
 ## Canonical chain
 
@@ -57,10 +59,11 @@ When a requirement or durable boundary changes:
 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.
+7. run the applicable full/lightweight planning audit and review legacy gaps without inventing business definitions;
+8. with complete supported chart inputs, regenerate both charts and run `npm run spec:charts:check -- <suite>`; otherwise report the precise chart-input gap;
+9. review human approval, controlling TODOs, and retained proof separately.
 
-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`.
+Downstream records do not silently override authority. Charts cannot authorize scope, dependencies, dates, evidence, or status. Their language follows `README.md`; title/language edits also require regeneration when chart inputs are complete.
 
 ## Status semantics
 
@@ -80,10 +83,11 @@ For a newly created plan, initialize delivery rows as `not-started`, `deferred`,
 
 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.
+- **Observed existing** targets are inspected and cited repository facts.
+- **Confirmed inputs** are explicitly supplied/confirmed values; they are not automatically accepted durable designs.
+- **Proposed new** targets remain proposals while design checks, explicit approval, or ADR acceptance are missing.
+- **Explicitly approved new** targets require framework/collision validation, explicit concrete design approval, and an `Accepted` governing ADR. Their source may be created later under a separately approved bounded execution dossier; absence of that future source is not a design blocker.
+- Generation approval, ADR acceptance, and execution approval are separate domains. Keep any partially approved target state and controlling TODOs explicit.
 
 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.
 

package/repo-agent-governance/tests/governance.test.mjs

@@ -177,7 +177,10 @@ test('initializer preserves a legacy-customized adapter during a staged upgrade'
     );
     writeFileSync(fixtureBootstrap, content);
     writeFileSync(resolve(root, 'CLAUDE.md'), 'legacy project customization\n');
-    writeFileSync(resolve(root, 'package.json'), readFileSync(resolve(ROOT_DIR, 'package.json')));
+    const projectPackage = JSON.parse(readFileSync(resolve(ROOT_DIR, 'package.json'), 'utf8'));
+    delete projectPackage.scripts['spec:check'];
+    projectPackage.scripts['project:custom'] = 'node project-owned.mjs';
+    writeFileSync(resolve(root, 'package.json'), JSON.stringify(projectPackage));
 
     const upgradeRoot = resolve(root, 'node_modules/.cabloy-upgrade');
     cpSync(GOVERNANCE_DIR, resolve(upgradeRoot, 'repo-agent-governance'), { recursive: true });
@@ -199,6 +202,12 @@ test('initializer preserves a legacy-customized adapter during a staged upgrade'
       /Staged governance source/,
     );
     assert.match(readFileSync(resolve(root, 'AGENTS.md'), 'utf8'), /Staged governance source/);
+    const updatedPackage = JSON.parse(readFileSync(resolve(root, 'package.json'), 'utf8'));
+    assert.equal(
+      updatedPackage.scripts['spec:check'],
+      'node ./repo-agent-governance/tools/spec-audit/audit.mjs',
+    );
+    assert.equal(updatedPackage.scripts['project:custom'], 'node project-owned.mjs');
   });
 });