cabloy 5.1.229 → 5.1.230

package/.cabloy-version

@@ -1 +1 @@
-5.1.229
+5.1.230

package/CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## 5.1.230
+
+### Features
+
+- Apply feature updates (details not specified in commit messages).
+
 ## 5.1.229
 
 ### Features

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.229",
+  "version": "5.1.230",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [

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

@@ -95,7 +95,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".agents/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -179,14 +179,14 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".agents/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -431,7 +431,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".claude/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -515,14 +515,14 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".claude/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -781,7 +781,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "b883f2b01ab79d51b23e899be43a1c90a821db916490f50c4b28958eedf36b6e",
+      "sha256": "c3233550631e7782834811d3bd73b9b823b0bd429a681cedff85e24128b9ed35",
       "source": "skills/cabloy-frontend-scaffold/SKILL.md",
       "target": ".cursor/skills/cabloy-frontend-scaffold/SKILL.md"
     },
@@ -865,14 +865,14 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4f1b4b87b2c0d2ff485c58c8f891189fd3dc7914d66af806c1a808d22cd94124",
+      "sha256": "64615460c3bec383bb0010ddc1412e7fa8f122bbb3f87cfe5c824891fe247e6c",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
+      "sha256": "9ec7a5dd8b7c1a5d561a96562ee754c148e1d14db953d3629075af89e38613d3",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },

package/repo-agent-governance/skills/cabloy-frontend-scaffold/SKILL.md

@@ -281,6 +281,8 @@ Always end with a verification path that matches the scope of the frontend chang
 
 For ordinary frontend changes, prefer a few critical user flows through the existing E2E infrastructure, selected by affected behavior with spec names, tags, or `--grep`. Reuse existing scenarios or extend them narrowly; do not require exhaustive isolated-test matrices, extensive fake dependencies, or custom source-evaluation loaders before delivery. When an actual problem is fixed, add focused regression coverage. Targeted unit or framework tests remain useful when they efficiently prove the behavior being changed; this is not a ban on existing tests or managed test-resource isolation.
 
+Business E2E should primarily assert user actions, visible business outcomes, and persistence after save/reload. Do not turn architecture guidance into default browser assertions about Controller/IoC object identity, model instances, or Query/cache internals. Assert those internals only for an explicit architecture/framework acceptance contract or a focused regression, preferably at the smallest suitable unit, framework, or integration layer. This does not remove architecture requirements or server-side safety checks.
+
 Keep relevant format, lint, and type checks lightweight and scope-dependent. Prepare only the affected flavor's required artifacts for runtime verification. Preserve applicable route, SSR/hydration, authentication, authorization, contract, and acceptance checks; frontend E2E does not replace server-side enforcement. If runtime verification is unavailable or not authorized, report the gap rather than building a substitute harness. See [Frontend Scripts](../../../repo-docs/frontend/scripts.md) for edition-aware preparation and filtered E2E commands.
 
 Shared checks, when applicable, include:

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

@@ -115,6 +115,7 @@ Source ownership: <observed paths and proposed paths>
 Specialist route: <backend/frontend/contract-loop/specialist>
 Safety/contract constraints: <tenant, auth, lifecycle, transaction, SSR, migration, privacy>
 Verification: <exact approved ATP procedures and commands>
+Failure handling: <bounded in-scope diagnosis/repair/reruns, limits, and explicit stop conditions; or stop/report only>
 Evidence: <required revision/environment/procedure/result/redacted artifact>
 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>
@@ -147,10 +148,12 @@ Verify the approved connected outcome, not merely supporting helper behavior. On
 
 After user correction, redirect the affected approach rather than rename, relocate, or repackage rejected work. Reassess only the affected scope and preserve valid unchanged approvals; the correction does not itself authorize destructive cleanup or a different feature.
 
+The approved dossier may cover bounded in-scope diagnosis, implementation/test repair, and reruns, including locator corrections. Record the first failure and subsequent attempts, then complete that connected work within the stated limits without another approval for each substep. Do not weaken expected business/security outcomes, skip required checks, or expand scope to obtain a pass. If repair/reruns are not authorized, the limit is reached, or the user explicitly required first-failure stopping, stop and report. This permission is prospective and never overrides an existing narrower approval.
+
 Stop and report rather than guessing when:
 
 - 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;
+- a failed test or missing required artifact cannot be resolved within the approved repair/rerun boundary, or an explicit stop condition applies;
 - the working tree becomes attribution-ambiguous;
 - a specialist discovers a requirement or contract change;
 - a planned external/destructive operation is needed;

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

@@ -24,6 +24,8 @@ Do not use `progress.md` to add requirements, technical contracts, acceptance pr
 
 ## Evidence layout
 
+Retain the minimum sufficient evidence required by the test plan and attribution rules below. Prefer existing test-runner reports, redacted logs, and concise ATP/progress pointers rather than duplicating their contents across receipt layers. Do not create full input snapshots, exhaustive hash manifests, custom evidence verifiers, or multilayer receipts by default; new evidence machinery needs an explicit test-plan requirement or a concrete attribution/integrity risk that existing artifacts cannot address. Preserving source hashes during sanitization does not require inventing a new all-input hashing system. Keep mandatory revision/worktree attribution, actual failures, privacy review, and historical evidence intact unless a separate approved consolidation follows the lifecycle rules below.
+
 Prefer the scalable phase/ATP layout for newly observed proof when the suite permits extensions:
 
 ```text
@@ -104,6 +106,14 @@ A genuinely documentary/design-only task can instead follow `not-started -> in-p
 
 A task may be `implementation-complete` when source work is complete but an ATP, browser check, paired build, release gate, redaction decision, or durable artifact remains. A phase can be verified without implying that a separately defined integration or release phase is verified.
 
+## Evidence lifecycle and consolidation
+
+Retain artifacts for a named ongoing development need, an applicable acceptance/retention requirement, or unique information still needed to explain a result. Creation alone and hypothetical future usefulness are not reasons for permanent retention. Maintained source-controlled business tests provide ongoing regression protection; historical run artifacts record only what happened for their attributed revision and do not prove changed code remains correct.
+
+Keep current delivery state, coverage gaps, and blockers concise in the existing progress/phase records. Retain key acceptance results and only the supporting primary evidence and revision/dirty-worktree attribution they still require. Move durable discoveries needed for further development into the owning source tests, design record, or issue/handoff instead of depending on an artifact chain. Retired one-shot runners, resolved diagnostic detail, repeated inventories/snapshots, and documentary receipts need not remain permanently when they have no such purpose or unique information.
+
+Inspect before deleting or overwriting historical material and obtain explicit approval for the consolidation/deletion scope, including replacement of any earlier unchanged-retention commitment. Preserve meaningful successes, failures, waivers, and gaps truthfully; retain primary proof required by continuing acceptance claims. Update incoming links and state when old hash-based verifiers are retired or no longer applicable rather than recreating their dependency chains. Do not delete by extension or Git status, replace the clutter with a giant archive or a new manifest/checker system, or promote acceptance status. Reorganizing existing evidence alone does not require rerunning business tests; verify affected references and records with existing tools. This guidance does not itself authorize cleanup or override a controlling retention requirement.
+
 ## Historical evidence and supersession
 
 Evidence is revision- and authority-scoped. When source paths, generated artifacts, contracts, scope, or security assumptions change:

package/repo-docs/ai/verification.md

@@ -2,6 +2,28 @@
 
 AI-assisted work should finish with checks that match the scope of the change.
 
+## Proportional verification
+
+Prefer a few critical business flows through existing test infrastructure over exhaustive upfront matrices or bespoke verification harnesses. Preserve applicable security, authorization, tenant isolation, SSR/hydration, data consistency, migration, cleanup, and formal acceptance requirements.
+
+### Assert business outcomes at the business layer
+
+Business E2E should focus on user actions, visible results, and persistence after save/reload, plus essential rejection paths. Architecture guidance is not automatically a requirement to inspect Controller/IoC object identity, model instances, or Query/cache internals in the browser. Test internal invariants when an explicit architecture/framework contract or an actual regression requires them, preferably at the smallest suitable unit, framework, or integration layer. Architecture requirements and server-side enforcement still apply.
+
+### Keep evidence sufficient, not elaborate
+
+Prefer native test reports, redacted logs, and concise ATP/progress links. Retain required revision/worktree attribution, changed-file scope, exact procedures, relevant environment/fixture identities, and observed outcomes, including failures. Do not introduce full input snapshots, exhaustive hash manifests, custom evidence verifiers, or multiple receipt layers unless the test plan requires them or a concrete attribution/integrity risk cannot be addressed with existing artifacts. Preserve privacy review and historical evidence; simpler future evidence is not permission to delete old records.
+
+Retain artifacts only for a named ongoing development need, an applicable acceptance/retention requirement, or unique information still needed to explain a result—not merely because they were generated or might someday be useful. Maintained source-controlled business tests provide ongoing regression protection; historical logs describe a particular run and cannot prove changed code remains correct. Keep current status and blockers in existing progress/phase records, and move durable discoveries into the owning tests, design record, or issue/handoff. A concise delivery summary plus the few primary artifacts needed to support continuing acceptance claims is preferable to permanent process-file chains.
+
+Historical consolidation requires inspection and explicit approval of the deletion scope, including any change to prior retention commitments. Preserve meaningful outcomes, failures, waivers, gaps, and necessary revision attribution; update links and retire obsolete verifier expectations. Remove redundant snapshots/receipts and one-shot helpers only when their required or unique information is retained elsewhere or no longer needed. Do not substitute a giant archive or another checker system. Evidence reorganization alone needs reference/record checks, not business-test reruns, and never advances acceptance or overrides controlling retention requirements.
+
+### Handle failures within the approved boundary
+
+For specification execution, the approved dossier may include bounded in-scope diagnosis, repair, and reruns, with limits and stop conditions. When covered, record the failure and perform the connected correction without requesting approval for every locator or test-fix substep. Do not weaken business/security expectations to obtain a pass. Stop when the approved repair/rerun boundary is absent or exhausted, an explicit first-failure stop applies, or new scope, authority, dependency, safety, external, or destructive-operation questions require renewed approval. This guidance does not broaden or retrospectively replace an existing approval.
+
+See the canonical `cabloy-frontend-scaffold` verification guidance and the `cabloy-spec-execution` execution-protocol and status-and-evidence references for operational details.
+
 ## Documentation verification
 
 For public docs changes, verify at minimum: