cabloy 5.1.190 → 5.1.192

package/{.claude → repo-agent-governance}/skills/cabloy-contract-loop/references/contract-loop-map.md

@@ -98,10 +98,10 @@ One persisted domain may deliberately own both conventional Admin Resource opera
 
 After generation, choose the consumer shape by boundary:
 
-| Consumer | Generated-contract follow-up |
-| --- | --- |
-| Admin custom operation with the same authority, projection, and Resource page semantics | thin module facade → `rest-resource.model.resource` → schema-driven Resource UI |
-| Web self-service operation with different authority, server-derived owner scope, DTO projection, or page/SSR semantics | dedicated Web model → purpose-built self-service pages |
+| Consumer                                                                                                               | Generated-contract follow-up                                                    |
+| ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |
+| Admin custom operation with the same authority, projection, and Resource page semantics                                | thin module facade → `rest-resource.model.resource` → schema-driven Resource UI |
+| Web self-service operation with different authority, server-derived owner scope, DTO projection, or page/SSR semantics | dedicated Web model → purpose-built self-service pages                          |
 
 The Web model is valid only for the separate self-service state domain. It must not become a parallel owner for Admin `select`/`view`, schemas, permissions, or generic Resource page state. See `../../../../repo-docs/fullstack/admin-resource-and-web-self-service.md` for the complete architecture.
 

package/{.claude → repo-agent-governance}/skills/cabloy-master-detail/SKILL.md

@@ -207,4 +207,4 @@ When helpful, structure the response around these points:
 5. nested DTO naming and placement reminders
 6. verification steps
 
-Keep the response practical. The value of this skill is to route master-detail requests into the correct generator-first workflow while preserving the recursive ownership rules encoded by the current source.
+Keep the response practical. The value of this skill is to route master-detail requests into the correct generator-first workflow while preserving the recursive ownership rules encoded by the current source.

package/{.claude → repo-agent-governance}/skills/cabloy-module-removal/SKILL.md

@@ -142,4 +142,4 @@ When using this skill, structure the response around these points when helpful:
 5. stale-generated-runtime recovery branch if needed
 6. verification steps
 
-Keep the response practical. The value of this skill is to choose the right removal branch quickly and keep generated working state in the correct role.
+Keep the response practical. The value of this skill is to choose the right removal branch quickly and keep generated working state in the correct role.

package/{.claude → repo-agent-governance}/skills/cabloy-spec-execution/SKILL.md

@@ -26,7 +26,7 @@ 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`;
+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:

package/{.claude → repo-agent-governance}/skills/cabloy-spec-execution/references/execution-protocol.md

@@ -13,7 +13,7 @@ git rev-parse HEAD
 find . -maxdepth 1 \( -name '__CABLOY_BASIC__' -o -name '__CABLOY_START__' \) -print
 ```
 
-Then inspect the root `package.json`, `CLAUDE.md`, 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.
+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.
 
@@ -111,13 +111,13 @@ Require explicit confirmation. If the user changes scope, rebuild the dossier an
 
 ## 6. Specialist routing
 
-| Task shape | Primary route | Coordinator must preserve |
-| --- | --- | --- |
-| Vona module/bean/service/model/entity/DTO/validation/migration/test | `cabloy-backend-scaffold` | CLI-first generation, tenant/security review, migration/index/version gate, tests, OpenAPI impact |
-| Zova page/component/route/model/metadata/SSR/test | `cabloy-frontend-scaffold` | route metadata, state ownership, hydration equivalence, emitted import suffixes, flavor/site proof |
-| OpenAPI, SDK/schema, generated consumer, reverse metadata, stale consumer | `cabloy-contract-loop` | source-first direction, paired SSR/REST reverse build, `deps:vona`, no hand edits |
-| master-detail, resource-field, module removal | corresponding specialist skill | specialized ownership and cleanup order |
-| requirement, architecture, scope, identity, or authority change | `cabloy-spec-generation` / `cabloy-domain-planning` | no implementation around unresolved authority |
+| Task shape                                                                | Primary route                                       | Coordinator must preserve                                                                          |
+| ------------------------------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
+| Vona module/bean/service/model/entity/DTO/validation/migration/test       | `cabloy-backend-scaffold`                           | CLI-first generation, tenant/security review, migration/index/version gate, tests, OpenAPI impact  |
+| Zova page/component/route/model/metadata/SSR/test                         | `cabloy-frontend-scaffold`                          | route metadata, state ownership, hydration equivalence, emitted import suffixes, flavor/site proof |
+| OpenAPI, SDK/schema, generated consumer, reverse metadata, stale consumer | `cabloy-contract-loop`                              | source-first direction, paired SSR/REST reverse build, `deps:vona`, no hand edits                  |
+| master-detail, resource-field, module removal                             | corresponding specialist skill                      | specialized ownership and cleanup order                                                            |
+| requirement, architecture, scope, identity, or authority change           | `cabloy-spec-generation` / `cabloy-domain-planning` | no implementation around unresolved authority                                                      |
 
 The coordinator may pass the dossier to the specialist; it should not duplicate the specialist’s detailed command tree.
 

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

@@ -54,15 +54,15 @@ Do not create an empty `evidence/` directory, placeholder `EVD-*` record, or fab
 
 Use the suite’s canonical status meanings:
 
-| Status | Meaning |
-| --- | --- |
-| `not-started` | Defined, but implementation or acceptance evidence has not started. |
-| `in-progress` | Work or verification has started, but closure checks remain. |
-| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete. |
-| `verified` | Applicable WBS checks and ATPs passed, with durable traceable evidence containing revision, environment, exact procedure, result, and redacted artifact location. |
-| `blocked` | A dependency, unresolved decision, failed gate, attribution problem, or missing required proof prevents closure. |
-| `waived` | A temporary exception has an owner, reason, affected scope, and expiry; expiry becomes a release blocker. |
-| `deferred` | Explicitly postponed scope; it is not complete or verified. |
+| Status                    | Meaning                                                                                                                                                           |
+| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `not-started`             | Defined, but implementation or acceptance evidence has not started.                                                                                               |
+| `in-progress`             | Work or verification has started, but closure checks remain.                                                                                                      |
+| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete.                                                                             |
+| `verified`                | Applicable WBS checks and ATPs passed, with durable traceable evidence containing revision, environment, exact procedure, result, and redacted artifact location. |
+| `blocked`                 | A dependency, unresolved decision, failed gate, attribution problem, or missing required proof prevents closure.                                                  |
+| `waived`                  | A temporary exception has an owner, reason, affected scope, and expiry; expiry becomes a release blocker.                                                         |
+| `deferred`                | Explicitly postponed scope; it is not complete or verified.                                                                                                       |
 
 The normal path is:
 

package/{.claude → repo-agent-governance}/skills/cabloy-spec-generation/SKILL.md

@@ -28,7 +28,7 @@ From the repository root, inspect:
 
 1. `git rev-parse --show-toplevel` and `git status --short`;
 2. `__CABLOY_BASIC__` and `__CABLOY_START__`;
-3. the root `package.json` and `CLAUDE.md`;
+3. the root `package.json` and `repo-agent-governance/` (or the active generated adapter);
 4. existing `repo-specs/` indexes and related suite/module topology;
 5. `npm run vona` and `npm run zova` when the records will cite implementation commands.
 
@@ -173,7 +173,7 @@ Optional records remain subordinate to the PRD/SRS/WBS/test-plan authority appro
 
 While drafting, preserve these principles and tailor them to confirmed scope:
 
-- `repo-specs/` is the product/business planning home; `repo-docs/` is public and agent-facing framework guidance; `repo-docs-internal/` holds supporting cross-suite maintainer rationale; `.claude/skills/` is workflow behavior; do not assume a particular internal record exists in every edition;
+- `repo-specs/` is the product/business planning home; `repo-docs/` is public and agent-facing framework guidance; `repo-docs-internal/` holds supporting cross-suite maintainer rationale; `repo-agent-governance/skills/` is authored workflow behavior; do not assume a particular internal record exists in every edition;
 - use suite-first ownership and distinguish new domain modules from reusable framework modules; do not duplicate an existing persistence or identity owner without a stated decision;
 - treat the active Vona instance as the tenant by default; do not introduce a store, organization, or merchant entity unless the confirmed domain contract requires it;
 - make identity, tenant scope, authorization, and ownership server-authoritative; menus, routes, browser filters, and UI visibility are not API authorization;

package/{.claude → repo-agent-governance}/skills/cabloy-spec-generation/references/repo-aware-discovery.md

@@ -78,13 +78,13 @@ Hand actual implementation-time synchronization to `cabloy-contract-loop`.
 
 ## Documentation boundaries
 
-| Content | Home |
-| --- | --- |
-| Product requirements, SRS contracts, WBS, ATPs, suite ADRs, delivery status | `repo-specs/<suite>/` |
-| Reusable user-facing or agent-facing framework guidance | `repo-docs/` |
-| Cross-suite maintainer architecture, rationale, and engineering ADRs | `repo-docs-internal/`; individual records may vary by edition |
-| Short durable AI operating rules | `CLAUDE.md` |
-| Reusable Claude procedure | `.claude/skills/` |
+| Content                                                                     | Home                                                          |
+| --------------------------------------------------------------------------- | ------------------------------------------------------------- |
+| Product requirements, SRS contracts, WBS, ATPs, suite ADRs, delivery status | `repo-specs/<suite>/`                                         |
+| Reusable user-facing or agent-facing framework guidance                     | `repo-docs/`                                                  |
+| Cross-suite maintainer architecture, rationale, and engineering ADRs        | `repo-docs-internal/`; individual records may vary by edition |
+| Short durable AI operating rules                                            | `repo-agent-governance/policies/`                             |
+| Reusable procedural workflow                                                | `repo-agent-governance/skills/`                               |
 
 Do not place suite product specifications in public docs, or copy repository-wide process rationale into every suite. Link to authoritative framework records instead.
 

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

@@ -24,18 +24,18 @@ The directory is repository-native, suite-local, and maintainer-facing. It is no
 
 ## Authority map
 
-| Document | Authority |
-| --- | --- |
-| `README.md` | Index, reading order, baseline summary, topology, authority map, and related-record links. It does not replace the other documents. |
-| `prd.md` | Product outcomes, personas, scope, journeys, business rules, product requirements, and product acceptance. |
-| `srs.md` | System contracts, capability/data ownership, APIs/DTOs, authorization, state, transactions, invariants, frontend/SSR boundaries, and technical acceptance. |
-| `pdp-wbs.md` | Delivery sequencing, dependencies, implementation tasks, completion checks, and delivery traceability. |
-| `test-plan.md` | Quality priorities, executable acceptance scenarios, fixtures, evidence format, verification procedures, and release proof. |
-| `progress.md` | Derived execution status, blockers, decisions needed, next proof, and evidence pointers. It never redefines requirements or contracts. |
-| `implementation-gantt.svg` | Deterministic derived WBS view of phases, task order, dependencies, status, and optional ATP labels. It is not schedule or planning authority. |
-| `implementation-burndown.svg` | Deterministic derived scope/status view. Without dated history, it is a scope-count reference, not a time-series, velocity trend, or forecast. |
-| `decisions/*.md` | Durable suite-local scope, architecture, security, ownership, migration, or integration decisions. |
-| `runbooks/*.md` | Operational procedures subordinate to the relevant SRS, ADR, WBS, and test plan. |
+| Document                      | Authority                                                                                                                                                  |
+| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `README.md`                   | Index, reading order, baseline summary, topology, authority map, and related-record links. It does not replace the other documents.                        |
+| `prd.md`                      | Product outcomes, personas, scope, journeys, business rules, product requirements, and product acceptance.                                                 |
+| `srs.md`                      | System contracts, capability/data ownership, APIs/DTOs, authorization, state, transactions, invariants, frontend/SSR boundaries, and technical acceptance. |
+| `pdp-wbs.md`                  | Delivery sequencing, dependencies, implementation tasks, completion checks, and delivery traceability.                                                     |
+| `test-plan.md`                | Quality priorities, executable acceptance scenarios, fixtures, evidence format, verification procedures, and release proof.                                |
+| `progress.md`                 | Derived execution status, blockers, decisions needed, next proof, and evidence pointers. It never redefines requirements or contracts.                     |
+| `implementation-gantt.svg`    | Deterministic derived WBS view of phases, task order, dependencies, status, and optional ATP labels. It is not schedule or planning authority.             |
+| `implementation-burndown.svg` | Deterministic derived scope/status view. Without dated history, it is a scope-count reference, not a time-series, velocity trend, or forecast.             |
+| `decisions/*.md`              | Durable suite-local scope, architecture, security, ownership, migration, or integration decisions.                                                         |
+| `runbooks/*.md`               | Operational procedures subordinate to the relevant SRS, ADR, WBS, and test plan.                                                                           |
 
 When records disagree, update the authoritative record first, then update downstream summaries, mappings, and derived status. After any change to `pdp-wbs.md`, `test-plan.md`, or `progress.md`, run `npm run spec:charts -- <suite>` followed by `npm run spec:charts:check -- <suite>`.
 
@@ -186,15 +186,15 @@ Use:
 
 Initialize a new suite with statuses such as `not-started`, `deferred`, or explicitly `blocked`; do not mark planning work as verified. Use this vocabulary:
 
-| Status | Meaning |
-| --- | --- |
-| `not-started` | Defined, but implementation or acceptance evidence has not started. |
-| `in-progress` | Work started, but closure checks are incomplete. |
-| `implementation-complete` | Source work is reported complete, but required ATP evidence or release gates are incomplete. |
-| `verified` | Required ATP evidence is observed and retained with revision, environment, procedure, result, and redacted artifact location. |
-| `blocked` | A dependency, unresolved decision, or failed gate prevents closure. |
-| `waived` | A temporary exception with owner, reason, and expiry; expiry makes it a release blocker. |
-| `deferred` | Explicitly postponed scope, not completed scope. |
+| Status                    | Meaning                                                                                                                       |
+| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
+| `not-started`             | Defined, but implementation or acceptance evidence has not started.                                                           |
+| `in-progress`             | Work started, but closure checks are incomplete.                                                                              |
+| `implementation-complete` | Source work is reported complete, but required ATP evidence or release gates are incomplete.                                  |
+| `verified`                | Required ATP evidence is observed and retained with revision, environment, procedure, result, and redacted artifact location. |
+| `blocked`                 | A dependency, unresolved decision, or failed gate prevents closure.                                                           |
+| `waived`                  | A temporary exception with owner, reason, and expiry; expiry makes it a release blocker.                                      |
+| `deferred`                | Explicitly postponed scope, not completed scope.                                                                              |
 
 Progress must remain a derived register. It may point to evidence but must not become a second requirements document. Include a decision-register entry for each material site strategy and show strategy/identifier deferral as a blocker only on affected frontend/site WBS branches; source reading, planning, or a selected strategy alone is not implementation evidence.
 
@@ -244,13 +244,13 @@ Use `Accepted` only for explicitly confirmed durable decisions; otherwise use `P
 
 Generate only when the confirmed scope requires them:
 
-| Extension | Generate when |
-| --- | --- |
-| `presentation-contracts.md` | Multiple Admin/resource scenes need stable audience, task, information-area, editability, snapshot, or renderer decisions. Keep it subordinate to PRD/SRS. |
-| `semantic-presentation-rollout.md` | Presentation/metadata work is staged, serial, resumable, and needs handoff gates. It does not replace WBS or test plan. |
-| `runbooks/<provider-or-operation>.md` | Real external provider/webhook, sandbox/live operation, reconciliation, cutover, incident, or deployment procedure is in scope. Never include secrets. |
-| Additional ADRs | A separate durable boundary or trade-off exists after ADR 0001. |
-| `evidence/` | Actual ATP execution has produced retained redacted evidence. Do not create empty evidence to simulate progress. |
+| Extension                             | Generate when                                                                                                                                              |
+| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `presentation-contracts.md`           | Multiple Admin/resource scenes need stable audience, task, information-area, editability, snapshot, or renderer decisions. Keep it subordinate to PRD/SRS. |
+| `semantic-presentation-rollout.md`    | Presentation/metadata work is staged, serial, resumable, and needs handoff gates. It does not replace WBS or test plan.                                    |
+| `runbooks/<provider-or-operation>.md` | Real external provider/webhook, sandbox/live operation, reconciliation, cutover, incident, or deployment procedure is in scope. Never include secrets.     |
+| Additional ADRs                       | A separate durable boundary or trade-off exists after ADR 0001.                                                                                            |
+| `evidence/`                           | Actual ATP execution has produced retained redacted evidence. Do not create empty evidence to simulate progress.                                           |
 
 For a presentation matrix, record audience, task, resource/scene, business information areas, field boundaries, renderer choice, and linked PRD/SRS/ATP records. It must not redefine API authority, persistence, validation, authorization, page/state ownership, or SSR privacy.
 
@@ -260,8 +260,8 @@ For an operational runbook, record environment boundaries, secret-management rul
 
 Every core document links to the README and relevant peers. Maintain a compact matrix like:
 
-| Product area | PRD | SRS | WBS | ATP | Evidence/status |
-| --- | --- | --- | --- | --- | --- |
+| Product area   | PRD       | SRS       | WBS       | ATP       | Evidence/status               |
+| -------------- | --------- | --------- | --------- | --------- | ----------------------------- |
 | `<capability>` | `PRD-...` | `SRS-...` | `WBS-...` | `ATP-...` | `progress.md` / evidence link |
 
 Every material product requirement needs at least one technical contract, delivery item, and executable acceptance scenario. Before reporting generation complete, statically audit exact-ID referential integrity and README/ADR decision-status consistency across the planning authority set. Exclude `evidence/` from this static audit: evidence is added only after execution.

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

@@ -64,15 +64,15 @@ Downstream records summarize or operationalize authority; they do not silently o
 
 ## Status semantics
 
-| Status | Meaning |
-| --- | --- |
-| `not-started` | Defined, but implementation or acceptance evidence has not started. |
-| `in-progress` | Work or verification has started, but closure checks are incomplete. |
-| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete. |
-| `verified` | Applicable WBS checks and ATPs passed, and durable evidence contains revision, environment, exact procedure, result, and redacted artifact location. |
-| `blocked` | A failed gate, dependency, or unresolved decision prevents closure. |
-| `waived` | A temporary exception explicitly approved with owner, reason, and expiry. |
-| `deferred` | Explicitly postponed scope; it is not complete or verified. |
+| Status                    | Meaning                                                                                                                                              |
+| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `not-started`             | Defined, but implementation or acceptance evidence has not started.                                                                                  |
+| `in-progress`             | Work or verification has started, but closure checks are incomplete.                                                                                 |
+| `implementation-complete` | Source work is reported complete, but required ATP or release evidence is incomplete.                                                                |
+| `verified`                | Applicable WBS checks and ATPs passed, and durable evidence contains revision, environment, exact procedure, result, and redacted artifact location. |
+| `blocked`                 | A failed gate, dependency, or unresolved decision prevents closure.                                                                                  |
+| `waived`                  | A temporary exception explicitly approved with owner, reason, and expiry.                                                                            |
+| `deferred`                | Explicitly postponed scope; it is not complete or verified.                                                                                          |
 
 For a newly created plan, initialize delivery rows as `not-started`, `deferred`, or `blocked` as appropriate. Creating Markdown files never makes implementation `implementation-complete` or `verified`.
 

package/{.claude → repo-agent-governance}/skills/cabloy-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cabloy-workflow
-description: This skill should be used when the main Cabloy problem is workflow routing before implementation: deciding between Vona backend scaffolding, Zova frontend scaffolding, contract-loop work, or docs/AI-enablement homes such as repo-docs, repo-docs-internal, CLAUDE.md, commands, or skills, including cases where Cabloy Basic vs Cabloy Start assumptions affect that routing. Trigger on requests to route, classify, choose a workflow, choose an edition-specific path, or decide where Cabloy guidance should live. Do not use it once the task is already clearly a backend scaffold, frontend scaffold, or contract-loop job.
+description: This skill should be used when the main Cabloy problem is workflow routing before implementation: deciding between Vona backend scaffolding, Zova frontend scaffolding, contract-loop work, or docs/AI-enablement homes such as repo-docs, repo-docs-internal, repo-agent-governance, commands, or skills, including cases where Cabloy Basic vs Cabloy Start assumptions affect that routing. Trigger on requests to route, classify, choose a workflow, choose an edition-specific path, or decide where Cabloy guidance should live. Do not use it once the task is already clearly a backend scaffold, frontend scaffold, or contract-loop job.
 ---
 
 # Cabloy Workflow
@@ -79,9 +79,8 @@ Use the docs/AI path when the task is about:
 
 - `repo-docs/`
 - `repo-docs-internal/`
-- `CLAUDE.md`
-- `.claude/commands/`
-- `.claude/skills/`
+- `repo-agent-governance/`
+- generated platform adapters such as `CLAUDE.md`, `.claude/commands/`, and `.claude/skills/`
 - repo guidance for AI development
 
 ## Step 3: Start from shared entrypoints
@@ -91,7 +90,7 @@ Before inventing a workflow, inspect these shared surfaces:
 - the repository or workspace `package.json` that owns the active scripts
 - `npm run vona`
 - `npm run zova`
-- root `CLAUDE.md` if present
+- root `repo-agent-governance/` if present, otherwise the active generated adapter
 - `repo-docs/` for public guidance
 - `repo-docs-internal/` for supporting maintainer rationale
 
@@ -179,7 +178,7 @@ Relevant internal records support routing and implementation but do not block th
 
 ### Root rules and commands
 
-Use `CLAUDE.md` and `.claude/commands/` for:
+Use `repo-agent-governance/policies/` and `commands/` as the authored source for:
 
 - concise operational guidance
 - named recurring workflows
@@ -187,7 +186,7 @@ Use `CLAUDE.md` and `.claude/commands/` for:
 
 ### Skills
 
-Use `.claude/skills/` for:
+Use `repo-agent-governance/skills/` for:
 
 - procedural workflows that benefit from reusable instructions
 - edition-aware decision trees
@@ -208,7 +207,7 @@ For these requests:
 
 - put the durable operational explanation in `repo-docs/`
 - put supporting rationale and invariants in `repo-docs-internal/`; preserve the public operational explanation when a particular internal record is unavailable or irrelevant
-- keep `CLAUDE.md` short and behavioral
+- keep canonical repository policy short and behavioral, then render adapters
 - do not treat `@Service()` as a business-layer naming decision only; for B2 it is a runtime-anchor placement choice
 
 ### Service underscore files

package/{.claude → repo-agent-governance}/skills/cabloy-worktree-environment/SKILL.md

@@ -29,10 +29,10 @@ Before proposing configuration values or writing files:
 
 Interpretation:
 
-| Marker | Edition | Managed clean E2E command |
-| --- | --- | --- |
-| `__CABLOY_BASIC__` only | Cabloy Basic | `npm run test:e2e` |
-| `__CABLOY_START__` only | Cabloy Start | `npm run test:e2e` |
+| Marker                  | Edition      | Managed clean E2E command |
+| ----------------------- | ------------ | ------------------------- |
+| `__CABLOY_BASIC__` only | Cabloy Basic | `npm run test:e2e`        |
+| `__CABLOY_START__` only | Cabloy Start | `npm run test:e2e`        |
 
 Stop without edits when both markers are present, neither marker is present, the checkout is primary/unregistered, required environment directories are missing, or the selected edition's required scripts are unavailable.
 
@@ -66,11 +66,11 @@ offset = linkedWorktreeOrdinal + batch
 
 Use these fixed baseline ports, which match the committed Cabloy defaults:
 
-| Setting | Baseline | Recommended value |
-| --- | ---: | --- |
-| `SERVER_LISTEN_PORT` | `7102` | `7102 + offset` |
-| `DEV_SERVER_PORT` | `9000` | `9000 + offset` |
-| `DEV_SERVER_HMR_PORT` | `24679` | `24679 + offset` |
+| Setting               | Baseline | Recommended value |
+| --------------------- | -------: | ----------------- |
+| `SERVER_LISTEN_PORT`  |   `7102` | `7102 + offset`   |
+| `DEV_SERVER_PORT`     |   `9000` | `9000 + offset`   |
+| `DEV_SERVER_HMR_PORT` |  `24679` | `24679 + offset`  |
 
 Set `APP_NAME` to the basename of the validated current worktree root. Do not inspect other worktrees’ configurations or append an env-derived suffix. Stop if that basename is empty or cannot be used as an application name without altering it; ask the user to rename/recreate the linked worktree instead.
 

package/{.claude → repo-agent-governance}/skills/cabloy-zova-source-reading/SKILL.md

@@ -193,11 +193,11 @@ When explaining a split page or component, establish role ownership before discu
 
 The source-confirmed direct member lookup order is:
 
-| Current bean | Direct member lookup order |
-| --- | --- |
-| Controller | Controller only |
-| Style | Style, then Controller |
-| Render | Render, then Controller, then Style |
+| Current bean | Direct member lookup order          |
+| ------------ | ----------------------------------- |
+| Controller   | Controller only                     |
+| Style        | Style, then Controller              |
+| Render       | Render, then Controller, then Style |
 
 State the shadowing caveat: an own member on the current bean takes precedence over each fallback surface. Recommend `this.member` for ordinary same-component companion access, such as Render reading Controller state or a Style-generated class.