@pareto4/pp-core 1.13.0 → 1.18.0

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` capability, 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` capability, 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` capability, 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` capability, 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` capability, 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` capability, 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,227 @@
-# 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)
+# 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
 ```
 
-**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.
+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.
+
+---
+
+## §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`, 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`** (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. 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`, 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`** (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. 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.

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

@@ -0,0 +1,147 @@
+# `verify:post` capability gate dispatch — enforce, do not decorate (TGATE-02, D-05)
+
+Extracted from `execute-phase.md` so the host loop body keeps shrinking, per ADR-857 Phase 6.
+`steps/` files are outside `tests/workflow-size-baseline.json` by design; the host is not, and the
+phase-6 ratchet on the host is a ratchet-DOWN that is never re-baselined. This is the second
+application of that pattern in this workflow — `steps/execute-pre-dispatch.md` is the first — and it
+is the mechanism rather than a workaround: every inline candidate for this body measured over the
+host's remaining headroom, while the labelled Read the host gained costs under a hundred bytes.
+
+This step is dispatched from two callers: `execute-phase.md`'s end-of-phase verification step, and
+`verify-work.md`'s issues-are-zero branch. Each Reads it immediately after it has
+`VERIFY_POST_HOOKS_JSON` in scope. It exists because **rendering is not enforcing**: every
+`verify:post` call site in this repository resolved STEP-kind hooks only, so a gate declared at this
+point would have rendered and been silently ignored — the decorative-dispatch defect already found
+once at the execute-side point. This file is what makes the declaration enforce.
+
+Read the `activeHooks` array from the printed `VERIFY_POST_HOOKS_JSON=` line, in-context (do NOT pipe it through a
+shell parser).
+
+**Admission first (D-28, D-05).** Both callers Read this file unconditionally right after rendering
+`verify:post`, so this is where the strict point refuses a config the gate could not read. It
+precedes the inert branch below because a broken config renders no gate and would take that branch.
+Without `.platform-bindings.json` it is inert and prints nothing.
+
+```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_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
+```
+
+**If `activeHooks` is empty or absent, or contains no entry where `kind == "gate"` and a
+`check.query` is present:** skip the rest of this file silently. Print nothing. This branch comes
+first deliberately — it is what keeps a project with no active `verify:post` capability
+structurally inert, and a gate paragraph reached before it would fire on a project that never
+enabled the capability at all.
+
+The predicate tests BOTH conditions, which is the predicate `ship.md`'s generic loop tests. Until
+04-12 it tested only the first, and that looser form was **harmless rather than correct**: an entry
+carrying no `check.query` would have reached the enforcer, whose own loop filters it out — so the
+right behaviour came from another file's guard rather than from this one's, and no predicate gate
+is declared at this point today that would have exposed the difference. A guard that is correct by
+another file's behaviour is one edit away from being wrong.
+
+**Otherwise, dispatch the gate.** Set:
+
+- `GATE_POINT=verify:post` — the loop point label, message text only.
+- `GATE_HOOKS_JSON=$VERIFY_POST_HOOKS_JSON` — the payload the host already rendered above; this
+  file never renders hooks itself.
+- `GATE_POSITIONAL_ARG="${PHASE_DIR}"` — the phase directory, which the host already has in scope
+  on the line after the render.
+- `GATE_UNPAIRED=strict` — **but only on a FULL-PHASE run: when the host's `WAVE_FILTER` is unset
+  AND this invocation carried no `--gaps-only`.** On a full-phase run this is one of the two points
+  at which every plan must already have an executed counterpart, so a
+  plan artifact with no summary counterpart is a real defect here rather than the normal
+  mid-lifecycle state it is at `plan:post` and `execute:wave:post`. When **either** of those
+  partial-execution modes is active, do not set `GATE_UNPAIRED` at all.
+
+  Four facts a future editor needs before touching this condition (04-12, CR-04; 04-18, WR-01).
+  The condition is on **partial execution**, not on one flag — read all four before adding a fifth
+  mode, because two of these were written when the condition named `WAVE_FILTER` alone and the
+  omission of the other mode shipped a halt onto a supported command. **One:** a
+  `--wave N` run legitimately leaves every later-wave plan holding a PLAN.md and no SUMMARY.md —
+  that is what the mode is *for*, and the host sets `WAVE_FILTER` from `--wave N` during argument
+  parsing, filters the plan list on it, and runs a wave-safety check on it, all before this point.
+  **Two:** this step runs **before** the host's `handle_partial_wave_execution` step, which is the
+  step that exists precisely to handle an incomplete phase — so an unconditional strict verdict
+  here is a false halt on a supported execution mode reached *ahead of* the code that would have
+  explained it, and the gate is declared `blocking: true` / `onError: halt`, so the user cannot
+  advance to the next wave at all. **Three:** the `ship:pre` caller is deliberately **not**
+  conditioned the same way and must not be "harmonised" with this one. Its preflight requires
+  `verification.status == passed` before its gate loop is reachable, so a ship run is by
+  construction a full-phase run: it has no partial mode and therefore no false halt to fix. The
+  asymmetry between the two strict points is the whole finding.
+
+  **Four:** `--gaps-only` is a partial-execution mode in exactly the sense `--wave N` is, and the
+  original condition did not cover it — the prose here even asserted `--wave N` was "the third
+  mid-lifecycle case", which made a complete-sounding enumeration out of an incomplete one. The
+  host filters the plan list on `--gaps-only` on the same line it filters on `WAVE_FILTER`, so a
+  gaps-only run legitimately leaves every **non**-gap plan holding a PLAN.md and no SUMMARY.md.
+  With the condition keyed to `WAVE_FILTER` alone, such a run reached this gate with `WAVE_FILTER`
+  unset, set `GATE_UNPAIRED=strict`, and drew `coverage_pair_missing` / `block: true` on those
+  untouched plans — a hard halt, on a `blocking: true` / `onError: halt` hook, that the user cannot
+  advance past. And `handle_partial_wave_execution` does not rescue it twice over: it guards on
+  `WAVE_FILTER` only, and it runs *after* this point regardless. Worst of all, the host documents
+  `/pp:execute-phase {X} --gaps-only` (with the workstream flag) as the gap-closure cycle's **own**
+  command — so the halt landed on the documented remedy for a failed verification, i.e. on the next
+  pass of the very loop this gate serves. The workstream placeholder is deliberately NOT written out
+  here: this file emits no command, and the token carries a substitution obligation that only a file
+  which does emit one should take on.
+
+  **Why this is keyed to the flag and not to a plan count.** `--wave N` is bound to a named host
+  variable; `--gaps-only` is not — the host's argument parsing says it "keeps its current meaning"
+  and every later reference is to the flag by name. So the flag is the only form available at this
+  point, and using it matches how the host itself tests this mode. Keying instead on "no incomplete
+  plans remain" would be a better invariant and would cover the *next* mode without an edit, but
+  that count does not exist yet here: the post-execution plan index is computed inside
+  `handle_partial_wave_execution`, one step **later**. Moving the count earlier is a host edit, and
+  the host is under a ratchet-down byte budget this file exists to protect. If a future change puts
+  an incomplete-plan count in scope at this point, prefer it to both flags and delete this fact.
+
+  The tolerant path is reached by leaving `GATE_UNPAIRED` **unset**, never by setting it to the
+  literal `tolerant`. The enforcer emits this parameter as a two-expansion flag pair specifically so
+  an unset variable contributes no word at all and the command line stays byte-identical to the one
+  that shipped before the parameter existed. An editor who writes the tolerant literal instead gets
+  a command line that works for a different reason — its equivalence to the unset case is the
+  router's tolerance of an explicit value, not the enforcer's contract — and the next parameter
+  added to that line inherits the confusion.
+
+Set **no** `GATE_WS`: a phase **directory** already carries the workstream partition — the
+enforcer's own parameter table says so — so the flag is neither needed nor set. Set **no**
+`GATE_STAGE`: this point validates BOTH stages, exactly as the `execute:post` caller deliberately
+omits it, and that omission is the documented invariant rather than an oversight to tidy up later.
+
+**A caller exposing neither partial-execution mode is a full-phase run by construction, and therefore
+strict.** The condition above is written for the host, which binds `WAVE_FILTER` during argument
+parsing and parses `--gaps-only`. `/pp-verify-work` binds neither, so both of its tests are vacuously
+satisfied and the strict value applies on every one of its runs. That is the right verdict rather
+than an accident of the wording: a UAT pass is a whole-phase judgement, and it is the point at which
+that workflow marks the phase complete in ROADMAP.md and STATE.md, so a plan artifact with no
+executed counterpart is exactly the defect the strict value exists to catch — not the normal
+mid-lifecycle state it is at `plan:post` and `execute:wave:post`. The obligation that places on the
+next caller: if one ever grows a partial-execution mode, it owes this condition the same two tests
+the host already answers, written here rather than assumed at the call site.
+
+Then Read and follow `pp-core/workflows/execute-phase/steps/check-query-gate.md` — the single
+generic `check.query` gate enforcer (GATE-02, D-VH-7). **It owns the halt decision**, the two-step
+contract and the `message` passthrough. Do not restate its loop here, and do not interpret its
+verdict here: a third enforcement loop is precisely what that enforcer was created to prevent, and
+two were already collapsed into it.
+
+**After the enforcer returns, certify the phase's end anchors — on a full-phase run only.** The
+enforcer halts on a blocking verdict, so this paragraph is reached only when it let the run go on;
+nothing here assumes the phase is clean from that. On a full-phase run (the same two tests that set
+`GATE_UNPAIRED=strict` above: `WAVE_FILTER` unset and no `--gaps-only`), run
+`pp_run vault anchor certify "${PHASE_DIR}" --raw`, print its one-line result, and continue
+regardless. On a `--wave N` or `--gaps-only` run, skip it: the verb's own strict check would block on
+the plans not yet run, so it could only refuse `not-clean`. The verb re-runs
+`check vault.trace "${PHASE_DIR}" --unpaired strict` itself and records each SUMMARY's end anchor in
+the directory's `.vault-certificates.json` only when that check answers clean with no override, so
+this step can never certify what the gate did not pass (D-107, D-108). A skipped or failed step
+certifies nothing, which only widens the next phase's SEAL-01 reach and never hides a commit (D-110).
+The verb prints nothing unless `vault admission` answers `on` (no `.platform-bindings.json`, or the
+vault off), so print nothing yourself then either. Every result (a certificate, `kept`, or a
+refusal such as `not-clean` or `overridden`) is printed, never retried, and never halts. No bash fence: this file carries one
+launcher preamble, in the admission fence, and this step needs no second one.