cabloy 5.1.150 → 5.1.152

package/.cabloy-version

@@ -1 +1 @@
-5.1.150
+5.1.152

package/.claude/commands/release.md

@@ -6,7 +6,14 @@ version: 1.0.0
 
 # Cabloy Release
 
-Run the release workflow for the cabloy package. The release script at `scripts/release.ts` performs 4 steps:
+This command applies only when the active checkout is unambiguously Cabloy Basic and its root `package.json` exposes the public `cabloy` release scripts. First inspect the repository-root edition markers and the active root script surface:
+
+- only `__CABLOY_BASIC__` present and the required `release*` scripts available → continue with this workflow;
+- only `__CABLOY_START__` present → stop: do not use this public release workflow or `scripts/release.ts`; use an explicitly configured Cabloy Start release workflow instead;
+- both markers or neither marker present → stop before choosing an edition-specific release path;
+- required Basic release scripts absent → stop and ask for the active release workflow rather than inferring one.
+
+The release script at `scripts/release.ts` performs 4 steps for the public `cabloy` package:
 
 1. **Version bump** — Detects changes since last `cabloy@*` tag, bumps `package.json` version, commits + tags + pushes
 2. **AI Changelog** — Calls Anthropic API to summarize commits into categorized changelog, writes to `CHANGELOG.md`
@@ -15,6 +22,8 @@ Run the release workflow for the cabloy package. The release script at `scripts/
 
 ## Commands
 
+Only after the Basic preflight above succeeds, use the matching script that exists in the active root `package.json`:
+
 | Command | Description |
 |---------|-------------|
 | `pnpm release-patch` | Full release with patch version bump |
@@ -26,6 +35,8 @@ Run the release workflow for the cabloy package. The release script at `scripts/
 | `pnpm release:publish` | Only publish to npm |
 | `pnpm release:github` | Only create GitHub release |
 
+Do not infer equivalent commands in Cabloy Start when this table is absent from its package scripts.
+
 ## CLI Options
 
 | Option | Description |

package/.claude/hooks/contract-loop-gate.ts

@@ -42,6 +42,11 @@ type ReverseSyncOutcome =
 
 type SyncState = Record<string, SyncStateEntry>;
 
+type EditionResolution =
+  | { kind: 'resolved'; edition: EditionConfig }
+  | { kind: 'ambiguous' }
+  | { kind: 'missing' };
+
 const SCRIPT_FILE = fileURLToPath(import.meta.url);
 const ROOT = path.resolve(path.dirname(SCRIPT_FILE), '../..');
 const ROOT_KEY = toPosixPath(ROOT);
@@ -102,7 +107,9 @@ const EDITION_CONFIGS: Record<'basic' | 'start', EditionConfig> = {
   },
 };
 
-const ACTIVE_EDITION = resolveEdition();
+const ACTIVE_EDITION_RESOLUTION = resolveEdition();
+const ACTIVE_EDITION =
+  ACTIVE_EDITION_RESOLUTION.kind === 'resolved' ? ACTIVE_EDITION_RESOLUTION.edition : null;
 const FALLBACK_REVERSE_VONA_CONTENT_MARKERS = [
   ...SHARED_REVERSE_VONA_CONTENT_MARKERS,
   ...EDITION_CONFIGS.basic.reverseVonaContentMarkers,
@@ -123,14 +130,12 @@ function normalizePath(value?: string): string | null {
   }
 }
 
-function resolveEdition(): EditionConfig | null {
-  if (existsSync(path.resolve(ROOT, '__CABLOY_BASIC__'))) {
-    return EDITION_CONFIGS.basic;
-  }
-  if (existsSync(path.resolve(ROOT, '__CABLOY_START__'))) {
-    return EDITION_CONFIGS.start;
-  }
-  return null;
+function resolveEdition(): EditionResolution {
+  const hasBasic = existsSync(path.resolve(ROOT, '__CABLOY_BASIC__'));
+  const hasStart = existsSync(path.resolve(ROOT, '__CABLOY_START__'));
+  if (hasBasic && hasStart) return { kind: 'ambiguous' };
+  if (!hasBasic && !hasStart) return { kind: 'missing' };
+  return { kind: 'resolved', edition: hasBasic ? EDITION_CONFIGS.basic : EDITION_CONFIGS.start };
 }
 
 function getReverseVonaContentMarkers(edition: EditionConfig | null): readonly string[] {
@@ -290,7 +295,11 @@ function autoSyncReverse(filePath: string, edition: EditionConfig): ReverseSyncO
 
 function buildReverseGuidance(edition: EditionConfig | null): string {
   if (!edition) {
-    return 'If backend tooling or backend metadata will consume this handoff, refresh generated metadata when applicable, resolve the active Cabloy edition marker before choosing the relevant Zova build and generated-output path, and then run `npm run deps:vona`.';
+    const resolutionMessage =
+      ACTIVE_EDITION_RESOLUTION.kind === 'ambiguous'
+        ? 'Both Cabloy edition markers are present, so stop before choosing an edition-specific build or generated-output path.'
+        : 'No Cabloy edition marker is present, so inspect the active package scripts and repository shape before choosing an edition-specific build or generated-output path.';
+    return `If backend tooling or backend metadata will consume this handoff, refresh generated metadata when applicable. ${resolutionMessage} Then run \`npm run deps:vona\` once the active edition is resolved.`;
   }
 
   const autoSyncCommands = edition.reverseAutoSyncCommands
@@ -319,18 +328,21 @@ function resolveReverseSyncOutcome(
     };
   }
 
-  if (shouldSkipAutoSync(filePath)) {
+  if (!edition) {
+    const reason =
+      ACTIVE_EDITION_RESOLUTION.kind === 'ambiguous'
+        ? 'both Cabloy edition markers are present'
+        : 'no Cabloy edition marker is present';
     return {
-      kind: 'skipped',
-      message: 'Auto-sync skipped because the same reverse-source edit was already synced recently in this repo.',
+      kind: 'not-applicable',
+      message: `Auto-sync did not run because ${reason}.`,
     };
   }
 
-  if (!edition) {
+  if (shouldSkipAutoSync(filePath)) {
     return {
-      kind: 'not-applicable',
-      message:
-        'Auto-sync did not run because the active Cabloy edition marker could not be resolved for this repo.',
+      kind: 'skipped',
+      message: 'Auto-sync skipped because the same reverse-source edit was already synced recently in this repo.',
     };
   }
 
@@ -344,6 +356,12 @@ function buildMessages(
 ): string {
   const messages = ["Contract-loop gate: this change may affect Cabloy's bidirectional contract loop."];
 
+  if (ACTIVE_EDITION_RESOLUTION.kind === 'ambiguous') {
+    messages.push(
+      'Both Cabloy edition markers are present, so stop before choosing an edition-specific build, generated-output path, or auto-sync action.',
+    );
+  }
+
   if (result.forwardReason) {
     messages.push(
       `Forward chain: ${result.forwardReason} If backend contract truth changed, verify the emitted OpenAPI/contract output and regenerate the frontend consumer path before considering the task done.`,

package/.claude/skills/cabloy-backend-scaffold/SKILL.md

@@ -25,9 +25,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then classify the request:
 

package/.claude/skills/cabloy-backend-scaffold/references/follow-up-checklist.md

@@ -50,7 +50,7 @@ When the active edition and installed modules provide `@Passport.rbac(...)` and
 - keep the dependency graph acyclic and free of duplicate edges; do not declare both forms for the same edge because propagation is transitive and current runtime collection does not deduplicate targets
 - when `modelsClearedByFn` is required, treat it as replacement behavior and explicitly own the target clear and any necessary downstream propagation
 - prefer normal Model/service mutation paths so source invalidation, commit-time re-clear, and configured double-delete remain active
-- add a warm-query → mutate-source → repeat-query regression test for each new dependency path; read [Vona Cross-Model Query-Cache Dependencies](../../../../repo-docs-internal/architecture/vona-cross-model-query-cache-dependencies.md) for the source-backed decision rules
+- add a warm-query → mutate-source → repeat-query regression test for each new dependency path; follow [Cross-model query-cache dependencies](../../../../repo-docs/backend/cache-guide.md#cross-model-query-cache-dependencies) for the portable decision rules
 - transaction behavior
 
 ## Test resource lifecycle follow-up

package/.claude/skills/cabloy-contract-loop/SKILL.md

@@ -53,9 +53,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then classify whether the task is really a contract-loop task.
 

package/.claude/skills/cabloy-domain-planning/SKILL.md

@@ -26,9 +26,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 This matters most when examples, frontend flavors, or suite/module availability may differ between editions.
 

package/.claude/skills/cabloy-frontend-scaffold/SKILL.md

@@ -25,9 +25,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then classify the request:
 

package/.claude/skills/cabloy-master-detail/SKILL.md

@@ -27,9 +27,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then classify the request into one of these entry shapes.
 

package/.claude/skills/cabloy-module-removal/SKILL.md

@@ -26,9 +26,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then classify the request into one of three branches:
 
@@ -128,7 +129,7 @@ Ask or confirm whether the task is:
 - code/runtime removal only
 - code/runtime removal plus docs/examples scrub
 
-If docs cleanup is in scope, update `repo-docs/` separately from the runtime cleanup and keep maintainer rationale in `repo-docs-internal/`.
+If docs cleanup is in scope, update `repo-docs/` separately from the runtime cleanup. When an established `repo-docs-internal/` home exists, keep maintainer rationale there; otherwise do not create or require that path as part of module removal.
 
 ## Response pattern
 

package/.claude/skills/cabloy-resource-field-update/SKILL.md

@@ -36,9 +36,10 @@ Check the repository root for these marker files:
 
 Interpretation:
 
-- `__CABLOY_BASIC__` present → this is Cabloy Basic
-- `__CABLOY_START__` present → this is Cabloy Start
-- neither present → inspect nearby scripts and ask before making edition-specific assumptions
+- only `__CABLOY_BASIC__` present → this is Cabloy Basic
+- only `__CABLOY_START__` present → this is Cabloy Start
+- both markers present → treat the repository as ambiguous or invalid and stop before making edition-specific assumptions
+- neither marker present → inspect the owning package scripts and nearby repository structure, then ask before making an edition-specific assumption
 
 Then confirm the request is about an **existing** resource field.
 
@@ -211,10 +212,12 @@ In Cabloy Basic, prefer `placeholder` over artificial empty-item injection when
 
 If the user explicitly wants to **demonstrate** the custom renderer workflow, branch into a frontend follow-up path.
 
-Use these references:
+Use these portable references:
 
 - `references/custom-renderer-demo-checklist.md`
-- `repo-docs-internal/architecture/backend-resource-field-workflow.md`
+- [Existing Resource Field Update](../../../repo-docs/backend/resource-field-update.md)
+
+When an active repository provides `repo-docs-internal/architecture/backend-resource-field-workflow.md`, it may be consulted as optional maintainer rationale. Its absence must not block or alter this shared workflow.
 
 Recommended shape:
 

package/.claude/skills/cabloy-spec-execution/SKILL.md

@@ -0,0 +1,169 @@
+---
+name: cabloy-spec-execution
+description: Use this skill whenever the user asks to implement, execute, deliver, verify, or close a task from an existing Cabloy suite specification, including requests such as “implement WBS-…”, “execute the approved phase”, “deliver the next spec task”, or “make the repo-specs plan real”. It coordinates one bounded WBS increment through the existing backend, frontend, and contract-loop skills, then records evidence-backed derived status. Require an explicit WBS task ID or a finite, explicitly approved phase; do not use it to invent requirements, resolve suite identity, replace cabloy-spec-generation, duplicate scaffold procedures, or perform unapproved destructive, deployment, or provider operations.
+---
+
+# Cabloy Spec Execution
+
+Use this skill as the control plane for delivering an already-approved suite specification. It turns one bounded WBS item into an implementation, verification, evidence, and progress handoff without becoming a second product authority.
+
+## Goals
+
+1. detect the active Cabloy edition and repository state before making implementation or command assumptions;
+2. select only an explicit, bounded, dependency-ready WBS increment;
+3. preserve PRD, SRS, ADR, WBS, and test-plan authority while routing technical work to the existing specialist skills;
+4. require scoped verification and durable redacted evidence before claiming `verified`;
+5. leave a resumable status and next-proof handoff without silently advancing neighboring work.
+
+Read these references before executing or substantially updating an increment:
+
+- `references/execution-protocol.md` for discovery, dossier, gates, routing, and safe-operation boundaries;
+- `references/status-and-evidence.md` for evidence retention, status transitions, supersession, and progress updates.
+
+## Step 1: Detect repository and edition
+
+From the active repository root, inspect:
+
+1. `git rev-parse --show-toplevel`, `git status --short`, current `HEAD`, and the working-tree classification;
+2. `__CABLOY_BASIC__` or `__CABLOY_START__`;
+3. root `package.json` and `CLAUDE.md`;
+4. the target `repo-specs/<suite>/` directory and relevant source/module topology.
+
+Interpret the markers as follows:
+
+- `__CABLOY_BASIC__` present: use Basic source, scripts, flavors, UI, and SSR facts only when observed;
+- `__CABLOY_START__` present: resolve Start-specific scripts, flavor/site names, paths, UI, and SSR behavior from the active Start repository;
+- neither present: stop before edition-specific execution and ask the user to confirm the repository context.
+
+A PostToolUse hook or an automatic build is convenience assistance, not evidence that the task is synchronized or verified. The deterministic chart commands are `npm run spec:charts -- <suite>` and `npm run spec:charts:check -- <suite>`; they validate derived-view freshness, not implementation or ATP completion.
+
+## Step 2: Require and classify the execution target
+
+Require one of:
+
+- an explicit WBS task identifier such as `WBS-ABC-20-01`;
+- a finite phase whose included WBS tasks and closure boundary are explicitly named and approved.
+
+Do not interpret “implement the suite”, “finish everything”, or “execute the next phase” as a sufficiently bounded target. Ask for the exact task or enumerate a finite candidate set and obtain approval before implementation.
+
+Classify the target:
+
+- **backend increment**: Vona module, bean, service, model, entity, DTO, validation, migration, or backend test;
+- **frontend increment**: Zova page, component, route, model, metadata, SSR, or frontend test;
+- **contract increment**: OpenAPI, DTO consumer, generated SDK/schema, reverse metadata handoff, or consumer-drift diagnosis;
+- **verification/closure increment**: an ATP, evidence, phase closure, or release gate explicitly defined by the test plan;
+- **authority change**: a requirement, contract, dependency, scope, or durable decision change. Stop and route this to `cabloy-spec-generation` or `cabloy-domain-planning` before execution.
+
+If a task maps to a more specialized Cabloy skill such as `cabloy-master-detail`, `cabloy-resource-field-update`, or `cabloy-module-removal`, use that specialist rather than flattening its procedure into this skill.
+
+## Step 3: Read the spec authority set
+
+Read the suite records in this order:
+
+1. `README.md` for identity, reading order, topology, and authority map;
+2. `prd.md`, `srs.md`, and applicable accepted/proposed ADRs for product and technical authority;
+3. `pdp-wbs.md` for the complete selected task, dependencies, source areas, exclusions, completion checks, and linked IDs;
+4. `test-plan.md` for linked `ATP-*` procedures, fixture/cleanup rules, evidence requirements, and release gates;
+5. `progress.md` for current derived state, blockers, waivers, prior evidence, superseded proof, and next action;
+6. linked evidence, phase indexes, presentation contracts, rollout records, or provider runbooks when referenced;
+7. `implementation-gantt.svg` and `implementation-burndown.svg` as derived views; check their freshness rather than treating them as authority.
+
+Do not trust the first status statement found in a historical record. Reconcile revision, chronology, supersession, and the authoritative current progress row before deciding readiness.
+
+## Step 4: Build and confirm an execution dossier
+
+Before implementation, present a concise dossier containing:
+
+- detected edition, repository root, suite, target WBS ID/finite phase, current revision, and clean/dirty working-tree classification;
+- linked `PRD-*`, `SRS-*`, `ATP-*`, ADR, and evidence records;
+- dependencies and their actual status/proof;
+- source-of-truth paths, proposed paths, ownership boundaries, and specialist skill route;
+- applicable tenant, identity, authorization, ownership, lifecycle, transaction, concurrency, idempotency, audit, privacy, SSR, migration, and contract-loop constraints;
+- exact scoped verification procedures and expected evidence;
+- records permitted to change (`progress.md`, evidence/phase index, derived implementation charts, and only other records whose established convention requires it);
+- remaining blockers, `TODO(confirm)` decisions, unsafe actions intentionally excluded, and one next action.
+
+Keep observed repository facts separate from target contracts. Require explicit user confirmation of this dossier before making source changes, running meaningful verification, or writing evidence/status updates. Do not treat silence as approval.
+
+## Step 5: Apply readiness gates
+
+Stop and route back to the relevant planning authority if any of the following applies:
+
+- the suite identity, ownership, or target boundary is unresolved;
+- PRD/SRS/ADR/WBS/test-plan records contradict one another;
+- a controlling `TODO(confirm)` or unaccepted ADR remains;
+- a predecessor is not complete according to the WBS, or its required evidence is absent;
+- the selected task is already `verified`, explicitly `deferred`, or currently `blocked`;
+- a persisted field/schema change lacks an explicit decision about incrementing `vonaModule.fileVersion`;
+- the working tree contains overlapping unclassified changes that make attribution or rollback unclear;
+- authorization, tenant isolation, privacy, lifecycle, transaction, concurrency, idempotency, or ownership behavior is unspecified for a material risk;
+- the requested work would expand scope or silently create a competing persistence, identity, or API authority.
+
+A task may be marked `in-progress` only when approved execution actually starts. Do not edit progress merely to reserve a task.
+
+## Step 6: Route the approved increment
+
+After confirmation, route the smallest coherent implementation unit:
+
+- Vona implementation -> `cabloy-backend-scaffold`;
+- Zova implementation -> `cabloy-frontend-scaffold`;
+- Vona/Zova contract synchronization, generated consumers, reverse metadata handoff, or stale consumer diagnosis -> `cabloy-contract-loop`;
+- master-detail, resource-field, or module-removal shape -> the corresponding specialized skill;
+- test-only/closure work -> follow the selected ATP and repository test ownership, without inventing a new test authority.
+
+Keep the specialist’s CLI-first and follow-up rules. Never hand-edit generated consumers. Do not automatically implement adjacent WBS items, choose unconfirmed routes/flavors, change requirements, commit/push, or invoke the next phase.
+
+## Step 7: Verify narrowly, then expand as required
+
+Start with the narrowest meaningful check for the selected task, then follow the linked ATP and release-gate requirements. Use only commands observed in the active repository and approved by the dossier.
+
+For contract-sensitive work:
+
+- forward chain: establish backend contract truth, inspect OpenAPI, regenerate Zova consumers, then perform thin frontend follow-up;
+- reverse chain: build the affected Zova flavor with both SSR and REST outputs, then run `npm run deps:vona`; build Web and Admin pairs when both are affected;
+- if generated artifacts are correct but installed Vona consumers remain stale, diagnose local dependency drift through `cabloy-contract-loop` rather than hand-patching generated files or reinstalling automatically.
+
+For SSR-sensitive work, verify server output and hydration-time initial render equivalence, privacy/admission behavior, and the exact active flavor/site contract. For backend tests, preserve separate `mockCtx(...)` boundaries for competing operations, explicit contention assertions, precise `finally` cleanup, and read-only managed seed behavior.
+
+A planned command, successful generation, code reading, manual walkthrough, screenshot, or unrelated broad test pass is not sufficient for `verified` unless the test plan explicitly defines it as adequate retained proof.
+
+## Step 8: Record evidence and derived status
+
+Record actual observed proof according to `references/status-and-evidence.md`. Prefer dedicated phase/ATP evidence records when the suite convention supports them; otherwise preserve the suite’s established inline test-plan convention. Update evidence first, then the derived progress register, and regenerate/check both implementation charts last. Use `npm run spec:charts -- <suite>` followed by `npm run spec:charts:check -- <suite>`; chart output remains derived and cannot repair an authority conflict.
+
+Set status accurately:
+
+- `in-progress` while work or verification remains open;
+- `implementation-complete` when source work is complete but ATP/release proof remains;
+- `verified` only after all applicable WBS checks and ATPs have durable linked redacted evidence;
+- `blocked`, `waived`, or `deferred` only with the required details.
+
+Do not create empty evidence records, fabricate `EVD-*` IDs, erase historical failures, or claim that a hook/build means verification passed. If changed source or authority invalidates old proof, mark it superseded or requiring rerun.
+
+## Step 9: Finish with a resumable handoff
+
+Report:
+
+1. target WBS/phase and detected edition;
+2. implementation files and commands actually changed/run;
+3. observed result and evidence locations, with secrets and sensitive data redacted;
+4. resulting status and the precise reason for it;
+5. blockers, decisions, or evidence still outstanding;
+6. one next proof/action only;
+7. refreshed `implementation-gantt.svg` and `implementation-burndown.svg`, README-derived chart language, and the chart check result.
+
+Do not automatically modify the next WBS item or claim release closure from feature-level verification.
+
+## Prohibited autonomous operations
+
+Unless a separate explicit workflow and confirmation authorizes them, do not:
+
+- run `npm run init`;
+- reset or recreate a database;
+- deploy, publish, cut over, or perform production/provider/webhook operations;
+- change credentials or retain secrets/raw tokens/signed callback state/live provider identifiers;
+- clean, reset, stash, checkout, or discard the working tree;
+- reinstall dependencies as a first response to drift;
+- scaffold broad source outside the approved WBS boundary;
+- commit or push;
+- mark implementation or verification complete without observed, traceable proof.

package/.claude/skills/cabloy-spec-execution/evals/evals.json

@@ -0,0 +1,71 @@
+{
+  "skill_name": "cabloy-spec-execution",
+  "evals": [
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    },
+    {
+      "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": []
+    }
+  ]
+}