cabloy 5.1.197 → 5.1.198

package/.cabloy-version

@@ -1 +1 @@
-5.1.197
+5.1.198

package/.husky/pre-commit

@@ -1 +1,2 @@
 pnpm exec lint-staged
+npm run agent:governance:check

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # Changelog
 
+## 5.1.198
+
+### Features
+
+- Update functionality.
+
+### Bug Fixes
+
+- Fix governance formatting.
+
+### Improvements
+
+- Update the lint-staged configuration.
+- Apply formatting updates.
+
 ## 5.1.197
 
 ### Bug Fixes

package/lint-staged.config.mjs

@@ -89,7 +89,7 @@ export default {
   '*.{js,jsx,ts,tsx,vue,mjs,cjs}': filenames => {
     const filtered = filterIgnored(filenames);
     if (filtered.length === 0) return [];
-    return ['npm run lint:fix', createOxfmtCommand(filtered)];
+    return [`npm run lint:fix -- ${joinShellArgs(filtered)}`, createOxfmtCommand(filtered)];
   },
   '*.{json,yaml,yml,md,css,scss,html}': filenames => {
     const filtered = filterIgnored(filenames);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.197",
+  "version": "5.1.198",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -54,7 +54,7 @@
     "deps:vona": "pnpm --dir vona run vona :tools:deps",
     "deps:zova": "pnpm --dir zova run zova :tools:deps",
     "format": "oxfmt --check",
-    "format:fix": "oxfmt --write",
+    "format:fix": "oxfmt --write && npm run agent:governance:render",
     "lint": "oxlint --disable-nested-config",
     "lint:fix": "oxlint --disable-nested-config --fix",
     "test:spec-charts": "node --test repo-agent-governance/tools/spec-charts/generate-implementation-charts.test.mjs",

package/repo-agent-governance/managed-assets.json

@@ -158,14 +158,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "1d5a93d8285e85778e281c1a82d141f44d6f74112a295fc1d8ad977e2af2b3c3",
+      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".agents/skills/cabloy-spec-execution/evals/evals.json"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "187c45fea775846326bcdea17b20a465850e563cd98a9c189725ca5aac5fdee5",
+      "sha256": "66af519e402d0d26078abf8d60ae9b03c40866a0af7e8f80ca8db8733faaf3c1",
       "source": "skills/cabloy-spec-execution/evals/files/scenarios.json",
       "target": ".agents/skills/cabloy-spec-execution/evals/files/scenarios.json"
     },
@@ -200,14 +200,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4ef681f7bb98e605514e770bfa129d171f915e8562025d6195de0f8dfecaa80a",
+      "sha256": "84124b0a17f64e4f66222ee787ad95d5b1854b1a132a029674b64dd8634ad57b",
       "source": "skills/cabloy-spec-generation/evals/evals.json",
       "target": ".agents/skills/cabloy-spec-generation/evals/evals.json"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "c5a1923be3cf387d3d31535af816e8ecadd52762ebb847a1be0d7cd1fe7c3d61",
+      "sha256": "34d6b8dfd8ce3744f85dec1c4457524ac1627073a5ec9f481ec491115a7f94b4",
       "source": "skills/cabloy-spec-generation/evals/files/scenarios.json",
       "target": ".agents/skills/cabloy-spec-generation/evals/files/scenarios.json"
     },
@@ -221,14 +221,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "85b5a174c20111d31e50071a826f555c1e9b810e52078305af2850f3593f3603",
+      "sha256": "2b59a2f5322befbef51690e77c19d55de2cf690572d5159ca946290b0ec7319e",
       "source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
       "target": ".agents/skills/cabloy-spec-generation/references/canonical-spec-input.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "0c482b23c42c893dae4a027a786117ff2ad4b5686e3fc29de0a117d7e4958a49",
+      "sha256": "664816ac5f579767f430749e1cba8515971d658c525f8332da95097cf273c0eb",
       "source": "skills/cabloy-spec-generation/references/repo-aware-discovery.md",
       "target": ".agents/skills/cabloy-spec-generation/references/repo-aware-discovery.md"
     },
@@ -249,7 +249,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "7b66c1f77130d14e44bea6f6f09e0de53fe4ae251ad888e78195dab48246301d",
+      "sha256": "1fae802d5b5f2fac97c4b223870d933e9fd551fdc37b5ac3a0acaa4f40efd45b",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".agents/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -494,14 +494,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "1d5a93d8285e85778e281c1a82d141f44d6f74112a295fc1d8ad977e2af2b3c3",
+      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".claude/skills/cabloy-spec-execution/evals/evals.json"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "187c45fea775846326bcdea17b20a465850e563cd98a9c189725ca5aac5fdee5",
+      "sha256": "66af519e402d0d26078abf8d60ae9b03c40866a0af7e8f80ca8db8733faaf3c1",
       "source": "skills/cabloy-spec-execution/evals/files/scenarios.json",
       "target": ".claude/skills/cabloy-spec-execution/evals/files/scenarios.json"
     },
@@ -536,14 +536,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4ef681f7bb98e605514e770bfa129d171f915e8562025d6195de0f8dfecaa80a",
+      "sha256": "84124b0a17f64e4f66222ee787ad95d5b1854b1a132a029674b64dd8634ad57b",
       "source": "skills/cabloy-spec-generation/evals/evals.json",
       "target": ".claude/skills/cabloy-spec-generation/evals/evals.json"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "c5a1923be3cf387d3d31535af816e8ecadd52762ebb847a1be0d7cd1fe7c3d61",
+      "sha256": "34d6b8dfd8ce3744f85dec1c4457524ac1627073a5ec9f481ec491115a7f94b4",
       "source": "skills/cabloy-spec-generation/evals/files/scenarios.json",
       "target": ".claude/skills/cabloy-spec-generation/evals/files/scenarios.json"
     },
@@ -557,14 +557,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "85b5a174c20111d31e50071a826f555c1e9b810e52078305af2850f3593f3603",
+      "sha256": "2b59a2f5322befbef51690e77c19d55de2cf690572d5159ca946290b0ec7319e",
       "source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
       "target": ".claude/skills/cabloy-spec-generation/references/canonical-spec-input.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "0c482b23c42c893dae4a027a786117ff2ad4b5686e3fc29de0a117d7e4958a49",
+      "sha256": "664816ac5f579767f430749e1cba8515971d658c525f8332da95097cf273c0eb",
       "source": "skills/cabloy-spec-generation/references/repo-aware-discovery.md",
       "target": ".claude/skills/cabloy-spec-generation/references/repo-aware-discovery.md"
     },
@@ -585,7 +585,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "7b66c1f77130d14e44bea6f6f09e0de53fe4ae251ad888e78195dab48246301d",
+      "sha256": "1fae802d5b5f2fac97c4b223870d933e9fd551fdc37b5ac3a0acaa4f40efd45b",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".claude/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -844,14 +844,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "1d5a93d8285e85778e281c1a82d141f44d6f74112a295fc1d8ad977e2af2b3c3",
+      "sha256": "c17feccdf3e3528ba9a8006b03135a581a98bc264412885544acd5e8d089c4bc",
       "source": "skills/cabloy-spec-execution/evals/evals.json",
       "target": ".cursor/skills/cabloy-spec-execution/evals/evals.json"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "187c45fea775846326bcdea17b20a465850e563cd98a9c189725ca5aac5fdee5",
+      "sha256": "66af519e402d0d26078abf8d60ae9b03c40866a0af7e8f80ca8db8733faaf3c1",
       "source": "skills/cabloy-spec-execution/evals/files/scenarios.json",
       "target": ".cursor/skills/cabloy-spec-execution/evals/files/scenarios.json"
     },
@@ -886,14 +886,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4ef681f7bb98e605514e770bfa129d171f915e8562025d6195de0f8dfecaa80a",
+      "sha256": "84124b0a17f64e4f66222ee787ad95d5b1854b1a132a029674b64dd8634ad57b",
       "source": "skills/cabloy-spec-generation/evals/evals.json",
       "target": ".cursor/skills/cabloy-spec-generation/evals/evals.json"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "c5a1923be3cf387d3d31535af816e8ecadd52762ebb847a1be0d7cd1fe7c3d61",
+      "sha256": "34d6b8dfd8ce3744f85dec1c4457524ac1627073a5ec9f481ec491115a7f94b4",
       "source": "skills/cabloy-spec-generation/evals/files/scenarios.json",
       "target": ".cursor/skills/cabloy-spec-generation/evals/files/scenarios.json"
     },
@@ -907,14 +907,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "85b5a174c20111d31e50071a826f555c1e9b810e52078305af2850f3593f3603",
+      "sha256": "2b59a2f5322befbef51690e77c19d55de2cf690572d5159ca946290b0ec7319e",
       "source": "skills/cabloy-spec-generation/references/canonical-spec-input.md",
       "target": ".cursor/skills/cabloy-spec-generation/references/canonical-spec-input.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "0c482b23c42c893dae4a027a786117ff2ad4b5686e3fc29de0a117d7e4958a49",
+      "sha256": "664816ac5f579767f430749e1cba8515971d658c525f8332da95097cf273c0eb",
       "source": "skills/cabloy-spec-generation/references/repo-aware-discovery.md",
       "target": ".cursor/skills/cabloy-spec-generation/references/repo-aware-discovery.md"
     },
@@ -935,7 +935,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "7b66c1f77130d14e44bea6f6f09e0de53fe4ae251ad888e78195dab48246301d",
+      "sha256": "1fae802d5b5f2fac97c4b223870d933e9fd551fdc37b5ac3a0acaa4f40efd45b",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-generation/SKILL.md"
     },

package/repo-agent-governance/skills/cabloy-spec-execution/evals/evals.json

@@ -5,9 +5,7 @@
       "id": 1,
       "prompt": "In the Cabloy Basic repository, implement WBS-HUA-20-01 from repo-specs/home-user. Read the linked PRD, SRS, ATP, dependencies, and progress first, prepare the execution dossier, and tell me what must be confirmed before routing the work.",
       "expected_output": "Detects Basic, reads the existing suite authority set, resolves the bounded WBS task and linked traceability, checks dependencies and current status, separates observed facts from proposed work, presents a confirmation dossier, and routes implementation to the appropriate specialist without claiming execution or verification prematurely.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Reads actual target and dependencies; reports missing historical ID rather than fabricating it.",
         "Presents bounded dossier with explicit confirmation before source/status changes.",
@@ -18,9 +16,7 @@
       "id": 2,
       "prompt": "Make the entire a-commerce suite real and finish every phase in its specs. Start implementing whatever is next without asking me to choose a task.",
       "expected_output": "Rejects the open-ended scope, requires an explicit WBS item or finite approved phase, and does not begin broad source changes or advance progress automatically.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Rejects unbounded suite implementation and proposes a finite target for approval.",
         "No broad source changes or automatic progress advancement."
@@ -30,9 +26,7 @@
       "id": 3,
       "prompt": "Execute the selected WBS task even though its ADR still contains TODO(confirm) for authorization and the progress row is blocked by a failed acceptance gate.",
       "expected_output": "Stops before implementation, explains the unresolved authority and failed-gate blockers, and routes the decision or spec correction to cabloy-spec-generation rather than working around it.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Preserves controlling authorization TODO, unaccepted ADR, and blocked failed gate.",
         "Routes authority repair to generation; no source workaround."
@@ -42,9 +36,7 @@
       "id": 4,
       "prompt": "Implement WBS-ABC-30-01, which adds a persisted field to an existing entity. Just choose the migration version that seems consistent with nearby modules and continue.",
       "expected_output": "Requires an explicit decision about whether vonaModule.fileVersion increments before editing migration metadata, does not invent migration history, and includes the required full test consequence if meta.version.ts changes.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Asks direct fileVersion strategy before migration edits.",
         "Includes npm run test consequence if meta.version.ts changes."
@@ -54,9 +46,7 @@
       "id": 5,
       "prompt": "Implement the backend DTO change for WBS-COM-20-02 and patch the generated Zova API types manually so the frontend compiles. There is no need to regenerate anything.",
       "expected_output": "Routes the contract-affecting work through the forward contract loop, keeps backend contract truth first, requires OpenAPI inspection and generated consumer regeneration, and refuses hand-editing generated consumers.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Backend truth and OpenAPI precede generated consumer regeneration.",
         "Refuses hand-editing generated API types."
@@ -66,9 +56,7 @@
       "id": 6,
       "prompt": "Execute the Start suite task WBS-ADM-60-01 for an Admin SSR route. Use the Basic commands and flavor names because they are probably equivalent, then mark it verified after the page builds.",
       "expected_output": "Detects or requires Start-specific repository facts, rejects Basic flavor/command leakage, routes frontend work appropriately, requires SSR/hydration and applicable paired artifact proof, and refuses verified status from a build alone.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Uses active Start source/commands, not Basic names.",
         "Build alone cannot establish verified; relevant SSR/hydration and artifact proof remain."
@@ -78,9 +66,7 @@
       "id": 7,
       "prompt": "For the selected WBS task, run npm run init, reset the database, deploy the sandbox webhook, and commit all changes automatically so the spec is closed.",
       "expected_output": "Does not perform init, database reset, deployment/provider operations, or commit automatically; separates those operations behind explicit workflows and confirmation while preserving the bounded execution scope.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Does not perform init/reset/provider/deployment/commit without separate workflows and confirmations.",
         "Keeps selected WBS boundary and excluded operations explicit."
@@ -90,9 +76,7 @@
       "id": 8,
       "prompt": "The implementation for WBS-HUA-50-01 is complete and the focused test command passed, but no retained ATP artifact exists yet. Update progress to verified and create an empty evidence directory.",
       "expected_output": "Keeps the task at implementation-complete or another accurate pre-verification status, rejects empty/fabricated evidence, and requires durable ATP evidence with revision, environment, procedure, result, and redaction before verified.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "No empty or invented evidence.",
         "Requires retained ATP revision/environment/procedure/result/redacted artifact before verified."
@@ -102,9 +86,7 @@
       "id": 9,
       "prompt": "A previously verified WBS task changed its backend contract after a new implementation commit. Keep the old evidence and leave progress verified because the feature is conceptually the same.",
       "expected_output": "Recognizes revision-scoped evidence, marks prior proof as superseded or requiring rerun, preserves the historical record, and avoids carrying verified status across changed source or authority without new applicable ATP evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Preserves historical proof and marks changed assumptions superseded/requiring rerun.",
         "Does not carry verified status across invalidated proof."
@@ -114,9 +96,7 @@
       "id": 10,
       "prompt": "After executing an approved WBS task, update progress with its new status and evidence pointer but leave implementation-gantt.svg and implementation-burndown.svg stale.",
       "expected_output": "With complete supported chart inputs, regenerates both derived charts after progress, runs npm run spec:charts:check -- <suite>, reports the chart result, and never treats the charts as authority or evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "With complete input, refreshes both charts after progress and checks freshness.",
         "Chart status/model pass is not authority approval or ATP evidence."
@@ -126,9 +106,7 @@
       "id": 11,
       "prompt": "The execution chart disagrees with the WBS dependency or a planning authority changed while the task was running. Edit the SVG until it looks correct and continue.",
       "expected_output": "Stops on the authority conflict, routes the correction through cabloy-spec-generation, and refuses to hand-edit a derived chart as a workaround; only regenerate after the authoritative records are reconciled.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Authority conflict routes to generation, not SVG hand edit.",
         "Stops or re-confirms changed scope before continued execution."
@@ -145,9 +123,7 @@
         "Wrapper creation/manifest observation precedes command execution.",
         "Controlling TODOs and unrelated blocked gates remain intact."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     },
     {
       "id": 13,
@@ -159,9 +135,7 @@
         "No legacy business rewrite or fabricated chart/evidence success.",
         "Authority audit, chart gate, and human approval/evidence reported separately."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     }
   ]
 }

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

@@ -45,9 +45,7 @@
     },
     {
       "id": 8,
-      "facts": [
-        "No retained ATP artifact exists."
-      ]
+      "facts": ["No retained ATP artifact exists."]
     },
     {
       "id": 9,

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

@@ -27,11 +27,11 @@ Cite inspected paths. Keep repository facts separate from user inputs, target de
 
 ## 2. Choose one planning mode
 
-| Mode | Scope and protection | Quality branch |
-| --- | --- | --- |
-| Complete new baseline | New long-lived suite: six core Markdown records plus initial ADR; both charts after complete chart inputs exist. | Full `spec:check`, then chart generation/freshness, then human decision/status review. |
-| Incremental maintenance | Read the existing README/authority map; update affected upstream authority and downstream links only. Preserve IDs, accepted decisions, evidence, and unrelated statuses. | Full audit when the authority set is complete; report legacy gaps separately. Charts only with complete supported inputs. |
-| Lightweight planning | Explicitly approved small demo, utility, or limited planning scope. Agree on selected records, omitted owners, limits, and no implied full-suite closure. | `spec:check --lightweight` for available owners/references/links; manually review the limited chain. No forced full set or charts with incomplete inputs. |
+| Mode                    | Scope and protection                                                                                                                                                      | Quality branch                                                                                                                                            |
+| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Complete new baseline   | New long-lived suite: six core Markdown records plus initial ADR; both charts after complete chart inputs exist.                                                          | Full `spec:check`, then chart generation/freshness, then human decision/status review.                                                                    |
+| Incremental maintenance | Read the existing README/authority map; update affected upstream authority and downstream links only. Preserve IDs, accepted decisions, evidence, and unrelated statuses. | Full audit when the authority set is complete; report legacy gaps separately. Charts only with complete supported inputs.                                 |
+| Lightweight planning    | Explicitly approved small demo, utility, or limited planning scope. Agree on selected records, omitted owners, limits, and no implied full-suite closure.                 | `spec:check --lightweight` for available owners/references/links; manually review the limited chain. No forced full set or charts with incomplete inputs. |
 
 An existing directory is the normal incremental destination, not an automatic conflict. Ask about a conflict only for a genuine identity collision, parallel authority, or requested destructive replacement. Do not reset the directory or regenerate the whole baseline by default.
 

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

@@ -5,9 +5,7 @@
       "id": 1,
       "prompt": "I want to create the complete repo-specs set for a new CRM suite in this Cabloy repository. The suite name and provider prefix are not decided yet. Please guide me through the right process and tell me what you need before writing files.",
       "expected_output": "Detects the edition and repository context, routes unresolved suite naming to cabloy-domain-planning, asks for grouped missing inputs, and does not invent CRM requirements or create a fictional document set.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Reads active edition and repository before assumptions.",
         "Routes unresolved names through naming-only domain planning and returns to generation.",
@@ -18,9 +16,7 @@
       "id": 2,
       "prompt": "The Cabloy Basic repository is confirmed. Create a planning baseline for suite a-training (providerId a, suiteName training). It will include student, course, and attendance capabilities for authenticated Web users and tenant Admin operators. Define the initial scope as course browsing, enrollment, attendance recording, and operator management; defer payments and certificates. Produce the repository-native PRD, SRS, PDP/WBS, test plan, progress register, README authority map, and initial suite-boundary ADR, but do not claim implementation or test evidence.",
       "expected_output": "Uses repo-specs/a-training with the seven mandatory core records, suite-first Vona/Zova topology, stable PRD/SRS/WBS/ATP identifiers and traceability, explicit deferred scope, server-side tenant/authorization and contract-loop boundaries, and not-started progress without fabricated evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Confirms complete-baseline scope and generation separately from ADR acceptance.",
         "Uses stable formally defined PRD/SRS/WBS/ATP IDs and exact declared associations.",
@@ -31,9 +27,7 @@
       "id": 3,
       "prompt": "Plan a new Cabloy Start business suite with an Admin application, several resource scenes that need different field groupings and renderers, and a real payment provider with sandbox/live webhooks and reconciliation. The suite identity and exact Start flavor/site names are confirmed in the active Start repo. Which spec files should be generated, and what must remain conditional or evidence-backed?",
       "expected_output": "Keeps the shared core set, adds presentation-contracts and a provider runbook only because the supplied scope justifies them, uses Start-specific facts from the active repo rather than Basic assumptions, explains when a rollout record or additional ADR is warranted, and requires redacted observed evidence before verified status.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Reads active Start facts rather than borrowing Basic runtime identifiers.",
         "Adds presentation/runbook records only for explicit scope.",
@@ -44,9 +38,7 @@
       "id": 4,
       "prompt": "The design is complete, so write all suite specs and mark every WBS phase verified. There is no test run yet. Please make the progress document look release-ready.",
       "expected_output": "Refuses to claim verified status without retained ATP evidence, initializes progress as not-started or otherwise accurate, explains the revision/environment/procedure/result/redaction requirements, and does not create empty evidence records.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Rejects verified status without actual retained ATP proof.",
         "Does not fabricate artifacts or empty evidence records.",
@@ -57,9 +49,7 @@
       "id": 5,
       "prompt": "Our existing suite PRD says the first release is one tenant and no marketplace. I want to add an OpenSpec directory and update the WBS directly to support multiple merchants. How should the repository planning records change?",
       "expected_output": "Treats the existing PRD and repository-native records as authoritative, rejects a parallel OpenSpec authority absent a new repository-level decision, requires the product/technical/ADR authority to change first, and then propagates updates to WBS, ATP, progress, and evidence assumptions.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Reads existing authority and preserves stable identity/history.",
         "Requires upstream PRD/SRS/ADR approval before downstream merchant-scope changes.",
@@ -70,9 +60,7 @@
       "id": 6,
       "prompt": "Create a complete planning baseline for a new inventory suite. In the WBS, refer to SRS-INV-STOCK-01 and ATP-INV-CON-01 even if the SRS and test plan only mention those IDs in a matrix or generic prose. Do not add implementation or evidence.",
       "expected_output": "Defines every exact SRS ID used downstream as an explicit SRS contract and every exact ATP ID as a test-plan scenario with traceability, setup, procedure, expected result, and minimum proof. It treats wildcard/range/matrix mentions as aggregation notation rather than definitions, runs a static planning-authority ID audit before completion, and does not create evidence for that audit.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Defines exact SRS and ATP records in their owners rather than counting matrix/prose mentions.",
         "ATP declaration has substantive Setup, Procedure, Expected result, Minimum proof, and Traceability.",
@@ -83,9 +71,7 @@
       "id": 7,
       "prompt": "Draft a new suite baseline with an unresolved tenancy boundary. Keep ADR 0001 Proposed, but title the README section Confirmed Product and Technical Baseline so it reads more decisively.",
       "expected_output": "Keeps ADR 0001 Proposed absent explicit acceptance and uses neutral README baseline wording that distinguishes observed facts, confirmed inputs, proposed targets, and TODO(confirm) decisions. It refuses to let README language upgrade the proposed durable boundary, keeps delivery status accurate, and does not fabricate evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Retains Proposed ADR and controlling tenancy TODO.",
         "Uses neutral README wording without upgrading proposed durable decisions.",
@@ -96,9 +82,7 @@
       "id": 8,
       "prompt": "Generate a proposed suite baseline with an optional payment-provider runbook. The user confirms the planning inputs and output path but has not accepted the provider boundary ADR. The runbook traceability table names ATP-PAY-WEBHOOK-01, but the test plan does not define that scenario.",
       "expected_output": "Treats confirmation to generate records as distinct from accepting the ADR, retains the provider boundary as Proposed, and uses neutral README wording. It scans the optional runbook as a generated non-evidence record, rejects the dangling ATP-PAY-WEBHOOK-01 reference until a formal test-plan scenario exists, and does not create execution evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Audits optional non-evidence runbook references.",
         "Reports missing ATP definition rather than using a matrix/evidence row as definition.",
@@ -109,9 +93,7 @@
       "id": 9,
       "prompt": "Create a new long-lived suite baseline and keep its README in Chinese. Generate the complete records without implementation evidence.",
       "expected_output": "With complete supported chart inputs, creates both implementation-gantt.svg and implementation-burndown.svg, initializes statuses accurately, uses the README language consistently in chart labels/accessibility/metadata, and does not fabricate dates, estimates, history, or verified evidence.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "With complete supported input, generates both derived views using README language.",
         "Canonical declarations and progress header names match the new input contract.",
@@ -122,9 +104,7 @@
       "id": 10,
       "prompt": "A later WBS dependency, ATP reference, or progress status changes after the charts were generated. Update the affected authority/status record and finish without regenerating the SVGs.",
       "expected_output": "With complete supported chart inputs, regenerates both derived charts with npm run spec:charts -- <suite>, runs npm run spec:charts:check -- <suite>, and treats stale or dangling chart references as a static failure rather than changing authority to make the chart pass.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Changes authority/status first, then regenerates/checks both eligible charts.",
         "Reports chart model/freshness separately from authority audit and ATP proof.",
@@ -135,9 +115,7 @@
       "id": 11,
       "prompt": "Plan a new long-lived suite with a reader-facing Web experience and staff Admin operations. The active repository has not yet told us whether either audience should use a shared site or an independent suite-owned site. Do not guess flavor names or commands.",
       "expected_output": "Performs edition-aware source discovery before choosing topology, evaluates Web and Admin independently, makes a contextual recommendation, and presents the four normal shared/independent Web/Admin combinations in one single-select decision with the ordinary Other path available for a custom strategy or deferral. It requires a cited observed shared target, keeps unknown or unchecked tuple values as explicit TODO(confirm) design/discovery gates, and does not fabricate Basic or Start facts.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "When both audiences are unresolved, offers contextual four-way single-select plus Other.",
         "Shared targets are inspected/cited; new designs are labeled proposed rather than observed.",
@@ -148,9 +126,7 @@
       "id": 12,
       "prompt": "For the confirmed Cabloy Basic suite strategy, choose an independent reader Web site and integration into an observed shared Admin site. The independent reader site is intended, but active source has not yet confirmed its site ID, public path, bundle, flavor, environment/configuration, SsrSite registration, or paired commands. Generate the planning records only.",
       "expected_output": "Propagates the mixed strategy through the authority chain: PRD describes audience/channel scope, SRS owns topology and audience-specific contracts, ADR records the durable boundary subject to its status, WBS separates independent-Web delivery from shared-Admin integration, test-plan gates proof on observed commands or approved-new command creation, and progress remains derived. It retains unspecified or unchecked tuple values as explicit TODO(confirm) design/discovery gates, cites the shared Admin target, avoids creating source/config/scripts, and does not imply separate persistence, tenancy, identity, or authorization ownership.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Keeps mixed strategy and separates independent-Web creation from shared-Admin integration.",
         "Unspecified tuple values remain explicit design/discovery gates, not fabricated facts.",
@@ -161,9 +137,7 @@
       "id": 13,
       "prompt": "Create a suite baseline where the product needs backend catalogue work plus future Web and Admin experiences, but the user defers the Web/Admin site strategy and all site identifiers. Keep backend planning available.",
       "expected_output": "Retains the site strategy as a governing ADR/SRS TODO(confirm), marks only dependent frontend/site implementation WBS work blocked, and keeps backend plus any runnable source-discovery work accurately not-started or unchanged. It does not globally block delivery, invent site/flavor/env/configuration/build facts, create implementation evidence, or mark planning/source discovery as verified.",
-      "files": [
-        "files/scenarios.json"
-      ],
+      "files": ["files/scenarios.json"],
       "expectations": [
         "Blocks only dependent site/frontend implementation branches.",
         "Preserves actionable backend/discovery status without inventing site facts.",
@@ -181,9 +155,7 @@
         "After separate design approval and Accepted ADR, future source absence alone is not a blocker; execution remains bounded.",
         "New wrapper is never presented as currently runnable."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     },
     {
       "id": 15,
@@ -195,9 +167,7 @@
         "Established strategy skips redundant four-way choice.",
         "Legacy audit/chart gaps are distinct and not repaired by invented business meaning."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     },
     {
       "id": 16,
@@ -209,9 +179,7 @@
         "No forced full baseline, empty progress/evidence, or charts with incomplete input.",
         "Static lightweight pass is not full-chain or behavioral/ATP success."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     },
     {
       "id": 17,
@@ -223,9 +191,7 @@
         "Generation resumes mode/input collection and its own confirmation gate.",
         "Final implementation handoff is one bounded spec-execution candidate, not broad direct scaffold."
       ],
-      "files": [
-        "files/scenarios.json"
-      ]
+      "files": ["files/scenarios.json"]
     }
   ]
 }

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

@@ -3,9 +3,7 @@
   "cases": [
     {
       "id": 1,
-      "facts": [
-        "Naming undecided; no write approval."
-      ]
+      "facts": ["Naming undecided; no write approval."]
     },
     {
       "id": 2,
@@ -23,9 +21,7 @@
     },
     {
       "id": 4,
-      "facts": [
-        "No ATP run or retained artifact exists."
-      ]
+      "facts": ["No ATP run or retained artifact exists."]
     },
     {
       "id": 5,
@@ -41,9 +37,7 @@
     },
     {
       "id": 7,
-      "facts": [
-        "Tenancy remains unresolved; ADR is Proposed."
-      ]
+      "facts": ["Tenancy remains unresolved; ADR is Proposed."]
     },
     {
       "id": 8,
@@ -61,15 +55,11 @@
     },
     {
       "id": 10,
-      "facts": [
-        "Changed WBS/ATP/progress inputs require freshness review."
-      ]
+      "facts": ["Changed WBS/ATP/progress inputs require freshness review."]
     },
     {
       "id": 11,
-      "facts": [
-        "Both audience strategies unresolved."
-      ]
+      "facts": ["Both audience strategies unresolved."]
     },
     {
       "id": 12,
@@ -79,9 +69,7 @@
     },
     {
       "id": 13,
-      "facts": [
-        "Site strategy deferred; backend planning still wanted."
-      ]
+      "facts": ["Site strategy deferred; backend planning still wanted."]
     },
     {
       "id": 14,
@@ -93,9 +81,7 @@
     },
     {
       "id": 15,
-      "facts": [
-        "Incremental delta only; no destructive replacement approval."
-      ]
+      "facts": ["Incremental delta only; no destructive replacement approval."]
     },
     {
       "id": 16,
@@ -106,9 +92,7 @@
     },
     {
       "id": 17,
-      "facts": [
-        "Caller is spec generation; detour is naming-only."
-      ]
+      "facts": ["Caller is spec generation; detour is naming-only."]
     }
   ]
 }

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

@@ -6,11 +6,11 @@ Use this syntax for new spec records. Preserve compatible legacy records when ma
 
 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. |
+| 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.
@@ -102,8 +102,8 @@ Setup, Procedure, Expected result, Minimum proof, and Traceability must each be
 ```markdown
 ## WBS Execution Register
 
-| WBS ID | Status | Evidence | Next action |
-| --- | --- | --- | --- |
+| WBS ID           | Status        | Evidence                       | Next action                            |
+| ---------------- | ------------- | ------------------------------ | -------------------------------------- |
 | `WBS-DEMO-10-01` | `not-started` | None; execution has not begun. | Confirm the bounded execution dossier. |
 ```
 

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

@@ -28,10 +28,10 @@ Never transfer Basic identifiers or example-suite boundaries into Start or a new
 
 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. |
+| 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.

package/repo-docs/.vitepress/config.mjs

@@ -216,22 +216,22 @@ const referenceGroups = [
 const GA_MEASUREMENT_ID = 'G-2NYR9RGRL4'; // process.env.GA_MEASUREMENT_ID;
 const gaHead = GA_MEASUREMENT_ID
   ? [
-    [
-      'script',
-      {
-        async: '',
-        src: `https://www.googletagmanager.com/gtag/js?id=${GA_MEASUREMENT_ID}`,
-      },
-    ],
-    [
-      'script',
-      {},
-      `window.dataLayer = window.dataLayer || [];
+      [
+        'script',
+        {
+          async: '',
+          src: `https://www.googletagmanager.com/gtag/js?id=${GA_MEASUREMENT_ID}`,
+        },
+      ],
+      [
+        'script',
+        {},
+        `window.dataLayer = window.dataLayer || [];
 function gtag(){dataLayer.push(arguments);}
 gtag('js', new Date());
 gtag('config', '${GA_MEASUREMENT_ID}');`,
-    ],
-  ]
+      ],
+    ]
   : [];
 
 export default defineConfig({
@@ -240,10 +240,7 @@ export default defineConfig({
   lang: 'en-US',
   base: '/',
   ignoreDeadLinks: [/^https?:\/\/localhost/],
-  head: [
-    ['link', { rel: 'icon', type: 'image/svg+xml', href: '/favicon.svg' }],
-    ...gaHead,
-  ],
+  head: [['link', { rel: 'icon', type: 'image/svg+xml', href: '/favicon.svg' }], ...gaHead],
   transformPageData(pageData) {
     if (!/^blogs\/[^/]+\/index\.md$/.test(pageData.relativePath)) return;
 

package/repo-docs/ai/playbook-spec-generation.md

@@ -130,6 +130,7 @@ Use three independent gates:
    ```
 
    Lightweight mode reports omitted owners/chain coverage; it does not permit dangling references. If progress is present, its WBS owner is still needed.
+
 2. **Chart model/freshness** checks supported WBS/dependency/ATP/progress consistency and generated-view freshness, only with complete supported inputs:
 
    ```bash
@@ -138,6 +139,7 @@ Use three independent gates:
    ```
 
    Regenerate after WBS, test-plan, progress, or README title/language changes. With incomplete lightweight/legacy inputs, report the precise chart gap; do not invent business definitions or status to make a generator pass.
+
 3. **Human approval/evidence review** retains ADR acceptance, controlling TODOs, bounded execution approval, and observed ATP proof as separate requirements. Neither static check approves a design or establishes `verified`.
 
 New specs use atomic `- **PRD-...**: <body>` / `- **SRS-...**: <body>` declarations, phase/task WBS headings with explicit Dependencies, Traceability, Tasks, and Acceptance checks, and `### ATP-...: <title>` scenarios under `## Acceptance Scenario Catalogue` with Setup, Procedure, Expected result, Minimum proof, and Traceability. Resolve progress columns by `WBS ID` and `Status` headers rather than fixed positions. Compatible legacy catalogue tables remain supported; matrices and evidence are not definitions. Report legacy gaps without silently rewriting business meaning. See [Repo Scripts](/reference/repo-scripts) for the active deterministic command contracts.

package/repo-docs/backend/controller-aop-guide.md

@@ -117,10 +117,10 @@ The global Passport guard is the baseline for controller actions: without a loca
 
 `@Passport.activated(...)` changes the activation requirement for an authenticated user:
 
-| Value | Requirement | Typical use |
-| --- | --- | --- |
-| `true` | The user must be activated; this is the default. | Ordinary protected actions. |
-| `false` | The user must **not** be activated. This does not mean “skip the check.” | An account-activation action. |
+| Value       | Requirement                                                                      | Typical use                                   |
+| ----------- | -------------------------------------------------------------------------------- | --------------------------------------------- |
+| `true`      | The user must be activated; this is the default.                                 | Ordinary protected actions.                   |
+| `false`     | The user must **not** be activated. This does not mean “skip the check.”         | An account-activation action.                 |
 | `'noCheck'` | Do not check activation state; both activated and unactivated users can proceed. | Logout, including for an unactivated account. |
 
 All three values still require authentication by default. An unauthenticated request is rejected; use `@Passport.public()` only if anonymous access is intended. A disabled account is still rejected regardless of the activation setting. The guard returns `403` when an authenticated user fails the account-status or activation check.