@pareto4/pp-core 1.17.1 → 1.19.0

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

@@ -75,13 +75,6 @@ fi
 # STRICT-03: the enforcement policy. Read once, here, through the same resolver
 # every other read path uses. With it off this file behaves exactly as it always has.
 VAULT_REQUIRED=$(pp_run query config-get vault.required --raw --default false 2>/dev/null || echo false)
-# STRICT-04: practice matching is separately activated. "Not enabled" and "zero
-# matched" are different facts and must never be rendered the same way.
-# Phase 15 D-25: asked of the SAME resolver the vault-practices gates use, at verify:post, where an
-# UNFILTERED vault-practices gate (vault.audit) is declared in both vault modes, so this prints true
-# exactly when the capability's gates render. A config-get read disagreed with the gates on the flat,
-# string and root-true + workstream-empty shapes (15-RESEARCH C-1).
-VAULT_PRACTICES_ENABLED=$(pp_run loop render-hooks verify:post --active-cap vault-practices 2>/dev/null || echo false)
 # Detect --auto / --chain in host $ARGUMENTS. SURFACING ONLY — see below.
 AUTO_MODE=false
 if echo "${ARGUMENTS:-}" | grep -qE -- '--auto|--chain'; then AUTO_MODE=true; fi
@@ -116,109 +109,13 @@ hole this phase closes, so it is stated here rather than left to be re-derived.
 
 ---
 
-## Practice clause (STRICT-04)
-
-Appended to the **success** messages below when `VAULT_REQUIRED` is `true`. It is part of the
-enforced gate's success line; with the policy off the messages are unchanged, which is what keeps
-the byte-identical promise.
-
-Compute it as follows, then substitute it as `${VAULT_PRACTICE_CLAUSE}`:
-
-**Standards mode is decided first** (Phase 15 D-22). Ask the matcher once, before reading
-`VAULT_PRACTICES_ENABLED`:
-
-```bash
-VAULT_PRACTICE_NA_JSON=$(pp_run vault practices match --raw 2>/dev/null || echo '{}')
-VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_NA_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
-```
-
-**If `VAULT_PRACTICE_NA_LINE` is non-empty** (standards mode: `vault practices match` answers
-not-applicable whenever the vault gate is active, whatever `VAULT_PRACTICES_ENABLED` holds): print
-`${VAULT_PRACTICE_NA_LINE}` verbatim as the card line, print NO number, and skip the rest of this
-clause. The line comes from the engine and names the standards record and the gate that checks it.
-"Practice matching is not enabled" would be a practices-mode sentence on a standards project, which
-is the default standards shape (`vault.practices_enabled` off).
-
-Otherwise (practices mode) continue below.
-
-**If `VAULT_PRACTICES_ENABLED` != `true`:**
-
-> practice matching is not enabled for this project
-
-Emit no number on this branch. Zero-matched and matching-not-running are different facts, and
-reporting `0` for the second is the reassuring-but-false signal this phase removes.
-
-**Otherwise, at `VAULT_GATE_POINT` == `execute`** — the phase's plans exist, so the count is
-phase-scoped, which is what STRICT-04 asks for:
-
-```bash
-VAULT_PRACTICE_PATHS=$(pp_run query phase-plan-index "${PHASE_NUMBER}" --raw 2>/dev/null | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const s=new Set();for(const p of (JSON.parse(d).plans||[]))for(const f of (p.files_modified||[]))s.add(f);process.stdout.write(Array.from(s).slice(0,200).join('\n'));}catch{process.stdout.write('');}")
-VAULT_PRACTICE_PATH_COUNT=$(printf '%s' "$VAULT_PRACTICE_PATHS" | grep -c . || echo 0)
-```
-
-Pass those paths **positionally** to the match arm — never `--changed`, which would scope to the
-working tree rather than to the phase:
-
-`pp_run` is a shell FUNCTION, and `xargs` execs a binary — it can never invoke one. The previous
-form here piped into `xargs -r pp_run …`, whose failure was swallowed by `2>/dev/null` and answered
-by the `|| echo '{}'` fallback, so this clause reported **`0` practices matched on every run**, in
-bash and zsh alike, with nothing to indicate it had not looked. That is the reassuring-but-false
-signal the branch above exists to remove, arriving by a different door: STRICT-04 asks how many
-practices applied to this phase, and a false zero answers it wrongly. The paths therefore go
-straight to the function as positionals, the way `code-review.md` already calls the same arm
-(02-SECURITY T-02-36).
-
-```bash
-VAULT_PRACTICE_ARGS=()
-while IFS= read -r _p; do [ -n "$_p" ] && VAULT_PRACTICE_ARGS+=("$_p"); done <<< "$VAULT_PRACTICE_PATHS"
-if [ ${#VAULT_PRACTICE_ARGS[@]} -gt 0 ]; then
-  VAULT_PRACTICE_JSON=$(pp_run vault practices match "${VAULT_PRACTICE_ARGS[@]}" --raw 2>/dev/null || echo '{}')
-else
-  VAULT_PRACTICE_JSON=$(pp_run vault practices match --raw 2>/dev/null | node -e "const d=require('fs').readFileSync(0,'utf-8');try{process.stdout.write(JSON.parse(d).status==='not_applicable'?d:'{}');}catch{process.stdout.write('{}');}")
-fi
-VAULT_PRACTICE_MATCHED=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'?'NA':String((r.matched||[]).length+(r.global||[]).length));}catch{process.stdout.write('0');}")
-VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
-```
-
-The path list is capped at **200** entries. When `VAULT_PRACTICE_PATH_COUNT` is `200`, the phase is
-wider than the bound and the clause must say so rather than present a truncated number as complete:
-
-> more than 200 files in scope — practice count not computed for this phase
-
-Otherwise:
-
-> `${VAULT_PRACTICE_MATCHED}` client practices apply to this phase
-
-**Otherwise, at `VAULT_GATE_POINT` == `plan`** — no phase scope exists yet, because the plans this
-count would be scoped to are the ones about to be written. Report what is true at this point and
-name when the scoped number arrives; do not fake a phase-scoped count and do not silently omit it:
-
-```bash
-VAULT_PRACTICE_JSON=$(pp_run vault practices match --raw 2>/dev/null || echo '{}')
-VAULT_PRACTICE_TOTAL=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'?'NA':String(r.practicesProcessed??0));}catch{process.stdout.write('0');}")
-VAULT_PRACTICE_NA_LINE=$(printf '%s' "$VAULT_PRACTICE_JSON" | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const r=JSON.parse(d);process.stdout.write(r.status==='not_applicable'&&typeof r.message==='string'?r.message:'');}catch{process.stdout.write('');}")
-```
-
-> the vault carries `` `${VAULT_PRACTICE_TOTAL}` `` practices at this ref; the phase-scoped matched count is reported at execute:pre once plans exist
-
-Each fence above assigns `VAULT_PRACTICE_JSON` itself before reading it — the two points never run
-in one gate, so neither fence reads the other's envelope. With no phase paths the execute fence
-still asks the matcher but keeps only a `not_applicable` answer, so practices mode still counts `0`.
-
-**If `VAULT_PRACTICE_MATCHED` (at execute) or `VAULT_PRACTICE_TOTAL` (at plan) is `NA`:** print
-`${VAULT_PRACTICE_NA_LINE}` verbatim as the card line, instead of the count line or the 200-file
-line, and print NO number — the envelope names the mode (`vault.mode = standards`); a count here would be the false
-"0 client practices apply" STRICT-04 forbids.
-
----
-
 ## §8 Message table — plan:pre column (`VAULT_GATE_POINT` == `plan`)
 
 **`fetched` + `tier: client`:**
 
 > Client vault loaded from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``). Planning will apply client standards.
 
-When `VAULT_REQUIRED` is `true`, append ` — ${VAULT_PRACTICE_CLAUSE}.` and skip the confirmation.
+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).
 
@@ -240,9 +137,9 @@ Surface this warning and require an explicit `confirmed` acknowledgment (`AskUse
 
 Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here.
 
-**`degraded`** (standards mode — the vault loaded but its `INDEX.md` is missing, unparseable, empty or names no file in the fetched tree, or the engine could not check it at all (`vault_index_unchecked`: the cached manifest records no file list, or the check faulted — this says nothing about `INDEX.md` itself); `check vault.status` sets `status: degraded` and a `reason` of the form `vault_index_*`):
+**`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. The standards-mode practice clause is unchanged from Phase 13. Planning proceeds without a usable index; the `## INDEX` section of `.planning/vault/SUMMARY.md` names the degradation.
+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.
 
 ---
 
@@ -255,7 +152,7 @@ Until this phase, nothing dispatched this column at all — it was written and n
 
 > Client vault present from `` `${VAULT_REPO}@${VAULT_REF}` `` (`` `${VAULT_FILE_COUNT}` `` files, sha `` `${VAULT_SHA}` ``). Build will apply client patterns.
 
-When `VAULT_REQUIRED` is `true`, append ` — ${VAULT_PRACTICE_CLAUSE}.` and skip the confirmation.
+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).
 
@@ -277,9 +174,9 @@ Surface this warning and require an explicit `confirmed` acknowledgment (`AskUse
 
 Surface this warning and require an explicit `confirmed` acknowledgment (`AskUserQuestion`, or a typed `confirmed` in TEXT_MODE). With `VAULT_REQUIRED` on, this state has already been stopped by the enforcer and is unreachable here.
 
-**`degraded`** (standards mode — the vault loaded but its `INDEX.md` is missing, unparseable, empty or names no file in the fetched tree, or the engine could not check it at all (`vault_index_unchecked`: the cached manifest records no file list, or the check faulted — this says nothing about `INDEX.md` itself); `check vault.status` sets `status: degraded` and a `reason` of the form `vault_index_*`):
+**`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. The standards-mode practice clause is unchanged from Phase 13. Build proceeds without a usable index; the `## INDEX` section of `.planning/vault/SUMMARY.md` names the degradation.
+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.
 
 ---
 

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

@@ -124,22 +124,6 @@ mid-lifecycle state it is at `plan:post` and `execute:wave:post`. The obligation
 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.
 
-**Before the enforcer runs, close the phase's range.** Run
-`pp_run vault manifest record "${PHASE_DIR}" --raw`, print its one-line result, and continue
-regardless. It writes `phases[<phase>].commits` = `git rev-list --reverse --no-merges
-<startCommit>..HEAD` beside the anchor item 4 of `execute-pre-dispatch.md` recorded, so the
-`vault.audit` gate dispatched next and `/pp-undo` read one list. A phase with no anchor (built
-before the anchor existed) answers `start-not-recorded`, which is exactly the case the audit's
-trace-digest fallback covers. `/pp-verify-work` reaches this file with `${PHASE_DIR}` bound too.
-
-**Then commit the recorded manifest.** Only when that result's `ok` is `true`, run
-`pp_run query commit "docs(phase-<phase>): record phase manifest" --files "<manifestPath>"`, with
-`<phase>` and `<manifestPath>` taken from the same result (`manifestPath` is root-relative). Print the
-outcome and continue on every path. Without this, a project that commits `.planning/` keeps the
-manifest untracked and `/pp-ship`'s clean-tree preflight asks about it every time. The commit verb
-itself skips on `commit_docs: false` and on a gitignored `.planning/`, so no guard is added here. A
-`nothing_to_commit` or failed commit is printed, never retried with raw `git`, and never halts.
-
 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
@@ -160,4 +144,4 @@ certifies nothing, which only widens the next phase's SEAL-01 reach and never hi
 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 runs as the manifest-record step above runs.
+launcher preamble, in the admission fence, and this step needs no second one.

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

@@ -179,6 +179,7 @@ fi
 
 Resolve `MVP_MODE` once via the centralized `phase.mvp-mode` query verb (precedence chain: CLI flag → ROADMAP `**Mode:** mvp` → `workflow.mvp_mode` config → false):
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 MVP_FLAG_ARG=""
 if [[ "$ARGUMENTS" =~ (^|[[:space:]])--mvp([[:space:]]|$) ]]; then MVP_FLAG_ARG="--cli-flag"; fi
 MVP_MODE=$(pp_run query phase.mvp-mode "${PHASE_NUMBER}" $MVP_FLAG_ARG --pick active)
@@ -218,7 +219,10 @@ Offer these recovery options:
 if [ "$MVP_MODE" = "true" ] && [ "$TDD_MODE" = "true" ]; then
   IS_BEHAVIOR_ADDING=$(pp_run query task.is-behavior-adding "$TASK_FILE" --pick is_behavior_adding)
   if [ "$IS_BEHAVIOR_ADDING" = "true" ]; then
-    RED_COMMIT=$(git log --oneline --grep="^test(${PHASE_NUMBER}-${PLAN_ID}):" -- "**/*.test.*" "**/*.spec.*" "tests/" | head -1)
+    # A `test` commit (any scope) whose `Phase:` trailer is this plan; a `test(<plan>):`
+    # subject from before the trailer convention still counts.
+    RED_COMMIT=$(git log --format='%h%x09%s%x09%(trailers:key=Phase,valueonly,separator=%x2C)' -- "**/*.test.*" "**/*.spec.*" "tests/" \
+      | awk -F'\t' -v id="${PHASE_NUMBER}-${PLAN_ID}" '$2 ~ /^test(\([^)]*\))?!?:/ && ($3 == id || index($2, "(" id "):") > 0) { print; exit }')
     if [ -z "$RED_COMMIT" ]; then
       pp_run query state.update last_gate_trip "${PLAN_ID}/${TASK_ID}" || true
       echo "MVP+TDD GATE TRIPPED: missing RED commit for ${PLAN_ID}/${TASK_ID}"
@@ -236,6 +240,7 @@ Pure doc-only / config-only / test-only tasks return `is_behavior_adding=false`
 Look for a `.continue-here.md` in the current phase directory:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 ls ${phase_dir}/.continue-here.md 2>/dev/null || true
 ```
 
@@ -286,8 +291,8 @@ checkpoints between tasks. The user can review, modify, or redirect work at any
    c. **If "Execute":** Read and follow `~/.claude/pp-core/workflows/execute-plan.md` **inline**
       (do NOT spawn a subagent). Execute tasks one at a time.
       The inline executor follows `EXECUTOR_HOOK_FRAGMENTS` (computed in the hooks fence above) as
-      its contract exactly as a spawned executor would: in standards mode it is the vault's
-      execute:pre executor fragment; in practices mode it is empty.
+      its contract exactly as a spawned executor would: it is the vault's execute:pre executor
+      fragment.
 
    d. **After each task:** Pause briefly. If the user intervenes (types anything), stop and address
       their feedback before continuing. Otherwise proceed to next task.
@@ -755,6 +760,7 @@ increases monotonically across waves. `{status}` is `complete` (success),
    rerun the same command. Do not fall back to broad worktree discovery.
 
    ```bash
+   [ -z "${ZSH_VERSION:-}" ] || emulate -R sh
    [ -n "${WAVE_WORKTREE_MANIFEST:-}" ] && [ -f "$WAVE_WORKTREE_MANIFEST" ] || {
      echo "BLOCKED: missing WAVE_WORKTREE_MANIFEST; refusing broad worktree cleanup (#3384)." >&2
      exit 1
@@ -784,6 +790,7 @@ increases monotonically across waves. `{status}` is `complete` (success),
    If the orchestrator deviated from the standard wave merge path (e.g., custom inter-worktree base-update merges with `merge: bring …` style messages), run this snippet after the custom merges are complete. It reads only `WAVE_WORKTREE_MANIFEST`; do not discover unrelated `worktree-agent-*` worktrees.
 
    ```bash
+   [ -z "${ZSH_VERSION:-}" ] || emulate -R sh
    # Cleanup-tail: pin orchestrator CWD to its OWN worktree before cleanup-tail (#3174, #630).
    # Same fix as the templated path: resolve the dispatch-time orchestrator root from the manifest,
    # not `git worktree list`'s first entry (always the main checkout — wrong for a lane orchestrator).
@@ -858,7 +865,7 @@ increases monotonically across waves. `{status}` is `complete` (success),
 
      # Only commit tracking files if they actually changed
      if ! git diff --quiet .planning/ROADMAP.md .planning/STATE.md 2>/dev/null; then
-       pp_run query commit "docs(phase-${PHASE_NUMBER}): update tracking after wave ${N}" --files .planning/ROADMAP.md .planning/STATE.md
+       pp_run query commit "docs(planning): update tracking after wave ${N}" --phase "${PHASE_NUMBER}" --files .planning/ROADMAP.md .planning/STATE.md
      fi
    elif [ "${TEST_EXIT}" -eq 124 ]; then
      echo "⚠ Skipping tracking update — test suite timed out. Plans remain in-progress. Run tests manually to confirm."
@@ -1062,6 +1069,7 @@ After all waves:
 
 **Security gate check:**
 ```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)
@@ -1213,7 +1221,8 @@ mv .planning/debug/{slug}.md .planning/debug/resolved/
 
 **6. Commit updated artifacts:**
 ```bash
-pp_run query commit "docs(phase-${PARENT_PHASE}): resolve UAT gaps and debug sessions after ${PHASE_NUMBER} gap closure" --files .planning/phases/*${PARENT_PHASE}*/*-UAT.md .planning/debug/resolved/*.md
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+pp_run query commit "docs(planning): resolve UAT gaps and debug sessions after ${PHASE_NUMBER} gap closure" --phase "${PARENT_PHASE}" --files .planning/phases/*${PARENT_PHASE}*/*-UAT.md .planning/debug/resolved/*.md
 ```
 </step>
 
@@ -1291,8 +1300,6 @@ Verify phase achieved its GOAL, not just completed tasks.
 VERIFIER_SKILLS=$(pp_run query agent-skills pp-verifier)
 ```
 
-Read and execute `execute-phase/steps/verifier-practice-payload.md` (sets `PRACTICE_VERDICT_INPUT`).
-
 ```
 Agent(
   description="Verify phase {phase_number} goal achievement",
@@ -1315,7 +1322,6 @@ ${CONTEXT_WINDOW >= 500000 ? `- Prior VERIFICATION.md files from earlier phases
 ` : ''}
 </files_to_read>
 
-${PRACTICE_VERDICT_INPUT}
 ${VERIFIER_SKILLS}",
   subagent_type="pp-verifier",
   model="{verifier_model}"
@@ -1379,7 +1385,7 @@ blocked: 0
 
 Commit the file:
 ```bash
-pp_run query commit "test({phase_num}): persist human verification items as UAT" --files "{phase_dir}/{phase_num}-UAT.md"
+pp_run query commit "docs(planning): persist human verification items as UAT" --phase "{phase_num}" --files "{phase_dir}/{phase_num}-UAT.md"
 ```
 
 **Step B: Present to user:**
@@ -1459,7 +1465,8 @@ These items are tracked and will appear in `/pp:progress` and `/pp:audit-uat`.
 ```
 
 ```bash
-pp_run query commit "docs(phase-{X}): complete phase execution" --files .planning/ROADMAP.md .planning/STATE.md .planning/REQUIREMENTS.md {phase_dir}/*-VERIFICATION.md
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+pp_run query commit "docs(planning): complete phase execution" --phase "{X}" --files .planning/ROADMAP.md .planning/STATE.md .planning/REQUIREMENTS.md {phase_dir}/*-VERIFICATION.md
 ```
 </step>
 
@@ -1492,6 +1499,7 @@ Copy failure must NOT block phase completion.
 This step runs AFTER `update_roadmap` marks the phase complete. It moves any pending todos that carry `resolves_phase: <current-phase-number>` to the completed directory.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 PHASE_NUM="${PHASE_NUMBER}"
 PENDING_DIR=".planning/todos/pending"
 COMPLETED_DIR=".planning/todos/completed"
@@ -1509,7 +1517,7 @@ for TODO_FILE in "$PENDING_DIR"/*.md; do
 done
 
 if [ ${#CLOSED[@]} -gt 0 ]; then
-  pp_run query commit "docs(phase-${PHASE_NUMBER}): auto-close ${#CLOSED[@]} todo(s) resolved by this phase" --files .planning/todos/completed/ .planning/STATE.md|| true
+  pp_run query commit "docs(planning): auto-close ${#CLOSED[@]} todo(s) resolved by this phase" --phase "${PHASE_NUMBER}" --files .planning/todos/completed/ .planning/STATE.md|| true
   echo "◆ Closed ${#CLOSED[@]} todo(s) resolved by Phase ${PHASE_NUMBER}:"
   for f in "${CLOSED[@]}"; do echo "  ✓ $f"; done
 fi
@@ -1534,7 +1542,7 @@ PROJECT.md falls behind silently over multiple phases.
 5. Commit the change:
 
 ```bash
-pp_run query commit "docs(phase-{X}): evolve PROJECT.md after phase completion" --files .planning/PROJECT.md
+pp_run query commit "docs(planning): evolve PROJECT.md after phase completion" --phase "{X}" --files .planning/PROJECT.md
 ```
 
 **Skip this step if** `.planning/PROJECT.md` does not exist.
@@ -1597,6 +1605,7 @@ Read and follow `~/.claude/pp-core/workflows/transition.md`, passing through the
 Check whether CONTEXT.md already exists for the next phase:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 ls .planning/phases/*{next}*/{next}-CONTEXT.md 2>/dev/null || echo "no-context"
 ```
 

package/pp-core/workflows/execute-plan.md

@@ -72,12 +72,13 @@ case "$VAULT_ADMIT" in on) echo "VAULT_ADMIT=on" ;; off|inert) : ;; *) pp_run va
 step silently and continue. Print nothing: a non-Pareto or `vault.enabled=false` project runs this
 workflow byte-identically to how it ran before this gate existed (GATE-04).
 
-**Otherwise, the load gate, in hook mode.** Render `execute:pre` and keep only the `vault` and
-`vault-practices` hooks, mechanically in the fence (D-30): no other capability's hook is run or
+**Otherwise, the load gate, in hook mode.** Render `execute:pre` and keep only the `vault`
+hooks, mechanically in the fence (D-30): no other capability's hook is run or
 injected here, because execute-phase's dispatcher owns those for its own run.
 
 ```bash
-EXECUTE_PRE_HOOKS_JSON=$(pp_run loop render-hooks execute:pre --raw | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const j=JSON.parse(d);j.activeHooks=(j.activeHooks||[]).filter((x)=>x&&(x.capId==='vault'||x.capId==='vault-practices'));process.stdout.write(JSON.stringify(j));}catch{process.stdout.write('');}")
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+EXECUTE_PRE_HOOKS_JSON=$(pp_run loop render-hooks execute:pre --raw | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const j=JSON.parse(d);j.activeHooks=(j.activeHooks||[]).filter((x)=>x&&x.capId==='vault');process.stdout.write(JSON.stringify(j));}catch{process.stdout.write('');}")
 printf '%s' "$EXECUTE_PRE_HOOKS_JSON" | node -e "let h=[];try{h=JSON.parse(require('fs').readFileSync(0,'utf-8')).activeHooks||[]}catch{}console.log('EXECUTE_PRE_HOOKS_JSON='+JSON.stringify({activeHooks:h}))"
 ```
 
@@ -91,6 +92,7 @@ the two-step contract, the halt and the message passthrough; none of them are re
 
 <step name="identify_plan">
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 # Use plans/summaries from INIT JSON, or list files
 (ls .planning/phases/XX-name/*-PLAN.md 2>/dev/null || true) | sort
 (ls .planning/phases/XX-name/*-SUMMARY.md 2>/dev/null || true) | sort
@@ -115,14 +117,15 @@ Present plan identification, wait for confirmation.
 </step>
 
 <step name="vault_trace_gate">
-This gate judges the ONE plan this run executes (D-06, D-38): a plan with no `<vault_practices>` /
-`<vault_standards>` record is blocked (`practices_block_absent` / `standards_block_absent`), never
+This gate judges the ONE plan this run executes (D-06, D-38): a plan with no
+`<vault_standards>` record is blocked (`standards_block_absent`), never
 rendered as nothing. Skip this step silently unless the admission step printed `VAULT_ADMIT=on`. The
 positional is the plan file, not its phase directory: sibling plans mid-wave are not this run's
 business, and `check vault.trace <plan file> --stage plan` by hand gives this gate's verdict.
 
 ```bash
-PLAN_POST_HOOKS_JSON=$(pp_run loop render-hooks plan:post --raw | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const j=JSON.parse(d);j.activeHooks=(j.activeHooks||[]).filter((x)=>x&&(x.capId==='vault'||x.capId==='vault-practices'));process.stdout.write(JSON.stringify(j));}catch{process.stdout.write('');}")
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+PLAN_POST_HOOKS_JSON=$(pp_run loop render-hooks plan:post --raw | node -e "const d=require('fs').readFileSync(0,'utf-8');try{const j=JSON.parse(d);j.activeHooks=(j.activeHooks||[]).filter((x)=>x&&x.capId==='vault');process.stdout.write(JSON.stringify(j));}catch{process.stdout.write('');}")
 printf '%s' "$PLAN_POST_HOOKS_JSON" | node -e "let h=[];try{h=JSON.parse(require('fs').readFileSync(0,'utf-8')).activeHooks||[]}catch{}console.log('PLAN_POST_HOOKS_JSON='+JSON.stringify({activeHooks:h}))"
 ```
 
@@ -312,9 +315,11 @@ End with: **Total deviations:** N auto-fixed (breakdown). **Impact:** assessment
 For `type: tdd` plans — RED-GREEN-REFACTOR:
 
 1. **Infrastructure** (first TDD plan only): detect project, install framework, config, verify empty suite
-2. **RED:** Read `<behavior>` → failing test(s) → run (MUST fail) → commit: `test({phase}-{plan}): add failing test for [feature]`
-3. **GREEN:** Read `<implementation>` → minimal code → run (MUST pass) → commit: `feat({phase}-{plan}): implement [feature]`
-4. **REFACTOR:** Clean up → tests MUST pass → commit: `refactor({phase}-{plan}): clean up [feature]`
+2. **RED:** Read `<behavior>` → failing test(s) → run (MUST fail) → commit: `test({area}): add failing test for [feature]`
+3. **GREEN:** Read `<implementation>` → minimal code → run (MUST pass) → commit: `feat({area}): implement [feature]`
+4. **REFACTOR:** Clean up → tests MUST pass → commit: `refactor({area}): clean up [feature]`
+
+`{area}` names the part of the codebase (`auth`, `billing`), never the plan; every one of these commits ends with the trailer `Phase: {phase}-{plan}` after a blank line.
 
 Errors: RED doesn't fail → investigate test/existing feature. GREEN doesn't pass → debug, iterate. REFACTOR breaks → undo.
 
@@ -348,7 +353,7 @@ If a commit is BLOCKED by a hook:
 <task_commit>
 ## Task Commit Protocol
 
-Canonical per-task commit rules live in **`agents/pp-executor.md`** (`<task_commit_protocol>`). Follow that section for staging, `{type}({phase}-{plan})` messages, `commit-to-subrepo` when `sub_repos` is set, post-commit checks, and untracked-file handling — do not duplicate or paraphrase the full protocol here (single source of truth).
+Canonical per-task commit rules live in **`agents/pp-executor.md`** (`<task_commit_protocol>`). Follow that section for staging, `{type}({area}): …` messages with the `Phase: {phase}-{plan}` trailer, `commit-to-subrepo` when `sub_repos` is set, post-commit checks, and untracked-file handling — do not duplicate or paraphrase the full protocol here (single source of truth).
 
 **Orchestrator note:** After each task, the spawned executor reports commit hashes; this workflow does not re-specify commit semantics beyond pointing at the executor.
 
@@ -440,8 +445,6 @@ One-liner SUBSTANTIVE: "JWT auth with refresh rotation using jose library" not "
 Include: duration, start/end times, task count, file count.
 
 Next: more plans → "Ready for {next-plan}" | last → "Phase complete, ready for next step".
-
-**Practices Applied (only when the plan carried a `<vault_practices>` block):** inside the atomic block above and BEFORE the Write, run `pp_run vault trace render` against the execute-stage ledger and include the returned section in that same single Write — no narrative between the render and the Write, for the reason the critical-ordering note already gives. It belongs here and not in the end-of-phase gate: the code reviewer reads this section from every summary in the phase and runs first inside that gate step, so a section produced there would never be visible to it.
 </step>
 
 <step name="update_current_position">
@@ -525,6 +528,7 @@ Counts PLAN vs SUMMARY files on disk and updates the progress-table row with the
 Mark completed requirements from the PLAN.md frontmatter `requirements:` field:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 pp_run query requirements.mark-complete ${REQ_IDS}
 ```
 
@@ -545,9 +549,9 @@ IS_WORKTREE=$([ -f .git ] && echo "true" || echo "false")
 
 # In parallel mode: exclude STATE.md and ROADMAP.md (orchestrator commits these)
 if [ "$IS_WORKTREE" = "true" ]; then
-  pp_run query commit "docs({phase}-{plan}): complete [plan-name] plan" --files .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md .planning/REQUIREMENTS.md
+  pp_run query commit "docs(planning): complete [plan-name] plan" --phase "{phase}-{plan}" --files .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md .planning/REQUIREMENTS.md
 else
-  pp_run query commit "docs({phase}-{plan}): complete [plan-name] plan" --files .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md .planning/STATE.md .planning/ROADMAP.md .planning/REQUIREMENTS.md
+  pp_run query commit "docs(planning): complete [plan-name] plan" --phase "{phase}-{plan}" --files .planning/phases/XX-name/{phase}-{plan}-SUMMARY.md .planning/STATE.md .planning/ROADMAP.md .planning/REQUIREMENTS.md
 fi
 ```
 </step>
@@ -556,13 +560,17 @@ fi
 If .planning/codebase/ doesn't exist: skip.
 
 ```bash
-FIRST_TASK=$(git log --oneline --grep="feat({phase}-{plan}):" --grep="fix({phase}-{plan}):" --grep="test({phase}-{plan}):" --reverse | head -1 | cut -d' ' -f1)
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
+# Oldest feat/fix/test commit carrying the plan's `Phase:` trailer (or, from before the trailer, its scope)
+FIRST_TASK=$(git log --reverse --format='%h%x09%s%x09%(trailers:key=Phase,valueonly,separator=%x2C)' \
+  | awk -F'\t' -v id="{phase}-{plan}" '$2 ~ /^(feat|fix|test)(\([^)]*\))?!?:/ && ($3 == id || index($2, "(" id "):") > 0) { print $1; exit }')
 git diff --name-only ${FIRST_TASK}^..HEAD 2>/dev/null || true
 ```
 
 Update only structural changes: new src/ dir → STRUCTURE.md | deps → STACK.md | file pattern → CONVENTIONS.md | API client → INTEGRATIONS.md | config → STACK.md | renamed → update paths. Skip code-only/bugfix/content changes.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 pp_run query commit "" --files .planning/codebase/*.md --amend
 ```
 </step>
@@ -571,6 +579,7 @@ pp_run query commit "" --files .planning/codebase/*.md --amend
 If `USER_SETUP_CREATED=true`: display `⚠️ USER SETUP REQUIRED` with path + env/config tasks at TOP.
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 (ls -1 .planning/phases/[current-phase-dir]/*-PLAN.md 2>/dev/null || true) | wc -l
 (ls -1 .planning/phases/[current-phase-dir]/*-SUMMARY.md 2>/dev/null || true) | wc -l
 ```

package/pp-core/workflows/explore.md

@@ -118,7 +118,7 @@ For each selected output, write the file:
 Commit if `commit_docs` is enabled:
 ```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
-pp_run query commit "docs: capture exploration — {topic_slug}" --files {file_list}
+pp_run query commit "docs(planning): capture exploration — {topic_slug}" --files {file_list}
 ```
 
 ## Step 6: Close

package/pp-core/workflows/forensics.md

@@ -64,6 +64,7 @@ Extract:
 For each phase directory in `.planning/phases/*/`:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 ls .planning/phases/*/
 ```
 
@@ -255,15 +256,16 @@ If actionable anomalies were found (HIGH or MEDIUM confidence):
 
 If confirmed:
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 # Check if "bug" label exists before using it
-BUG_LABEL=$(gh label list --repo open-gsd/pp-core --search "bug" --json name -q '.[0].name' 2>/dev/null)
+BUG_LABEL=$(gh label list --repo pareto000/pp-core --search "bug" --json name -q '.[0].name' 2>/dev/null)
 LABEL_FLAG=""
 if [ -n "$BUG_LABEL" ]; then
   LABEL_FLAG="--label bug"
 fi
 
 gh issue create \
-  --repo open-gsd/pp-core \
+  --repo pareto000/pp-core \
   --title "bug: {concise description from anomaly}" \
   $LABEL_FLAG \
   --body "{formatted findings from report}"

package/pp-core/workflows/health.md

@@ -65,6 +65,7 @@ health output, the two modes are independent diagnostics.
 **Run health validation:**
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 pp_run query validate.health $REPAIR_FLAG $BACKFILL_FLAG
 ```
 

package/pp-core/workflows/help/modes/full.md

@@ -601,7 +601,7 @@ The commands above cover the most common day-to-day flows. Every command listed
 - **`/pp:secure-phase [phase]`** — Retroactively verify threat mitigations for a completed phase.
 - **`/pp:validate-phase [phase]`** — Retroactively audit and fill Nyquist validation gaps for a completed phase.
 - **`/pp:ui-review [phase]`** — Retroactive 6-pillar visual audit of implemented frontend code.
-- **`/pp:vault-review [phase]`** — Retroactive per-practice vault review (counts by verdict; reports, never gates).
+- **`/pp:vault-review [phase]`** — Retroactive client-vault review of a phase (reports, never gates).
 - **`/pp:eval-review [phase]`** — Audit an executed AI phase's evaluation coverage and produce an EVAL-REVIEW.md remediation plan.
 - **`/pp:audit-fix --source <audit-uat> [--severity medium|high|all] [--max N] [--dry-run]`** — Autonomous audit-to-fix pipeline: find issues, classify, fix, test, commit.
 - **`/pp:add-tests <phase> [additional instructions]`** — Generate tests for a completed phase based on UAT criteria and implementation.

package/pp-core/workflows/import.md

@@ -42,6 +42,7 @@ Usage: /pp:import --from <path>
 Verify the path does not contain traversal sequences and the file exists:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 case "{FILEPATH}" in
   *..* ) echo "SECURITY_ERROR: path contains traversal sequence"; exit 1 ;;
 esac
@@ -228,7 +229,7 @@ Update `.planning/STATE.md` if appropriate (e.g., increment total plan count).
 
 Commit the imported plan and updated files:
 ```bash
-pp_run query commit "docs({phase}): import plan from {basename FILEPATH}" --files .planning/phases/{phase}/{plan}-PLAN.md .planning/ROADMAP.md
+pp_run query commit "docs(planning): import plan from {basename FILEPATH}" --phase "{phase}" --files .planning/phases/{phase}/{plan}-PLAN.md .planning/ROADMAP.md
 ```
 
 Display completion:

package/pp-core/workflows/ingest-docs.md

@@ -33,6 +33,7 @@ Parse `$ARGUMENTS`:
 **Validate paths:**
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 case "{SCAN_PATH}" in *..*) echo "SECURITY_ERROR: path contains traversal sequence"; exit 1 ;; esac
 test -d "{SCAN_PATH}" || echo "PATH_NOT_FOUND"
 if [ -n "{MANIFEST_PATH}" ]; then

package/pp-core/workflows/init/steps/client-context-capture.md

@@ -61,6 +61,7 @@ Capture these fields, in this order:
 managed-block writer:
 
 ```bash
+[ -z "${ZSH_VERSION:-}" ] || emulate -R sh
 if [ "$(pp_run query platform-bindings --pick present 2>/dev/null)" = "true" ]; then
   # Write collected values to a temp JSON file using node + JSON.stringify so that
   # multi-line values, embedded quotes, backslashes, and $(...) sequences are encoded