@pareto4/pp-core 1.5.1 → 1.5.3

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
 

package/pp-core/references/ui-brand.md

@@ -1,6 +1,6 @@
 <ui_patterns>
 
-Visual patterns for user-facing GSD output. Orchestrators @-reference this file.
+Visual patterns for user-facing pp-core output. Orchestrators @-reference this file.
 
 ## Stage Banners
 
@@ -8,7 +8,7 @@ Use for major workflow transitions.
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► {STAGE NAME}
+ pp-core ► {STAGE NAME}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -155,7 +155,7 @@ Always at end of major completions.
 
 - Varying box/banner widths
 - Mixing banner styles (`===`, `---`, `***`)
-- Skipping `GSD ►` prefix in banners
+- Skipping `pp-core ►` prefix in banners
 - Random emoji (`🚀`, `✨`, `💫`)
 - Missing Next Up block after completions
 

package/pp-core/references/universal-anti-patterns.md

@@ -21,7 +21,7 @@ Rules that apply to ALL workflows and agents. Individual workflows may have addi
 
 ## Subagent Rules
 
-10. **NEVER** use non-GSD agent types (`general-purpose`, `Explore`, `Plan`, `Bash`, `feature-dev`, etc.) -- ALWAYS use `subagent_type: "pp-{agent}"` (e.g., `pp-phase-researcher`, `pp-executor`, `pp-planner`). GSD agents have project-aware prompts, audit logging, and workflow context. Generic agents bypass all of this.
+10. **NEVER** use non-pp-core agent types (`general-purpose`, `Explore`, `Plan`, `Bash`, `feature-dev`, etc.) -- ALWAYS use `subagent_type: "pp-{agent}"` (e.g., `pp-phase-researcher`, `pp-executor`, `pp-planner`). pp-core agents have project-aware prompts, audit logging, and workflow context. Generic agents bypass all of this.
 11. **Do not** re-litigate decisions that are already locked in CONTEXT.md (or PROJECT.md ## Context section) -- respect locked decisions unconditionally.
 
 ## Questioning Anti-Patterns
@@ -50,10 +50,10 @@ Reference: `references/questioning.md` for the full anti-pattern list.
 22. **Config fallback awareness**: Config loading returns `null` silently on invalid JSON. If your workflow depends on config values, check for null and warn the user: "config.json is invalid or missing -- running with defaults."
 23. **Partial state recovery**: If STATE.md references a phase directory that doesn't exist, do not proceed silently. Warn the user and suggest diagnosing the mismatch.
 
-## GSD-Specific Rules
+## pp-core-Specific Rules
 
-24. **Do not** check for `mode === 'auto'` or `mode === 'autonomous'` -- GSD uses `yolo` config flag. Check `yolo: true` for autonomous mode, absence or `false` for interactive mode.
-25. **Prefer `pp-tools query`** for orchestration when a handler exists; when shelling out to the legacy CLI, use **`pp-tools.cjs`** (not `pp-tools.js` or any other filename) — GSD ships the programmatic API as CommonJS for Node.js CLI compatibility.
+24. **Do not** check for `mode === 'auto'` or `mode === 'autonomous'` -- pp-core uses `yolo` config flag. Check `yolo: true` for autonomous mode, absence or `false` for interactive mode.
+25. **Prefer `pp-tools query`** for orchestration when a handler exists; when shelling out to the legacy CLI, use **`pp-tools.cjs`** (not `pp-tools.js` or any other filename) — pp-core ships the programmatic API as CommonJS for Node.js CLI compatibility.
 26. **Plan files MUST follow `{padded_phase}-{NN}-PLAN.md` pattern** (e.g., `01-01-PLAN.md`). Never use `PLAN-01.md`, `plan-01.md`, or any other variation -- pp-tools detection depends on this exact pattern.
 27. **Do not start executing the next plan before writing the SUMMARY.md for the current plan** -- downstream plans may reference it via `@` includes.
 

package/pp-core/references/workstream-flag.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-The `--ws <name>` flag scopes GSD operations to a specific workstream, enabling
+The `--ws <name>` flag scopes pp-core operations to a specific workstream, enabling
 parallel milestone work by multiple Claude Code instances on the same codebase.
 
 ## Resolution Priority
@@ -19,14 +19,14 @@ The shared `.planning/active-workstream` file is fundamentally unsafe when multi
 Claude/Codex instances are active on the same repo at the same time. One session can
 silently repoint another session's `STATE.md`, `ROADMAP.md`, and phase paths.
 
-GSD now prefers a session-scoped pointer keyed by runtime/session identity
+pp-core now prefers a session-scoped pointer keyed by runtime/session identity
 (`GSD_SESSION_KEY`, `CODEX_THREAD_ID`, `CLAUDE_CODE_SSE_PORT`, terminal session IDs,
 or the controlling TTY). This keeps concurrent sessions isolated while preserving
 legacy compatibility for runtimes that do not expose a stable session key.
 
 ## Session Identity Resolution
 
-When GSD resolves the session-scoped pointer in step 3 above, it uses this order:
+When pp-core resolves the session-scoped pointer in step 3 above, it uses this order:
 
 1. Explicit runtime/session env vars such as `GSD_SESSION_KEY`, `CODEX_THREAD_ID`,
    `CLAUDE_SESSION_ID`, `CLAUDE_CODE_SSE_PORT`, `OPENCODE_SESSION_ID`,
@@ -35,11 +35,11 @@ When GSD resolves the session-scoped pointer in step 3 above, it uses this order
 2. `TTY` or `SSH_TTY` if the shell/runtime already exposes the terminal path
 3. A single best-effort `tty` probe, but only when stdin is interactive
 
-If none of those produce a stable identity, GSD does not keep probing. It falls
+If none of those produce a stable identity, pp-core does not keep probing. It falls
 back directly to the legacy shared `.planning/active-workstream` file.
 
 This matters in headless or stripped environments: when stdin is already
-non-interactive, GSD intentionally skips shelling out to `tty` because that path
+non-interactive, pp-core intentionally skips shelling out to `tty` because that path
 cannot discover a stable session identity and only adds avoidable failures on the
 routing hot path.
 
@@ -48,14 +48,14 @@ routing hot path.
 Session-scoped pointers are intentionally lightweight and best-effort:
 
 - Clearing a workstream for one session removes only that session's pointer file
-- If that was the last pointer for the repo, GSD also removes the now-empty
+- If that was the last pointer for the repo, pp-core also removes the now-empty
   per-project temp directory
 - If sibling session pointers still exist, the temp directory is left in place
-- When a pointer refers to a workstream directory that no longer exists, GSD
+- When a pointer refers to a workstream directory that no longer exists, pp-core
   treats it as stale state: it removes that pointer file and resolves to `null`
   until the session explicitly sets a new active workstream again
 
-GSD does not currently run a background garbage collector for historical temp
+pp-core does not currently run a background garbage collector for historical temp
 directories. Cleanup is opportunistic at the pointer being cleared or self-healed,
 and broader temp hygiene is left to OS temp cleanup or future maintenance work.
 

package/pp-core/templates/README.md

@@ -1,8 +1,8 @@
-# GSD Canonical Artifact Registry
+# pp-core Canonical Artifact Registry
 
-This directory contains the template files for every artifact that GSD workflows officially produce. The table below is the authoritative index: **if a `.planning/` root file is not listed here, `pp-health` will flag it as W019** (unrecognized artifact).
+This directory contains the template files for every artifact that pp-core workflows officially produce. The table below is the authoritative index: **if a `.planning/` root file is not listed here, `pp-health` will flag it as W019** (unrecognized artifact).
 
-Agents should query this file before treating a `.planning/` file as authoritative. If the file name does not appear below, it is not a canonical GSD artifact.
+Agents should query this file before treating a `.planning/` file as authoritative. If the file name does not appear below, it is not a canonical pp-core artifact.
 
 ---
 
@@ -20,7 +20,7 @@ These files live directly at `.planning/` — not inside phase subdirectories.
 | `BACKLOG.md` | *(inline)* | `/pp-add-backlog` | Pending ideas and deferred work |
 | `LEARNINGS.md` | *(inline)* | `/pp:extract-learnings`, `/pp:execute-phase` | Phase retrospective learnings for future plans |
 | `THREADS.md` | *(inline)* | `/pp:thread` | Persistent discussion threads |
-| `config.json` | `config.json` | `/pp:new-project`, `/pp:health --repair` | Project-specific GSD configuration |
+| `config.json` | `config.json` | `/pp:new-project`, `/pp:health --repair` | Project-specific pp-core configuration |
 | `CLAUDE.md` | `claude-md.md` | `/pp-profile` | Auto-assembled Claude Code context file |
 | `RETROSPECTIVE.md` | *(inline)* | `/pp:complete-milestone` | Living milestone retrospective updated at each milestone close |
 

package/pp-core/templates/claude-md.md

@@ -85,7 +85,7 @@ No project skills found. Add skills to any of: `.claude/skills/`, `.agents/skill
 **Discovery behavior:**
 - Scans `.claude/skills/`, `.agents/skills/`, `.cursor/skills/`, `.github/skills/` for subdirectories containing `SKILL.md`
 - Extracts `name` and `description` from YAML frontmatter (supports multi-line descriptions)
-- Skips GSD's own installed skills (directories starting with `pp-`)
+- Skips pp-core's own installed skills (directories starting with `pp-`)
 - Deduplicates by skill name across directories
 
 ### Workflow Enforcement Section
@@ -127,7 +127,7 @@ CLAUDE.md file and no profile section exists yet.
 3. **Conventions** — Code patterns and rules (how code is written)
 4. **Architecture** — System structure (how components fit together)
 5. **Skills** — Discovered project skills with name and description (what domain knowledge is available)
-6. **Workflow Enforcement** — Default GSD entry points for file-changing work
+6. **Workflow Enforcement** — Default pp-core entry points for file-changing work
 7. **Profile** — Developer behavioral preferences (how to interact)
 
 ## Marker Format

package/pp-core/templates/codebase/architecture.md

@@ -146,7 +146,7 @@ Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code org
 
 **CLI Command Execution:**
 
-1. User runs: `gsd new-project`
+1. User runs: `pp new-project`
 2. Commander parses args and flags
 3. Command handler invoked (`src/commands/new-project.ts`)
 4. Handler calls service methods (`src/services/project.ts` → `create()`)
@@ -180,7 +180,7 @@ Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code org
 
 **CLI Entry:**
 - Location: `src/index.ts`
-- Triggers: User runs `gsd <command>`
+- Triggers: User runs `pp <command>`
 - Responsibilities: Register commands, parse args, display help
 
 **Commands:**

package/pp-core/templates/codebase/structure.md

@@ -126,7 +126,7 @@ Template for `.planning/codebase/STRUCTURE.md` - captures physical file organiza
 pp-core/
 ├── bin/                # Executable entry points
 ├── commands/           # Slash command definitions
-│   └── gsd/           # GSD-specific commands
+│   └── pp/            # pp-core-specific commands
 ├── pp-core/     # Skill resources
 │   ├── references/    # Principle documents
 │   ├── templates/     # File templates

package/pp-core/templates/copilot-instructions.md

@@ -1,7 +1,7 @@
-# Instructions for GSD
+# Instructions for pp-core
 
-- Use the pp-core skill when the user asks for GSD or uses a `pp-*` command.
+- Use the pp-core skill when the user asks for pp-core or uses a `pp-*` command.
 - Treat `/pp-...` or `pp-...` as command invocations and load the matching file from `.github/skills/pp-*`.
 - When a command says to spawn a subagent, prefer a matching custom agent from `.github/agents`.
-- Do not apply GSD workflows unless the user explicitly asks for them.
+- Do not apply pp-core workflows unless the user explicitly asks for them.
 - After completing any `pp-*` command (or any deliverable it triggers: feature, bug fix, tests, docs, etc.), ALWAYS: (1) offer the user the next step by prompting via `ask_user`; repeat this feedback loop until the user explicitly indicates they are done.

package/pp-core/templates/dev-preferences.md

@@ -4,7 +4,7 @@ description: Load developer preferences into this session
 
 # Developer Preferences
 
-> Generated by GSD on {{generated_at}} from {{data_source}}.
+> Generated by pp-core on {{generated_at}} from {{data_source}}.
 > Run `/pp:profile-user --refresh` to regenerate.
 
 ## Behavioral Directives

package/pp-core/templates/research.md

@@ -568,7 +568,7 @@ function useVehicleControls(rigidBodyRef) {
 - When "how do experts do this" matters more than "which library"
 
 **Structure:**
-- Use XML tags for section markers (matches GSD templates)
+- Use XML tags for section markers (matches pp-core templates)
 - Seven core sections: summary, standard_stack, architecture_patterns, dont_hand_roll, common_pitfalls, code_examples, sources
 - All sections required (drives comprehensive research)
 

package/pp-core/templates/summary-complex.md

@@ -50,7 +50,7 @@ status: complete
 [Key decisions with brief rationale]
 
 ## Deviations from Plan (Auto-fixed)
-[Detailed auto-fix records per GSD deviation rules]
+[Detailed auto-fix records per pp-core deviation rules]
 
 ## Issues Encountered
 [Problems during planned work and resolutions]

package/pp-core/workflows/add-tests.md

@@ -62,7 +62,7 @@ Exit.
 Present banner:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► ADD TESTS — Phase ${phase_number}: ${phase_name}
+ pp-core ► ADD TESTS — Phase ${phase_number}: ${phase_name}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 </step>
@@ -279,7 +279,7 @@ Create a test coverage report and present to user:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► TEST GENERATION COMPLETE
+ pp-core ► TEST GENERATION COMPLETE
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 ## Results

package/pp-core/workflows/add-todo.md

@@ -1,5 +1,5 @@
 <purpose>
-Capture an idea, task, or issue that surfaces during a GSD session as a structured todo for later work. Enables "thought → capture → continue" flow without losing context.
+Capture an idea, task, or issue that surfaces during a pp-core session as a structured todo for later work. Enables "thought → capture → continue" flow without losing context.
 </purpose>
 
 <required_reading>

package/pp-core/workflows/ai-integration-phase.md

@@ -1,5 +1,5 @@
 <purpose>
-Generate an AI design contract (AI-SPEC.md) for phases that involve building AI systems. Orchestrates pp-framework-selector → pp-ai-researcher → pp-domain-researcher → pp-eval-planner with a validation gate. Inserts between discuss-phase and plan-phase in the GSD lifecycle.
+Generate an AI design contract (AI-SPEC.md) for phases that involve building AI systems. Orchestrates pp-framework-selector → pp-ai-researcher → pp-domain-researcher → pp-eval-planner with a validation gate. Inserts between discuss-phase and plan-phase in the pp-core lifecycle.
 
 AI-SPEC.md locks four things before the planner creates tasks:
 1. Framework selection (with rationale and alternatives)
@@ -95,7 +95,7 @@ If "Update": continue to step 5.
 Display:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AI DESIGN CONTRACT — PHASE {N}: {name}
+ pp-core ► AI DESIGN CONTRACT — PHASE {N}: {name}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 ◆ Step 1/4 — Framework Selection...
@@ -266,7 +266,7 @@ git commit -m "docs({phase_slug}): generate AI-SPEC.md — {primary_framework} +
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AI-SPEC COMPLETE — PHASE {N}: {name}
+ pp-core ► AI-SPEC COMPLETE — PHASE {N}: {name}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 ◆ Framework: {primary_framework}

package/pp-core/workflows/audit-milestone.md

@@ -7,7 +7,7 @@ Read all files referenced by the invoking prompt's execution_context before star
 </required_reading>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-integration-checker — Checks cross-phase integration
 </available_agent_types>
 

package/pp-core/workflows/autonomous.md

@@ -101,7 +101,7 @@ Display startup banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS
+ pp-core ► AUTONOMOUS
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Milestone: {milestone_version} — {milestone_name}
@@ -158,7 +158,7 @@ Exit cleanly.
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ COMPLETE 🎉
+ pp-core ► AUTONOMOUS ▸ COMPLETE 🎉
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  All phases complete! Nothing left to do.
@@ -197,7 +197,7 @@ For the current phase, display the progress banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ Phase {N}/{T}: {Name} [████░░░░] {P}%
+ pp-core ► AUTONOMOUS ▸ Phase {N}/{T}: {Name} [████░░░░] {P}%
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -593,7 +593,7 @@ For each entry in `activeHooks` in array order where `kind == "step"` and `ref.s
 Skill(skill="gsd-${ref.skill}", args="${PHASE_NUM}")
 ```
 
-(i.e. prepend `gsd-` to `ref.skill` — so `ui-review` → `pp-ui-review`.)
+(i.e. prepend `pp-` to `ref.skill` — so `ui-review` → `pp-ui-review`.)
 
 Display the review result summary and score from UI-REVIEW.md if produced. Continue to iterate step regardless of result — hooks at this point are advisory, not blocking.
 
@@ -623,7 +623,7 @@ Read and execute: `$HOME/.claude/pp-core/references/autonomous-smart-discuss.md`
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ --to ${TO_PHASE} REACHED
+ pp-core ► AUTONOMOUS ▸ --to ${TO_PHASE} REACHED
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Completed through phase ${TO_PHASE} as requested.
@@ -675,7 +675,7 @@ If all phases complete, proceed to lifecycle step.
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ PHASE ${ONLY_PHASE} COMPLETE ✓
+ pp-core ► AUTONOMOUS ▸ PHASE ${ONLY_PHASE} COMPLETE ✓
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Phase ${ONLY_PHASE}: ${PHASE_NAME} — Done
@@ -693,7 +693,7 @@ Display lifecycle transition banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ LIFECYCLE
+ pp-core ► AUTONOMOUS ▸ LIFECYCLE
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  All phases complete → Starting lifecycle: audit → complete → cleanup
@@ -784,7 +784,7 @@ Display final completion banner:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ COMPLETE 🎉
+ pp-core ► AUTONOMOUS ▸ COMPLETE 🎉
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Milestone: {milestone_version} — {milestone_name}
@@ -817,7 +817,7 @@ When any phase operation fails or a blocker is detected, present 3 options via A
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTONOMOUS ▸ STOPPED
+ pp-core ► AUTONOMOUS ▸ STOPPED
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
  Completed: {list of completed phases}

package/pp-core/workflows/debug.md

@@ -6,7 +6,7 @@ Systematic debugging using the scientific method with subagent isolation.
 Orchestrates symptom gathering, session creation, and delegation to `pp-debug-session-manager`.
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-debug-session-manager — manages debug checkpoint/continuation loop in isolated context
 - pp-debugger — investigates bugs using scientific method
 </available_agent_types>

package/pp-core/workflows/diagnose-issues.md

@@ -7,7 +7,7 @@ Orchestrator stays lean: parse gaps, spawn agents, collect results, update UAT.
 </purpose>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-debugger — Diagnoses and fixes issues
 </available_agent_types>
 
@@ -194,7 +194,7 @@ pp_run query commit "docs({phase_num}): add root causes from diagnosis" --files
 Display:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► DIAGNOSIS COMPLETE
+ pp-core ► DIAGNOSIS COMPLETE
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 | Gap (Truth) | Root Cause | Files |

package/pp-core/workflows/discuss-phase/modes/chain.md

@@ -48,7 +48,7 @@ _PP_SHIM_NAME="pp-tools.cjs"; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(git rev-parse -
    Banner:
    ```
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-    GSD ► AUTO-ADVANCING TO PLAN
+    pp-core ► AUTO-ADVANCING TO PLAN
    ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
    Context captured. Launching plan-phase...
@@ -69,7 +69,7 @@ _PP_SHIM_NAME="pp-tools.cjs"; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(git rev-parse -
    - **PHASE COMPLETE** → Full chain succeeded. Display:
      ```
      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-      GSD ► PHASE ${PHASE} COMPLETE
+      pp-core ► PHASE ${PHASE} COMPLETE
      ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
      Auto-advance pipeline finished: discuss → plan → execute

package/pp-core/workflows/discuss-phase-assumptions.md

@@ -7,7 +7,7 @@ believe based on evidence, and ask the user only to correct what's wrong.
 </purpose>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-assumptions-analyzer — Analyzes codebase to surface implementation assumptions
 </available_agent_types>
 
@@ -642,7 +642,7 @@ pp_run query config-set workflow._auto_chain_active true
 Display banner:
 ```text
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► AUTO-ADVANCING TO PLAN
+ pp-core ► AUTO-ADVANCING TO PLAN
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Context captured (assumptions mode). Launching plan-phase...

package/pp-core/workflows/do.md

@@ -1,5 +1,5 @@
 <purpose>
-Analyze freeform text from the user and route to the most appropriate GSD command. This is a dispatcher — it never does the work itself. Match user intent to the best command, confirm the routing, and hand off.
+Analyze freeform text from the user and route to the most appropriate pp-core command. This is a dispatcher — it never does the work itself. Match user intent to the best command, confirm the routing, and hand off.
 </purpose>
 
 <required_reading>
@@ -16,7 +16,7 @@ Read all files referenced by the invoking prompt's execution_context before star
 If `$ARGUMENTS` is empty, ask via AskUserQuestion:
 
 ```
-What would you like to do? Describe the task, bug, or idea and I'll route it to the right GSD command.
+What would you like to do? Describe the task, bug, or idea and I'll route it to the right pp-core command.
 ```
 
 Wait for response before continuing.
@@ -79,7 +79,7 @@ Which approach fits better?
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► ROUTING
+ pp-core ► ROUTING
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 **Input:** {first 80 chars of $ARGUMENTS}
@@ -102,7 +102,7 @@ After invoking the command, stop. The dispatched command handles everything from
 
 <success_criteria>
 - [ ] Input validated (not empty)
-- [ ] Intent matched to exactly one GSD command
+- [ ] Intent matched to exactly one pp-core command
 - [ ] Ambiguity resolved via user question (if needed)
 - [ ] Project existence checked for routes that require it
 - [ ] Routing decision displayed before dispatch

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

@@ -3,7 +3,7 @@ Generate, update, and verify all project documentation — both canonical doc ty
 </purpose>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-doc-writer — Writes and updates project documentation files
 - pp-doc-verifier — Verifies factual claims in docs against the live codebase
 </available_agent_types>
@@ -346,12 +346,12 @@ Check for hand-written docs in the queue and gather user decisions before dispat
 Present the following choice using `AskUserQuestion` if available, or inline prompt otherwise:
 
 ```
-{filename} appears to be hand-written (no GSD marker found).
+{filename} appears to be hand-written (no pp-core marker found).
 
 How should this file be handled?
   [1] preserve    -- Skip entirely. Leave unchanged.
   [2] supplement  -- Append only missing sections. Existing content untouched.
-  [3] regenerate  -- Overwrite with a fresh GSD-generated doc.
+  [3] regenerate  -- Overwrite with a fresh pp-core-generated doc.
 ```
 
 Record each decision. Update the doc queue:
@@ -1154,10 +1154,10 @@ End workflow.
 - [ ] CHANGELOG.md was NOT generated or queued
 - [ ] Each doc was generated in correct mode (create for new, update for existing)
 - [ ] Wave 1 docs (README, ARCHITECTURE, CONFIGURATION) completed before Wave 2 started
-- [ ] Generated docs contain zero GSD methodology content
+- [ ] Generated docs contain zero pp-core methodology content
 - [ ] docs/DEPLOYMENT.md and docs/CONFIGURATION.md use VERIFY markers for undiscoverable claims (if generated)
 - [ ] All generated files committed (if commit_docs is true)
-- [ ] Hand-written docs (no GSD marker) prompted for preserve/supplement/regenerate before dispatch (unless --force)
+- [ ] Hand-written docs (no pp-core marker) prompted for preserve/supplement/regenerate before dispatch (unless --force)
 - [ ] --force flag skipped preservation prompts and regenerated all docs
 - [ ] --verify-only flag reported doc status without generating files
 - [ ] Per-package READMEs generated for monorepo workspaces (if applicable)

package/pp-core/workflows/eval-review.md

@@ -1,5 +1,5 @@
 <purpose>
-Retroactive audit of an implemented AI phase's evaluation coverage. Standalone command that works on any GSD-managed AI phase. Produces a scored EVAL-REVIEW.md with gap analysis and remediation plan.
+Retroactive audit of an implemented AI phase's evaluation coverage. Standalone command that works on any pp-core-managed AI phase. Produces a scored EVAL-REVIEW.md with gap analysis and remediation plan.
 
 Use after /pp:execute-phase to verify that the evaluation strategy from AI-SPEC.md was actually implemented. Mirrors the pattern of /pp:ui-review and /pp:validate-phase.
 </purpose>
@@ -28,7 +28,7 @@ AGENT_SKILLS_AUDITOR=$(pp_run query agent-skills pp-eval-auditor)
 Display banner:
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► EVAL AUDIT — PHASE {N}: {name}
+ pp-core ► EVAL AUDIT — PHASE {N}: {name}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ```
 
@@ -119,7 +119,7 @@ Read the written EVAL-REVIEW.md. Extract:
 
 ```
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- GSD ► EVAL AUDIT COMPLETE — PHASE {N}: {name}
+ pp-core ► EVAL AUDIT COMPLETE — PHASE {N}: {name}
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 ◆ Score: {overall_score}/100

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

@@ -41,7 +41,7 @@ Read STATE.md before any operation to load project context.
 </required_reading>
 
 <available_agent_types>
-These are the valid GSD subagent types registered in .claude/agents/ (or equivalent for your runtime).
+These are the valid pp-core subagent types registered in .claude/agents/ (or equivalent for your runtime).
 Always use the exact name from this list — do not fall back to 'general-purpose' or other built-in types:
 
 - pp-executor — Executes plan tasks, commits, creates SUMMARY.md
@@ -280,8 +280,8 @@ checkpoints between tasks. The user can review, modify, or redirect work at any
 **Benefits of interactive mode:**
 - No subagent overhead — dramatically lower token usage
 - User catches mistakes early — saves costly verification cycles
-- Maintains GSD's planning/tracking structure
-- Best for: small phases, bug fixes, verification gaps, learning GSD
+- Maintains pp-core's planning/tracking structure
+- Best for: small phases, bug fixes, verification gaps, learning pp-core
 
 **Skip to handle_branching step** (interactive plans execute inline after grouping).
 </step>
@@ -1212,7 +1212,7 @@ CHECK_EXIT=$?
 
 ```
 Phase blocked: {N} TDD plan(s) violate the RED→GREEN gate sequence under MVP+TDD.
-Resolve and re-run /gsd execute-phase, or override with /gsd execute-phase {phase} --force-mvp-gate to ship anyway.
+Resolve and re-run /pp:execute-phase, or override with /pp:execute-phase {phase} --force-mvp-gate to ship anyway.
 ```
 
 (`--force-mvp-gate` is the documented, not-yet-implemented escape hatch.) Outside MVP+TDD, TDD-review violations remain advisory (table shown, execution continues).
@@ -1693,7 +1693,7 @@ For 1M+ context models, consider:
 
 <failure_handling>
 - **Quota / rate-limit (any runtime — #3095):** Agent return body contains a sentinel like `usage limit`, `rate limit`, `429`, `too many requests`, `RESOURCE_EXHAUSTED`, `usage_limit_reached`. Route via `pp-tools.cjs query agent.classify-failure` → `class: "quota-exceeded"`. Do not offer retry-now; the right action is wait-for-reset and resume.
-- **classifyHandoffIfNeeded false failure:** Agent reports "failed" but error is `classifyHandoffIfNeeded is not defined` → Claude Code bug, not GSD. Spot-check (SUMMARY exists, commits present) → if pass, treat as success
+- **classifyHandoffIfNeeded false failure:** Agent reports "failed" but error is `classifyHandoffIfNeeded is not defined` → Claude Code bug, not pp-core. Spot-check (SUMMARY exists, commits present) → if pass, treat as success
 - **Agent fails mid-plan:** Missing SUMMARY.md → report, ask user how to proceed
 - **Dependency chain breaks:** Wave 1 fails → Wave 2 dependents likely fail → user chooses attempt or skip
 - **All agents in wave fail:** Systemic issue → stop, report for investigation

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

@@ -33,7 +33,7 @@ a capability (#1164), not core.
 </atomic_close_out_invariant>
 
 <available_agent_types>
-Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+Valid pp-core subagent types (use exact names — do not fall back to 'general-purpose'):
 - pp-executor — Executes plan tasks, commits, creates SUMMARY.md
 </available_agent_types>