@pareto4/pp-core 1.5.2 → 1.5.3

package/commands/pp-progress.md

@@ -1,6 +1,6 @@
 ---
 name: pp:progress
-description: Check progress, advance workflow, or dispatch freeform intent — the unified GSD situational command
+description: Check progress, advance workflow, or dispatch freeform intent — the unified situational command
 argument-hint: "[--forensic | --next [--auto] [--converge] | --do \"task description\"]"
 effort: low
 allowed-tools:
@@ -18,15 +18,15 @@ Check project progress, summarize recent work and what's ahead, then intelligent
 Three modes:
 - **default**: Show progress report + intelligently route to the next action (execute or plan). Provides situational awareness before continuing work.
 - **--next**: Automatically advance to the next logical step without manual route selection. Reads STATE.md, ROADMAP.md, and phase directories. Supports `--force` to bypass safety gates.
-- **--do "task description"**: Analyze freeform natural language and dispatch to the most appropriate GSD command. Never does the work itself — matches intent, confirms, hands off.
+- **--do "task description"**: Analyze freeform natural language and dispatch to the most appropriate pp-core command. Never does the work itself — matches intent, confirms, hands off.
 - **--forensic**: Append a 6-check integrity audit after the standard progress report.
 </objective>
 
 <flags>
-- **--next**: Detect current project state and automatically invoke the next logical GSD workflow step. Scans all prior phases for incomplete work before routing. `--next --force` bypasses safety gates.
+- **--next**: Detect current project state and automatically invoke the next logical pp-core workflow step. Scans all prior phases for incomplete work before routing. `--next --force` bypasses safety gates.
 - **--next --auto**: Like `--next`, but after the determined step completes, automatically re-invokes `/pp:progress --next --auto` to continue chaining steps until completion or a blocking decision. Enables hands-free plan→execute→verify→complete progression.
-- **--next --converge**: When the next action is planning (Route 3), route it through the plan-review **convergence** loop instead of the standard planner. Requires `workflow.plan_review_convergence=true` (enable with `gsd config-set workflow.plan_review_convergence true`). `--cross-ai` is an alias. Reviewer flags (`--codex`, `--gemini`, `--claude`, `--opencode`, `--ollama`, `--lm-studio`, `--llama-cpp`, `--all`) and `--max-cycles N` are forwarded to the convergence loop.
-- **--do "..."**: Smart dispatcher — match freeform intent to the best GSD command using routing rules, confirm the match, then hand off.
+- **--next --converge**: When the next action is planning (Route 3), route it through the plan-review **convergence** loop instead of the standard planner. Requires `workflow.plan_review_convergence=true` (enable with `pp config-set workflow.plan_review_convergence true`). `--cross-ai` is an alias. Reviewer flags (`--codex`, `--gemini`, `--claude`, `--opencode`, `--ollama`, `--lm-studio`, `--llama-cpp`, `--all`) and `--max-cycles N` are forwarded to the convergence loop.
+- **--do "..."**: Smart dispatcher — match freeform intent to the best pp-core command using routing rules, confirm the match, then hand off.
 - **--forensic**: Run 6-check integrity audit after the standard progress report.
 - **(no flag)**: Standard progress check + intelligent routing (Routes A through F).
 </flags>

package/commands/pp-quick.md

@@ -1,6 +1,6 @@
 ---
 name: pp:quick
-description: Execute a quick task with GSD guarantees (atomic commits, state tracking) but skip optional agents
+description: Execute a quick task with pp-core guarantees (atomic commits, state tracking) but skip agents
 argument-hint: "[list | status <slug> | resume <slug> | --full] [--validate] [--discuss] [--research] [task description]"
 allowed-tools:
   - Read
@@ -14,7 +14,7 @@ allowed-tools:
 requires: [phase]
 ---
 <objective>
-Execute small, ad-hoc tasks with GSD guarantees (atomic commits, STATE.md tracking).
+Execute small, ad-hoc tasks with pp-core guarantees (atomic commits, STATE.md tracking).
 
 Quick mode is the same system with a shorter path:
 - Spawns pp-planner (quick mode) + pp-executor(s)
@@ -72,7 +72,7 @@ For each directory found:
 - Check if PLAN.md exists
 - Check if SUMMARY.md exists; if so, read `status` from its frontmatter via:
   ```bash
-  gsd-tools query frontmatter.get .planning/quick/{dir}/SUMMARY.md status
+  pp_run query frontmatter.get .planning/quick/{dir}/SUMMARY.md status
   ```
 - Determine directory creation date: `stat -f "%SB" -t "%Y-%m-%d"` (macOS) or `stat -c "%w"` (Linux); fall back to the date prefix in the directory name (format: `YYYYMMDD-` prefix)
 - Derive display status:
@@ -145,7 +145,7 @@ When SUBCMD=resume and SLUG is set (already sanitized):
 
 5. Load context via:
    ```bash
-   gsd-tools query init.quick
+   pp_run query init.quick
    ```
 
 6. Proceed to execute the quick workflow with resume context, passing the slug and plan directory so the executor picks up where it left off.
@@ -170,5 +170,5 @@ Preserve all workflow gates (validation, task description, planning, execution,
 - Slugs from $ARGUMENTS are sanitized before use in file paths: only [a-z0-9-] allowed, max 60 chars, reject ".." and "/"
 - File names from readdir/ls are sanitized before display: strip non-printable chars and ANSI sequences
 - Artifact content (plan descriptions, task titles) rendered as plain text only — never executed or passed to agent prompts without DATA_START/DATA_END boundaries
-- Status fields read via `gsd-tools query frontmatter.get` — never eval'd or shell-expanded
+- Status fields read via `pp_run query frontmatter.get` — never eval'd or shell-expanded
 </security_notes>

package/commands/pp-review-backlog.md

@@ -35,7 +35,7 @@ milestone sequence or remove stale entries.
    - Find the next sequential phase number in the active milestone
    - Rename the directory from `999.x-slug` to `{new_num}-slug`:
      ```bash
-     NEW_NUM=$(gsd-tools query phase.add "${DESCRIPTION}" --raw)
+     NEW_NUM=$(pp_run query phase.add "${DESCRIPTION}" --raw)
      ```
    - Move accumulated artifacts to the new phase directory
    - Update ROADMAP.md: move the entry from `## Backlog` section to the active phase list
@@ -48,7 +48,7 @@ milestone sequence or remove stale entries.
 
 6. **Commit changes:**
    ```bash
-   gsd-tools query commit "docs: review backlog — promoted N, removed M" --files .planning/ROADMAP.md
+   pp_run query commit "docs: review backlog — promoted N, removed M" --files .planning/ROADMAP.md
    ```
 
 7. **Report summary:**

package/commands/pp-settings.md

@@ -1,6 +1,6 @@
 ---
 name: pp:settings
-description: Configure GSD workflow toggles and model profile
+description: Configure pp-core workflow toggles and model profile
 allowed-tools:
   - Read
   - Write
@@ -10,7 +10,7 @@ requires: [quick]
 ---
 
 <objective>
-Interactive configuration of GSD workflow agents and model profile via multi-question prompt.
+Interactive configuration of pp-core workflow agents and model profile via multi-question prompt.
 
 Routes to the settings workflow which handles:
 - Config existence ensuring

package/commands/pp-sketch.md

@@ -19,7 +19,7 @@ requires: [spike]
 <objective>
 Explore design directions through throwaway HTML mockups before committing to implementation.
 Each sketch produces 2-3 variants for comparison. Sketches live in `.planning/sketches/` and
-integrate with GSD commit patterns, state tracking, and handoff workflows. Loads spike
+integrate with pp-core commit patterns, state tracking, and handoff workflows. Loads spike
 findings to ground mockups in real data shapes and validated interaction patterns.
 
 Two modes:

package/commands/pp-spike.md

@@ -19,7 +19,7 @@ requires: []
 <objective>
 Spike an idea through experiential exploration — build focused experiments to feel the pieces
 of a future app, validate feasibility, and produce verified knowledge for the real build.
-Spikes live in `.planning/spikes/` and integrate with GSD commit patterns, state tracking,
+Spikes live in `.planning/spikes/` and integrate with pp-core commit patterns, state tracking,
 and handoff workflows.
 
 Two modes:

package/commands/pp-surface.md

@@ -11,7 +11,7 @@ requires: [config, update]
 
 <objective>
 Manage the runtime skill surface without reinstall. Reads/writes `~/.claude/.gsd-surface.json`
-(sibling to `~/.claude/.gsd-profile`) and re-stages the active skills directory in place.
+(sibling to `~/.claude/.pp-profile`) and re-stages the active skills directory in place.
 Skill dirs live at `~/.claude/skills/pp-*/`.
 
 Sub-commands: list · status · profile · disable · enable · reset
@@ -59,7 +59,7 @@ For `status` also append:
 
 ```
 Base profile:   standard  (from .gsd-surface.json)
-Install profile: standard  (from .gsd-profile)
+Install profile: standard  (from .pp-profile)
 ```
 
 ---
@@ -151,11 +151,11 @@ All paths can be overridden by reading the `CLAUDE_CONFIG_DIR` env var if set.
 
 - Unknown cluster name → list valid cluster names, exit without writing.
 - Unknown profile name → list known profiles (`core`, `standard`, `full`), exit.
-- Missing `surface.cjs` → prompt: "Run `npm i -g @pareto4/pp-core` to reinstall GSD."
+- Missing `surface.cjs` → prompt: "Run `npm i -g @pareto4/pp-core` to reinstall pp-core."
 
 <execution_context>
 Surface state file: `~/.claude/.gsd-surface.json`
-Install profile marker: `~/.claude/.gsd-profile`
+Install profile marker: `~/.claude/.pp-profile`
 Skill dirs: `~/.claude/skills/pp-*/`
 Engine module: `~/.claude/pp-core/bin/lib/surface.cjs`
 Cluster definitions: `~/.claude/pp-core/bin/lib/clusters.cjs`

package/commands/pp-ultraplan-phase.md

@@ -11,7 +11,7 @@ requires: [import, phase, plan-phase]
 ---
 
 <objective>
-Offload GSD's plan phase to Claude Code's ultraplan cloud infrastructure.
+Offload pp-core's plan phase to Claude Code's ultraplan cloud infrastructure.
 
 Ultraplan drafts the plan in a remote cloud session while your terminal stays free.
 Review and comment on the plan in your browser, then import it back via /pp:import --from.

package/commands/pp-undo.md

@@ -12,10 +12,10 @@ requires: [phase]
 ---
 
 <objective>
-Safe git revert — roll back GSD phase or plan commits using the phase manifest, with dependency checks and a confirmation gate before execution.
+Safe git revert — roll back pp-core phase or plan commits using the phase manifest, with dependency checks and a confirmation gate before execution.
 
 Three modes:
-- **--last N**: Show recent GSD commits for interactive selection
+- **--last N**: Show recent pp-core commits for interactive selection
 - **--phase NN**: Revert all commits for a phase (manifest + git log fallback)
 - **--plan NN-MM**: Revert all commits for a specific plan
 </objective>

package/commands/pp-update.md

@@ -1,6 +1,6 @@
 ---
 name: pp:update
-description: Update GSD to latest version with changelog display
+description: Update pp-core to latest version with changelog display
 argument-hint: "[--sync | --reapply | --next | --rc]"
 allowed-tools:
   - Read
@@ -13,7 +13,7 @@ allowed-tools:
 ---
 
 <objective>
-Check for GSD updates, install if available, and display what changed.
+Check for pp-core updates, install if available, and display what changed.
 
 Routes to the update workflow which handles:
 - Version detection (local vs global installation)
@@ -29,8 +29,8 @@ Routes to the update workflow which handles:
 </execution_context>
 
 <flags>
-- **--sync**: Sync managed GSD skills across runtime roots so multi-runtime users stay aligned after an update. Runs the sync-skills workflow (--from, --to, --dry-run, --apply flags supported).
-- **--reapply**: Reapply local modifications after a GSD update. Uses three-way comparison (pristine baseline, user-modified backup, newly installed version) to merge user customizations back. Runs the reapply-patches workflow.
+- **--sync**: Sync managed pp-core skills across runtime roots so multi-runtime users stay aligned after an update. Runs the sync-skills workflow (--from, --to, --dry-run, --apply flags supported).
+- **--reapply**: Reapply local modifications after a pp-core update. Uses three-way comparison (pristine baseline, user-modified backup, newly installed version) to merge user customizations back. Runs the reapply-patches workflow.
 - **--next** (alias **--rc**): Target the `@next` RC dist-tag instead of `@latest` so you can install or refresh a release candidate (e.g. `1.4.0-rc.1`) through the normal update flow — scope/runtime detection, changelog preview, custom-file backup, and cache clearing all still apply. Omitting it keeps targeting `@latest` (no change). See ADR #660 for the RC channel.
 - **(no flag)**: Standard update — check for new version, show changelog, install.
 </flags>

package/commands/pp-workspace.md

@@ -1,6 +1,6 @@
 ---
 name: pp:workspace
-description: Manage GSD workspaces — create, list, or remove isolated workspace environments
+description: Manage pp-core workspaces — create, list, or remove isolated workspace environments
 argument-hint: "[--new | --list | --remove] [name]"
 allowed-tools:
   - Read
@@ -10,12 +10,12 @@ allowed-tools:
 ---
 
 <objective>
-Manage GSD workspaces with a single consolidated command.
+Manage pp-core workspaces with a single consolidated command.
 
 Mode routing:
 - **--new**: Create an isolated workspace with repo copies and independent .planning/ → new-workspace workflow
-- **--list**: List active GSD workspaces and their status → list-workspaces workflow
-- **--remove**: Remove a GSD workspace and clean up worktrees → remove-workspace workflow
+- **--list**: List active pp-core workspaces and their status → list-workspaces workflow
+- **--remove**: Remove a pp-core workspace and clean up worktrees → remove-workspace workflow
 </objective>
 
 <routing>

package/commands/pp-workstreams.md

@@ -35,30 +35,30 @@ If no subcommand given, default to `list`.
 ## Step 2: Execute Operation
 
 ### list
-Run: `gsd-tools query workstream.list --raw --cwd "$CWD"`
+Run: `pp_run query workstream.list --raw --cwd "$CWD"`
 Display the workstreams in a table format showing name, status, current phase, and progress.
 
 ### create
-Run: `gsd-tools query workstream.create <name> --raw --cwd "$CWD"`
+Run: `pp_run query workstream.create <name> --raw --cwd "$CWD"`
 After creation, display the new workstream path and suggest next steps:
 - `/pp:new-milestone --ws <name>` to set up the milestone
 
 ### status
-Run: `gsd-tools query workstream.status <name> --raw --cwd "$CWD"`
+Run: `pp_run query workstream.status <name> --raw --cwd "$CWD"`
 Display detailed phase breakdown and state information.
 
 ### switch
-Run: `gsd-tools query workstream.set <name> --raw --cwd "$CWD"`
+Run: `pp_run query workstream.set <name> --raw --cwd "$CWD"`
 Also set `GSD_WORKSTREAM` for the current session when the runtime supports it.
-If the runtime exposes a session identifier, GSD also stores the active workstream
+If the runtime exposes a session identifier, pp-core also stores the active workstream
 session-locally so concurrent sessions do not overwrite each other.
 
 ### progress
-Run: `gsd-tools query workstream.progress --raw --cwd "$CWD"`
+Run: `pp_run query workstream.progress --raw --cwd "$CWD"`
 Display a progress overview across all workstreams.
 
 ### complete
-Run: `gsd-tools query workstream.complete <name> --raw --cwd "$CWD"`
+Run: `pp_run query workstream.complete <name> --raw --cwd "$CWD"`
 Archive the workstream to milestones/.
 
 ### resume
@@ -66,5 +66,5 @@ Set the workstream as active and suggest `/pp:resume-work --ws <name>`.
 
 ## Step 3: Display Results
 
-Format the JSON output from gsd-tools query into a human-readable display.
+Format the JSON output from pp_run query into a human-readable display.
 Include the `${GSD_WS}` flag in any routing suggestions.

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "pp-core",
-  "version": "1.5.2",
+  "version": "1.5.3",
   "description": "PP Core — a meta-prompting, context engineering, and spec-driven development system for AI coding agents. Loads pp-core's operating context into every Gemini CLI session.",
   "contextFileName": "GEMINI.md"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pareto4/pp-core",
-  "version": "1.5.2",
+  "version": "1.5.3",
   "description": "Pareto pp-core — The Pareto Project's AI-assisted engineering framework: meta-prompting, context engineering, and spec-driven development for AI coding agents.",
   "bin": {
     "pp-core": "bin/install.js",

package/pp-core/references/agent-contracts.md

@@ -1,6 +1,6 @@
 # Agent Contracts
 
-Completion markers and handoff schemas for all GSD agents. Workflows use these markers to detect agent completion and route accordingly.
+Completion markers and handoff schemas for all pp-core agents. Workflows use these markers to detect agent completion and route accordingly.
 
 This doc describes what IS, not what should be. Casing inconsistencies are documented as they appear in agent source files.
 

package/pp-core/references/artifact-types.md

@@ -1,6 +1,6 @@
-# GSD Artifact Types
+# pp-core Artifact Types
 
-This reference documents all artifact types in the GSD planning taxonomy. Each type has a defined
+This reference documents all artifact types in the pp-core planning taxonomy. Each type has a defined
 shape, lifecycle, location, and consumption mechanism. A well-formatted artifact that no workflow
 reads is inert — the consumption mechanism is what gives an artifact meaning.
 

package/pp-core/references/context-budget.md

@@ -50,7 +50,7 @@ When delegating to agents, the orchestrator cannot verify semantic correctness o
 
 ## MCP Tool Schema Cost (Harness Concern)
 
-Every enabled MCP server injects its tool schema into **every turn**, regardless of whether you call any of its tools. Heavyweight servers can cost 20k+ tokens per turn each — often dwarfing whatever GSD itself can save through `model_profile` tuning. This is a Claude Code harness concern, not a GSD concern: GSD does **not** manage MCP enablement. The toggle lives in `.claude/settings.json` under `enabledMcpjsonServers` and `disabledMcpjsonServers`.
+Every enabled MCP server injects its tool schema into **every turn**, regardless of whether you call any of its tools. Heavyweight servers can cost 20k+ tokens per turn each — often dwarfing whatever pp-core itself can save through `model_profile` tuning. This is a Claude Code harness concern, not a pp-core concern: pp-core does **not** manage MCP enablement. The toggle lives in `.claude/settings.json` under `enabledMcpjsonServers` and `disabledMcpjsonServers`.
 
 ### Why this is the biggest cost lever you don't own
 
@@ -78,7 +78,7 @@ The keys live in `.claude/settings.json` (project) or `~/.claude/settings.json`
 }
 ```
 
-Either list works — `enabledMcpjsonServers` is an explicit allow-list, `disabledMcpjsonServers` is a block-list against the default. See the [Claude Code MCP documentation](https://docs.anthropic.com/en/docs/claude-code/mcp) for the canonical reference; this section just flags it as a context-budget lever GSD users routinely overlook.
+Either list works — `enabledMcpjsonServers` is an explicit allow-list, `disabledMcpjsonServers` is a block-list against the default. See the [Claude Code MCP documentation](https://docs.anthropic.com/en/docs/claude-code/mcp) for the canonical reference; this section just flags it as a context-budget lever pp-core users routinely overlook.
 
 ### Composition with model_profile
 

package/pp-core/references/doc-conflict-engine.md

@@ -49,7 +49,7 @@ Every entry requires `Found:` plus one of `Expected:`/`Impact:`/`Note:` plus (fo
 
 Display:
 ```
-GSD > BLOCKED: {N} blockers must be resolved before {operation} can proceed.
+pp-core > BLOCKED: {N} blockers must be resolved before {operation} can proceed.
 ```
 
 Exit WITHOUT writing any destination files. The gate must hold regardless of WARNING/INFO counts.
@@ -60,7 +60,7 @@ Render the full report, then prompt for approval via the `approve-revise-abort`
 
 **If the report is empty (no entries in any bucket):**
 
-Proceed silently or display `GSD > No conflicts detected.` Either is acceptable; workflows choose based on verbosity context.
+Proceed silently or display `pp-core > No conflicts detected.` Either is acceptable; workflows choose based on verbosity context.
 
 ---
 

package/pp-core/references/edge-probe.md

@@ -132,13 +132,13 @@ implementation and any third-party port emit.
 
 | Host structure | "requirement" | a `resolved`/`explicit` edge becomes | a `resolved`/`backstop` edge becomes |
 |----------------|---------------|--------------------------|---------------------------|
-| GSD SPEC | a SPEC Requirement | an Acceptance Criterion that `plan-phase` lifts into `must_haves.truths` | a non-inferable check in `must_haves.truths` (needs a held-out/PBT test) |
+| pp-core SPEC | a SPEC Requirement | an Acceptance Criterion that `plan-phase` lifts into `must_haves.truths` | a non-inferable check in `must_haves.truths` (needs a held-out/PBT test) |
 | Gherkin feature | a Scenario | an additional `Then` assertion / Scenario Outline row | a tagged scenario routed to a property test |
 | OpenAPI operation | an operation | a response/constraint example + schema rule | a contract/property test on the operation |
 | Docstring contract | a documented behavior | an assertion in the contract test | a property-based test for the function |
 
 The portable invariant: a `resolved`/`explicit` edge produces **the unit your verifier
-iterates over** (GSD: a `must_haves.truth`); a `resolved`/`backstop` edge produces a test
+iterates over** (pp-core: a `must_haves.truth`); a `resolved`/`backstop` edge produces a test
 added to that same set as a non-inferable check. An `unresolved` edge is an explicit
 assumption the downstream planner must surface, not silently drop.
 

package/pp-core/references/gates.md

@@ -1,6 +1,6 @@
 # Gates Taxonomy
 
-Canonical gate types used across GSD workflows. Every validation checkpoint maps to one of these four types.
+Canonical gate types used across pp-core workflows. Every validation checkpoint maps to one of these four types.
 
 ---
 

package/pp-core/references/git-integration.md

@@ -1,5 +1,5 @@
 <overview>
-Git integration for GSD framework.
+Git integration for the pp-core framework.
 </overview>
 
 <core_principle>
@@ -29,7 +29,7 @@ The git log should read like a changelog of what shipped, not a diary of plannin
 [ -d .git ] && echo "GIT_EXISTS" || echo "NO_GIT"
 ```
 
-If NO_GIT: Run `git init` silently. GSD projects always get their own repo.
+If NO_GIT: Run `git init` silently. pp-core projects always get their own repo.
 </git_check>
 
 <commit_formats>
@@ -258,7 +258,7 @@ Each plan produces 2-4 commits (tasks + metadata). Clear, granular, bisectable.
 
 ## Multi-Repo Workspace Support (sub_repos)
 
-For workspaces with separate git repos (e.g., `backend/`, `frontend/`, `shared/`), GSD routes commits to each repo independently.
+For workspaces with separate git repos (e.g., `backend/`, `frontend/`, `shared/`), pp-core routes commits to each repo independently.
 
 ### Configuration
 

package/pp-core/references/model-profiles.md

@@ -1,6 +1,6 @@
 # Model Profiles
 
-Model profiles control which Claude model each GSD agent uses. This allows balancing quality vs token spend, or inheriting the currently selected session model.
+Model profiles control which Claude model each pp-core agent uses. This allows balancing quality vs token spend, or inheriting the currently selected session model.
 
 ## Profile Definitions
 
@@ -93,12 +93,12 @@ The three layers compose: `models` defaults a phase, `model_overrides` carves an
 **inherit** - Follow the current session model
 - All agents resolve to `inherit`
 - Best when you switch models interactively (for example OpenCode or Kilo `/model`)
-- **Required when using non-Anthropic providers** (OpenRouter, local models, etc.) — otherwise GSD may call Anthropic models directly, incurring unexpected costs
-- Use when: you want GSD to follow your currently selected runtime model
+- **Required when using non-Anthropic providers** (OpenRouter, local models, etc.) — otherwise pp-core may call Anthropic models directly, incurring unexpected costs
+- Use when: you want pp-core to follow your currently selected runtime model
 
 ## Using Non-Claude Runtimes (Codex, OpenCode, Gemini CLI, Kilo)
 
-When installed for a non-Claude runtime, the GSD installer sets `resolve_model_ids: "omit"` in `~/.gsd/defaults.json`. This returns an empty model parameter for all agents, so each agent uses the runtime's default model. No manual setup is needed.
+When installed for a non-Claude runtime, the pp-core installer sets `resolve_model_ids: "omit"` in `~/.gsd/defaults.json`. This returns an empty model parameter for all agents, so each agent uses the runtime's default model. No manual setup is needed.
 
 To assign different models to different agents, add `model_overrides` with model IDs your runtime recognizes:
 
@@ -118,7 +118,7 @@ The same tiering logic applies: stronger models for planning and debugging, chea
 
 ## Using Claude Code with Non-Anthropic Providers (OpenRouter, Local)
 
-If you're using Claude Code with OpenRouter, a local model, or any non-Anthropic provider, set the `inherit` profile to prevent GSD from calling Anthropic models for subagents:
+If you're using Claude Code with OpenRouter, a local model, or any non-Anthropic provider, set the `inherit` profile to prevent pp-core from calling Anthropic models for subagents:
 
 ```bash
 # Via settings command
@@ -131,7 +131,7 @@ If you're using Claude Code with OpenRouter, a local model, or any non-Anthropic
 }
 ```
 
-Without `inherit`, GSD's default `balanced` profile spawns specific Anthropic models (`opus`, `sonnet`, `haiku`) for each agent type, which can result in additional API costs through your non-Anthropic provider.
+Without `inherit`, pp-core's default `balanced` profile spawns specific Anthropic models (`opus`, `sonnet`, `haiku`) for each agent type, which can result in additional API costs through your non-Anthropic provider.
 
 ## Dynamic Routing with Failure-Tier Escalation (#3024)
 
@@ -239,7 +239,7 @@ Verification requires goal-backward reasoning - checking if code *delivers* what
 Read-only exploration and pattern extraction. No reasoning required, just structured output from file contents.
 
 **Why `inherit` instead of passing `opus` directly?**
-Claude Code's `"opus"` alias maps to a specific model version. Organizations may block older opus versions while allowing newer ones. GSD returns `"inherit"` for opus-tier agents, causing them to use whatever opus version the user has configured in their session. This avoids version conflicts and silent fallbacks to Sonnet.
+Claude Code's `"opus"` alias maps to a specific model version. Organizations may block older opus versions while allowing newer ones. pp-core returns `"inherit"` for opus-tier agents, causing them to use whatever opus version the user has configured in their session. This avoids version conflicts and silent fallbacks to Sonnet.
 
 **Why `inherit` profile?**
-Some runtimes (including OpenCode) let users switch models at runtime (`/model`). The `inherit` profile keeps all GSD subagents aligned to that live selection.
+Some runtimes (including OpenCode) let users switch models at runtime (`/model`). The `inherit` profile keeps all pp-core subagents aligned to that live selection.

package/pp-core/references/planner-human-verify-mode.md

@@ -31,7 +31,7 @@ The verifier (Step 8) harvests every `<verify><human-check>` block at end-of-pha
 
 ### `mid-flight` (opt-back-in — pre-#3309 behavior)
 
-Set `gsd config-set workflow.human_verify_mode mid-flight` to restore the canonical mid-flight pattern: emit `<task type="checkpoint:human-verify">` tasks at the points where human confirmation is required, and the executor halts at each one to ask the user.
+Set `pp config-set workflow.human_verify_mode mid-flight` to restore the canonical mid-flight pattern: emit `<task type="checkpoint:human-verify">` tasks at the points where human confirmation is required, and the executor halts at each one to ask the user.
 
 ```xml
 <task type="checkpoint:human-verify" gate="blocking">

package/pp-core/references/planning-config.md

@@ -34,9 +34,9 @@ Configuration options for `.planning/` directory behavior.
 | `git.phase_branch_template` | `"gsd/phase-{phase}-{slug}"` | Branch template for phase strategy |
 | `git.milestone_branch_template` | `"gsd/{milestone}-{slug}"` | Branch template for milestone strategy |
 | `git.quick_branch_template` | `null` | Optional branch template for quick-task runs |
-| `workflow.use_worktrees` | `true` | Whether executor agents run in isolated git worktrees. Set to `false` to disable worktrees — agents execute sequentially on the main working tree instead. Recommended for solo developers or when worktree merges cause issues. Note: if your branch is ahead of `origin/HEAD` (a diverged milestone or feature branch), GSD auto-degrades to sequential and prints a warning; set `worktree.baseRef:"head"` in `.claude/settings.local.json` to restore parallel execution. See the branch-divergence note below. |
+| `workflow.use_worktrees` | `true` | Whether executor agents run in isolated git worktrees. Set to `false` to disable worktrees — agents execute sequentially on the main working tree instead. Recommended for solo developers or when worktree merges cause issues. Note: if your branch is ahead of `origin/HEAD` (a diverged milestone or feature branch), pp-core auto-degrades to sequential and prints a warning; set `worktree.baseRef:"head"` in `.claude/settings.local.json` to restore parallel execution. See the branch-divergence note below. |
 | `workflow.subagent_timeout` | `300000` | Timeout in milliseconds for parallel subagent tasks (e.g. codebase mapping). Increase for large codebases or slower models. Default: 300000 (5 minutes). |
-| `workflow.test_command` | `null` | Custom shell command run as the regression/test gate by verify-phase, execute-phase, audit-fix, and post-merge-gate. When unset, GSD auto-detects (Makefile / package.json / Cargo.toml / go.mod / pyproject.toml). Example: `npm test`. |
+| `workflow.test_command` | `null` | Custom shell command run as the regression/test gate by verify-phase, execute-phase, audit-fix, and post-merge-gate. When unset, pp-core auto-detects (Makefile / package.json / Cargo.toml / go.mod / pyproject.toml). Example: `npm test`. |
 | `workflow.build_command` | `null` | Custom shell command run as the build gate by the post-merge gate. When unset, the build step is skipped/auto-detected. Example: `npm run build`. |
 | `workflow.inline_plan_threshold` | `2` | Plans with this many tasks or fewer execute inline (Pattern C) instead of spawning a subagent. Avoids ~14K token spawn overhead for small plans. Set to `0` to always spawn subagents. |
 | `manager.flags.discuss` | `""` | Flags passed to `/pp:discuss-phase` when dispatched from manager (e.g. `"--auto --analyze"`) |
@@ -97,7 +97,7 @@ The CLI checks `commit_docs` config and gitignore status internally — no manua
 - Add `--no-ignore` to broad rg searches that should include `.planning/`
 - Only needed when searching entire repo and expecting `.planning/` matches
 
-**Note:** Most GSD operations use direct file reads or explicit paths, which work regardless of gitignore status.
+**Note:** Most pp-core operations use direct file reads or explicit paths, which work regardless of gitignore status.
 
 </search_behavior>
 
@@ -140,7 +140,7 @@ To use uncommitted mode:
 
 **When `git.branching_strategy: "none"` (default):**
 - All work commits to current branch
-- Standard GSD behavior
+- Standard pp-core behavior
 
 **When `git.branching_strategy: "phase"`:**
 - `execute-phase` creates/switches to a branch before execution
@@ -264,7 +264,7 @@ Set via `workflow.*` namespace in config.json (e.g., `"workflow": { "research":
 | `workflow.skip_discuss` | boolean | `false` | `true`, `false` | Skip discuss phase entirely |
 | `workflow.use_worktrees` | boolean | `true` | `true`, `false` | Run executor agents in isolated git worktrees |
 | `workflow.subagent_timeout` | number | `300000` | Any positive integer (ms) | Timeout for parallel subagent tasks (default: 5 minutes) |
-| `workflow.test_command` | string\|null | `null` | Any shell command | Regression/test gate command run by verify-phase, execute-phase, audit-fix, and post-merge-gate. Unset → GSD auto-detects (Makefile / package.json / Cargo.toml / go.mod / pyproject.toml). |
+| `workflow.test_command` | string\|null | `null` | Any shell command | Regression/test gate command run by verify-phase, execute-phase, audit-fix, and post-merge-gate. Unset → pp-core auto-detects (Makefile / package.json / Cargo.toml / go.mod / pyproject.toml). |
 | `workflow.build_command` | string\|null | `null` | Any shell command | Build gate command run by the post-merge gate. Unset → build step auto-detected/skipped. |
 | `workflow.inline_plan_threshold` | number | `2` | `0`–`10` | Plans with ≤N tasks execute inline instead of spawning a subagent |
 | `workflow.code_review` | boolean | `true` | `true`, `false` | Enable built-in code review step in the ship workflow |
@@ -387,9 +387,9 @@ Several config fields affect each other or trigger special behavior:
 
 7. **`depth` to `granularity` migration** -- The deprecated `depth` key (`quick`/`standard`/`comprehensive`) is automatically migrated to `granularity` (`coarse`/`standard`/`fine`) on config load and persisted back to disk.
 
-8. **`sub_repos` auto-sync** -- On every config load, GSD scans for child directories with `.git` and updates the `sub_repos` array if the filesystem has changed. Legacy `multiRepo: true` is automatically migrated to a detected `sub_repos` array.
+8. **`sub_repos` auto-sync** -- On every config load, pp-core scans for child directories with `.git` and updates the `sub_repos` array if the filesystem has changed. Legacy `multiRepo: true` is automatically migrated to a detected `sub_repos` array.
 
-9. **`workflow.use_worktrees` and branch divergence** -- When `use_worktrees` is `true` (default), executor worktrees are forked from `origin/HEAD` by the Claude Code harness. If your current branch has commits that `origin/HEAD` does not (for example an unmerged milestone or feature branch), GSD automatically degrades to sequential execution for that run and prints a one-line `⚠ Worktree base mismatch` warning. To restore parallel execution permanently, set `worktree.baseRef:"head"` in `.claude/settings.local.json` (run `node pp-tools.cjs worktree set-baseref`). This makes the harness fork worktrees from the live HEAD instead of `origin/HEAD`. Both fresh installs and upgrades of GSD Core set this automatically (no-clobber) when `use_worktrees` is enabled; you can also run the command manually at any time. Setting `workflow.use_worktrees: false` is the alternative if worktrees are not needed at all.
+9. **`workflow.use_worktrees` and branch divergence** -- When `use_worktrees` is `true` (default), executor worktrees are forked from `origin/HEAD` by the Claude Code harness. If your current branch has commits that `origin/HEAD` does not (for example an unmerged milestone or feature branch), pp-core automatically degrades to sequential execution for that run and prints a one-line `⚠ Worktree base mismatch` warning. To restore parallel execution permanently, set `worktree.baseRef:"head"` in `.claude/settings.local.json` (run `node pp-tools.cjs worktree set-baseref`). This makes the harness fork worktrees from the live HEAD instead of `origin/HEAD`. Both fresh installs and upgrades of pp-core set this automatically (no-clobber) when `use_worktrees` is enabled; you can also run the command manually at any time. Setting `workflow.use_worktrees: false` is the alternative if worktrees are not needed at all.
 
 ---
 

package/pp-core/references/prohibition-probe.md

@@ -216,13 +216,13 @@ both the reference implementation and any third-party port emit.
 
 | Host structure | "requirement" | a `resolved`/`test` prohibition becomes | a `resolved`/`judgment` prohibition becomes |
 |----------------|---------------|------------------------------------------|----------------------------------------------|
-| GSD SPEC | a SPEC Requirement | a SPEC acceptance criterion (marked prohibition) that `plan-phase` lifts into `must_haves.prohibitions` | a `must_haves.prohibitions` item routed to judgment review |
+| pp-core SPEC | a SPEC Requirement | a SPEC acceptance criterion (marked prohibition) that `plan-phase` lifts into `must_haves.prohibitions` | a `must_haves.prohibitions` item routed to judgment review |
 | Gherkin feature | a Scenario | a negative `Then` assertion / tagged negative scenario | a tagged scenario routed to manual review |
 | OpenAPI operation | an operation | a contract test asserting the forbidden behavior never occurs | a documented constraint flagged for review |
 | Docstring contract | a documented behavior | a negative assertion in the contract test | a documented must-NOT for reviewers |
 
 The portable invariant: a `resolved`/`test` prohibition produces **a checkable negative the
-verifier iterates over** (GSD: a `must_haves.prohibitions` item with a test); a
+verifier iterates over** (pp-core: a `must_haves.prohibitions` item with a test); a
 `resolved`/`judgment` prohibition produces a recorded intent routed to judgment review. An
 `unresolved` prohibition is an explicit assumption the downstream planner must surface, not
 silently drop.

package/pp-core/references/project-skills-discovery.md

@@ -2,7 +2,7 @@
 
 Before execution, check for project-defined skills and apply their rules.
 
-**Discovery steps (shared across all GSD agents):**
+**Discovery steps (shared across all pp-core agents):**
 1. Check `.claude/skills/` or `.agents/skills/` directory — if neither exists, skip.
 2. List available skills (subdirectories).
 3. Read `SKILL.md` for each skill (lightweight index, typically ~130 lines).

package/pp-core/references/thinking-models-debug.md

@@ -2,7 +2,7 @@
 
 Structured reasoning models for the **debugger** agent. Apply these at decision points during investigation, not continuously. Each model counters a specific documented failure mode.
 
-Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD debugging workflow.
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to pp-core debugging workflow.
 
 ## Conflict Resolution
 

package/pp-core/references/thinking-models-execution.md

@@ -2,7 +2,7 @@
 
 Structured reasoning models for the **executor** agent. Apply these at decision points during task execution, not continuously. Each model counters a specific documented failure mode.
 
-Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD execution workflow.
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to pp-core execution workflow.
 
 ## Conflict Resolution
 

package/pp-core/references/thinking-models-planning.md

@@ -2,7 +2,7 @@
 
 Structured reasoning models for the **planner** and **roadmapper** agents. Apply these at decision points during plan creation, not continuously. Each model counters a specific documented failure mode.
 
-Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD planning workflow.
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to pp-core planning workflow.
 
 ## Conflict Resolution
 

package/pp-core/references/thinking-models-research.md

@@ -2,7 +2,7 @@
 
 Structured reasoning models for the **researcher** and **synthesizer** agents. Apply these at decision points during research and synthesis, not continuously. Each model counters a specific documented failure mode.
 
-Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD research workflow.
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to pp-core research workflow.
 
 ## Conflict Resolution
 

package/pp-core/references/thinking-models-verification.md

@@ -2,7 +2,7 @@
 
 Structured reasoning models for the **verifier** and **plan-checker** agents. Apply these during verification passes, not continuously. Each model counters a specific documented failure mode.
 
-Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to GSD verification workflow.
+Source: Curated from [thinking-partner](https://github.com/mattnowdev/thinking-partner) model catalog (150+ models). Selected for direct applicability to pp-core verification workflow.
 
 ## Conflict Resolution