@pareto4/pp-core 1.11.0 → 1.12.0

package/scripts/workflow-size.cjs

@@ -36,8 +36,10 @@ function lfByteCount(filePath) {
 
 /**
  * List top-level workflow stems (filenames without the `.md` extension), sorted.
- * Non-recursive by design: per-mode bodies under `workflows/<name>/modes/` and
- * templates are NOT measured — only the always-loaded top-level workflows.
+ * Top-level only on purpose: a stem is what the tier tables (XL/LARGE/DEFAULT)
+ * classify, and only top-level files have a tier. Nested files under
+ * `workflows/<name>/{steps,modes,templates}/` are still SIZE-guarded — see
+ * `measureMdTree` / `measureWorkflows`, which recurse.
  *
  * @param {string} [dir] - Workflows directory (defaults to the canonical one).
  * @returns {string[]} Sorted stems, e.g. `['autonomous', 'plan-phase', ...]`.
@@ -52,10 +54,10 @@ function listWorkflowStems(dir = WORKFLOWS_DIR) {
 
 /**
  * Measure every top-level `.md` file in `dir`, keyed by filename, byte sizes.
- * Generic over directory and an optional filename predicate — used for both
- * workflows (`pp-core/workflows/*.md`) and agents (`agents/gsd-*.md`) so the
- * size guards and the baseline generator share one measurement path (#1074).
- * Non-recursive by design.
+ * Generic over directory and an optional filename predicate — used for agents
+ * (`agents/pp-*.md`), which are a flat directory, so the agent guard and the
+ * baseline generator share one measurement path (#1074).
+ * Non-recursive by design; use `measureMdTree` for a nested tree.
  *
  * @param {string} dir - Directory to scan.
  * @param {function(string): boolean} [predicate] - Filename filter (default: all `.md`).
@@ -72,19 +74,69 @@ function measureMdFiles(dir, predicate = () => true) {
 }
 
 /**
- * Measure every top-level workflow file, keyed by filename (`<stem>.md`).
+ * List every `.md` file under `dir`, recursively, as POSIX relative paths
+ * (`plan-phase.md`, `execute-phase/steps/vault-fetch.md`), sorted.
+ *
+ * Keys are POSIX on every platform so the committed baseline is identical on a
+ * Windows checkout. Top-level files keep their bare filename, exactly as the
+ * non-recursive `measureMdFiles` keys them, so existing consumers that look up
+ * `baseline['plan-phase.md']` keep working.
+ *
+ * @param {string} dir - Directory to walk.
+ * @param {function(string): boolean} [predicate] - Filter on the POSIX relative path.
+ * @returns {string[]} Sorted POSIX relative paths.
+ */
+function listMdTree(dir, predicate = () => true) {
+  const out = [];
+  const walk = (abs, rel) => {
+    for (const entry of fs.readdirSync(abs, { withFileTypes: true })) {
+      const childRel = rel ? `${rel}/${entry.name}` : entry.name;
+      const childAbs = path.join(abs, entry.name);
+      if (entry.isDirectory()) walk(childAbs, childRel);
+      else if (entry.isFile() && entry.name.endsWith('.md') && predicate(childRel)) {
+        out.push(childRel);
+      }
+    }
+  };
+  walk(dir, '');
+  return out.sort();
+}
+
+/**
+ * Measure every `.md` file under `dir`, recursively, keyed by POSIX relative
+ * path (see `listMdTree`), LF byte sizes.
+ *
+ * @param {string} dir - Directory to walk.
+ * @param {function(string): boolean} [predicate] - Filter on the POSIX relative path.
+ * @returns {Object<string, number>} Map of relative path → LF byte size, keys sorted.
+ */
+function measureMdTree(dir, predicate = () => true) {
+  const out = {};
+  for (const rel of listMdTree(dir, predicate)) {
+    out[rel] = lfByteCount(path.join(dir, ...rel.split('/')));
+  }
+  return out;
+}
+
+/**
+ * Measure every workflow `.md` file — top-level AND nested (`steps/`, `modes/`,
+ * `templates/`, ...) — keyed by POSIX relative path. Recursive since the
+ * workflow size budget policy of 2026-10-11: a nested step file is loaded into
+ * context just like its parent, so growth there must be visible too.
  *
  * @param {string} [dir] - Workflows directory (defaults to the canonical one).
- * @returns {Object<string, number>} Map of `<stem>.md` → LF byte size, sorted.
+ * @returns {Object<string, number>} Map of relative path → LF byte size, sorted.
  */
 function measureWorkflows(dir = WORKFLOWS_DIR) {
-  return measureMdFiles(dir);
+  return measureMdTree(dir);
 }
 
 module.exports = {
   WORKFLOWS_DIR,
   lfByteCount,
   listWorkflowStems,
+  listMdTree,
   measureMdFiles,
+  measureMdTree,
   measureWorkflows,
 };

package/commands/pp-build-handoff.md

@@ -1,46 +0,0 @@
----
-name: pp:build-handoff
-description: "[DEPRECATED] Alias for /pp-discovery-to-build; removed in a future major."
-argument-hint: "[--skip-validation] [--scaffold]"
-allowed-tools:
-  - Read
-  - Write
-  - Edit
-  - Bash
-  - Glob
-  - Grep
-  - Agent
-  - AskUserQuestion
-requires: [new-project]
----
-
-<runtime_note>
-**Copilot (VS Code):** Use `vscode_askquestions` wherever this workflow calls `AskUserQuestion`. They are equivalent — `vscode_askquestions` is the VS Code Copilot implementation of the same interactive question API.
-</runtime_note>
-
-<deprecation_note>
-**Deprecated:** `/pp-build-handoff` was renamed to `/pp-discovery-to-build` in v1.8.0. This
-alias runs the identical workflow and is kept for back-compat with v1.7.x. Prefer
-`/pp-discovery-to-build`; this alias will be removed in a future major release.
-</deprecation_note>
-
-<objective>
-Bridge the gap between a completed Pareto Discovery Sprint and pp-core execution.
-
-Validates all 13 Discovery sessions are complete, synthesizes their outputs into a
-single structured handoff document, bootstraps the `.planning/` project state
-(PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, config.json), and wires up
-cross-references so pp-core agents can trace every decision back to the Discovery
-session that produced it.
-
-**After this command:** pp-core is initialized. Run `/pp-plan-phase 1` to start
-execution, or `/pp-autonomous` to run all phases.
-</objective>
-
-<execution_context>
-@~/.claude/pp-core/workflows/discovery-to-build.md
-</execution_context>
-
-<process>
-Execute end-to-end.
-</process>

package/pp-core/workflows/execute-phase/steps/per-plan-worktree-gate.md

@@ -1,94 +0,0 @@
-# Per-plan worktree decision (#2772)
-
-Run this for **each plan in the current wave** before its `Agent()` dispatch. The output `USE_WORKTREES_FOR_PLAN` gates the dispatch branch (worktree mode vs sequential mode) for that plan only — other plans in the same wave can still take the worktree path.
-
-`SUBMODULE_PATHS` is computed once in the `initialize` step (parsed from `.gitmodules`).
-
-`PLAN_FILES` is the whitespace-separated list of paths the plan declared it will touch, extracted from the `phase-plan-index` JSON loaded in `discover_and_group_plans`:
-
-```bash
-# plan_json is the JSON object for this plan from PLAN_INDEX.plans[]
-# files_modified is an array of strings (repo-relative paths or globs)
-PLAN_FILES=$(jq -r '.files_modified // [] | join(" ")' <<<"$plan_json")
-plan_id=$(jq -r '.id' <<<"$plan_json")
-```
-
-Then run the per-plan gate:
-
-```bash
-USE_WORKTREES_FOR_PLAN="$USE_WORKTREES"
-
-if [ -n "$SUBMODULE_PATHS" ] && [ "$USE_WORKTREES_FOR_PLAN" != "false" ]; then
-  if [ -z "$PLAN_FILES" ]; then
-    # Fallback: planned paths are unknown/unparseable — fall back to the safe
-    # behavior (disable worktree isolation for this plan) and log why.
-    echo "[worktree] Plan ${plan_id}: files_modified missing/unparseable — disabling worktree isolation as a safety fallback (submodule project)"
-    USE_WORKTREES_FOR_PLAN=false
-  else
-    # Compute intersection with glob-safe normalization. Both sides are
-    # normalized (strip leading "./", strip trailing "/") and matched
-    # bidirectionally so a globby planned path like "vendor/**/*.c" still
-    # matches submodule "vendor/foo", and "./vendor/foo/bar.c" matches
-    # submodule "vendor/foo".
-    INTERSECT=""
-    set -f  # disable globbing while iterating literal patterns
-    for sm_raw in $SUBMODULE_PATHS; do
-      # Normalize submodule path: strip ./ prefix and trailing /
-      sm="${sm_raw#./}"
-      sm="${sm%/}"
-      [ -z "$sm" ] && continue
-      for pf_raw in $PLAN_FILES; do
-        # Normalize planned path the same way
-        pf="${pf_raw#./}"
-        pf="${pf%/}"
-        [ -z "$pf" ] && continue
-        matched=0
-        # Direction 1: planned path is the submodule or lies inside it
-        case "$pf" in
-          "$sm"|"$sm"/*) matched=1 ;;
-        esac
-        # Direction 2: submodule lies inside the planned path (e.g. plan
-        # declares "vendor" or a glob expanding to a directory containing
-        # the submodule).
-        if [ "$matched" -eq 0 ]; then
-          case "$sm" in
-            "$pf"|"$pf"/*) matched=1 ;;
-          esac
-        fi
-        # Direction 3: planned path uses a glob — strip glob wildcards
-        # and check whether the resulting prefix overlaps the submodule
-        # path in either direction.
-        if [ "$matched" -eq 0 ]; then
-          case "$pf" in
-            *'*'*|*'?'*|*'['*)
-              # Take the literal prefix before the first glob metachar.
-              prefix="${pf%%[*?[]*}"
-              prefix="${prefix%/}"
-              if [ -n "$prefix" ]; then
-                case "$sm" in
-                  "$prefix"|"$prefix"/*) matched=1 ;;
-                esac
-                if [ "$matched" -eq 0 ]; then
-                  case "$prefix" in
-                    "$sm"|"$sm"/*) matched=1 ;;
-                  esac
-                fi
-              fi
-              ;;
-          esac
-        fi
-        if [ "$matched" -eq 1 ]; then
-          INTERSECT="$INTERSECT $pf_raw"
-        fi
-      done
-    done
-    set +f
-    if [ -n "$INTERSECT" ]; then
-      echo "[worktree] Plan ${plan_id}: planned paths intersect submodule paths (${INTERSECT# }) — disabling worktree isolation for this plan"
-      USE_WORKTREES_FOR_PLAN=false
-    fi
-  fi
-fi
-```
-
-After running this for the plan, the dispatch branches in `execute_waves` step 3 MUST gate on `USE_WORKTREES_FOR_PLAN` for the current plan, not on the project-level `USE_WORKTREES`. Track which plans in this wave actually used worktrees (append `plan_id` to a `WAVE_WORKTREE_PLANS` accumulator when `USE_WORKTREES_FOR_PLAN != false`) — the post-wave cleanup step (5.5) uses this to decide whether worktree-merge cleanup is needed at all.