@pareto4/pp-core 1.17.1 → 1.19.0

package/pp-core/workflows/vault-write-back.md

@@ -1,11 +1,10 @@
 <purpose>
-Take one local practice file from preview to a confirmed, pushed promotion into the client
-vault — and nothing more. This workflow is the single human gate in front of an
-irreversible outward action: it shows the operator the complete preview, asks once whether
-to proceed, and only on explicit approval re-invokes the same guarded CLI arm in confirmed
-mode. It never authors, edits, or reformats the practice file, and it performs no direct git
-operation of its own — every outward action happens inside the promote verb, which this
-workflow only calls.
+Take one local standards document from preview to a confirmed, pushed promotion into the client
+vault, together with its INDEX.md entry, and nothing more. This workflow is the single human gate
+in front of an irreversible outward action: it shows the operator the complete preview, asks once
+whether to proceed, and only on explicit approval re-invokes the same guarded CLI verb in confirmed
+mode. It never authors, edits or reformats the document, and it performs no git operation of its
+own; every outward action happens inside `pp_run vault standards promote`.
 </purpose>
 
 <required_reading>
@@ -15,79 +14,67 @@ Read all files referenced by the invoking prompt's execution_context before star
 <process>
 
 <step name="text_mode">
-Resolve `TEXT_MODE` here, before the first question, mirroring the same resolution `init.md`
-does before its own first prompt. Set `TEXT_MODE=true` if `--text` is present in
-`$ARGUMENTS`. When `TEXT_MODE` is active, replace every `AskUserQuestion` call in this
-workflow — including the gate in Step 4 — with a plain-text numbered list, and ask the
-operator to type their choice number. This is required because non-Claude runtimes have no
-interactive question tool, and the confirmation in Step 4 is the entire point of this
-workflow — it must degrade to plain text, never disappear.
-</step>
-
-<step name="resolve_launcher">
-Resolve the `pp_run` launcher shim before any other step, so every call below goes through
-the repo-local or installed `pp-tools` binary rather than assuming a global install:
-
-```bash
-```
+Set `TEXT_MODE=true` if `--text` is present in `$ARGUMENTS`. When `TEXT_MODE` is active, replace
+every `AskUserQuestion` call in this workflow, including the gate below, with a plain-text numbered
+list, and ask the operator to type their choice number. The confirmation is the point of this
+workflow: it must degrade to plain text, never disappear.
 </step>
 
 <step name="resolve_input">
-Take the practice file path from `$ARGUMENTS` (the first token that is not `--text`). When
-none was given, ask the operator for one with a plain prompt:
+Take from `$ARGUMENTS`:
 
-```text
-Path to the local practice file to promote (e.g. practices/my-practice.md):
-```
+- the document path: the first token that is not a flag (required; ask for it with a plain prompt
+  when it is missing: `Path to the local standards document to promote (e.g. docs/standards/api-errors.md):`);
+- `--path <vault-path>`: where the document goes in the vault (optional; defaults to
+  `standards/<file name>`);
+- `--entry "<what it is>; used when <…>"`: the document's INDEX.md entry text (required when the
+  vault's INDEX.md does not list the document yet; replaces the existing line when given for a
+  listed document);
+- `--section <title>`: the INDEX.md `##` section a new entry goes under (optional).
+
+When the document is new to the vault and no `--entry` was given, ask the operator for one plain
+sentence of the form `<what the document is>; used when <when a plan should follow it>`. Never
+invent it.
 
-Do not compose, author, rewrite, or reformat the practice file at this or any later step —
-authoring stays outside this guarded path entirely. Whatever bytes are on disk right now at
-that path are exactly the bytes that will be previewed and, if approved, pushed.
+Do not compose, rewrite or reformat the document at this or any later step. Whatever bytes are on
+disk at that path are exactly the bytes that will be previewed and, if approved, pushed.
 
 ```bash
-PRACTICE_FILE="<the resolved path>"
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+DOC_FILE="<the resolved path>"
+PROMOTE_ARGS=()   # add --path, --entry and --section with their values, as given
 ```
 </step>
 
 <step name="preview">
-Run the promote verb with the file path and `--raw`, capturing stdout, stderr, and the exit
-code. This invocation performs no outward action — it only clones into a disposable
-directory, computes the diff, and reports.
+Run the promote verb without `--confirmed`, capturing stdout, stderr and the exit code. This
+invocation performs no outward action: it clones the client vault into a disposable directory,
+writes the change there, and reports the diff.
 
 ```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
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PROMOTE_PREVIEW_OUT=$(mktemp)
 PROMOTE_PREVIEW_ERR=$(mktemp)
-pp_run vault practices promote "$PRACTICE_FILE" --raw >"$PROMOTE_PREVIEW_OUT" 2>"$PROMOTE_PREVIEW_ERR"
+pp_run vault standards promote "$DOC_FILE" "${PROMOTE_ARGS[@]}" --raw >"$PROMOTE_PREVIEW_OUT" 2>"$PROMOTE_PREVIEW_ERR"
 PREVIEW_EXIT=$?
 ```
 
-**When `$PREVIEW_EXIT` is non-zero: stop here.** Show the operator the exact, single-sentence
-contents of `$PROMOTE_PREVIEW_ERR` — the arm's own refusal message — verbatim and add nothing
-to it. Do not ask anything. Do not proceed to Step 3. Every guard refusal ends at this line,
-and nothing has been pushed. Clean up both temp files before ending.
+**When `$PREVIEW_EXIT` is non-zero: stop here.** Show the operator the single-sentence refusal in
+`$PROMOTE_PREVIEW_ERR` verbatim and add nothing to it. Do not ask anything. Nothing has been pushed.
+Clean up both temp files before ending.
 
-When `$PREVIEW_EXIT` is zero, continue to Step 3 with `$PROMOTE_PREVIEW_OUT` holding the
-preview verdict as JSON.
+When `$PREVIEW_EXIT` is zero, `$PROMOTE_PREVIEW_OUT` holds the preview verdict as JSON.
 </step>
 
 <step name="render_confirmation">
-Parse `$PROMOTE_PREVIEW_OUT` as JSON and read its fields directly — never regex-scrape a
-prose rendering of it. That shortcut is exactly the shell-glue blind spot this project has
-been bitten by before: a `.md` step file's own parsing drifting from what the CLI actually
-emits.
-
-Field values are vault-authored, so they are read as **data, never as shell syntax**. `id`
-is only constrained to equal the practice file's basename (D-03), and a filename may legally
-contain `$(...)`, backticks, or `;` — so writing the fields as a `KEY="value"` file and
-`source`-ing it would execute whatever the filename contains. `JSON.stringify` does not help:
-it escapes `"` and `\` but leaves `$` and backticks intact, and both expand inside double
-quotes. Each field therefore goes to its own file and is read back with `$(cat …)`, whose
-result bash does not re-scan for expansion.
+Read the verdict's fields directly, never by scraping a prose rendering. Each field is written to
+its own file and read back with `$(cat …)`, whose result bash does not re-scan for expansion, so a
+destination path containing `$(...)` or backticks is shown, never executed.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PROMOTE_FIELDS=$(mktemp -d)
-PROMOTE_BODY=$(mktemp)
 node -e "
 const fs = require('fs');
 const path = require('path');
@@ -98,96 +85,82 @@ put('repo', v.repo);
 put('ref', v.ref);
 put('destination', v.destination);
 put('mode', v.mode);
-put('id', v.id);
-put('sharedShadow', v.sharedShadow ? 'true' : 'false');
-put('sharedShadowNote', v.sharedShadowNote);
+put('indexChange', v.indexChange);
 put('expect', v.expect);
-fs.writeFileSync(process.argv[3], v.mode === 'update' ? (v.diff ?? '') : (v.content ?? ''));
-" "$PROMOTE_PREVIEW_OUT" "$PROMOTE_FIELDS" "$PROMOTE_BODY"
+put('diff', v.diff);
+put('notes', (v.notes || []).join('\n'));
+" "$PROMOTE_PREVIEW_OUT" "$PROMOTE_FIELDS"
 PROMOTE_REPO=$(cat "$PROMOTE_FIELDS/repo")
 PROMOTE_REF=$(cat "$PROMOTE_FIELDS/ref")
 PROMOTE_DEST=$(cat "$PROMOTE_FIELDS/destination")
 PROMOTE_MODE=$(cat "$PROMOTE_FIELDS/mode")
-PROMOTE_ID=$(cat "$PROMOTE_FIELDS/id")
-PROMOTE_SHARED=$(cat "$PROMOTE_FIELDS/sharedShadow")
-PROMOTE_SHARED_NOTE=$(cat "$PROMOTE_FIELDS/sharedShadowNote")
+PROMOTE_INDEX=$(cat "$PROMOTE_FIELDS/indexChange")
 PROMOTE_EXPECT=$(cat "$PROMOTE_FIELDS/expect")
 ```
 
-Show the operator, in this exact order, reading every value from the parsed fields above —
-never truncated, summarized, or collapsed to "the first N lines":
+Show the operator, in this order, never truncated or summarised:
 
 1. The target vault repository (`$PROMOTE_REPO`) and ref (`$PROMOTE_REF`).
-2. The destination path inside that repository (`$PROMOTE_DEST`).
-3. Whether this **creates** a new practice or **updates** an existing one
-   (`$PROMOTE_MODE`, for id `$PROMOTE_ID`).
-4. When `$PROMOTE_SHARED` is `true`, the shared-vault disclosure sentence verbatim from
-   `$PROMOTE_SHARED_NOTE` — this id also exists in the shared Pareto vault, and promoting it
-   here makes the client's version the one that applies for this client.
-5. One line stating plainly that the secret scan already run inside the promote verb found
-   nothing in this file — a file that failed that scan would have refused before a preview
-   was ever produced, so reaching this line already proves the scan passed.
-6. The complete contents of `$PROMOTE_BODY` — the full diff when `$PROMOTE_MODE` is
-   `update`, or the full new-file content when it is `create`. Show every byte; the operator
-   is about to approve exactly these bytes, so nothing here may be shortened.
+2. The destination path in the vault (`$PROMOTE_DEST`), and whether this **creates** a new
+   standards document or **updates** an existing one (`$PROMOTE_MODE`).
+3. What happens to INDEX.md (`$PROMOTE_INDEX`): `added` (a new line), `replaced` (its line gets the
+   new entry text) or `unchanged`.
+4. One line stating that the secret scan inside the promote verb found nothing; a document that
+   failed it would have been refused before any preview existed.
+5. Any notes in `$PROMOTE_FIELDS/notes`.
+6. The complete contents of `$PROMOTE_FIELDS/diff`: the document and the INDEX.md change, every
+   byte. The operator is about to approve exactly these bytes.
 </step>
 
 <step name="gate">
-Ask the operator with `AskUserQuestion` (or a numbered plain-text prompt when `TEXT_MODE` is
-active) whether to push this to the client vault. Offer exactly two outcomes — there is no
-default, no timeout, and no auto-advance, because this is an irreversible outward action and
-this confirmation is the whole review step:
+Ask once whether to push. Exactly two outcomes, no default, no timeout, no auto-advance:
 
 ```text
 AskUserQuestion([
   {
     header: "Push to client vault",
-    question: "Push this practice to the client vault now?",
+    question: "Push this standards document to the client vault now?",
     multiSelect: false,
     options: [
-      { label: "Push it", description: "Push exactly the diff/content shown above" },
+      { label: "Push it", description: "Push exactly the diff shown above" },
       { label: "Stop", description: "Do not push anything — the vault stays unchanged" }
     ]
   }
 ])
 ```
 
-**When the operator chooses to stop:** print one sentence saying nothing was pushed and the
-client vault is unchanged, clean up the temp files, and end the workflow here.
+**When the operator chooses to stop:** say in one sentence that nothing was pushed and the client
+vault is unchanged, clean up the temp paths, and end.
 
-**When the operator chooses to push:** continue to Step 5.
+**When the operator chooses to push:** continue.
 </step>
 
 <step name="push">
-Only inside this approved branch, run the promote verb again with the same file path, the
-confirmed flag, the expect token carried verbatim from the preview verdict, and `--raw`. This
-workflow never runs an outward git operation itself — the only thing it does here is invoke
-this verb a second time; every push, every commit, and every other outward action happens
-inside the verb, not in this shell block.
+Only inside this approved branch, run the verb again with the same arguments, `--confirmed`, and the
+expect token carried verbatim from the preview.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PROMOTE_PUSH_OUT=$(mktemp)
 PROMOTE_PUSH_ERR=$(mktemp)
-pp_run vault practices promote "$PRACTICE_FILE" --confirmed --expect "$PROMOTE_EXPECT" --raw >"$PROMOTE_PUSH_OUT" 2>"$PROMOTE_PUSH_ERR"
+pp_run vault standards promote "$DOC_FILE" "${PROMOTE_ARGS[@]}" --confirmed --expect "$PROMOTE_EXPECT" --raw >"$PROMOTE_PUSH_OUT" 2>"$PROMOTE_PUSH_ERR"
 PUSH_EXIT=$?
 ```
 
-**When `$PUSH_EXIT` is non-zero:** show the arm's own single-sentence refusal from
-`$PROMOTE_PUSH_ERR` verbatim and end — the arm has already guaranteed nothing was pushed on a
-refusal. A concurrent-edit refusal here is expected, ordinary behavior: it means someone else
-changed this same practice in the client vault between the preview in Step 2 and this push.
-The remedy is simply to run this workflow again from the top — the new preview will diff
-against their current version. Clean up all temp files before ending.
-
-When `$PUSH_EXIT` is zero, continue to Step 6 with `$PROMOTE_PUSH_OUT` holding the push
-verdict as JSON.
+**When `$PUSH_EXIT` is non-zero:** show the verb's single-sentence refusal from `$PROMOTE_PUSH_ERR`
+verbatim and end; a refusal guarantees nothing was pushed. A concurrent-edit refusal is ordinary:
+someone changed the document or INDEX.md in the vault since the preview. The remedy is to run this
+workflow again from the top. Clean up all temp paths before ending.
 </step>
 
 <step name="report">
-Parse `$PROMOTE_PUSH_OUT` the same way Step 3 parsed the preview verdict — direct field
-reads, never a prose scrape:
+Read the push verdict's fields the same way, then show the operator the repository, the destination,
+the new commit, what happened to INDEX.md, and whether the local vault cache was refreshed. When the
+refresh did not succeed, say so plainly: the next vault fetch picks the change up; the push itself
+succeeded.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 node -e "
 const fs = require('fs');
 const v = JSON.parse(fs.readFileSync(process.argv[1], 'utf8'));
@@ -195,19 +168,14 @@ process.stdout.write(
   'repo=' + (v.repo ?? '') + '\n' +
   'destination=' + (v.destination ?? '') + '\n' +
   'commit=' + (v.commit ?? '') + '\n' +
+  'indexChange=' + (v.indexChange ?? '') + '\n' +
   'cacheRefreshed=' + String(!!v.cacheRefreshed) + '\n'
 );
 " "$PROMOTE_PUSH_OUT"
 ```
 
-Show the operator: the repository, the destination path, the new commit the push produced,
-and whether the local read cache of the vault was refreshed. When the local cache refresh did
-not succeed, say so plainly and note that the next vault fetch will pick up the change — this
-is a cosmetic staleness in the local cache only, not a sign the push failed.
-
-Clean up every temp path created in this workflow (`$PROMOTE_PREVIEW_OUT`,
-`$PROMOTE_PREVIEW_ERR`, `$PROMOTE_BODY`, `$PROMOTE_PUSH_OUT`, `$PROMOTE_PUSH_ERR`, and the
-`$PROMOTE_FIELDS` **directory**, which needs `rm -rf`) before ending.
+Clean up every temp path created in this workflow (`$PROMOTE_PREVIEW_OUT`, `$PROMOTE_PREVIEW_ERR`,
+`$PROMOTE_PUSH_OUT`, `$PROMOTE_PUSH_ERR`, and the `$PROMOTE_FIELDS` directory with `rm -rf`).
 </step>
 
 </process>

package/pp-core/workflows/verify-phase.md

@@ -38,6 +38,7 @@ Extract from init JSON: `phase_dir`, `phase_number`, `phase_name`, `has_plans`,
 
 Then load phase details and list plans/summaries:
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 pp_run query roadmap.get-phase "${phase_number}"
 grep -E "^| ${phase_number}" .planning/REQUIREMENTS.md 2>/dev/null || true
 ls "$phase_dir"/*-SUMMARY.md "$phase_dir"/*-PLAN.md 2>/dev/null || true
@@ -57,6 +58,7 @@ Extract **phase goal** from ROADMAP.md (the outcome to verify, not tasks), **req
 Use `pp-tools.cjs query` verify handlers (or legacy pp-tools) to extract must_haves from each PLAN:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 for plan in "$PHASE_DIR"/*-PLAN.md; do
   MUST_HAVES=$(pp_run query frontmatter.get "$plan" --field must_haves)
   echo "=== $plan ===" && echo "$MUST_HAVES"
@@ -124,6 +126,7 @@ For each truth: identify supporting artifacts → check artifact status → chec
 Use `pp-tools.cjs query verify.artifacts` (or legacy pp-tools) for artifact verification against must_haves in each PLAN:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 for plan in "$PHASE_DIR"/*-PLAN.md; do
   ARTIFACT_RESULT=$(pp_run query verify.artifacts "$plan")
   echo "=== $plan ===" && echo "$ARTIFACT_RESULT"
@@ -167,6 +170,7 @@ wiring or leftover code from plan revisions.
 Use `pp-tools.cjs query verify.key-links` (or legacy pp-tools) for key link verification against must_haves in each PLAN:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 for plan in "$PHASE_DIR"/*-PLAN.md; do
   LINKS_RESULT=$(pp_run query verify.key-links "$plan")
   echo "=== $plan ===" && echo "$LINKS_RESULT"
@@ -223,6 +227,7 @@ phase.
 no `<decisions>` block.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 GATE_CFG=$(pp_run query config-get workflow.context_coverage_gate 2>/dev/null || echo "true")
 if [ "$GATE_CFG" != "false" ]; then
   # Discover the phase CONTEXT.md via glob expansion rather than `ls | head`

package/pp-core/workflows/verify-work.md

@@ -38,6 +38,7 @@ If $ARGUMENTS contains a phase number, load context:
 
 ```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
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 GSD_WS=""
 echo "$ARGUMENTS" | grep -qE -- '--ws[[:space:]]+[^[:space:]]+' && GSD_WS=$(echo "$ARGUMENTS" | grep -oE -- '--ws[[:space:]]+[^[:space:]]+')
 PHASE_ARG=$(echo "$ARGUMENTS" | sed -E 's/--ws[[:space:]]+[^[:space:]]+//g' | xargs)
@@ -51,6 +52,7 @@ AGENT_SKILLS_CHECKER=$(pp_run query agent-skills pp-plan-checker)
 Parse JSON for: `planner_model`, `checker_model`, `commit_docs`, `phase_found`, `phase_dir`, `phase_number`, `phase_name`, `has_verification`, `uat_path`.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 # MVP mode detection via the centralized phase.mvp-mode resolver.
 # verify-work has no --mvp CLI flag (mode is inherited from the planned phase),
 # so we omit --cli-flag — the verb falls through roadmap → config → false.
@@ -111,6 +113,7 @@ Continue to `create_uat_file`.
 Before UAT, check UI capability activation and whether Playwright/Puppeteer MCP tools are available.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PLAN_HOOKS_JSON=$(pp_run loop render-hooks plan:pre --raw)
 UI_SPEC_FILE=$(ls "${PHASE_DIR}"/*-UI-SPEC.md 2>/dev/null | head -1)
 ```
@@ -148,6 +151,7 @@ UI checkpoints: {N} auto-verified, {M} queued for manual review
 Use `phase_dir` from init (or run init if not already done).
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 ls "$phase_dir"/*-SUMMARY.md 2>/dev/null || true
 ```
 
@@ -167,6 +171,7 @@ When `MVP_MODE=false` (mode is null, absent, or the phase has no `**Mode:**` lin
 **User-story format guard.** When `MVP_MODE=true`, also verify the phase's goal is in User Story format via the centralized validator:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PHASE_GOAL=$(pp_run query roadmap.get-phase "${phase_number}" ${GSD_WS} --pick goal)
 USER_STORY_VALID=$(pp_run query user-story.validate --story "$PHASE_GOAL" --pick valid)
 if [ "$USER_STORY_VALID" != "true" ]; then
@@ -434,7 +439,7 @@ Clear Current Test section:
 
 Commit the UAT file:
 ```bash
-pp_run query commit "test({phase_num}): complete UAT - {passed} passed, {issues} issues" --files ".planning/phases/XX-name/{phase_num}-UAT.md"
+pp_run query commit "docs(planning): complete UAT - {passed} passed, {issues} issues" --phase "{phase_num}" --files ".planning/phases/XX-name/{phase_num}-UAT.md"
 ```
 
 Present summary:
@@ -458,12 +463,13 @@ Present summary:
 **If issues == 0:**
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 VERIFY_POST_HOOKS_JSON=$(pp_run loop render-hooks verify:post --raw)
 printf '%s' "$VERIFY_POST_HOOKS_JSON" | node -e "let h=[];try{h=JSON.parse(require('fs').readFileSync(0,'utf-8')).activeHooks||[]}catch{}console.log('VERIFY_POST_HOOKS_JSON='+JSON.stringify({activeHooks:h}))"
 SECURITY_FILE=$(ls "${PHASE_DIR}"/*-SECURITY.md 2>/dev/null | head -1)
 ```
 
-**Vault practice gates.** Read `pp-core/workflows/execute-phase/steps/verify-post-gate.md` — it
+**Vault gates.** Read `pp-core/workflows/execute-phase/steps/verify-post-gate.md` — it
 dispatches this point's blocking gates to the generic enforcer, which owns the halt. Rendering the
 payload above is not enforcing it, and the branch below marks the phase complete.
 
@@ -478,6 +484,7 @@ Skill(skill="pp-${ref.skill}", args="{phase}")
 After the skill returns, refresh `SECURITY_FILE`:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 SECURITY_FILE=$(ls "${PHASE_DIR}"/*-SECURITY.md 2>/dev/null | head -1)
 ```
 

package/scripts/gen-capability-registry.cjs

@@ -1247,8 +1247,7 @@ function validateGate(gate, prefix) {
  *   - contribution.into ∈ step's agentRoles, OR contribution.into names an agent
  *     already registered by some capability's own `agents` array (a non-pipeline
  *     consumer of the same loop point, e.g. code-review.md reading execute:post
- *     alongside execute-phase.md — see capabilities/vault-practices's
- *     execute:post -> pp-code-reviewer contribution)
+ *     alongside execute-phase.md)
  *   - when references a config key in cap.config
  *
  * NOTE: step.consumes satisfiability is NOT checked here — it requires the full
@@ -1331,78 +1330,9 @@ function validateAgainstContract(cap, capId, knownAgentIds) {
   return errors;
 }
 
-/**
- * Phase 15 D-02: validate the per-hook `vaultMode` filter field.
- *
- * The pure loop resolver evaluates `vaultMode` against an injected mode value
- * and never emits it, so an unknown or misplaced value must be refused HERE,
- * at generation, never interpreted at runtime. Three rules, each reported on
- * its own:
- *   (a) the field is allowed on contributions and gates only (a step is
- *       refused);
- *   (b) the value must be a string in the vault capability's declared
- *       `config["vault.mode"].values`. That enum declaration is the ONE owner of
- *       the closed set; it is read here, never restated. With no vault
- *       capability, or no such values array, there is no closed set and every
- *       `vaultMode` is refused (fail closed);
- *   (c) the declaring capability must be `vault` or list `vault` in `requires`,
- *       so a filtered hook can only exist where the vault gate's closure holds.
- *
- * Presence is own-property presence, so a JSON `null` is refused under (b).
- *
- * @param {Map<string, object>} capMap
- * @returns {string[]} error strings; empty = all pass
- */
-function validateVaultModeField(capMap) {
-  const errors = [];
-  const vaultCap = capMap.get('vault');
-  const modeDecl = vaultCap && vaultCap.config && typeof vaultCap.config === 'object'
-    ? vaultCap.config['vault.mode']
-    : undefined;
-  const allowed = modeDecl && Array.isArray(modeDecl.values)
-    ? modeDecl.values.filter((v) => typeof v === 'string')
-    : null;
-  const KINDS = [['steps', 'step'], ['contributions', 'contribution'], ['gates', 'gate']];
-  for (const [capId, cap] of capMap) {
-    if (!cap || typeof cap !== 'object') continue;
-    const prefix = 'capability "' + capId + '"';
-    const requiresVault = Array.isArray(cap.requires) && cap.requires.includes('vault');
-    for (const [arrKey, kind] of KINDS) {
-      const arr = Array.isArray(cap[arrKey]) ? cap[arrKey] : [];
-      for (const hook of arr) {
-        if (!hook || typeof hook !== 'object') continue;
-        if (!Object.prototype.hasOwnProperty.call(hook, 'vaultMode')) continue;
-        const where = prefix + ' ' + kind + ' at point "' + String(hook.point) + '"';
-        const value = hook.vaultMode;
-        if (kind === 'step') {
-          errors.push(where + ': vaultMode is allowed on contributions and gates only');
-        }
-        if (allowed === null) {
-          errors.push(
-            where + ': vaultMode ' + JSON.stringify(value) + ' cannot be checked: the vault capability ' +
-            'declares no "vault.mode" values, which own the closed set',
-          );
-        } else if (typeof value !== 'string' || !allowed.includes(value)) {
-          errors.push(
-            where + ': vaultMode ' + JSON.stringify(value) + ' is not one of [' + allowed.join(', ') +
-            '] (the closed set owned by the vault capability\'s "vault.mode" values)',
-          );
-        }
-        if (capId !== 'vault' && !requiresVault) {
-          errors.push(
-            where + ': vaultMode is allowed only on the "vault" capability or a capability that ' +
-            'lists "vault" in requires',
-          );
-        }
-      }
-    }
-  }
-  return errors;
-}
-
 /**
  * Quick 261015-ect (QD-13): the vault-family rule for `requiresPlatformBindings`,
- * the mirror of the vaultMode rule (c) above. A capability that is `vault` or
+ * A capability that is `vault` or
  * lists `vault` in `requires` MUST declare the field, so a vault-family
  * capability added later cannot render hooks on a project the vault does not
  * govern by forgetting it. A capability outside the family may declare it too.
@@ -1441,18 +1371,15 @@ const SEAL_FIELD_NAME = 'onRecordedArtifacts';
  * A gate carrying the field renders for an enabled, config-inactive capability
  * over recorded vault artifacts, bypassing the capability's active check and
  * its `when` (D-18). That is a widening of render behaviour, so the field is
- * closed HERE, at generation, to exactly the shape the two shipped seal gates
- * have. Six rules, each reported on its own:
+ * closed HERE, at generation, to exactly the shape the shipped seal gate has.
+ * Five rules, each reported on its own:
  *   (a) gates only (a step or contribution carrying it is refused);
  *   (b) the value is literal `true` (`"true"`, `1`, `null`, `false` refused);
- *   (c) the declaring capability lists `vault` in `requires` and is not `vault`
- *       itself (D-26: with the vault off the injected mode is null, so both
- *       modes' filtered gates pass and sealing the vault capability too would
- *       dispatch `check vault.trace` twice);
- *   (d) the gate also carries `vaultMode` (the resolver filters by mode BEFORE
- *       the predicate, research C-1);
- *   (e) the gate is `blocking: true`;
- *   (f) the point is `ship:pre` (D-21: the requirement's block point; a seal at
+ *   (c) the declaring capability is `vault` or lists `vault` in `requires`.
+ *       A seal gate never dispatches twice: the resolver drops it whenever its
+ *       capability is active, so it renders only with the vault switched off;
+ *   (d) the gate is `blocking: true`;
+ *   (e) the point is `ship:pre` (D-21: the requirement's block point; a seal at
  *       verify:post would halt execute-phase on a switch set on purpose).
  *
  * Presence is own-property presence.
@@ -1481,15 +1408,12 @@ function validateSealField(capMap) {
         if (value !== true) {
           errors.push(where + ': ' + SEAL_FIELD_NAME + ' must be literal true (got ' + JSON.stringify(value) + ')');
         }
-        if (capId === 'vault' || !requiresVault) {
+        if (capId !== 'vault' && !requiresVault) {
           errors.push(
-            where + ': ' + SEAL_FIELD_NAME + ' is allowed only on a capability that lists "vault" in requires ' +
-            'and is not "vault" itself',
+            where + ': ' + SEAL_FIELD_NAME + ' is allowed only on the "vault" capability or a capability that ' +
+            'lists "vault" in requires',
           );
         }
-        if (!Object.prototype.hasOwnProperty.call(hook, 'vaultMode')) {
-          errors.push(where + ': a gate carrying ' + SEAL_FIELD_NAME + ' must also carry vaultMode');
-        }
         if (hook.blocking !== true) {
           errors.push(where + ': a gate carrying ' + SEAL_FIELD_NAME + ' must be blocking: true');
         }
@@ -1662,10 +1586,6 @@ const TIER_RANK = { core: 0, standard: 1, full: 2 };
 function validateCrossCapability(capMap, centralKeys) {
   const errors = [];
 
-  // Phase 15 D-02: the per-hook vaultMode filter field (needs capMap to read the
-  // vault capability's closed value set and every capability's `requires`).
-  errors.push(...validateVaultModeField(capMap));
-
   // Phase 16 D-19: the per-hook seal field (needs capMap for every capability's
   // `requires`).
   errors.push(...validateSealField(capMap));
@@ -2841,7 +2761,6 @@ module.exports = {
   validateAgainstContract,
   validateConsumesGlobal,
   validateCrossCapability,
-  validateVaultModeField,
   validateSealField,
   validatePlatformBindingsField,
   SEAL_FIELD_NAME,

package/scripts/lint-test-file-count.allowlist.json

@@ -114,14 +114,6 @@
       ],
       "issue": "180"
     },
-    "vault-review": {
-      "files": [
-        "vault-review.integration.test.cjs",
-        "vault-review.security.test.cjs",
-        "vault-review.test.cjs"
-      ],
-      "issue": "71924 — Vault Assurance phase 06 (06-03/06-04), three distinct concerns for pp-core/bin/lib/vault-review.cjs: vault-review.test (06-03 unit tests over every pure derivation — the verdict vocabularies, both derived-N-A arms, the counts arithmetic, the range resolver and the clean-render refusal predicate), vault-review.integration.test (06-04 SEAM tests — the deterministic validator of the agent-written artifact, plus the `check vault-review` arm driven through the real pp-core/bin/pp-tools.cjs, where the exit-0/no-block-key contract of D-06-01 and VERIFY-03 is proved at the boundary a gate enforcer actually reads, with RED control 2 proving that guard non-vacuous), and vault-review.security.test (06-04 ADVERSARIAL tests — a spoofed external-content fence-end marker, directive-shaped text and a forged tool-call block planted in real practice BODIES, proving 05-REVIEW's open Critical CR-02 is not repeated on this surface, plus the CR-03 class: no absolute filesystem path in any emitted byte). The split mirrors the `vault` cluster's own reasoning: the unit lane, the CLI seam and the security marker are independently load-bearing verification gates, and the `.security.test.cjs` marker is what makes the adversarial lane identifiable to a reader and to scripts/run-tests.cjs. Consolidating would blur three different questions into one file."
-    },
     "verify": {
       "files": [
         "bug-2969-verify-reapply-patches.test.cjs",
@@ -189,22 +181,12 @@
       "files": [
         "feat-71924-vault-required-gate.test.cjs",
         "vault-doors.integration.test.cjs",
-        "vault-practices.property.test.cjs",
         "vault-read-path.test.cjs",
         "vault-security.test.cjs",
         "vault-status-check.test.cjs",
         "vault.test.cjs"
       ],
-      "issue": "v1.7.0 Client Vault Load — four distinct concerns: vault.test (fetch/status/summary unit), vault-security (VSEC-02/03 write-guard + secret/fence), vault-read-path (VGATE-03 SUMMARY pointer), vault-status-check (VGATE-02 gate-query handler). Phase 24-02 added vault-practices.property.test.cjs (fast-check fuzz of the practices glob-fallback compiler + a practices-frontmatter round-trip, PRAC-02) — it is grouped under this bucket rather than \"vault-practices\" because the test-file-count lint's hyphen-prefix matcher treats \"vault-practices.property\" (period before \"property\") as starting with \"vault-\" before it can match the more specific \"vault-practices-\" prefix; the module it actually tests is pp-core/bin/lib/vault-practices.cjs, not vault.cjs. Vault Assurance phase 02 (#71924) added feat-71924-vault-required-gate.test.cjs as the phase's ONE consolidated source-grep feature file — it owns the source-text assertions for GATE-02, GATE-03, GATE-06, GATE-08, GATE-09 and GATE-10 together, deliberately in a single file so the phase's six requirements do not each spawn a sibling; later plans in the phase extend it rather than adding files. Vault Assurance phase 16 plan 10 added vault-doors.integration.test.cjs as the phase's ONE door fence-proof owner (DOOR-01..05, D-09): every door's shipped fence (execute-plan, quick, fast, debug, the secondary doors) composed by tests/helpers/gate-fence-composer.cjs and run in bash and zsh, one describe per door plan, so 16-12..16-15 extend it rather than each adding a sibling. The hyphen-prefix matcher attributes it here because no vault-doors module exists; it tests workflow fences, not vault.cjs."
-    },
-    "vault-practices": {
-      "files": [
-        "vault-practices-examples.test.cjs",
-        "vault-practices-matcher.test.cjs",
-        "vault-practices.slow.test.cjs",
-        "vault-practices.test.cjs"
-      ],
-      "issue": "Phase 24 (24-01/24-02/24-04) — three distinct concerns for pp-core/bin/lib/vault-practices.cjs: vault-practices.test (24-01 parser/validation/discovery unit tests), vault-practices-matcher.test (24-02 glob matcher + two-bucket result + report unit tests), vault-practices-examples.test (24-04 shipped-example drift guard + minimal-comments global-bucket smoke case, PRAC-03 Success Criterion 3). All three test the same production module and are each independently load-bearing; consolidating would blur distinct plan-level verification gates. Vault Assurance phase 05 (#71924) added vault-practices.slow.test.cjs — the >5 s six-axis worst-case matcher corpus for the same production module (pp-core/bin/lib/vault-practices.cjs), split out per the .slow suffix convention so the default suite stays fast; attributed here once the count lint learned to strip the .slow suffix."
+      "issue": "v1.7.0 Client Vault Load — four distinct concerns: vault.test (fetch/status/summary unit), vault-security (VSEC-02/03 write-guard + secret/fence), vault-read-path (VGATE-03 SUMMARY pointer), vault-status-check (VGATE-02 gate-query handler). Vault Assurance phase 02 (#71924) added feat-71924-vault-required-gate.test.cjs as the phase's ONE consolidated source-grep feature file — it owns the source-text assertions for GATE-02, GATE-03, GATE-06, GATE-08, GATE-09 and GATE-10 together, deliberately in a single file so the phase's six requirements do not each spawn a sibling; later plans in the phase extend it rather than adding files. Vault Assurance phase 16 plan 10 added vault-doors.integration.test.cjs as the phase's ONE door fence-proof owner (DOOR-01..05, D-09): every door's shipped fence (execute-plan, quick, fast, debug, the secondary doors) composed by tests/helpers/gate-fence-composer.cjs and run in bash and zsh, one describe per door plan, so 16-12..16-15 extend it rather than each adding a sibling. The hyphen-prefix matcher attributes it here because no vault-doors module exists; it tests workflow fences, not vault.cjs."
     }
   }
 }