@pareto4/pp-core 1.17.1 → 1.18.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,64 @@ 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>"
+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
 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
 PROMOTE_FIELDS=$(mktemp -d)
-PROMOTE_BODY=$(mktemp)
 node -e "
 const fs = require('fs');
 const path = require('path');
@@ -98,94 +82,78 @@ 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
 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
 node -e "
@@ -195,19 +163,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-work.md

@@ -463,7 +463,7 @@ printf '%s' "$VERIFY_POST_HOOKS_JSON" | node -e "let h=[];try{h=JSON.parse(requi
 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.
 

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."
     }
   }
 }

package/scripts/lint-test-file-count.cjs

@@ -80,12 +80,11 @@ function prodPrefix(filename) {
 // stamps. Five forms are stripped: `.integration`, `.slow`, `.security`,
 // `.install` and the bare `.test`.
 //
-// `.property` is DELIBERATELY NOT stripped. The `vault` entry in
-// scripts/lint-test-file-count.allowlist.json documents
-// vault-practices.property.test.cjs as parked in that bucket precisely because
-// this function leaves the suffix on — stripping it would re-cluster the file
-// into `vault-practices` and turn that entry's own explanation into a false
-// statement. Changing it is a deliberate allowlist migration, not a tidy-up.
+// `.property` is DELIBERATELY NOT stripped: a `<name>.property.test.cjs` keeps
+// the suffix in its prefix, so the hyphen-prefix matcher clusters it under the
+// shortest matching module rather than under `<name>`. Stripping it would
+// re-cluster every property test the allowlist has already counted. Changing
+// it is a deliberate allowlist migration, not a tidy-up.
 function testEffectivePrefix(testName) {
   const bare = testName
     .replace(/\.(integration|slow|security|install)\.test\.(ts|cjs)$/, '')

package/scripts/prompt-injection-scan.sh

@@ -95,9 +95,6 @@ ALLOWLIST=(
   'tests/fixtures/adversarial/security/::a directory of adversarial corpus files whose entire purpose is to BE injection payloads for the suites above; measured 20 pattern hits across its 7 tracked files at HEAD on 2026-09-19'
   'tests/discovery-vault-context.test.cjs::the DISCO-03/SC4 suite plants a real role-manipulation line (the PLANTED constant) into a fixture vault document and asserts the shipped scanner FINDS it, which is the non-vacuity partner for the assertion that the subflow itself scans clean; the payload has to be a literal for that half to mean anything, so the file matches the vocabulary it exists to prove is caught'
   'tests/vault-status-check.test.cjs::sanitisation seeds for the vault status message carry a real instruction and a real control character on purpose, each paired with a non-vacuity assertion that the RENDERED message does not carry it intact; measured 5 pattern hits at HEAD on 2026-09-19'
-  'tests/vault-practices-matcher.test.cjs::the CR-01 fence-spoof suite plants a real instruction-override line and a forged end-fence marker inside practice bodies on purpose, each paired with an assertion that the RENDERED practices block keeps the planted text inside the fence and leaves exactly one genuine closer, so the payload must be a literal for the defang proof to mean anything; measured 3 pattern hits at HEAD b4dd6b3 on 2026-10-04'
-  'tests/vault-review.security.test.cjs::the CR-02 suite seeds a practice body with directive-shaped text aimed at the practice judge (the DIRECTIVE_TEXT constant) and asserts the rendered review entry carries it only between the fence markers, after the reference-data preamble, so the judge reads it as data; the text must be a literal for that assertion to mean anything; measured 1 pattern hit at HEAD b4dd6b3 on 2026-10-04'
-  'tests/practices-review-check-property.test.cjs::a false positive rather than a payload, since the fence-parsing invariance property builds a never-closed fence whose second-opener line is ordinary English about whether the client line becomes a cut point, and one role-pattern regex matches that plain wording; the fixture text stays as written; measured 1 pattern hit at HEAD b4dd6b3 on 2026-10-04'
   'tests/vault-index.integration.test.cjs::the fence-spoof suite seeds a vault document heading and an INDEX description that carry a forged end-fence marker followed by an instruction-override phrase, and asserts the rendered SUMMARY keeps exactly one live end marker with the planted line defanged inside the fence, so the phrase must be a literal for the defang proof to mean anything; measured 4 pattern hits at HEAD 5ddb0b3 on 2026-10-12'
   'tests/vault-seal.integration.test.cjs::the uncovered-commit suite builds a commit whose subject is an instruction-override phrase padded past the cap, modelling a hostile commit message, and asserts the subject leaving the seal leaf is controls-collapsed and bounded to SEAL_SUBJECT_CAP before it can reach a record; measured 1 pattern hit at HEAD 5ddb0b3 on 2026-10-12'
   'tests/vault-standards.integration.test.cjs::the D-14 suites plant instruction-override lines in a standards document and in its INDEX description, each tagged with a random token, and assert that neither the token nor the phrase appears in any output of vault standards block or consulted, so the phrase must be a literal for the absence proof to mean anything; measured 6 pattern hits at HEAD 5ddb0b3 on 2026-10-12'