cabloy 5.1.213 → 5.1.215

package/.cabloy-version

@@ -1 +1 @@
-5.1.213
+5.1.215

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,19 @@
 # Changelog
 
+## 5.1.215
+
+### Features
+
+- Add support for skills.
+
+## 5.1.214
+
+### Improvements
+
+- Enhance the AI specification.
+- Refactor database reset logic.
+- Improve `printTip` output.
+
 ## 5.1.213
 
 ### Bug Fixes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cabloy",
-  "version": "5.1.213",
+  "version": "5.1.215",
   "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

@@ -179,21 +179,21 @@
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".agents/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "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"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".agents/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -242,14 +242,14 @@
     {
       "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"
     },
     {
       "adapter": "codex",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".agents/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -515,21 +515,21 @@
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".claude/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "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"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".claude/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -578,14 +578,14 @@
     {
       "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"
     },
     {
       "adapter": "claude",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".claude/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -683,7 +683,7 @@
     {
       "adapter": "cursor",
       "category": "policy",
-      "sha256": "2948516f964a13242178b4f5969756d469f60cc1766616a53e899c5551cf443d",
+      "sha256": "050769a0c11ce7706b6dc0d526aad3ecd9d5a2ca1edd4d3eab699aac5eec9996",
       "source": "policies/repository.md",
       "target": ".cursor/rules/cabloy-governance.mdc"
     },
@@ -865,21 +865,21 @@
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "e3441608051b6383385a9c4bd7fd77c8fc9e48a89293c4da81f05e067f9a8e8a",
+      "sha256": "044824fcfceff8153b722b8239d81d939286cb05ec03f75e78cfd03afe465f5a",
       "source": "skills/cabloy-spec-execution/references/execution-protocol.md",
       "target": ".cursor/skills/cabloy-spec-execution/references/execution-protocol.md"
     },
     {
       "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"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "60e20ef75f390a25464208470b6862f7a559d9eddf4d6f8012d2b99cc992c887",
+      "sha256": "cc739f11ae129235375a461b7376d639af967e1c659d4735a03b0973ff53dbdd",
       "source": "skills/cabloy-spec-execution/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-execution/SKILL.md"
     },
@@ -928,14 +928,14 @@
     {
       "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"
     },
     {
       "adapter": "cursor",
       "category": "skill",
-      "sha256": "4d7c6a45eb8854ac50a04e8cbf878c7b47dc5253dad05b9cea7ed0ec2b28b1d0",
+      "sha256": "846d81a0c8067900c4bcf3b9a854ca831cf4f0d2a184511fc6a01560da3b8dcb",
       "source": "skills/cabloy-spec-generation/SKILL.md",
       "target": ".cursor/skills/cabloy-spec-generation/SKILL.md"
     },
@@ -1005,14 +1005,14 @@
     {
       "adapter": "codex",
       "category": "policy",
-      "sha256": "f4f6c2584bd58846e315ecf2c0772a47735ef0d1f24a72213d2d6ea13673db71",
+      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
       "source": "policies/repository.md",
       "target": "AGENTS.md"
     },
     {
       "adapter": "claude",
       "category": "policy",
-      "sha256": "f4f6c2584bd58846e315ecf2c0772a47735ef0d1f24a72213d2d6ea13673db71",
+      "sha256": "4056d436da610d0438fe8aa4c873cd23442613de800799b358b1c1a2483d7402",
       "source": "policies/repository.md",
       "target": "CLAUDE.md"
     }

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

@@ -69,7 +69,10 @@ Before inventing a custom implementation path:
 - In SSR, keep server HTML and the client's hydration-time initial render equivalent. When server rendering intentionally omits private, cookie-unavailable, or browser-only state, keep the same neutral shell or placeholder through hydration and defer its query/load/render branch to an explicit post-hydration, admission, mounted, or interaction boundary.
 - Keep portable repo-wide AI rules short and durable in `repo-agent-governance/policies/`; put branching root workflows in `repo-agent-governance/skills/` and regenerate platform adapters instead of hand-editing them.
 - Treat hooks, permissions, local settings, credentials, MCP registration, command discovery, and automatic command execution as platform-specific integrations, not portable rule or skill capabilities.
+- 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/SKILL.md

@@ -90,9 +90,13 @@ Classify targets as observed existing, proposed new, or explicitly approved new.
 
 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.
 
+Reuse an already explicitly approved dossier when the target, scope, authority, dependencies, safety conditions and permitted operations remain valid. Check current revision/worktree attribution and evidence applicability; a revision change alone calls for an impact check, not automatic reapproval. Do not request the same approval again merely because a skill handoff, session continuation or implementation substep occurred. Refresh affected parts and seek renewed approval only when a material change, newly observed risk or the approval's own conditions require it. Existing approval never expands to another task or an unapproved external/destructive operation.
+
 ## Step 5: Apply readiness gates
 
-Stop and route back to the relevant planning authority if any of the following applies:
+Apply these gates to the selected increment and its actual dependencies, not every unresolved detail in the suite. Separate start-readiness from the runtime evidence this increment will produce and from later release gates; predecessor proof remains mandatory. If blocked, name the exact condition, affected branch and closure criterion in the existing records. Recommend a meaningful dependency-ready alternative for approval when one exists, without silently changing the target or its status. A smaller subincrement of a blocked WBS requires a justified independent boundary and explicit approval; it cannot bypass a controlling safety gate or claim parent completion.
+
+Stop and route only the affected authority questions back to planning 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;
@@ -106,6 +110,8 @@ Stop and route back to the relevant planning authority if any of the following a
 
 A task may be marked `in-progress` only when approved execution actually starts. Do not edit progress merely to reserve a task.
 
+Once the selected increment is ready and explicitly approved, execute its coherent implementation and verification steps without adding another preparation/review cycle by default. Any proposed planning return must identify the new fact, material authority question or concrete blocker it resolves and a finite exit condition; restating accepted direction is not sufficient. Batch related unresolved decisions rather than serializing each into another micro-plan. Preserve all mandatory reviews and safety/authorization gates; no round quota forces implementation.
+
 ## Step 6: Route the approved increment
 
 After confirmation, route the smallest coherent implementation unit:

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

@@ -71,7 +71,9 @@ Before implementation, verify:
 - tenant, identity, authorization, ownership, privacy, lifecycle, transaction, concurrency, idempotency, audit, and recovery constraints are defined for the task’s risk;
 - the requested change does not broaden scope or create a competing persistence, identity, or API authority.
 
-When authority records conflict, stop. Update the authoritative PRD, SRS, or ADR through `cabloy-spec-generation`, then propagate the change through WBS, ATP, evidence assumptions, and progress. Do not reconcile a conflict by silently editing a downstream status or implementation plan.
+Apply readiness to the selected increment and its real dependency graph. Record each blocker with its affected branch, decision owner and finite closure condition in existing records; keep future refinements and release-only questions separate. Do not require the new implementation's runtime ATP evidence before implementation starts, but retain required predecessor evidence and any specifically mandated pre-implementation qualification. When blocked, surface one meaningful, independently verifiable alternative if available, without executing it unapproved or changing formal dependencies/status to bypass the blocker. A foundation-only subincrement needs concrete integration value, checks and explicit scope approval; it does not complete the parent WBS.
+
+When authority records conflict, stop the affected work. Update the authoritative PRD, SRS, or ADR through `cabloy-spec-generation`, then propagate the change through WBS, ATP, evidence assumptions, and progress. Do not reconcile a conflict by silently editing a downstream status or implementation plan. A return to planning must name the new fact, material authority question or blocker to resolve and its exit condition; do not restart a preparation/review cycle merely to restate accepted direction. Batch related decisions and report stalled convergence if further refinement has no justified new value.
 
 ## 4. Special gates
 
@@ -123,7 +125,7 @@ Excluded operations: <init/reset/deploy/provider/etc.>
 Next action: <one action after confirmation>
 ```
 
-Require explicit confirmation. If the user changes scope, rebuild the dossier and re-check dependencies and authority. A prior confirmation does not authorize a new task, phase, provider operation, or destructive command.
+Require explicit confirmation unless this same bounded dossier already has valid explicit approval. Reuse unchanged approval across skill handoffs, session continuations and implementation substeps after checking current revision/worktree attribution and evidence applicability. Revision change alone requires an impact check, not automatic reapproval. Refresh affected dossier parts and obtain renewed approval for material scope/authority/dependency/safety changes, newly observed risks or conditions specified by the approval. A prior confirmation does not authorize a new task, phase, provider operation, or destructive command. Once ready and approved, proceed with the coherent implementation/verification sequence rather than requesting the same permission or another planning round by default.
 
 ## 6. Specialist routing
 

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/SKILL.md

@@ -69,6 +69,16 @@ Ask only for missing inputs in a compact clarification pass:
 
 Label recommendations as proposals. A request for comprehensiveness is not permission to invent security or business decisions.
 
+### Planning convergence
+
+For the next bounded increment, keep a finite blocker/exit checklist in the existing owning records, not a new planning hierarchy. Name each material unresolved decision, why it blocks this increment, its decision owner and closure condition; separate deferrable details and future increments. Batch related decisions into a compact review rather than mechanically splitting preparation, review and reconfirmation into separate rounds.
+
+Before proposing more planning, identify the blocker or material uncertainty it addresses, the new fact or decision value expected, and the exit condition or resulting implementation handoff. If another pass merely restates accepted direction or leaves the same blockers without a justified new approach, report the stalled convergence and recommend a concrete decision, bounded feasibility check or scope disposition instead of another micro-plan. Do not impose a fixed round limit or weaken security requirements to force code.
+
+Apply blockers only along actual dependencies, not to the whole suite by default. Surface one meaningful, independently verifiable implementation candidate on an unaffected branch when available; do not invent one or use empty scaffolding/document counts as progress. A foundation-only increment must have explicit integration value and its own checks, and must not be reported as completion of its parent feature. If none is ready, state the exact reason.
+
+Stop refining when the selected increment's material contracts, dependencies, scope, safety constraints and verification plan are sufficient. Request only missing execution approval, or hand off within existing explicit approval whose scope and conditions remain valid. Reopen settled decisions only for a material change or newly observed risk. Generation/design approval alone still does not authorize implementation; runtime ATP proof and release approval remain later gates, not proof that must already exist for the new implementation to start.
+
 ## 6. Confirm generation scope
 
 Before writing, present the edition/root, mode, identity/path, intended ownership, outcomes/scope, site strategy/target tuple classification, affected records, justified omissions/extensions, unresolved gates, and initial status/evidence policy. Include planned chart eligibility and README language.

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