Cabloy Spec Execution

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 repo-agent-governance/ (or the active generated adapter);
4. the target repo-specs/<suite>/ directory and relevant source/module topology.

Interpret the markers as follows:

• exactly __CABLOY_BASIC__: use observed Basic source, scripts, flavors, UI, and SSR facts;
• exactly __CABLOY_START__: resolve those facts from the active Start repository;
• both markers: stop; the checkout is invalid or ambiguous;
• neither: inspect the owning package/structure and ask before edition-specific execution.

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. applicable implementation charts as derived views: check freshness only with complete supported README/WBS/ATP/progress inputs; otherwise report the legacy/lightweight input gap without inventing business definitions.

Keep planning authority audit (npm run spec:check -- <suite>, with --lightweight only for agreed limited scope), chart model/freshness, and human approval/evidence as three independent gates. Static passes do not clear controlling TODOs, accept ADRs, or prove ATP execution.

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.

Classify targets as observed existing, proposed new, or explicitly approved new. An explicitly approved new site/flavor tuple may be created before target source exists when framework constraints and collisions were checked, the concrete design was explicitly approved, and its governing ADR is Accepted. Cite the design, planned paths/manifests, and creation prerequisites. A new wrapper remains a planned addition until created and observed; do not run it prematurely. Shared integration still needs an observed owner. Proposed/unchecked values and controlling TODOs remain gated.

Require explicit dossier approval before source changes, meaningful verification, or evidence/status updates. Generation approval, design/ADR acceptance, and this execution approval are separate; silence is not 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 neither verified nor formally opted-in planning-complete with a named-reviewer, revision-scoped documentary closure disposition, or its required evidence is absent; a planning-complete edge does not authorize execution;
• the selected task is already verified or planning-complete, 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.