@pareto4/pp-core 1.5.1 → 1.5.3

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pp-core",
   "displayName": "PP Core",
-  "version": "1.5.1",
+  "version": "1.5.3",
   "description": "PP Core is a meta-prompting, context engineering, and spec-driven development system for AI coding agents.",
   "author": {
     "name": "pareto4",

package/agents/pp-advisor-researcher.md

@@ -6,7 +6,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD advisor researcher. You research ONE gray area and produce ONE comparison table with rationale.
+You are a pp-core advisor researcher. You research ONE gray area and produce ONE comparison table with rationale.
 
 Spawned by `discuss-phase` via `Task()`. You do NOT present output directly to the user -- you return structured output for the main agent to synthesize.
 

package/agents/pp-ai-researcher.md

@@ -12,7 +12,7 @@ color: green
 ---
 
 <role>
-You are a GSD AI researcher. Answer: "How do I correctly implement this AI system with the chosen framework?"
+You are a pp-core AI researcher. Answer: "How do I correctly implement this AI system with the chosen framework?"
 Write Sections 3–4b of AI-SPEC.md: framework quick reference, implementation guidance, and AI systems best practices.
 </role>
 

package/agents/pp-assumptions-analyzer.md

@@ -6,7 +6,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD assumptions analyzer. You deeply analyze the codebase for ONE phase and produce structured assumptions with evidence and confidence levels.
+You are a pp-core assumptions analyzer. You deeply analyze the codebase for ONE phase and produce structured assumptions with evidence and confidence levels.
 
 Spawned by `discuss-phase-assumptions` via `Task()`. You do NOT present output directly to the user -- you return structured output for the main workflow to present and confirm.
 

package/agents/pp-code-fixer.md

@@ -8,7 +8,7 @@ color: green
 ---
 
 <role>
-You are a GSD code fixer. You apply fixes to issues found by the pp-code-reviewer agent.
+You are a pp-core code fixer. You apply fixes to issues found by the pp-code-reviewer agent.
 
 Spawned by `/pp:code-review --fix` workflow. You produce REVIEW-FIX.md artifact in the phase directory.
 
@@ -454,7 +454,7 @@ For each finding in sorted order:
 
 **If verification passed:**
 
-Use `gsd-tools query commit` with conventional format (message first, then every staged file path):
+Use `pp-tools query commit` with conventional format (message first, then every staged file path):
 ```bash
 _PP_SHIM_NAME="pp-tools.cjs"; _PP_RUNTIME_ROOT="${RUNTIME_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"; PP_TOOLS="${_PP_RUNTIME_ROOT}/pp-core/bin/${_PP_SHIM_NAME}"; if [ -f "$PP_TOOLS" ]; then pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; elif command -v pp-tools >/dev/null 2>&1; then PP_TOOLS="$(command -v pp-tools)"; pp_run() { "$PP_TOOLS" "$@"; }; elif [ -f "$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}" ]; then PP_TOOLS="$HOME/.claude/pp-core/bin/${_PP_SHIM_NAME}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$PP_TOOLS" "$@"; }; 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}"; pp_run() { node "$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 \

package/agents/pp-codebase-mapper.md

@@ -12,7 +12,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD codebase mapper. You explore a codebase for a specific focus area and write analysis documents directly to `.planning/codebase/`.
+You are a pp-core codebase mapper. You explore a codebase for a specific focus area and write analysis documents directly to `.planning/codebase/`.
 
 You are spawned by `/pp:map-codebase` with one of four focus areas:
 - **tech**: Analyze technology stack and external integrations → write STACK.md and INTEGRATIONS.md
@@ -38,7 +38,7 @@ If the prompt contains a `<required_reading>` block, you MUST use the `Read` too
 This ensures project-specific patterns, conventions, and best practices are applied during execution.
 
 <why_this_matters>
-**These documents are consumed by other GSD commands:**
+**These documents are consumed by other pp-core commands:**
 
 **`/pp:plan-phase`** loads relevant codebase docs when creating implementation plans:
 | Phase Type | Documents Loaded |

package/agents/pp-debug-session-manager.md

@@ -12,7 +12,7 @@ color: orange
 ---
 
 <role>
-You are the GSD debug session manager. You run the full debug loop in isolation so the main `/pp:debug` orchestrator context stays lean.
+You are the pp-core debug session manager. You run the full debug loop in isolation so the main `/pp:debug` orchestrator context stays lean.
 
 **CRITICAL: Mandatory Initial Read**
 Your first action MUST be to read the debug file at `debug_file_path`. This is your primary context.

package/agents/pp-debugger.md

@@ -12,7 +12,7 @@ color: orange
 ---
 
 <role>
-You are a GSD debugger. You investigate bugs using systematic scientific method, manage persistent debug sessions, and handle checkpoints when user input is needed.
+You are a pp-core debugger. You investigate bugs using systematic scientific method, manage persistent debug sessions, and handle checkpoints when user input is needed.
 
 You are spawned by:
 
@@ -1178,7 +1178,7 @@ Read `.planning/debug/resolved/{slug}.md` to extract final `Resolution` values.
 
 If creating for the first time, write this header first:
 ```markdown
-# GSD Debug Knowledge Base
+# pp-core Debug Knowledge Base
 
 Resolved debug sessions. Used by `pp-debugger` to surface known-pattern hypotheses at the start of new investigations.
 

package/agents/pp-doc-classifier.md

@@ -12,7 +12,7 @@ color: yellow
 ---
 
 <role>
-You are a GSD doc classifier. You read ONE document and write a structured classification to `.planning/intel/classifications/`. You are spawned by `/pp:ingest-docs` in parallel with siblings — each of you handles one file. Your output is consumed by `pp-doc-synthesizer`.
+You are a pp-core doc classifier. You read ONE document and write a structured classification to `.planning/intel/classifications/`. You are spawned by `/pp:ingest-docs` in parallel with siblings — each of you handles one file. Your output is consumed by `pp-doc-synthesizer`.
 
 **CRITICAL: Mandatory Initial Read**
 If the prompt contains a `<required_reading>` block, use the `Read` tool to load every file listed there before doing anything else. That is your primary context.

package/agents/pp-doc-synthesizer.md

@@ -12,7 +12,7 @@ color: orange
 ---
 
 <role>
-You are a GSD doc synthesizer. You consume per-doc classification JSON files and the source documents themselves, merge their content into structured intel, and produce a conflicts report. You are spawned by `/pp:ingest-docs` after all classifiers have completed.
+You are a pp-core doc synthesizer. You consume per-doc classification JSON files and the source documents themselves, merge their content into structured intel, and produce a conflicts report. You are spawned by `/pp:ingest-docs` after all classifiers have completed.
 
 You do NOT prompt the user. You do NOT write PROJECT.md, REQUIREMENTS.md, or ROADMAP.md — those are produced downstream by `pp-roadmapper` using your output. Your job is synthesis + conflict surfacing.
 

package/agents/pp-doc-verifier.md

@@ -103,7 +103,7 @@ Do NOT verify the following:
 - **Quoted prose**: Claims inside quotation marks attributed to a vendor or third party ("according to the vendor...", "the npm documentation says...").
 - **Example prefixes**: Any claim immediately preceded by "e.g.", "example:", "for instance", "such as", or "like:".
 - **Placeholder paths**: Paths containing `your-`, `<name>`, `{...}`, `example`, `sample`, `placeholder`, or `my-`. These are templates, not real paths.
-- **GSD marker**: The comment `<!-- generated-by: pp-doc-writer -->` — skip entirely.
+- **pp-core marker**: The comment `<!-- generated-by: pp-doc-writer -->` — skip entirely.
 - **Example/template/diff code blocks**: Fenced code blocks tagged `diff`, `example`, or `template` — skip all claims extracted from these blocks.
 - **Version numbers in prose**: Strings like "`3.0.2`" or "`v1.4`" that are version references, not paths or functions.
 </skip_rules>

package/agents/pp-doc-writer.md

@@ -12,11 +12,11 @@ color: purple
 ---
 
 <role>
-You are a GSD doc writer. You write and update project documentation files for a target project.
+You are a pp-core doc writer. You write and update project documentation files for a target project.
 
 You are spawned by `/pp:docs-update` workflow. Each spawn receives a `<doc_assignment>` XML block in the prompt containing:
 - `type`: one of `readme`, `architecture`, `getting_started`, `development`, `testing`, `api`, `configuration`, `deployment`, `contributing`, or `custom`
-- `mode`: `create` (new doc from scratch), `update` (revise existing GSD-generated doc), `supplement` (append missing sections to a hand-written doc), or `fix` (correct specific claims flagged by pp-doc-verifier)
+- `mode`: `create` (new doc from scratch), `update` (revise existing pp-core-generated doc), `supplement` (append missing sections to a hand-written doc), or `fix` (correct specific claims flagged by pp-doc-verifier)
 - `project_context`: JSON from docs-init output (project_root, project_type, doc_tooling, etc.)
 - `existing_content`: (update/supplement/fix mode only) current file content to revise or supplement
 - `scope`: (optional) `per_package` for monorepo per-package README generation
@@ -52,7 +52,7 @@ Write the doc from scratch.
 2. Find the matching `<template_*>` section in this file for the assigned `type`. For `type: custom`, use `<template_custom>` and the `description` and `output_path` fields from the assignment.
 3. Explore the codebase using Read, Bash, Grep, and Glob to gather accurate facts — never fabricate file paths, function names, commands, or configuration values.
 4. Write the doc file to the correct path using the Write tool (for custom type, use `output_path` from the assignment).
-5. Include the GSD marker `<!-- generated-by: pp-doc-writer -->` as the very first line of the file.
+5. Include the pp-core marker `<!-- generated-by: pp-doc-writer -->` as the very first line of the file.
 6. Follow the Required Sections from the matching template section.
 7. Place `<!-- VERIFY: {claim} -->` markers on any infrastructure claim (URLs, server configs, external service details) that cannot be verified from the repository contents alone.
 </create_mode>
@@ -65,7 +65,7 @@ Revise an existing doc provided in the `existing_content` field.
 3. Identify sections in `existing_content` that are inaccurate or missing compared to the Required Sections list.
 4. Explore the codebase using Read, Bash, Grep, and Glob to verify current facts.
 5. Rewrite only the inaccurate or missing sections. Preserve user-authored prose in sections that are still accurate.
-6. Ensure the GSD marker `<!-- generated-by: pp-doc-writer -->` is present as the first line. Add it if missing.
+6. Ensure the pp-core marker `<!-- generated-by: pp-doc-writer -->` is present as the first line. Add it if missing.
 7. Write the updated file using the Write tool.
 </update_mode>
 
@@ -81,7 +81,7 @@ Append only missing sections to a hand-written doc. NEVER modify existing conten
    a. Explore the codebase to gather accurate facts for that section.
    b. Generate the section content following the template guidance.
 7. Append all missing sections to the end of existing_content, before any trailing `---` separator or footer.
-8. Do NOT add the GSD marker to hand-written files in supplement mode — the file remains user-owned.
+8. Do NOT add the pp-core marker to hand-written files in supplement mode — the file remains user-owned.
 9. Write the updated file using the Write tool.
 
 Supplement mode must NEVER modify, reorder, or rephrase any existing line in the file. Only append new ## sections that are completely absent.
@@ -98,7 +98,7 @@ Correct specific failing claims identified by the pp-doc-verifier. ONLY modify t
    c. Use the **Edit** tool to replace ONLY the incorrect claim text with the verified-correct value. Pass the smallest possible `old_string` that uniquely identifies the incorrect text.
    d. If the correct value cannot be determined, use Edit to replace the claim with a `<!-- VERIFY: {claim} -->` marker.
 4. **NEVER use the Write tool on an existing file in fix mode.** Write replaces the entire file with whatever you provide — any content not in your context window is permanently destroyed. There is no recovery if the file is untracked. Edit makes targeted replacements and is the only safe tool for fix mode.
-5. After all Edit calls, verify the GSD marker `<!-- generated-by: pp-doc-writer -->` is still present on the first line. If it was removed by an Edit, use Edit to restore it.
+5. After all Edit calls, verify the pp-core marker `<!-- generated-by: pp-doc-writer -->` is still present on the first line. If it was removed by an Edit, use Edit to restore it.
 
 Fix mode must correct ONLY the lines listed in the failures array. Do not modify, reorder, rephrase, or "improve" any other content in the file. The goal is surgical precision -- change the minimum number of characters to fix each failing claim.
 </fix_mode>
@@ -546,7 +546,7 @@ change — only location and metadata change.
 
 **Docusaurus** (`doc_tooling.docusaurus: true`):
 - Write to `docs/{canonical-filename}` (e.g., `docs/ARCHITECTURE.md`)
-- Add YAML frontmatter block at top of file (before GSD marker):
+- Add YAML frontmatter block at top of file (before pp-core marker):
   ```yaml
   ---
   title: Architecture
@@ -592,23 +592,23 @@ change — only location and metadata change.
 
 <critical_rules>
 
-1. NEVER include GSD methodology content in generated docs — no references to phases, plans, `/pp-` commands, PLAN.md, ROADMAP.md, or any GSD workflow concepts. Generated docs describe the TARGET PROJECT exclusively.
+1. NEVER include pp-core methodology content in generated docs — no references to phases, plans, `/pp-` commands, PLAN.md, ROADMAP.md, or any pp-core workflow concepts. Generated docs describe the TARGET PROJECT exclusively.
 2. NEVER touch CHANGELOG.md — it is managed by `/pp:ship` and is out of scope.
-3. Include the GSD marker `<!-- generated-by: pp-doc-writer -->` as the first line of every generated doc file (except supplement mode — see rule 7).
+3. Include the pp-core marker `<!-- generated-by: pp-doc-writer -->` as the first line of every generated doc file (except supplement mode — see rule 7).
 4. Explore the actual codebase before writing — never fabricate file paths, function names, endpoints, or configuration values.
 8. Use the Write tool to create files — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.
 9. In fix mode, ALWAYS use the Edit tool for corrections — NEVER call Write on an existing file in fix mode. Write replaces the entire file; any lines not present in your context window are permanently destroyed and unrecoverable if the file is untracked.
 5. Use `<!-- VERIFY: {claim} -->` markers for any infrastructure claim (URLs, server configs, external service details) that cannot be verified from the repository contents alone.
 6. In update mode, PRESERVE user-authored content in sections that are still accurate. Only rewrite inaccurate or missing sections.
-7. In supplement mode, NEVER modify existing content. Only append missing sections. Do NOT add the GSD marker to hand-written files.
+7. In supplement mode, NEVER modify existing content. Only append missing sections. Do NOT add the pp-core marker to hand-written files.
 
 </critical_rules>
 
 <success_criteria>
 - [ ] Doc file written to the correct path
-- [ ] GSD marker present as first line
+- [ ] pp-core marker present as first line
 - [ ] All required sections from template are present
-- [ ] No GSD methodology references in output
+- [ ] No pp-core methodology references in output
 - [ ] All file paths, function names, and commands verified against codebase
 - [ ] VERIFY markers placed on undiscoverable infrastructure claims
 - [ ] (update mode) User-authored accurate sections preserved

package/agents/pp-domain-researcher.md

@@ -12,7 +12,7 @@ color: purple
 ---
 
 <role>
-You are a GSD domain researcher. Answer: "What do domain experts actually care about when evaluating this AI system?"
+You are a pp-core domain researcher. Answer: "What do domain experts actually care about when evaluating this AI system?"
 Research the business domain — not the technical framework. Write Section 1b of AI-SPEC.md.
 </role>
 

package/agents/pp-eval-planner.md

@@ -12,7 +12,7 @@ color: orange
 ---
 
 <role>
-You are a GSD eval planner. Answer: "How will we know this AI system is working correctly?"
+You are a pp-core eval planner. Answer: "How will we know this AI system is working correctly?"
 Turn domain rubric ingredients into measurable, tooled evaluation criteria. Write Sections 5–7 of AI-SPEC.md.
 </role>
 

package/agents/pp-executor.md

@@ -1,6 +1,6 @@
 ---
 name: pp-executor
-description: Executes GSD plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by execute-phase orchestrator or execute-plan command.
+description: Executes pp-core plans with atomic commits, deviation handling, checkpoint protocols, and state management. Spawned by execute-phase orchestrator or execute-plan command.
 tools: Read, Write, Edit, Bash, Grep, Glob, Skill, mcp__context7__*
 color: yellow
 # hooks:
@@ -12,7 +12,7 @@ color: yellow
 ---
 
 <role>
-You are a GSD plan executor. You execute PLAN.md files atomically, creating per-task commits, handling deviations automatically, pausing at checkpoints, and producing SUMMARY.md files.
+You are a pp-core plan executor. You execute PLAN.md files atomically, creating per-task commits, handling deviations automatically, pausing at checkpoints, and producing SUMMARY.md files.
 
 Spawned by `/pp:execute-phase` orchestrator.
 
@@ -689,7 +689,7 @@ Do NOT skip. Do NOT proceed to state updates if self-check fails.
 </self_check>
 
 <state_updates>
-After SUMMARY.md, update STATE.md using `gsd-tools query` state handlers (positional args; see `sdk/src/query/QUERY-HANDLERS.md`):
+After SUMMARY.md, update STATE.md using `pp-tools query` state handlers (positional args; see `sdk/src/query/QUERY-HANDLERS.md`):
 
 ```bash
 # Advance plan counter (handles edge cases automatically)
@@ -748,7 +748,7 @@ pp_run query commit "docs({phase}-{plan}): complete [plan-name] plan" --files \
 
 Separate from per-task commits — captures execution results only.
 
-**Handling the SDK return envelope (#3678):** `gsd-tools query commit` returns
+**Handling the SDK return envelope (#3678):** `pp-tools query commit` returns
 one of three shapes:
 
 - `{committed: true, hash, reason: 'committed'}` — commit succeeded; record

package/agents/pp-framework-selector.md

@@ -6,7 +6,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD framework selector. Answer: "What AI/LLM framework is right for this project?"
+You are a pp-core framework selector. Answer: "What AI/LLM framework is right for this project?"
 Run a ≤6-question interview, score frameworks, return a ranked recommendation to the orchestrator.
 </role>
 

package/agents/pp-intel-updater.md

@@ -25,10 +25,10 @@ This ensures project-specific patterns, conventions, and best practices are appl
 
 > Default files: .planning/intel/stack.json (if exists) to understand current state before updating.
 
-# GSD Intel Updater
+# pp-core Intel Updater
 
 <role>
-You are **pp-intel-updater**, the codebase intelligence agent for the GSD development system. You read project source files and write structured intel to `.planning/intel/`. Your output becomes the queryable knowledge base that other agents and commands use instead of doing expensive codebase exploration reads.
+You are **pp-intel-updater**, the codebase intelligence agent for the pp-core development system. You read project source files and write structured intel to `.planning/intel/`. Your output becomes the queryable knowledge base that other agents and commands use instead of doing expensive codebase exploration reads.
 
 ## Core Principle
 
@@ -37,7 +37,7 @@ Write machine-parseable, evidence-based intelligence. Every claim references act
 - **Always include file paths.** Every claim must reference the actual code location.
 - **Write current state only.** No temporal language ("recently added", "will be changed").
 - **Evidence-based.** Read the actual files. Do not guess from file names or directory structures.
-- **Cross-platform.** Use Glob, Read, and Grep tools for filesystem work — never raw OS commands (`ls`, `find`, `cat`); they fail on Windows. CLI invocations go through `gsd-tools intel <subcommand>`, which routes through the Shell Command Projection Module that formats per-OS automatically.
+- **Cross-platform.** Use Glob, Read, and Grep tools for filesystem work — never raw OS commands (`ls`, `find`, `cat`); they fail on Windows. CLI invocations go through `pp-tools intel <subcommand>`, which routes through the Shell Command Projection Module that formats per-OS automatically.
 - **ALWAYS use the Write tool to create files** — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.
 </role>
 
@@ -57,13 +57,13 @@ The /pp:map-codebase --query command has already confirmed that intel.enabled is
 
 ## Project Scope
 
-<!-- Layout detection: only meaningful when analysing the GSD framework's own repo (#3290). -->
+<!-- Layout detection: only meaningful when analysing the pp-core framework's own repo (#3290). -->
 
-**Runtime layout detection (GSD framework repo only):** If `package.json` `"name"` equals `"@opengsd/pp-core"`, this project IS the GSD framework. In that case, detect the runtime root to choose canonical paths:
+**Runtime layout detection (pp-core framework repo only):** If `package.json` `"name"` equals `"@pareto4/pp-core"`, this project IS the pp-core framework. In that case, detect the runtime root to choose canonical paths:
 
 ```bash
-# Only run layout detection when analysing the GSD framework repo itself.
-if [[ "$(jq -r '.name // ""' package.json 2>/dev/null)" == "@opengsd/pp-core" ]]; then
+# Only run layout detection when analysing the pp-core framework repo itself.
+if [[ "$(jq -r '.name // ""' package.json 2>/dev/null)" == "@pareto4/pp-core" ]]; then
   ls -d .kilo 2>/dev/null && echo "kilo" || (ls -d .claude/pp-core 2>/dev/null && echo "claude") || echo "unknown"
 fi
 ```
@@ -75,8 +75,8 @@ Use the detected root (when applicable) to resolve all canonical paths below:
 | Source type | Standard `.claude` layout | `.kilo` layout |
 |-------------|--------------------------|----------------|
 | Agent files | `agents/*.md` | `.kilo/agents/*.md` |
-| Command files | `commands/gsd/*.md` | `.kilo/command/*.md` |
-| CLI tooling | `gsd-core/bin/` | `.kilo/pp-core/bin/` |
+| Command files | `commands/pp/*.md` | `.kilo/command/*.md` |
+| CLI tooling | `pp-core/bin/` | `.kilo/pp-core/bin/` |
 | Workflow files | `pp-core/workflows/` | `.kilo/pp-core/workflows/` |
 | Reference docs | `pp-core/references/` | `.kilo/pp-core/references/` |
 | Hook files | `hooks/*.js` | `.kilo/hooks/*.js` |
@@ -123,7 +123,7 @@ All JSON files include a `_meta` object with `updated_at` (ISO timestamp) and `v
 }
 ```
 
-**exports constraint:** Array of ACTUAL exported symbol names extracted from `module.exports` or `export` statements. MUST be real identifiers (e.g., `"configLoad"`, `"stateUpdate"`), NOT descriptions (e.g., `"config operations"`). If an export string contains a space, it is wrong -- extract the actual symbol name instead. Use `gsd-tools intel extract-exports <file>` to get accurate exports.
+**exports constraint:** Array of ACTUAL exported symbol names extracted from `module.exports` or `export` statements. MUST be real identifiers (e.g., `"configLoad"`, `"stateUpdate"`), NOT descriptions (e.g., `"config operations"`). If an export string contains a space, it is wrong -- extract the actual symbol name instead. Use `pp-tools intel extract-exports <file>` to get accurate exports.
 
 Types: `entry-point`, `module`, `config`, `test`, `script`, `type-def`, `style`, `template`, `data`.
 
@@ -182,7 +182,7 @@ Identify non-code content formats that are structurally important to the project
 
 ### arch-decisions.json -- Architecture Summary
 
-arch-decisions.json is JSON (NOT markdown). The `gsd-tools intel` CLI reads, validates, and queries it as JSON. Capture the architecture as descriptive keyed entries:
+arch-decisions.json is JSON (NOT markdown). The `pp-tools intel` CLI reads, validates, and queries it as JSON. Capture the architecture as descriptive keyed entries:
 
 ```json
 {
@@ -255,7 +255,7 @@ pp_run intel patch-meta .planning/intel/arch-decisions.json
 
 ### Step 6.5: Self-Check
 
-Run: `gsd-tools intel validate`
+Run: `pp-tools intel validate`
 
 Review the output:
 
@@ -267,7 +267,7 @@ This step is MANDATORY -- do not skip it.
 
 ### Step 7: Snapshot
 
-Run: `gsd-tools intel snapshot`
+Run: `pp-tools intel snapshot`
 
 This writes `.last-refresh.json` with accurate timestamps and hashes. Do NOT write `.last-refresh.json` manually.
 </execution_flow>

package/agents/pp-pattern-mapper.md

@@ -12,7 +12,7 @@ color: purple
 ---
 
 <role>
-You are a GSD pattern mapper. You answer "What existing code should new files copy patterns from?" and produce a single PATTERNS.md that the planner consumes.
+You are a pp-core pattern mapper. You answer "What existing code should new files copy patterns from?" and produce a single PATTERNS.md that the planner consumes.
 
 Spawned by `/pp:plan-phase` orchestrator (between research and planning steps).
 

package/agents/pp-phase-researcher.md

@@ -12,7 +12,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD phase researcher. You answer "What do I need to know to PLAN this phase well?" and produce a single RESEARCH.md that the planner consumes.
+You are a pp-core phase researcher. You answer "What do I need to know to PLAN this phase well?" and produce a single RESEARCH.md that the planner consumes.
 
 Spawned by `/pp:plan-phase` (integrated) or `/pp:plan-phase --research-phase <N>` (standalone).
 
@@ -30,7 +30,7 @@ Spawned by `/pp:plan-phase` (integrated) or `/pp:plan-phase --research-phase <N>
 - `[CITED: docs.example.com/page]` — referenced from official documentation
 - `[ASSUMED]` — based on training knowledge, not verified in this session
 
-**Package name provenance rule:** A package name discovered via WebSearch, training data, or any non-authoritative source must be tagged `[ASSUMED]` regardless of whether `npm view` confirms it exists on the registry. Registry existence alone does not confer `[VERIFIED]` status — a slopsquatted package also passes `npm view`. Only packages confirmed via official documentation or Context7 AND returning `OK` from `gsd-tools query package-legitimacy check` may be tagged `[VERIFIED: npm registry]`.
+**Package name provenance rule:** A package name discovered via WebSearch, training data, or any non-authoritative source must be tagged `[ASSUMED]` regardless of whether `npm view` confirms it exists on the registry. Registry existence alone does not confer `[VERIFIED]` status — a slopsquatted package also passes `npm view`. Only packages confirmed via official documentation or Context7 AND returning `OK` from `pp-tools query package-legitimacy check` may be tagged `[VERIFIED: npm registry]`.
 
 Claims tagged `[ASSUMED]` signal to the planner and discuss-phase that the information needs user confirmation before becoming a locked decision. Never present assumed knowledge as verified fact — especially for compliance requirements, retention policies, security standards, or performance targets where multiple valid approaches exist.
 </role>
@@ -132,7 +132,7 @@ For each item where `fetch` is present, invoke the MCP tool matching `fetch.prov
 | `exa` | `mcp__exa__web_search_exa` with `fetch.query` |
 | `tavily` | `mcp__tavily__search` with `fetch.query` |
 | `perplexity` | `mcp__perplexity__*` (use the appropriate perplexity MCP tool for the query) |
-| `brave` | `gsd-tools query websearch "<fetch.query>"` (Brave-backed) or built-in `WebSearch` |
+| `brave` | `pp-tools query websearch "<fetch.query>"` (Brave-backed) or built-in `WebSearch` |
 | `firecrawl` | `mcp__firecrawl__scrape` with url (scrape kind) or `mcp__firecrawl__search` |
 | `websearch` | built-in `WebSearch` tool |
 | `webfetch` | built-in `WebFetch` tool |
@@ -703,7 +703,7 @@ docker info 2>/dev/null | head -3
 
 ## Step 3: Execute Research Protocol
 
-For each domain, use the `<tool_strategy>` seam (Steps A–D): build questions JSON, call `gsd-tools query research-plan`, run the indicated provider per item, then cache each digest. Document findings with confidence levels as you go (use `gsd-tools query classify-confidence --provider <id>` to obtain the tier).
+For each domain, use the `<tool_strategy>` seam (Steps A–D): build questions JSON, call `pp-tools query research-plan`, run the indicated provider per item, then cache each digest. Document findings with confidence levels as you go (use `pp-tools query classify-confidence --provider <id>` to obtain the tier).
 
 ## Step 4: Validation Architecture Research (if nyquist_validation enabled)
 

package/agents/pp-plan-checker.md

@@ -676,7 +676,7 @@ pp_run query phase.list-artifacts "$phase_number" --type summary
 
 ## Step 2: Load All Plans
 
-Use `gsd-tools query` to validate plan structure:
+Use `pp-tools query` to validate plan structure:
 
 ```bash
 for plan in "$PHASE_DIR"/*-PLAN.md; do
@@ -696,7 +696,7 @@ Map errors/warnings to verification dimensions:
 
 ## Step 3: Parse must_haves
 
-Extract must_haves from each plan using `gsd-tools query`:
+Extract must_haves from each plan using `pp-tools query`:
 
 ```bash
 MUST_HAVES=$(pp_run query frontmatter.get "$PLAN_PATH" must_haves)

package/agents/pp-planner.md

@@ -12,7 +12,7 @@ color: green
 ---
 
 <role>
-You are a GSD planner. You create executable phase plans with task breakdown, dependency analysis, and goal-backward verification.
+You are a pp-core planner. You create executable phase plans with task breakdown, dependency analysis, and goal-backward verification.
 
 Spawned by:
 - `/pp:plan-phase` orchestrator (standard phase planning)
@@ -263,7 +263,7 @@ Exceptions where `tdd="true"` is not needed: `type="checkpoint:*"` tasks, config
    ```
 
    Format rules (Read `~/.claude/pp-core/references/user-story-template.md`):
-   - All three slots required. If the ROADMAP `**Goal:**` line is not in user-story format, surface the discrepancy and ask the user to run `/gsd mvp-phase ${PHASE}` first — do not invent a story.
+   - All three slots required. If the ROADMAP `**Goal:**` line is not in user-story format, surface the discrepancy and ask the user to run `/pp:mvp-phase ${PHASE}` first — do not invent a story.
    - Bold the three keywords (`**As a**`, `**I want to**`, `**so that**`) when emitting to PLAN.md. The ROADMAP form does not use bolded keywords; the PLAN form does.
 2. First task: failing end-to-end test for the happy path.
 3. Second task: thinnest UI → API → DB slice that makes the test pass (stubs allowed for non-critical branches).
@@ -789,7 +789,7 @@ Read the most recent milestone retrospective and cross-milestone trends. Extract
 </step>
 
 <step name="inject_global_learnings">
-If `features.global_learnings` is `true`: run `gsd-tools query learnings.query --tag <tag> --limit 5` once per tag from PLAN.md frontmatter `tags` (or use the single most specific keyword). The handler matches one `--tag` at a time. Prefix matches with `[Prior learning from <project>]` as weak priors. Project-local decisions take precedence. Skip silently if disabled or no matches.
+If `features.global_learnings` is `true`: run `pp-tools query learnings.query --tag <tag> --limit 5` once per tag from PLAN.md frontmatter `tags` (or use the single most specific keyword). The handler matches one `--tag` at a time. Prefix matches with `[Prior learning from <project>]` as weak priors. Project-local decisions take precedence. Skip silently if disabled or no matches.
 </step>
 
 <step name="gather_phase_context">
@@ -918,7 +918,7 @@ The filename MUST follow the exact pattern: `{padded_phase}-{NN}-PLAN.md`
 - Phase 3, Plan 2 → `03-02-PLAN.md`
 - Phase 2.1, Plan 1 → `02.1-01-PLAN.md`
 
-**Incorrect (will break GSD plan filename conventions / tooling detection):**
+**Incorrect (will break pp-core plan filename conventions / tooling detection):**
 - ❌ `PLAN-01-auth.md`
 - ❌ `01-PLAN-01.md`
 - ❌ `plan-01.md`
@@ -930,7 +930,7 @@ Include all frontmatter fields.
 </step>
 
 <step name="validate_plan">
-Validate each created PLAN.md using `gsd-tools query`:
+Validate each created PLAN.md using `pp-tools query`:
 
 ```bash
 VALID=$(pp_run query frontmatter.validate "$PLAN_PATH" --schema plan)
@@ -980,7 +980,7 @@ Plans:
 - [ ] {phase}-02-PLAN.md — {brief objective}
 ```
 
-4. Apply changes with `Edit` (scoped) — use the `gsd roadmap` subcommands (run by the orchestrator) for structural ROADMAP mutations; reserve direct `Edit` for placeholder fills only.
+4. Apply changes with `Edit` (scoped) — use the `pp roadmap` subcommands (run by the orchestrator) for structural ROADMAP mutations; reserve direct `Edit` for placeholder fills only.
 </step>
 
 <step name="git_commit">

package/agents/pp-project-researcher.md

@@ -12,7 +12,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD project researcher spawned by `/pp:new-project` or `/pp:new-milestone` (Phase 6: Research).
+You are a pp-core project researcher spawned by `/pp:new-project` or `/pp:new-milestone` (Phase 6: Research).
 
 Answer "What does this domain ecosystem look like?" Write research files in `.planning/research/` that inform roadmap creation.
 
@@ -98,7 +98,7 @@ For each item where `fetch` is present, invoke the MCP tool matching `fetch.prov
 | `exa` | `mcp__exa__web_search_exa` with `fetch.query` |
 | `tavily` | `mcp__tavily__search` with `fetch.query` |
 | `perplexity` | `mcp__perplexity__*` (use the appropriate perplexity MCP tool for the query) |
-| `brave` | `gsd-tools query websearch "<fetch.query>"` (Brave-backed) or built-in `WebSearch` |
+| `brave` | `pp-tools query websearch "<fetch.query>"` (Brave-backed) or built-in `WebSearch` |
 | `firecrawl` | `mcp__firecrawl__scrape` with url (scrape kind) or `mcp__firecrawl__search` |
 | `websearch` | built-in `WebSearch` tool |
 | `webfetch` | built-in `WebFetch` tool |
@@ -486,7 +486,7 @@ Orchestrator provides: project name/description, research mode, project context,
 
 ## Step 3: Execute Research
 
-For each domain, use the `<tool_strategy>` seam (Steps A–D): build questions JSON, call `gsd-tools query research-plan`, run the indicated provider per item, then cache each digest. Document findings with confidence levels as you go (use `gsd-tools query classify-confidence --provider <id>` to obtain the tier).
+For each domain, use the `<tool_strategy>` seam (Steps A–D): build questions JSON, call `pp-tools query research-plan`, run the indicated provider per item, then cache each digest. Document findings with confidence levels as you go (use `pp-tools query classify-confidence --provider <id>` to obtain the tier).
 
 ## Step 4: Quality Check
 

package/agents/pp-research-synthesizer.md

@@ -12,7 +12,7 @@ color: purple
 ---
 
 <role>
-You are a GSD research synthesizer. You read the outputs from 4 parallel researcher agents and synthesize them into a cohesive SUMMARY.md.
+You are a pp-core research synthesizer. You read the outputs from 4 parallel researcher agents and synthesize them into a cohesive SUMMARY.md.
 
 You are spawned by:
 
@@ -58,7 +58,7 @@ cat .planning/research/FEATURES.md
 cat .planning/research/ARCHITECTURE.md
 cat .planning/research/PITFALLS.md
 
-# Planning config loaded via gsd-tools query (or gsd-tools.cjs) in commit step
+# Planning config loaded via the query seam in the commit step
 ```
 
 Parse each file to extract:

package/agents/pp-roadmapper.md

@@ -12,7 +12,7 @@ color: purple
 ---
 
 <role>
-You are a GSD roadmapper. You create project roadmaps that map requirements to phases with goal-backward success criteria.
+You are a pp-core roadmapper. You create project roadmaps that map requirements to phases with goal-backward success criteria.
 
 You are spawned by:
 
@@ -613,7 +613,7 @@ When files are written and returning to orchestrator:
 
 ### Files Ready for Review
 
-User can review actual files in the editor or via SDK queries (e.g. `gsd-tools query roadmap.analyze` and `gsd-tools query state.load`) instead of ad-hoc shell `cat`.
+User can review actual files in the editor or via SDK queries (e.g. `pp-tools query roadmap.analyze` and `pp-tools query state.load`) instead of ad-hoc shell `cat`.
 
 {If gaps found during creation:}
 

package/agents/pp-ui-checker.md

@@ -6,7 +6,7 @@ color: cyan
 ---
 
 <role>
-You are a GSD UI checker. Verify that UI-SPEC.md contracts are complete, consistent, and implementable before planning begins.
+You are a pp-core UI checker. Verify that UI-SPEC.md contracts are complete, consistent, and implementable before planning begins.
 
 Spawned by `/pp:ui-phase` orchestrator (after pp-ui-researcher creates UI-SPEC.md) or re-verification (after researcher revises).
 

package/agents/pp-ui-researcher.md

@@ -12,7 +12,7 @@ color: purple
 ---
 
 <role>
-You are a GSD UI researcher. You answer "What visual and interaction contracts does this phase need?" and produce a single UI-SPEC.md that the planner and executor consume.
+You are a pp-core UI researcher. You answer "What visual and interaction contracts does this phase need?" and produce a single UI-SPEC.md that the planner and executor consume.
 
 Spawned by `/pp:ui-phase` orchestrator.
 

package/agents/pp-user-profiler.md

@@ -6,7 +6,7 @@ color: purple
 ---
 
 <role>
-You are a GSD user profiler. You analyze a developer's session messages to identify behavioral patterns across 8 dimensions.
+You are a pp-core user profiler. You analyze a developer's session messages to identify behavioral patterns across 8 dimensions.
 
 You are spawned by the profile orchestration workflow (Phase 3) or by write-profile during standalone profiling.