@pareto4/pp-core 1.13.0 → 1.17.1

package/pp-core/workflows/execute-phase/steps/post-merge-gate.md

@@ -1,13 +1,11 @@
 # Step: post_merge_gate
 
-Post-merge build & test gate. Runs exactly once per wave, after the wave's merge
-step — the wave's one full-suite run (`suite_runs: 1` in the dispatch plan); no
-executor runs the full suite. Catches cross-plan integration failures that
-per-plan checks cannot detect.
-
-**Step A — Build gate:** run it only when the dispatch plan's wave `build` is true.
-When it is false (no plan in the wave touches source), print
-`⚠ Post-merge build gate skipped — no plan in this wave touches source` and go to Step B.
+Post-merge build & test gate. Runs after all worktrees in a wave are merged
+(parallel mode), or after the last plan completes (serial mode). Catches
+cross-plan integration failures that individual worktree self-checks cannot
+detect.
+
+**Step A — Build gate:**
 
 ```bash
 _PP_SHIM_NAME="pp-tools.cjs"; _pp_root() { ( for _v in $(env | sed -n 's/^\(GIT_[A-Za-z0-9_]*\)=.*/\1/p'); do unset "$_v"; done; _c=$(git rev-parse --git-common-dir 2>/dev/null); if [ "${_c##*/}" = .git ] && cd "$_c/.." 2>/dev/null; then pwd -P; else git rev-parse --show-toplevel 2>/dev/null || pwd; fi ); }; pp_run() { case "$PP_TOOLS" in *.cjs) node "$PP_TOOLS" "$@";; *) "$PP_TOOLS" "$@";; esac; }; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(_pp_root)}"; PP_TOOLS="${_PP_RUNTIME_ROOT}/pp-core/bin/${_PP_SHIM_NAME}"; if [ -f "$PP_TOOLS" ]; then :; elif [ -f "${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}"; elif command -v pp-tools >/dev/null 2>&1; then PP_TOOLS="$(command -v pp-tools)"; else echo "ERROR: pp-tools.cjs not found at $PP_TOOLS and pp-tools is not on PATH. Run: npx -y @pareto4/pp-core@latest --claude --local" >&2; exit 1; fi; if [ -n "${CLAUDE_ENV_FILE:-}" ] && [ -n "${PP_TOOLS:-}" ]; then printf "export PATH='%s':\"\$PATH\"\n" "${PP_TOOLS%/*}" >> "$CLAUDE_ENV_FILE" 2>/dev/null || true; fi

package/pp-core/workflows/execute-phase/steps/vault-fetch.md

@@ -1,25 +1,126 @@
-# Vault fetch + summary (plan:pre and execute:pre step dispatch)
+# vault fetch + summary — the bespoke step dispatch, served at `plan:pre` and `execute:pre`
 
-Capability-driven dispatch for an active step hook where `kind == "step"` and `capId == "vault"`, at plan:pre (hooks in `PLAN_PRE_HOOKS_JSON`) or execute:pre (hooks in `EXECUTE_PRE_HOOKS_JSON`). Runs `vault fetch` then `vault summary` so `.planning/vault/SUMMARY.md` exists on the researcher and planner read paths, and so the `vault.status` gate that follows judges a fresh fetch. The generic step contract dispatches only `ref.skill`/`ref.agent` hooks — not `ref.command` — so this bespoke block owns the `vault fetch` command run. The registry evaluates `when: vault.enabled`; an inert capability yields no hook. `onError: skip` — a failed fetch logs a warning and continues; the gate after it decides whether a missing client vault may proceed (it stops only when `vault.required` is true).
+Capability-driven dispatch for an active vault step hook where `kind == "step"` and `capId == "vault"`. The `vault` capability declares that step at **two** loop points — `plan:pre` and `execute:pre` — and this one file serves both, Read from ten call sites — nine hook-mode callers at those two points and one direct-mode caller with no loop point (see the Direct mode paragraph below); the caller table below names them. Runs `vault fetch`, which now writes `.planning/vault/SUMMARY.md` itself (STRICT-05). What that buys differs by point and both reasons are real: at `plan:pre` the summary exists on the researcher and planner read paths before the researcher `Agent()` spawn; at `execute:pre` the fetch is attempted *before* the gate decides, so a fresh clone or a CI runner with a reachable vault fetches and passes rather than being blocked for a cache it never had a chance to populate (GATE-03). The generic step contract dispatches only `ref.skill`/`ref.agent` hooks — not `ref.command` — so this bespoke block owns the `vault fetch` command run. The registry evaluates `when: vault.enabled`; an inert capability yields no hook.
 
-Read the active step hook from the point's hooks JSON (in-context) where `kind == "step"` and `capId == "vault"`.
+## Callers — bind `VAULT_FETCH_HOOKS_JSON` (hook mode) or set `VAULT_FETCH_DIRECT` (direct mode) before Reading this file
 
-**If no active vault step hook exists:** skip (`vault.enabled` is not true). From a side door (`vault-door-gate.md`), `DOOR_VAULT=true` is the active step hook.
+`VAULT_FETCH_HOOKS_JSON` is a **parameter**, in exactly the sense `check-query-gate.md`'s
+`GATE_HOOKS_JSON` is one: this file never renders hooks itself, and the caller sets it to the
+`activeHooks` payload the caller already rendered for **its own** loop point. This file therefore
+names no caller's payload variable anywhere, deliberately — it is Read from ten places, nine at
+two loop points and one with no loop point at all, so any one variable name is dead at the other
+nine, and the guard's next instruction is *skip*. A step file that hard-names one caller's variable
+does not merely mis-document the other callers; it silently turns their fetch off
+(02-VERIFICATION, G-2).
 
-**If an active vault step hook exists** (recognizable by `capId == "vault"` + `ref.command == "vault fetch"`):
+| Caller | Loop point | Binding |
+|--------|------------|---------|
+| `pp-core/workflows/plan-phase.md`, `### plan:pre vault fetch + summary` | `plan:pre` | `VAULT_FETCH_HOOKS_JSON` ← the `plan:pre` payload that section already has in scope |
+| `pp-core/workflows/autonomous.md`, §3a.5-i, the `ref.command` + `capId == "vault"` branch | `plan:pre` | `VAULT_FETCH_HOOKS_JSON` ← the `plan:pre` payload §3a.5 rendered |
+| `pp-core/workflows/execute-phase/steps/execute-pre-dispatch.md`, step 1 "Fetch first" | `execute:pre` | `VAULT_FETCH_HOOKS_JSON` ← the `execute:pre` payload that dispatcher already reads its `activeHooks` from |
+| `pp-core/workflows/quick.md`, Step 2.4 (16-11) | `plan:pre` | `VAULT_FETCH_HOOKS_JSON` ← quick's `plan:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/debug.md`, § 0b Vault admission and load gate (16-14) | `plan:pre` | `VAULT_FETCH_HOOKS_JSON` ← debug's `plan:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/code-review-fix.md`, `vault_admission_gate` (16-15) | `execute:pre` | `VAULT_FETCH_HOOKS_JSON` ← the door's `execute:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/validate-phase.md`, § 0.5 (16-15) | `execute:pre` | `VAULT_FETCH_HOOKS_JSON` ← the door's `execute:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/add-tests.md`, `vault_admission_gate` (16-15) | `execute:pre` | `VAULT_FETCH_HOOKS_JSON` ← the door's `execute:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/audit-fix.md`, `vault_admission_gate` (16-15) | `execute:pre` | `VAULT_FETCH_HOOKS_JSON` ← the door's `execute:pre` payload, filtered in the fence to the `vault` and `vault-practices` capabilities, after its own admission fence |
+| `pp-core/workflows/discovery-sprint/vault-context.md`, § 2 "Fetch" (Read from Flow 2 Step 1 and prefill Step 0 of the discovery sprint) | none — direct mode (D-11-09) | `VAULT_FETCH_DIRECT=true`; the payload parameter is left empty; the two activation guards run first, in order |
+
+A **next caller** (the eleventh) inherits one obligation and one only: bind this parameter from the payload it
+rendered for its own point, before the Read — or, when it has no loop point, run the two activation
+guards and set `VAULT_FETCH_DIRECT` (Direct mode below). Nothing in this file needs to change to
+accommodate it — that is the whole reason both parameters exist instead of a sentence naming a
+caller's variable.
+
+The step's static `onError: skip` remains the **registry-level dispatch policy** and is unchanged. Layered on top of it is a **runtime** decision this block makes for itself: when `vault.required` is true, a failed fetch or an unwritten summary hard-stops with `PARETO_GATE_BLOCKED:vault.fetch` and a non-zero exit (STRICT-03, GATE-09). A static `onError` cannot depend on a config value, which is why the arm lives here rather than in the capability declaration. With `vault.required` false — the default — every path below behaves exactly as it did before: a warning, and the run continues.
+
+**Admission first (D-28, D-05).** This check runs before the hook-presence check below because a loop-point host renders no vault hook at all on a config the gate cannot read, so without it a direct or unconditional caller would skip the fetch silently. It is inert without `.platform-bindings.json` (a probe that cannot answer, such as on a malformed bindings file, defers to the verb, which checks bindings first itself); `on`, `off` and `inert` continue to the hook check exactly as before, and anything else (`config-unreadable`, or no answer) halts naming the file and the repair (research C-4).
 
 ```bash
 _PP_SHIM_NAME="pp-tools.cjs"; _pp_root() { ( for _v in $(env | sed -n 's/^\(GIT_[A-Za-z0-9_]*\)=.*/\1/p'); do unset "$_v"; done; _c=$(git rev-parse --git-common-dir 2>/dev/null); if [ "${_c##*/}" = .git ] && cd "$_c/.." 2>/dev/null; then pwd -P; else git rev-parse --show-toplevel 2>/dev/null || pwd; fi ); }; pp_run() { case "$PP_TOOLS" in *.cjs) node "$PP_TOOLS" "$@";; *) "$PP_TOOLS" "$@";; esac; }; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(_pp_root)}"; PP_TOOLS="${_PP_RUNTIME_ROOT}/pp-core/bin/${_PP_SHIM_NAME}"; if [ -f "$PP_TOOLS" ]; then :; elif [ -f "${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}"; elif command -v pp-tools >/dev/null 2>&1; then PP_TOOLS="$(command -v pp-tools)"; else echo "ERROR: pp-tools.cjs not found at $PP_TOOLS and pp-tools is not on PATH. Run: npx -y @pareto4/pp-core@latest --claude --local" >&2; exit 1; fi; if [ -n "${CLAUDE_ENV_FILE:-}" ] && [ -n "${PP_TOOLS:-}" ]; then printf "export PATH='%s':\"\$PATH\"\n" "${PP_TOOLS%/*}" >> "$CLAUDE_ENV_FILE" 2>/dev/null || true; fi
-# vault fetch: populates .planning/vault/ cache + manifest
-if ! pp_run vault fetch 2>&1; then
+VAULT_ADMIT_PRESENT=$(pp_run query platform-bindings --pick present 2>/dev/null || echo true)
+VAULT_ADMIT=inert
+if [ "$VAULT_ADMIT_PRESENT" = true ]; then VAULT_ADMIT=$(pp_run vault admission 2>/dev/null || echo unrecognised); fi
+case "$VAULT_ADMIT" in on) echo "VAULT_ADMIT=on" ;; off|inert) : ;; *) pp_run vault admission --explain; echo "PARETO_GATE_BLOCKED:vault.admission"; exit 1 ;; esac
+```
+
+Read the active vault step hook from `VAULT_FETCH_HOOKS_JSON` (in-context) where `kind == "step"` and `capId == "vault"`. A caller binding this payload to `$X` means the JSON on the `X=` line the caller's render fence PRINTED (D-99): a payload a fence only assigned is invisible in the next call.
+
+**If no active vault step hook exists** and `VAULT_FETCH_DIRECT` is not the literal `true`: skip (non-Pareto project, `vault.enabled` false, or vault bindings absent).
+
+**Direct mode — `VAULT_FETCH_DIRECT` (D-11-09):** consulted **only** when `VAULT_FETCH_HOOKS_JSON` is empty, mirroring the `GATE_DIRECT_QUERY` parameter `check-query-gate.md` already ships for build entry points that declare no loop-host frontmatter. A caller with no loop point cannot render a payload at all: the `vault` capability declares this step at exactly `plan:pre` and `execute:pre`, and the twelve canonical loop points are frozen by the loop-host contract, so there is no third point such a caller could render and no payload for it to bind. Setting this parameter to the literal `true` makes the block below run exactly as it does for an active hook — the same `vault fetch`, the same `.planning/vault/SUMMARY.md` write, the same three arms and the same required-miss halt token and non-zero exit — so a direct caller inherits the first of the two `plan:pre` halt surfaces from its owner rather than authoring a fourth copy of it (D-11-11). A direct caller MUST run the two activation guards itself first, in this order: `pp_run query platform-bindings --pick present` (when not `true`, do not Read this file at all — non-Pareto project, fully inert), then `pp_run vault admission` (16-04, D-28: on `on`, Read this file; on `off` or `inert`, do not Read it; on anything else, `config-unreadable` or no answer, print `pp_run vault admission --explain` and halt with `PARETO_GATE_BLOCKED:vault.admission` and a non-zero exit, because a config the gate cannot read is not a vault that is off). A direct dispatch has not been through the registry's `when` evaluation and therefore carries none of its inertness, which is the same obligation `check-query-gate.md` § Direct-query mode places on a direct caller of the gate. Hook-mode callers are unaffected: with a non-empty payload this parameter is never read, so all hook-mode callers behave exactly as they did before it existed.
+
+The block below also records the verdict before and after the fetch and says so when the fetch changed it (D-08-08): the plan:pre / execute:pre ordering is fetch-then-gate (`plan-phase.md` §5.1 then §5.6; `execute-pre-dispatch.md` steps 1-2), so a by-hand `check vault.status` taken earlier can legitimately disagree with the gate — the disagreement is temporal, and this line is what makes it explicable (D-08-05). Both snapshots are pure reads (D-08-04): they report the manifest, they never fetch, and they add nothing at all on a run that does not reach the block — an inactive hook with no direct-mode caller — because they live inside the run condition above and nowhere else.
+
+**If an active vault step hook exists** (recognizable by `capId == "vault"` + `ref.command == "vault fetch"`) — or `VAULT_FETCH_DIRECT` is `true` with an empty payload:
+
+```bash
+# vault.required — read ONCE, with an explicit default (STRICT-03). The key is
+# declared in `capabilities/vault/capability.json`, so this read returns the
+# project's configured value; with it set true the hard-stop arm below is live.
+VAULT_REQUIRED=$(pp_run query config-get vault.required --raw --default false 2>/dev/null || echo false)
+
+# vault fetch: populates .planning/vault/ cache + manifest AND writes
+# .planning/vault/SUMMARY.md itself. The separate `vault summary` subcommand
+# call that used to live here is deliberately GONE (STRICT-05): the fetch and the
+# summary were paired only by this markdown, so a direct CLI fetch, an --auto run
+# that never dispatched this step, or an agent skipping the second instruction
+# each produced a populated cache with no SUMMARY.md. The pairing is now code.
+# D-08-08: a pure read of the manifest as it stands BEFORE this fetch rewrites
+# it. This is the reading an operator's own by-hand `check vault.status` would
+# have produced a moment ago, captured here because nothing downstream can
+# reconstruct it once the fetch has landed.
+VAULT_PRE_VERDICT=$(pp_run check vault.status --raw 2>/dev/null || echo '{}')
+VAULT_FETCH_JSON=$(pp_run vault fetch --raw 2>/dev/null || echo '{}')
+VAULT_SOURCE=$(printf '%s' "$VAULT_FETCH_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).source||'');}catch{process.stdout.write('');}")
+VAULT_SUMMARY_WRITTEN=$(printf '%s' "$VAULT_FETCH_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(String(JSON.parse(d).summaryWritten===true));}catch{process.stdout.write('false');}")
+VAULT_SUMMARY_ERROR=$(printf '%s' "$VAULT_FETCH_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(String(JSON.parse(d).summaryError||''));}catch{process.stdout.write('');}")
+VAULT_FETCH_REASON=$(printf '%s' "$VAULT_FETCH_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const p=JSON.parse(d);process.stdout.write(String(p.fallbackReason||p.warning||''));}catch{process.stdout.write('');}")
+
+# D-08-08: the same pure read AFTER the fetch, and a comparison of the five
+# fields that decide the gate. Values are envelope fields this file's siblings
+# already print; `reason` is a frozen code. Pipes and newlines are stripped and
+# each summary is cut at 300 characters, because the two summaries are carried
+# through a single pipe-delimited string that `cut` then splits.
+VAULT_POST_VERDICT=$(pp_run check vault.status --raw 2>/dev/null || echo '{}')
+VAULT_VERDICT_DIFF=$(PRE="$VAULT_PRE_VERDICT" POST="$VAULT_POST_VERDICT" node -e "const F=['tier','ref','stale','block','reason'];const g=(s)=>{let p={};try{p=JSON.parse(s)||{};}catch{p={};}return F.map((k)=>k+'='+String(p[k]===undefined||p[k]===null?'':p[k])).join(' ').replace(/[\r\n|]/g,'').slice(0,300);};const a=g(process.env.PRE||'');const b=g(process.env.POST||'');process.stdout.write(a===b?'same||':'changed|'+a+'|'+b);")
+VAULT_VERDICT_CHANGED=$(printf '%s' "$VAULT_VERDICT_DIFF" | cut -d'|' -f1)
+VAULT_VERDICT_BEFORE=$(printf '%s' "$VAULT_VERDICT_DIFF" | cut -d'|' -f2)
+VAULT_VERDICT_AFTER=$(printf '%s' "$VAULT_VERDICT_DIFF" | cut -d'|' -f3)
+if [ "$VAULT_VERDICT_CHANGED" = "changed" ]; then
+  echo "ℹ vault fetch changed the gate verdict: before — ${VAULT_VERDICT_BEFORE}; after — ${VAULT_VERDICT_AFTER}. A check vault.status read taken before this fetch described the earlier state (D-08-08)."
+fi
+
+# Read the OUTCOME, never the exit code: `pp-tools vault ...` exits 0 on every
+# path by design (D-VH-7 — the command reports, the workflow halts), so the old
+# `if ! pp_run vault fetch` guard could not take its failure branch.
+VAULT_FETCH_FAILED=false
+if [ -z "$VAULT_SOURCE" ] || [ "$VAULT_SOURCE" = "miss" ]; then VAULT_FETCH_FAILED=true; fi
+VAULT_LOAD_OK=true
+if [ "$VAULT_FETCH_FAILED" = "true" ] || [ "$VAULT_SUMMARY_WRITTEN" != "true" ]; then VAULT_LOAD_OK=false; fi
+
+if [ "$VAULT_REQUIRED" = "true" ] && [ "$VAULT_LOAD_OK" = "false" ]; then
+  # Arm 3 — vault.required is on: a miss, a failed fetch and an unwritable
+  # summary all hard-stop (D-VH-4). Print the failure verbatim, then the named
+  # halt token and a non-zero exit — the same two halves the extracted enforcer
+  # uses, so an agent stops and an unattended runner sees the exit code.
+  echo "✗ vault could not be loaded and vault.required is true (STRICT-03)" >&2
+  if [ -n "$VAULT_FETCH_REASON" ]; then echo "  fetch: $VAULT_FETCH_REASON" >&2; fi
+  if [ -n "$VAULT_SUMMARY_ERROR" ]; then echo "  summary: $VAULT_SUMMARY_ERROR" >&2; fi
+  echo "PARETO_GATE_BLOCKED:vault.fetch"
+  exit 1
+elif [ "$VAULT_FETCH_FAILED" = "true" ]; then
+  # Arm 1 — fetch failed, vault.required off. Same effect as before this plan.
   echo "⚠ vault fetch failed — continuing without vault context (onError:skip)" >&2
+  if [ -n "$VAULT_FETCH_REASON" ]; then echo "  reason: $VAULT_FETCH_REASON" >&2; fi
+elif [ "$VAULT_SUMMARY_WRITTEN" != "true" ]; then
+  # Arm 2 — fetch succeeded, the summary did not reach disk. STRICT-05: this is
+  # the branch the confirmation line used to fall through to unconditionally,
+  # pointing agents at a SUMMARY.md that was never written.
+  echo "⚠ vault summary not written — .planning/vault/SUMMARY.md is absent (onError:skip)" >&2
+  if [ -n "$VAULT_SUMMARY_ERROR" ]; then echo "  reason: $VAULT_SUMMARY_ERROR" >&2; fi
 else
-  # vault summary: writes .planning/vault/SUMMARY.md — the bounded index
-  # that planner, researcher, and executor pointers reference.
-  if ! pp_run vault summary 2>&1; then
-    echo "⚠ vault summary failed — SUMMARY.md may be absent (onError:skip)" >&2
-  else
-    echo "✓ vault fetch + summary complete: .planning/vault/SUMMARY.md"
-  fi
+  # The claim is now reachable ONLY when summaryWritten is true.
+  echo "✓ vault fetch + summary complete: .planning/vault/SUMMARY.md"
 fi
 ```

package/pp-core/workflows/execute-phase/steps/vault-load-gate.md

@@ -1,28 +1,330 @@
-# Vault load gate (plan:pre + execute:pre)
+# Vault load gate — state rendering (plan:pre + execute:pre)
 
-One file serves both call sites: the host sets `VAULT_GATE_POINT` to `plan` (plan:pre) or
-`execute` (execute:pre) before executing this step. The verdict, its wording and whether it
-blocks are decided by the CLI — `computeVaultVerdict` is the only owner. This step relays the
-card verbatim and reads one field; it never re-derives any part of the verdict.
+Renders the vault load state for the operator before planning or build. The host sets
+`VAULT_GATE_POINT` to `plan` (for plan:pre) or `execute` (for execute:pre) before
+executing this step — **one file serves both call sites** (D-05). The §8 message table
+(design §8) column is selected by this parameter.
+
+**This file decides nothing.** The halt belongs to
+`pp-core/workflows/execute-phase/steps/check-query-gate.md`, the single generic `check.query`
+enforcer, which both call sites run *before* reading this file (GATE-02, D-VH-7). There is exactly
+one halt implementation in the repo and this is not it. Deciding and rendering are separated on
+purpose: if you are here because a gate did not stop a build, the enforcer is where to look. Do not
+add a halt to this file.
+
+Gated entirely on `.platform-bindings.json`: when no bindings file is present, this gate
+is a **no-op** — fully inert for non-Pareto projects. The verdict is read from
+`pp_run check vault.status --raw` — a pure manifest read that never fetches, never errors,
+and degrades to `{"present":false}` on any problem.
 
 ```bash
 _PP_SHIM_NAME="pp-tools.cjs"; _pp_root() { ( for _v in $(env | sed -n 's/^\(GIT_[A-Za-z0-9_]*\)=.*/\1/p'); do unset "$_v"; done; _c=$(git rev-parse --git-common-dir 2>/dev/null); if [ "${_c##*/}" = .git ] && cd "$_c/.." 2>/dev/null; then pwd -P; else git rev-parse --show-toplevel 2>/dev/null || pwd; fi ); }; pp_run() { case "$PP_TOOLS" in *.cjs) node "$PP_TOOLS" "$@";; *) "$PP_TOOLS" "$@";; esac; }; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(_pp_root)}"; PP_TOOLS="${_PP_RUNTIME_ROOT}/pp-core/bin/${_PP_SHIM_NAME}"; if [ -f "$PP_TOOLS" ]; then :; elif [ -f "${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${_PP_RUNTIME_ROOT}/.codex/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${HERMES_HOME:-$HOME/.hermes}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CURSOR_CONFIG_DIR:-$HOME/.cursor}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEX_HOME:-$HOME/.codex}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GEMINI_CONFIG_DIR:-$HOME/.gemini}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${COPILOT_CONFIG_DIR:-$HOME/.copilot}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${WINDSURF_CONFIG_DIR:-$HOME/.codeium/windsurf}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${AUGMENT_CONFIG_DIR:-$HOME/.augment}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${TRAE_CONFIG_DIR:-$HOME/.trae}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${QWEN_CONFIG_DIR:-$HOME/.qwen}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CODEBUDDY_CONFIG_DIR:-$HOME/.codebuddy}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${CLINE_CONFIG_DIR:-$HOME/.cline}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${GROK_AGENTS_HOME:-$HOME/.agents}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${ANTIGRAVITY_CONFIG_DIR:-$HOME/.gemini/antigravity}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${OPENCODE_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/opencode}/pp-core/bin/${_PP_SHIM_NAME}"; elif [ -f "${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="${KILO_CONFIG_DIR:-${XDG_CONFIG_HOME:-$HOME/.config}/kilo}/pp-core/bin/${_PP_SHIM_NAME}"; elif command -v pp-tools >/dev/null 2>&1; then PP_TOOLS="$(command -v pp-tools)"; else echo "ERROR: pp-tools.cjs not found at $PP_TOOLS and pp-tools is not on PATH. Run: npx -y @pareto4/pp-core@latest --claude --local" >&2; exit 1; fi; if [ -n "${CLAUDE_ENV_FILE:-}" ] && [ -n "${PP_TOOLS:-}" ]; then printf "export PATH='%s':\"\$PATH\"\n" "${PP_TOOLS%/*}" >> "$CLAUDE_ENV_FILE" 2>/dev/null || true; fi
-VAULT_CARD=$(pp_run check vault.status --card --point "${VAULT_GATE_POINT:-plan}") || exit 1
-VAULT_ACTION=$(pp_run check vault.status --pick action) || exit 1
-[ -n "$VAULT_ACTION" ] || exit 1
-[ -z "$VAULT_CARD" ] || printf '%s\n' "$VAULT_CARD"
-echo "VAULT_ACTION=$VAULT_ACTION"
-[ "$VAULT_ACTION" != stop ] || exit 1
+VAULT_GATE_PRESENT=$(pp_run query platform-bindings --pick present 2>/dev/null || echo true)
+```
+
+**If `VAULT_GATE_PRESENT` != `true`:** skip entirely (non-Pareto project — fully inert). A probe
+that cannot answer (a malformed bindings file exits 1) reads as present, as `hasPlatformBindings`
+does (16-04 D-47 b), so the card renders the verdict instead of vanishing.
+
+```bash
+VAULT_VERDICT=$(pp_run check vault.status --raw 2>/dev/null || echo '{"present":false}')
+VAULT_STATUS=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).status||'miss');}catch{process.stdout.write('miss');}")
+VAULT_TIER=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).tier||'');}catch{process.stdout.write('');}")
+VAULT_FALLBACK_REASON=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).fallbackReason||'');}catch{process.stdout.write('');}")
+VAULT_REPO=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const p=JSON.parse(d);process.stdout.write(p.repo||p.source||'');}catch{process.stdout.write('');}")
+VAULT_REF=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).ref||'');}catch{process.stdout.write('');}")
+VAULT_SHA=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const s=JSON.parse(d).resolvedSha||'';process.stdout.write(s.slice(0,8));}catch{process.stdout.write('');}")
+VAULT_FILE_COUNT=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(String(JSON.parse(d).fileCount??0));}catch{process.stdout.write('0');}")
+VAULT_STALE=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(String(!!JSON.parse(d).stale));}catch{process.stdout.write('false');}")
+VAULT_FETCHED_AT=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).fetchedAt||'');}catch{process.stdout.write('');}")
+# 14-07 (D-21/D-25): the engine's operator message, relayed verbatim by the degraded row below — one text, one owner.
+VAULT_MESSAGE=$(printf '%s' "$VAULT_VERDICT" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const m=JSON.parse(d).message;process.stdout.write(typeof m==='string'?m:'');}catch{process.stdout.write('');}")
+# D-08-27: the CONFIGURED client coordinates, read straight from
+# `.platform-bindings.json`. This is a PURE BINDINGS READ: the verdict envelope is
+# deliberately not consulted for it, because with `vault.required` off the envelope
+# carries no drift field by design (STRICT-01), and D-08-29 rules the drift fact is
+# rendered as prose in this file rather than added as a new envelope key.
+VAULT_BINDINGS_JSON=$(pp_run query platform-bindings --raw 2>/dev/null || echo '{}')
+VAULT_CONFIGURED_REPO_SET=$(printf '%s' "$VAULT_BINDINGS_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const c=JSON.parse(d).client;process.stdout.write(c&&typeof c.vaultRepo==='string'&&c.vaultRepo.trim()?'true':'false');}catch{process.stdout.write('false');}")
+# Mirrors `resolveClientCoordinates` (src/vault-coordinates.cts): `client.vaultRef`
+# trimmed, or `main` when a client repo is configured with no ref, or empty when no
+# client repo is configured at all — so the ref rendered below is the same one the
+# verdict compares against. T-08-39: the value is project-authored, but it is
+# interpolated into an agent's context, so bound it — charset `[A-Za-z0-9._/-]`,
+# cut at 100 characters.
+VAULT_CONFIGURED_REF=$(printf '%s' "$VAULT_BINDINGS_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const c=JSON.parse(d).client;const set=!!(c&&typeof c.vaultRepo==='string'&&c.vaultRepo.trim());const r=set?((typeof c.vaultRef==='string'?c.vaultRef.trim():'')||'main'):'';process.stdout.write(r.replace(/[^A-Za-z0-9._\/-]/g,'').slice(0,100));}catch{process.stdout.write('');}")
+VAULT_CONFIGURED_REF_RAW=$(printf '%s' "$VAULT_BINDINGS_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const c=JSON.parse(d).client;const set=!!(c&&typeof c.vaultRepo==='string'&&c.vaultRepo.trim());const r=set?((typeof c.vaultRef==='string'?c.vaultRef.trim():'')||'main'):'';process.stdout.write(r);}catch{process.stdout.write('');}")
+VAULT_CONFIGURED_REF_TEXT="${VAULT_CONFIGURED_REF:-(none configured)}"
+# D-08-24 / D-08-29: ref drift — a client-tier cache whose ref is not the ref the
+# bindings configure. With `VAULT_REQUIRED` on the enforcer already stopped the run
+# for this state (`client_vault_ref_drifted_from_configured`, plan 08-01), so the
+# warning this flag selects is reached only with the policy off — the schema default.
+# D-08-39: these lines are a COPY of `resolveRefDrift`'s predicate (src/vault.cts) —
+# the one consumer that cannot call the owner — and are PINNED against it by the
+# agreement test in tests/vault-status-check.test.cjs, which extracts them BY PREFIX
+# and runs them in bash and zsh. Compare the RAW ref: the charset bound above is a
+# RENDERING bound, and applying it to a comparison input claimed drift on `v1.2.1+b`,
+# a legal git ref, because the `+` was stripped before the test.
+VAULT_REF_DRIFT=false
+if [ "$VAULT_TIER" = "client" ] && [ "$VAULT_CONFIGURED_REPO_SET" = "true" ] && [ -n "$VAULT_REF" ] && [ "$VAULT_CONFIGURED_REF_RAW" != "$VAULT_REF" ]; then VAULT_REF_DRIFT=true; fi
+# Compute human-readable cache age when stale
+VAULT_AGE=""
+if [ "$VAULT_STALE" = "true" ] && [ -n "$VAULT_FETCHED_AT" ]; then
+  VAULT_AGE=$(VAULT_FETCHED_AT="$VAULT_FETCHED_AT" node -e "const ms=Date.now()-new Date(process.env.VAULT_FETCHED_AT).getTime();const d=Math.floor(ms/86400000);const h=Math.floor((ms%86400000)/3600000);process.stdout.write(d>0?d+'d':h+'h');")
+fi
+# STRICT-03: the enforcement policy. Read once, here, through the same resolver
+# every other read path uses. With it off this file behaves exactly as it always has.
+VAULT_REQUIRED=$(pp_run query config-get vault.required --raw --default false 2>/dev/null || echo false)
+# STRICT-04: practice matching is separately activated. "Not enabled" and "zero
+# matched" are different facts and must never be rendered the same way.
+# Phase 15 D-25: asked of the SAME resolver the vault-practices gates use, at verify:post, where an
+# UNFILTERED vault-practices gate (vault.audit) is declared in both vault modes, so this prints true
+# exactly when the capability's gates render. A config-get read disagreed with the gates on the flat,
+# string and root-true + workstream-empty shapes (15-RESEARCH C-1).
+VAULT_PRACTICES_ENABLED=$(pp_run loop render-hooks verify:post --active-cap vault-practices 2>/dev/null || echo false)
+# Detect --auto / --chain in host $ARGUMENTS. SURFACING ONLY — see below.
+AUTO_MODE=false
+if echo "${ARGUMENTS:-}" | grep -qE -- '--auto|--chain'; then AUTO_MODE=true; fi
+```
+
+Select message based on `VAULT_STATUS`, `VAULT_TIER`, and `VAULT_GATE_POINT`, then handle confirmation.
+
+---
+
+## What this file does under each policy setting (STRICT-03)
+
+- **`VAULT_REQUIRED` is `false` or absent (the default).** Everything below behaves exactly as it
+  always has: surface the state message and require an explicit `confirmed`. The rendered text is
+  byte-identical to the pre-policy build for the same verdict, pinned by committed goldens in
+  `tests/vault-read-path.test.cjs`.
+
+- **`VAULT_REQUIRED` is `true` and the verdict blocks.** You will not reach this file — the enforcer
+  has already stopped the run — unless an accepted attributed override suppressed the block; then
+  `status` may be `degraded` and the degraded row below applies (D-25). **There is deliberately
+  nothing to do here for those states.** Do not
+  add a halt, a warning or a prompt for them out of a sense of incompleteness; a second
+  implementation is exactly how two halts drift apart.
+
+- **`VAULT_REQUIRED` is `true` and the verdict passes.** Render the success line for the point and
+  **skip the confirmation prompt**. A gate already enforced deterministically does not also need a
+  human to agree with it, and asking would train operators to press through gates — the habit this
+  phase exists to break.
+
+Invocation mode never changes any of the above. `--auto` / `--chain` selects how the state is
+surfaced, never whether the run proceeds. Mode-dependent gate behaviour was the precise shape of the
+hole this phase closes, so it is stated here rather than left to be re-derived.
+
+---
+
+## Practice clause (STRICT-04)
+
+Appended to the **success** messages below when `VAULT_REQUIRED` is `true`. It is part of the
+enforced gate's success line; with the policy off the messages are unchanged, which is what keeps
+the byte-identical promise.
+
+Compute it as follows, then substitute it as `${VAULT_PRACTICE_CLAUSE}`:
+
+**Standards mode is decided first** (Phase 15 D-22). Ask the matcher once, before reading
+`VAULT_PRACTICES_ENABLED`:
+
+```bash
+VAULT_PRACTICE_NA_JSON=$(pp_run vault practices match --raw 2>/dev/null || echo '{}')
+VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_NA_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
 ```
 
-**If the fence exits non-zero** (a command failed, the action is empty, or it is `stop`): STOP —
-do not plan or build, in any mode. The gate is `onError: halt`: a read that crashed is never a pass.
+**If `VAULT_PRACTICE_NA_LINE` is non-empty** (standards mode: `vault practices match` answers
+not-applicable whenever the vault gate is active, whatever `VAULT_PRACTICES_ENABLED` holds): print
+`${VAULT_PRACTICE_NA_LINE}` verbatim as the card line, print NO number, and skip the rest of this
+clause. The line comes from the engine and names the standards record and the gate that checks it.
+"Practice matching is not enabled" would be a practices-mode sentence on a standards project, which
+is the default standards shape (`vault.practices_enabled` off).
+
+Otherwise (practices mode) continue below.
+
+**If `VAULT_PRACTICES_ENABLED` != `true`:**
+
+> practice matching is not enabled for this project
+
+Emit no number on this branch. Zero-matched and matching-not-running are different facts, and
+reporting `0` for the second is the reassuring-but-false signal this phase removes.
+
+**Otherwise, at `VAULT_GATE_POINT` == `execute`** — the phase's plans exist, so the count is
+phase-scoped, which is what STRICT-04 asks for:
+
+```bash
+VAULT_PRACTICE_PATHS=$(pp_run query phase-plan-index "${PHASE_NUMBER}" --raw 2>/dev/null | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const s=new Set();for(const p of (JSON.parse(d).plans||[]))for(const f of (p.files_modified||[]))s.add(f);process.stdout.write(Array.from(s).slice(0,200).join('\n'));}catch{process.stdout.write('');}")
+VAULT_PRACTICE_PATH_COUNT=$(printf '%s' "$VAULT_PRACTICE_PATHS" | grep -c . || echo 0)
+```
+
+Pass those paths **positionally** to the match arm — never `--changed`, which would scope to the
+working tree rather than to the phase:
+
+`pp_run` is a shell FUNCTION, and `xargs` execs a binary — it can never invoke one. The previous
+form here piped into `xargs -r pp_run …`, whose failure was swallowed by `2>/dev/null` and answered
+by the `|| echo '{}'` fallback, so this clause reported **`0` practices matched on every run**, in
+bash and zsh alike, with nothing to indicate it had not looked. That is the reassuring-but-false
+signal the branch above exists to remove, arriving by a different door: STRICT-04 asks how many
+practices applied to this phase, and a false zero answers it wrongly. The paths therefore go
+straight to the function as positionals, the way `code-review.md` already calls the same arm
+(02-SECURITY T-02-36).
+
+```bash
+VAULT_PRACTICE_ARGS=()
+while IFS= read -r _p; do [ -n "$_p" ] && VAULT_PRACTICE_ARGS+=("$_p"); done <<< "$VAULT_PRACTICE_PATHS"
+if [ ${#VAULT_PRACTICE_ARGS[@]} -gt 0 ]; then
+  VAULT_PRACTICE_JSON=$(pp_run vault practices match "${VAULT_PRACTICE_ARGS[@]}" --raw 2>/dev/null || echo '{}')
+else
+  VAULT_PRACTICE_JSON=$(pp_run vault practices match --raw 2>/dev/null | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).status==='not_applicable'?d:'{}');}catch{process.stdout.write('{}');}")
+fi
+VAULT_PRACTICE_MATCHED=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'?'NA':String((r.matched||[]).length+(r.global||[]).length));}catch{process.stdout.write('0');}")
+VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
+```
+
+The path list is capped at **200** entries. When `VAULT_PRACTICE_PATH_COUNT` is `200`, the phase is
+wider than the bound and the clause must say so rather than present a truncated number as complete:
+
+> more than 200 files in scope — practice count not computed for this phase
+
+Otherwise:
+
+> `${VAULT_PRACTICE_MATCHED}` client practices apply to this phase
+
+**Otherwise, at `VAULT_GATE_POINT` == `plan`** — no phase scope exists yet, because the plans this
+count would be scoped to are the ones about to be written. Report what is true at this point and
+name when the scoped number arrives; do not fake a phase-scoped count and do not silently omit it:
+
+```bash
+VAULT_PRACTICE_JSON=$(pp_run vault practices match --raw 2>/dev/null || echo '{}')
+VAULT_PRACTICE_TOTAL=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'?'NA':String(r.practicesProcessed??0));}catch{process.stdout.write('0');}")
+VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
+```
+
+> the vault carries `` `${VAULT_PRACTICE_TOTAL}` `` practices at this ref; the phase-scoped matched count is reported at execute:pre once plans exist
+
+Each fence above assigns `VAULT_PRACTICE_JSON` itself before reading it — the two points never run
+in one gate, so neither fence reads the other's envelope. With no phase paths the execute fence
+still asks the matcher but keeps only a `not_applicable` answer, so practices mode still counts `0`.
+
+**If `VAULT_PRACTICE_MATCHED` (at execute) or `VAULT_PRACTICE_TOTAL` (at plan) is `NA`:** print
+`${VAULT_PRACTICE_NA_LINE}` verbatim as the card line, instead of the count line or the 200-file
+line, and print NO number — the envelope names the mode (`vault.mode = standards`); a count here would be the false
+"0 client practices apply" STRICT-04 forbids.
+
+---
+
+## §8 Message table — plan:pre column (`VAULT_GATE_POINT` == `plan`)
+
+**`fetched` + `tier: client`:**
+
+> Client vault loaded from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``). Planning will apply client standards.
+
+When `VAULT_REQUIRED` is `true`, append ` — ${VAULT_PRACTICE_CLAUSE}.` and skip the confirmation.
+Otherwise surface this message and require an explicit `confirmed` acknowledgment
+(`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE).
+
+**`fetched` + `tier: fallback` (intentionally more prominent — design §8):**
+
+> ℹ Loaded a **fallback-tier** vault (tier `` `${VAULT_TIER}` ``), read from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files) — *${VAULT_FALLBACK_REASON}*. The configured client ref `` `${VAULT_CONFIGURED_REF_TEXT}` `` did not load. Planning will apply this fallback vault's defaults, not the client's current standards. Proceed?
+
+Surface this message and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). The fallback confirmation is deliberately more prominent than the client tier: proceeding on a fallback vault's defaults instead of the client's own standards is a state the user should consciously acknowledge. With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here. (D-08-27: the line names the tier that loaded and the ref that failed; it no longer calls the loaded vault "shared" or presents the client's own repo as evidence that a shared vault loaded. On this fork's ladder the fallback source can be the client repo itself at another ref, which is exactly how the retired wording read as a client-vault success.)
+
+**`cache` (all tiers failed, using cached copy):**
+
+> ⚠ Could not reach client or shared vault — using cached copy from `` `${VAULT_FETCHED_AT}` `` (tier `` `${VAULT_TIER}` ``, may be stale). Proceed?
+
+Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, a stale cache has already been stopped by the enforcer; a TTL-fresh cache passes and is rendered without a prompt.
+
+**`miss` (no vault reachable, no cached copy):**
+
+> ⚠ No vault reachable (client or shared) and no cached copy. Planning will proceed WITHOUT vault context.
+
+Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here.
+
+**`degraded`** (standards mode — the vault loaded but its `INDEX.md` is missing, unparseable, empty or names no file in the fetched tree, or the engine could not check it at all (`vault_index_unchecked`: the cached manifest records no file list, or the check faulted — this says nothing about `INDEX.md` itself); `check vault.status` sets `status: degraded` and a `reason` of the form `vault_index_*`):
+
+Print `${VAULT_MESSAGE}` verbatim — the engine built it; do not restate or paraphrase it here. With `VAULT_REQUIRED` false it is the degraded-index warning, naming `INDEX.md`, what was measured and the repair: surface it and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` true this row is reachable only after an accepted attributed override (`PP_VAULT_OVERRIDE_REASON`) suppressed the block at the enforcer (D-25), and the message is the override notice naming the suppressed `vault_index_*` reason (or the block text naming `INDEX.md`, if the override reached only the enforcer's own call): print it and the envelope's `override` record when present, and continue without a prompt — the override is the acknowledgment and is already recorded in the envelope the enforcer acted on. The standards-mode practice clause is unchanged from Phase 13. Planning proceeds without a usable index; the `## INDEX` section of `.planning/vault/SUMMARY.md` names the degradation.
+
+---
+
+## §8 Message table — execute:pre column (`VAULT_GATE_POINT` == `execute`)
+
+Dispatched from `pp-core/workflows/execute-phase/steps/execute-pre-dispatch.md` after the enforcer.
+Until this phase, nothing dispatched this column at all — it was written and never read.
+
+**`fetched` + `tier: client`:**
+
+> Client vault present from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``). Build will apply client patterns.
+
+When `VAULT_REQUIRED` is `true`, append ` — ${VAULT_PRACTICE_CLAUSE}.` and skip the confirmation.
+Otherwise surface this message and require an explicit `confirmed` acknowledgment
+(`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE).
+
+**`fetched` + `tier: fallback` (intentionally more prominent — design §8):**
+
+> ℹ Using a **fallback-tier** vault (tier `` `${VAULT_TIER}` ``), read from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``) — *${VAULT_FALLBACK_REASON}*. The configured client ref `` `${VAULT_CONFIGURED_REF_TEXT}` `` did not load. Build applies this fallback vault's defaults, not the client's current patterns. Proceed?
+
+Surface this message and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). The fallback confirmation is deliberately more prominent than the client tier. With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here. (D-08-27: the line names the tier that loaded and the ref that failed; it no longer calls the loaded vault "shared" or presents the client's own repo as evidence that a shared vault loaded. On this fork's ladder the fallback source can be the client repo itself at another ref, which is exactly how the retired wording read as a client-vault success.)
+
+**`cache` (all tiers failed, using cached copy):**
+
+> ⚠ Could not reach client or shared vault — using cached copy from `` `${VAULT_FETCHED_AT}` `` (tier `` `${VAULT_TIER}` ``, `` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``, may be stale). Proceed?
+
+Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, a stale cache has already been stopped by the enforcer; a TTL-fresh cache passes and is rendered without a prompt.
+
+**`miss` (no vault reachable, no cached copy):**
+
+> ⚠ No vault reachable (client or shared) and no cached copy. Build will proceed WITHOUT vault context.
+
+Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here.
+
+**`degraded`** (standards mode — the vault loaded but its `INDEX.md` is missing, unparseable, empty or names no file in the fetched tree, or the engine could not check it at all (`vault_index_unchecked`: the cached manifest records no file list, or the check faulted — this says nothing about `INDEX.md` itself); `check vault.status` sets `status: degraded` and a `reason` of the form `vault_index_*`):
+
+Print `${VAULT_MESSAGE}` verbatim — the engine built it; do not restate or paraphrase it here. With `VAULT_REQUIRED` false it is the degraded-index warning, naming `INDEX.md`, what was measured and the repair: surface it and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` true this row is reachable only after an accepted attributed override (`PP_VAULT_OVERRIDE_REASON`) suppressed the block at the enforcer (D-25), and the message is the override notice naming the suppressed `vault_index_*` reason (or the block text naming `INDEX.md`, if the override reached only the enforcer's own call): print it and the envelope's `override` record when present, and continue without a prompt — the override is the acknowledgment and is already recorded in the envelope the enforcer acted on. The standards-mode practice clause is unchanged from Phase 13. Build proceeds without a usable index; the `## INDEX` section of `.planning/vault/SUMMARY.md` names the degradation.
+
+---
+
+## Ref drift (policy off) — applies to the client-tier arm of both columns
+
+When `VAULT_REF_DRIFT` is `true`, append the following paragraph to the selected client-tier
+message before surfacing it (D-08-24, rendered here per D-08-29 so the JSON envelope stays
+byte-identical with the policy off):
+
+> ⚠ Ref drift: this cache was fetched from `` `${VAULT_REF}` `` but `.platform-bindings.json` configures `` `client.vaultRef: ${VAULT_CONFIGURED_REF}` `` — what loaded is not the configured ref, so the standards applied may not be the client's current ones. With `vault.required` off this is a warning; run `pp-tools vault fetch` to load the configured ref, then re-run `pp-tools check vault.status`.
+
+Reachability: with `VAULT_REQUIRED` on, drift has already stopped the run at the enforcer
+(`client_vault_ref_drifted_from_configured`, plan 08-01), so this paragraph is reached **only**
+with the policy off — which is the schema default, and therefore the state most operators are in.
+The facts it names come from `VAULT_CONFIGURED_REF` (a `.platform-bindings.json` read) and
+`VAULT_REF` (an existing envelope field); no new envelope key is consulted, and none is added.
+Appending this paragraph is the only change the client-tier arms take — their success wording is
+unchanged, because plan 08-02's router success line is the gate SURFACE for a clean pass (D-08-20)
+and a second rendering of it here would be a copy that can drift.
+
+---
+
+## Stale suffix (applies to all statuses)
+
+When `VAULT_STALE` is `true`, append ` (cache is \`${VAULT_AGE}\` old)` to the selected message before surfacing it to the user.
+
+---
+
+## Surfacing mode (`--auto` / `--chain`)
+
+When `AUTO_MODE` is `true`: **do not display an interactive prompt.** Print the selected message
+(including the stale suffix when applicable) as a log line, so a non-interactive pipeline run leaves
+an auditable record of the load state that was in effect.
+
+This is a **presentation choice only**. It does not decide anything: whether the run proceeds was
+settled by the enforcer before this file was read, identically in interactive and unattended runs.
+
+---
+
+## Confirmation (interactive mode)
+
+When `AUTO_MODE` is `false` and `VAULT_REQUIRED` is `false`:
+
+Use `AskUserQuestion` to surface the selected message and await `confirmed`. In TEXT_MODE (`--text` in `$ARGUMENTS`), replace `AskUserQuestion` with a plain-text prompt and accept a typed `confirmed`. With the policy off the gate is advisory: proceeding after `confirmed` (or with a timeout / empty input) is allowed, exactly as before.
 
-**Otherwise relay the printed card to the user verbatim**, then act on `VAULT_ACTION` only:
+When `VAULT_REQUIRED` is `true`, do not prompt at all — see the policy section above.
 
-| `VAULT_ACTION` | What to do |
-|---|---|
-| `none` | The vault is disabled — continue silently. |
-| `proceed` | The client vault is loaded — show the card and continue. |
-| `confirm` | Degraded and `vault.required` is false. Interactive: ask for an explicit `confirmed` (`AskUserQuestion`; in TEXT_MODE — `--text` in `$ARGUMENTS` — a plain-text prompt accepting a typed `confirmed`), then continue. With `--auto` / `--chain` in `$ARGUMENTS`: log the card and continue without prompting. |
-| `stop` | The fence already exited non-zero: `vault.required` is true and the client vault is not loaded. **STOP** in every mode (including `--auto` / `--chain`); the operator fixes what the card names and re-runs. |
+`TEXT_MODE` follows the same rule as the host workflow (`--text` in `$ARGUMENTS`): replace `AskUserQuestion` with a plain-text numbered prompt.