cabloy 5.1.194 → 5.1.196

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

@@ -5,67 +5,163 @@
       "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": [
+        "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.",
+        "Keeps target classes and approvals distinct."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Rejects unbounded suite implementation and proposes a finite target for approval.",
+        "No broad source changes or automatic progress advancement."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Preserves controlling authorization TODO, unaccepted ADR, and blocked failed gate.",
+        "Routes authority repair to generation; no source workaround."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Asks direct fileVersion strategy before migration edits.",
+        "Includes npm run test consequence if meta.version.ts changes."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Backend truth and OpenAPI precede generated consumer regeneration.",
+        "Refuses hand-editing generated API types."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Uses active Start source/commands, not Basic names.",
+        "Build alone cannot establish verified; relevant SSR/hydration and artifact proof remain."
+      ]
     },
     {
       "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": [
+        "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."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "No empty or invented evidence.",
+        "Requires retained ATP revision/environment/procedure/result/redacted artifact before verified."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Preserves historical proof and marks changed assumptions superseded/requiring rerun.",
+        "Does not carry verified status across invalidated proof."
+      ]
     },
     {
       "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": "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": []
+      "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"
+      ],
+      "expectations": [
+        "With complete input, refreshes both charts after progress and checks freshness.",
+        "Chart status/model pass is not authority approval or ATP evidence."
+      ]
     },
     {
       "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": [
+        "files/scenarios.json"
+      ],
+      "expectations": [
+        "Authority conflict routes to generation, not SVG hand edit.",
+        "Stops or re-confirms changed scope before continued execution."
+      ]
+    },
+    {
+      "id": 12,
+      "prompt": "Prepare the execution dossier for one bounded task that creates a new independent SSR tuple. Its concrete design has passed active framework/collision checks and the governing ADR is Accepted; cite and verify those records rather than trusting this sentence. Future site source and its planned wrapper do not exist yet. Ask separately for execution approval, then create only the approved tuple/wrapper boundary before observing and running the paired command.",
+      "expected_output": "Uses approved-new semantics without demanding pre-existing future source, verifies design/check/ADR authority, preserves the execution approval gate, and treats the wrapper as a planned addition until created and observed.",
+      "expectations": [
+        "Verifies actual accepted design/check records; fixture assertion alone is insufficient.",
+        "Future source absence alone does not block a correctly approved creation task.",
+        "No creation before bounded execution dossier approval.",
+        "Wrapper creation/manifest observation precedes command execution.",
+        "Controlling TODOs and unrelated blocked gates remain intact."
+      ],
+      "files": [
+        "files/scenarios.json"
+      ]
+    },
+    {
+      "id": 13,
+      "prompt": "For a bounded task in an explicitly lightweight or legacy spec set, preserve its controlling TODO/ADR/blocked gates. Chart inputs are incomplete. Do not invent missing business definitions, rewrite the suite baseline, or claim chart freshness. Show which authority/evidence gates block execution and which chart omission is merely a missing derived input.",
+      "expected_output": "Separates task-authority readiness from chart-input omission, preserves controlling gates, reports exact missing input, and routes needed authority repair to generation without forcing charts or changing legacy business meaning.",
+      "expectations": [
+        "Conditional chart branch names incomplete inputs rather than requiring fake definitions.",
+        "Controlling TODO, unaccepted ADR, and blocked status still prevent execution.",
+        "No legacy business rewrite or fabricated chart/evidence success.",
+        "Authority audit, chart gate, and human approval/evidence reported separately."
+      ],
+      "files": [
+        "files/scenarios.json"
+      ]
     }
   ]
 }

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

@@ -0,0 +1,84 @@
+{
+  "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": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 2,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 3,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 4,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 5,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 6,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 7,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 8,
+      "facts": [
+        "No retained ATP artifact exists."
+      ]
+    },
+    {
+      "id": 9,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 10,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 11,
+      "facts": [
+        "No approvals implied by the prompt; inspect actual suite authority and active source."
+      ]
+    },
+    {
+      "id": 12,
+      "facts": [
+        "Approved-new assertions must be corroborated by actual authority/source checks.",
+        "No execution dossier approval yet; future wrapper is a planned addition."
+      ]
+    },
+    {
+      "id": 13,
+      "facts": [
+        "Chart inputs incomplete; controlling authority gates are intentionally unresolved."
+      ]
+    }
+  ]
+}

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

@@ -0,0 +1,9 @@
+# Execution Skill Evaluation Protocol
+
+Follow the [shared two-phase protocol](../../cabloy-spec-generation/evals/protocol.md) with this bundle's `evals.json` and `files/scenarios.json`.
+
+Read synthetic scenario facts normally, then inspect the active repository, scripts, selected suite authority, target WBS, dependencies, and evidence. Fixtures cannot replace actual source, accepted ADRs, collision checks, commands, or retained proof.
+
+Phase A produces discovery/readiness findings and the bounded dossier without implementation, verification, or status writes. Phase B supplies missing decisions and separately confirms the execution dossier across recorded follow-up turns. Generation approval and design/ADR acceptance do not substitute for execution approval. A new wrapper must be created and observed before it is run.
+
+Record expectation outcomes, actual tool/file effects, preserved controlling gates, retained proof, status, chart eligibility/freshness, and one bounded next action. Static parser/audit/chart/governance tests do not establish behavioral eval success. Unrun turns or missing actual evidence remain not run/blocked. Do not create a broad runner or use these cases as permission for unsafe operations.

package/repo-agent-governance/skills/cabloy-spec-execution/references/execution-protocol.md

@@ -15,7 +15,19 @@ find . -maxdepth 1 \( -name '__CABLOY_BASIC__' -o -name '__CABLOY_START__' \) -p
 
 Then inspect the root `package.json`, `repo-agent-governance/` (or the active generated adapter), the suite spec directory, and actual affected source paths. Classify the worktree as clean, dirty with unrelated changes, dirty with overlapping changes, or otherwise unknown. Do not clean or reset it to make execution easier.
 
-For Basic, resolve current scripts, sites, flavors, UI, and generated paths from the active repository. For Start, inspect the active Start repository and use its own commands and flavor/site names. The shared execution model does not make edition-specific runtime facts interchangeable.
+Exactly one edition marker is required before edition-specific work. Both markers mean stop as invalid/ambiguous; neither means inspect the owning package/structure and ask. For Basic or Start, resolve scripts, sites, UI, flavors, and generated paths from that active repository. Shared workflow does not make runtime facts interchangeable.
+
+## Target semantics
+
+Apply the same classes used by generation:
+
+- **Observed existing**: cite inspected source/configuration/manifest and the owner.
+- **Proposed new**: design approval, framework/collision checks, or ADR acceptance is missing; creation stays gated.
+- **Explicitly approved new**: concrete design passed framework/collision checks, user explicitly approved it, and governing ADR is `Accepted`. A separately approved bounded WBS task can create its future source. Do not require a deliberately new target to exist already.
+
+For a new independent site, verify the site ID/public-path collisions, exclusive root-path owner, flavor/composition, SSR admission/profile, site module/registration, bundle/release identity, generated REST package/import, durable manifests, and paired commands together. Cite checked framework surfaces and accepted design authority. A shared target still requires an observed owner.
+
+A new wrapper is a planned addition until implementation creates it in the durable manifest. Observe its resulting definition and SSR/REST pairing before running it. Neither tuple design nor generation approval is execution approval. Keep controlling TODOs, unaccepted ADRs, and blocked gates; absence of future source alone is not one of those gates.
 
 ## 2. Target selection
 
@@ -41,7 +53,9 @@ Read in this order:
 3. complete WBS task and dependency rows;
 4. linked ATP definitions and test-plan release gates;
 5. progress, blockers, waivers, and next proof;
-6. linked evidence, phase indexes, runbooks, presentation contracts, rollout records, and the two derived implementation charts; verify their freshness with `npm run spec:charts:check -- <suite>`.
+6. linked evidence, indexes, runbooks, presentation/rollout records, and applicable derived charts. With complete supported chart inputs, check freshness using `npm run spec:charts:check -- <suite>`; otherwise report the precise legacy/lightweight gap.
+
+Run the applicable authority audit (`npm run spec:check -- <suite>`; `--lightweight` only for agreed limited scope). Keep definition/reference/chain/link audit, chart model/freshness, and human approval/evidence review separate. Compatible legacy catalogue tables remain definitions only in their owning catalogue role; matrices/evidence do not define records. Do not invent business declarations to repair a tool gap.
 
 Before implementation, verify:
 
@@ -52,7 +66,7 @@ Before implementation, verify:
 - the selected task is not already `verified`, `deferred`, or `blocked`;
 - source ownership and the target API/state/page boundary are unambiguous;
 - current evidence is still valid for the current source revision and authority set;
-- both implementation charts are present and current, or their regeneration is included in the approved record-update scope;
+- with complete supported inputs, both charts are current or regeneration is in approved scope; with incomplete inputs, the omission is explicit and does not conceal a controlling task-authority gap;
 - dirty-worktree changes can be attributed without overwriting unrelated work;
 - tenant, identity, authorization, ownership, privacy, lifecycle, transaction, concurrency, idempotency, audit, and recovery constraints are defined for the task’s risk;
 - the requested change does not broaden scope or create a competing persistence, identity, or API authority.
@@ -100,7 +114,9 @@ Specialist route: <backend/frontend/contract-loop/specialist>
 Safety/contract constraints: <tenant, auth, lifecycle, transaction, SSR, migration, privacy>
 Verification: <exact approved ATP procedures and commands>
 Evidence: <required revision/environment/procedure/result/redacted artifact>
-Derived charts: regenerate `implementation-gantt.svg` and `implementation-burndown.svg` after `progress.md`, then run `npm run spec:charts:check -- <suite>`; their language follows `README.md` and they remain non-authoritative.
+Target classes: <observed existing / proposed new / explicitly approved new; design checks, ADR and planned additions>
+Quality gates: <authority audit; chart input eligibility/model/freshness; human approval/evidence>
+Derived charts: with complete inputs, regenerate both after progress or README title/language changes, then run spec:charts:check; otherwise name the input gap. They remain non-authoritative.
 Allowed record updates: <evidence/phase index/progress/derived charts, or explicitly named authority change>
 Blocked or unresolved: <TODOs, waivers, conflicts>
 Excluded operations: <init/reset/deploy/provider/etc.>
@@ -127,7 +143,7 @@ Start with the narrowest meaningful check, then execute linked ATP procedures an
 
 Stop and report rather than guessing when:
 
-- a command or path is not observed in the active repository;
+- a command to run is not yet observed, or a creation path lacks the explicit approved-new design/ADR/execution boundary; future source absence alone is not a blocker for an approved creation task;
 - a test fails or a required artifact is missing;
 - the working tree becomes attribution-ambiguous;
 - a specialist discovers a requirement or contract change;

package/repo-agent-governance/skills/cabloy-spec-execution/references/status-and-evidence.md

@@ -12,9 +12,11 @@ For ordinary execution that does not change authority:
 2. update a dedicated phase/ATP evidence record when the suite convention supports it;
 3. update a rollout or operational handoff record when it is part of the established suite flow;
 4. update `progress.md` with derived status, evidence pointers, blockers, and next proof;
-5. regenerate `implementation-gantt.svg` and `implementation-burndown.svg` last, then run `npm run spec:charts:check -- <suite>`.
+5. with complete supported README/WBS/ATP/progress inputs, regenerate both charts last, then run `npm run spec:charts:check -- <suite>`; otherwise report the exact lightweight/legacy omission rather than forcing definitions.
 
-The charts are derived views only. Refresh them after status, review-date, evidence-pointer, or evidence-supersession changes that affect their display; do not edit them to conceal an authority conflict. Their labels, accessibility text, and metadata follow the suite `README.md` language.
+Refresh applicable charts after display-affecting status/evidence/review changes and README title/language edits. Labels, accessibility, and metadata follow README language. Charts cannot conceal authority conflicts.
+
+Keep `spec:check` definition/reference/chain/link validation, chart model/freshness, and human approval/evidence as independent gates. A static pass is not ATP proof or ADR/execution acceptance. A legacy definition gap requires an approved authority repair, not an invented business contract or a matrix/evidence mention promoted into a definition.
 
 Some Basic suites retain observed evidence inline in `test-plan.md`. Preserve the existing convention rather than introducing duplicate evidence stores. If the procedure, expected result, evidence requirement, release gate, or delivery scope changes, update the owning authority first and then reassess existing evidence before updating progress.
 
@@ -88,7 +90,7 @@ Do not trust a later progress summary over a contradictory, more recent ATP/arti
 
 ## Progress update contract
 
-Update only the selected task/phase’s derived fields unless an authority change was explicitly approved:
+Locate `WBS ID` and `Status` by header names in the execution register, not fixed cell positions; preserve other/reordered columns and require unique selected rows. Update only the selected task/phase’s derived fields unless an authority change was explicitly approved:
 
 - current status;
 - last reviewed revision/date;