cabloy 5.1.214 → 5.1.216

package/.cabloy-version

@@ -1 +1 @@
-5.1.214
+5.1.216

package/.github/workflows/agent-governance.yml

@@ -38,3 +38,22 @@ jobs:
           npm run spec:charts:check -- home-user
       - name: build documentation
         run: npm run docs:build
+
+  evidence-platforms:
+    name: evidence paths (${{ matrix.os }})
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, windows-latest, macos-latest]
+    runs-on: ${{ matrix.os }}
+    steps:
+      - uses: actions/checkout@v6
+      - uses: actions/setup-node@v6
+        with:
+          node-version: 24
+      - name: verify native evidence tooling
+        run: node --test repo-agent-governance/tests/evidence-paths.test.mjs
+      - name: verify sanitizer command entrypoint
+        run: npm run --silent evidence:sanitize -- --help
+      - name: verify checker command entrypoint
+        run: npm run --silent evidence:check -- --help

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # Changelog
 
+## 5.1.216
+
+### Features
+
+- Apply feature updates.
+
+### Improvements
+
+- Update the agent governance configuration.
+
+## 5.1.215
+
+### Features
+
+- Add support for skills.
+
 ## 5.1.214
 
 ### Improvements

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.214",
+  "version": "5.1.216",
   "gitHead": "2c5c19284bab738e492856189acb6fad74b8a7b7",
   "description": "A Node.js fullstack framework",
   "keywords": [
@@ -62,6 +62,8 @@
     "spec:charts": "node ./repo-agent-governance/tools/spec-charts/generate-implementation-charts.mjs",
     "spec:charts:check": "node ./repo-agent-governance/tools/spec-charts/generate-implementation-charts.mjs --check",
     "spec:check": "node ./repo-agent-governance/tools/spec-audit/audit.mjs",
+    "evidence:sanitize": "node repo-agent-governance/tools/evidence-paths/sanitize.mjs sanitize",
+    "evidence:check": "node repo-agent-governance/tools/evidence-paths/sanitize.mjs check",
     "docs:dev": "pnpm --dir repo-docs docs:dev",
     "docs:build": "pnpm --dir repo-docs docs:build",
     "docs:preview": "pnpm --dir repo-docs docs:preview",

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

@@ -186,7 +186,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
+      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".agents/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -242,7 +242,7 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
+      "sha256": "6066944449f7072dbecfde7a79ceb16ebf75777b00c28ddc996b90d8dcdf2145",
       "source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
       "target": ".agents/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
     },
@@ -522,7 +522,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
+      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".claude/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -578,7 +578,7 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
+      "sha256": "6066944449f7072dbecfde7a79ceb16ebf75777b00c28ddc996b90d8dcdf2145",
       "source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
       "target": ".claude/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "0b196a0d31058bb1d54efd10cdd7acbe51534d5738a908af57ef13d285afea8a",
+      "sha256": "050769a0c11ce7706b6dc0d526aad3ecd9d5a2ca1edd4d3eab699aac5eec9996",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -872,7 +872,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "d9bc04fff4781daed907508efb36efe7e60fcf8d2de98e0089b175273f29e14e",
+      "sha256": "17fd93c93c94e5a5b36bcea2c70e779d031b8158b99d03556e8d358e80ad7893",
       "source": "skills/cabloy-spec-execution/references/status-and-evidence.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/status-and-evidence.md"
     },
@@ -928,7 +928,7 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4174bef895433d6bdfd6238c6a90391e825e1dce90194cfd47bd6aa2d7a02494",
+      "sha256": "6066944449f7072dbecfde7a79ceb16ebf75777b00c28ddc996b90d8dcdf2145",
       "source": "skills/cabloy-spec-generation/references/traceability-and-status-rules.md",
       "target": ".cursor/skills/cabloy-spec-generation/references/traceability-and-status-rules.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "f4242299ae0b3a95427caaf9b137032767afa381d29135254195107348c4c42b",
+      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "f4242299ae0b3a95427caaf9b137032767afa381d29135254195107348c4c42b",
+      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

package/repo-agent-governance/policies/repository.md

@@ -72,6 +72,7 @@ Before inventing a custom implementation path:
 - Plan to resolve named blockers for a bounded increment, not every future detail. Define finite exit criteria, batch related decisions, and require new facts, decision value, or explicit blocker reduction for further planning; do not substitute repeated refinement for delivery.
 - Scope blockers to their actual dependency branches and surface meaningful, independently verifiable implementation candidates elsewhere without executing them unapproved. Once the selected increment is ready, request missing execution approval or proceed within existing unchanged approval; do not repeatedly reconfirm the same scope. Preserve security gates and separate runtime evidence/release requirements; neither a planning-round quota nor empty scaffolding justifies bypass or completion.
 - After implementation, do not launch broad reviews automatically; when review is needed, scope it to the current diff and report only high-confidence issues.
+- Sanitize machine-local paths before retaining or sharing evidence: preserve useful repository-relative locations, failures, exit codes, and source hashes; check the tool's supported coverage and manually review remaining sensitive data. Path sanitization is not secret scanning or acceptance proof.
 - Do not modify shared environment identity or ports merely to bypass a busy resource. For intentional parallel worktree setup, follow `repo-docs/fullstack/parallel-worktree-environment.md`; otherwise wait for the shared resource or ask the user. Create or change worktree-local environment overrides only through the explicitly invoked `cabloy-worktree-environment` skill and its confirmation phase, and only in `vona/env/.env.local` and `zova/env/.env.local`; never modify flavor-, mode-, app-mode-, or runtime-specific `.env.*.local` files. The skill derives the standard `APP_NAME`, `SERVER_LISTEN_PORT`, `DEV_SERVER_PORT`, `DEV_SERVER_HMR_PORT`, and API-derived `API_BASE_URL` tuple only from Git worktree metadata and fixed port baselines; never read or expose `.env*` content while recommending values. Admin and Web are alternative commands using this shared tuple and must not run concurrently in one worktree; use another linked worktree for concurrent use. Detect the active edition before choosing scripts, and never run `npm run init` as an automatic follow-up.
 - In Cabloy Basic and Cabloy Start, root `npm run test` and `npm run test:e2e` allocate an isolated same-checkout test run: disposable run-specific database and Redis namespaces, runtime/public paths, and listener. Ordinary same-checkout dev-process presence alone is not a blocker; do not require dev shutdown, another worktree, or environment changes solely to run these tests. Judge conflicts by actual overlap with effective test resources or shared preparation writes, not process names. Builds and dependency installation/generation remain shared prerequisites; coordinate overlapping writes, and check custom external resources separately. This guarantee does not cover raw test commands or authorize manual resets, process killing, or shared configuration changes. See `repo-docs/reference/repo-scripts.md`.
 - For isolated E2E through Vona integrated SSR, do not edit Zova `API_BASE_URL` environment values or rebuild solely to match the test port: Vona supplies runtime server/browser API origins. On an origin mismatch, check explicit SSR Site and module-specific API URL overrides first; follow the active repository's scripts for changed SSR/REST artifacts and dependency synchronization. Do not generalize this handoff to Zova standalone SSR or SPA. See [Runtime API origins](repo-docs/fullstack/ssr-entry-modes.md#runtime-api-origins-in-vona-integrated-ssr).

package/repo-agent-governance/scripts/pack-check.mjs

@@ -18,6 +18,7 @@ const required = [
   'repo-agent-governance/tools/contract-loop/core.mjs',
   'repo-agent-governance/tools/contract-loop/hook-runtime.mjs',
   'repo-agent-governance/tools/spec-audit/audit.mjs',
+  'repo-agent-governance/tools/evidence-paths/sanitize.mjs',
   'repo-agent-governance/tools/spec-charts/spec-parser.mjs',
   'repo-agent-governance/tools/spec-charts/generate-implementation-charts.mjs',
   'repo-agent-governance/skills/cabloy-spec-generation/SKILL.md',

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

@@ -8,7 +8,7 @@ The suite’s `test-plan.md` owns ATP definitions, procedures, expected outcomes
 
 For ordinary execution that does not change authority:
 
-1. retain actual evidence;
+1. sanitize and review actual evidence before durable retention;
 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;
@@ -52,6 +52,33 @@ Do not retain credentials, raw tokens, signed callback state, secrets, live prov
 
 Do not create an empty `evidence/` directory, placeholder `EVD-*` record, or fabricated artifact merely to satisfy a traceability table. A command written in a test plan or dossier is prospective until it is actually executed and retained.
 
+## Machine-local paths before retention
+
+Sanitize compiler output, CLI banners, stderr, exception stacks, and path-bearing JSON/diffs before saving or sharing them. Paths inside the observed checkout should be repository-root-relative, not relative to the evidence file. Use stable aliases such as `<MAIN_CHECKOUT>` for other roots; do not collapse unrelated roots into the same identity. Avoid raw intermediate logs and `tee` before sanitization. This does not intercept tool/terminal output automatically; callers must route both producer streams through the sanitizer. Do not capture secret-bearing output merely because a path tool is present.
+
+Verify the active root scripts first. The path-only commands are:
+
+```bash
+# Bash; use a new output filename, never overwrite an existing record.
+set -o pipefail
+set -o noclobber
+npm run --silent test:agent-governance 2>&1 | npm run --silent evidence:sanitize > evidence.pending.txt
+stage_status=( "${PIPESTATUS[@]}" )
+printf 'producer_exit=%s sanitizer_exit=%s\n' "${stage_status[0]}" "${stage_status[1]}"
+# Only check/retain the artifact if sanitizer_exit is 0; preserve producer failure.
+if [ "${stage_status[1]}" -eq 0 ]; then
+  npm run --silent evidence:check -- -- evidence.pending.txt
+fi
+```
+
+The producer above is an example verification command, not authorization to run unrelated tests. Retain evidence only after evaluating **both** producer and sanitizer statuses and reviewing sensitive data. `pipefail` prevents a failed producer from appearing successful because sanitization succeeded; it does not preserve every stage's exact exit code. When exact codes matter, capture Bash's `PIPESTATUS` immediately after the pipeline (Zsh: `pipestatus`) before running another command, and record each result. Do not let `set -e` abort before capturing a known failing verification result. A failed sanitizer may already have emitted earlier sanitized lines: its partial output is not acceptable evidence.
+
+The pipeline above is Bash-specific. For Windows/PowerShell, consult `repo-docs/reference/repo-scripts.md#windows-and-powershell`: preserve UTF-8 bytes and each native process's exit status; PowerShell's final `$LASTEXITCODE` alone does not record both stages. Do not reuse Bash/Zsh status syntax in PowerShell or retain a raw intermediate file to work around encoding.
+
+The tool defaults to its owning checkout, not the shell's working directory. `--repo-root` changes that root; repeatable `--map 'ROOT=ALIAS'` declares other absolute roots without retaining their physical locations in output. Use the same mappings for sanitization and checking. Consult `repo-docs/reference/repo-scripts.md#evidence-path-sanitization` for supported path forms, scan limits and exit codes. Unknown roots/encodings and semantic paths need manual review; the checker must not be described as a universal privacy or secret scanner. Excluded or unsupported inputs mean incomplete coverage, not clean evidence. Keep checks explicitly scoped to the intended artifacts rather than a broad repository scan.
+
+Preserve command flags, diagnostic codes, line/column information, failures, exit codes, and source-file hashes. Source hashes refer to original source bytes, not sanitized log bytes. A path-redacted historical patch is not byte-exact or apply-ready; label it accordingly. Redaction is presentation-only, not a rerun, new approval, ATP success, or status advancement. A passing path check proves only the declared path-recognition coverage and does not replace secret/customer-data review or the test plan's evidence gate.
+
 ## Status vocabulary
 
 Use the suite’s canonical status meanings:

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

@@ -113,6 +113,8 @@ A retained evidence entry should include:
 
 Evidence must be synthetic or redacted. Never retain credentials, raw tokens, signed callback state, secrets, live provider identifiers, or real customer/payment data merely to prove a scenario.
 
+Plan machine-local path sanitization before durable retention, including compiler stderr and exception stacks. Preserve useful repository-relative locations, failures, exit codes, and original source hashes; use stable aliases for external roots. Follow `cabloy-spec-execution`'s `references/status-and-evidence.md` retention/check procedure and the public command reference at `repo-docs/reference/repo-scripts.md#evidence-path-sanitization`. Path checking covers declared patterns only; it is not secret scanning, producer success, or ATP proof.
+
 A planned command is not a result. A code reading, design review, manual walkthrough, or single screenshot is not by itself sufficient for `verified` unless the applicable test plan explicitly defines it as adequate proof and the result is retained.
 
 ## Waivers