godpowers 2.2.1 → 2.3.1

package/CHANGELOG.md

@@ -7,6 +7,64 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.3.1] - 2026-06-08
+
+### Added
+- Added `/god-extension-scaffold` as the slash-command entry point for
+  extension pack authoring, with routing metadata, installer profile coverage,
+  package payload checks, and front-door recipe coverage.
+- Added code-intelligence host capability detection for optional `ast-grep`,
+  `sg`, and LSP tooling without downgrading baseline host guarantees when those
+  tools are absent.
+- Added public starter-path regression checks that verify README and Quick
+  Proof goal labels resolve through shipped `/god` recipes and routes.
+
+### Changed
+- Updated public surface counts to 112 slash commands and 42 intent recipes
+  across release notes, reference docs, architecture maps, package metadata,
+  and project Pillars.
+- Tightened public front-door recipe matching for starter phrases including
+  "start a product", "add a feature", "fix production", "maintain health",
+  "audit an existing repo", "ship a release", and extension authoring.
+- Aligned the brownfield onboarding recipe to audit reconstructed artifacts
+  before tech-debt prioritization.
+
+### Fixed
+- Prevented maintainer-repository documentation drift from leaking into normal
+  user project dashboards.
+- Corrected Quick Proof output so fixture-backed checks render
+  `--project=.` for the user project path.
+- Hardened extension install, planning-system detection, and agent-cache cleanup
+  around symlinked directories that point outside the trusted source tree.
+- Removed phantom `god-*` examples from the extension scaffold skill prose so
+  agent-reference validation stays clean.
+
+## [2.3.0] - 2026-05-30
+
+### Added
+- Added source-grounded planning helpers so build plans can name existing files,
+  existing symbols, planned new artifacts, and unchecked references before
+  execution begins.
+- Added package legitimacy checks for package-backed stack and dependency
+  replacement decisions, covering npm existence, typo risk, staleness, and
+  repository metadata.
+- Added role-based installer profiles (`core`, `builder`, `maintainer`,
+  `suite`, and `full`) plus `--minimal` as a compact alias for the core
+  surface.
+- Added atomic file-write helpers and wired them into state, checkpoint,
+  requirements, linkage, source-sync, reverse-sync, and async filesystem
+  persistence paths.
+- Added executor repair classification for retry, decomposition, pruning, and
+  escalation so failed implementation attempts leave clearer next actions.
+
+### Changed
+- Debranded legacy planning-system wording across public docs, runtime
+  detection, fixtures, tests, and sync-back surfaces to keep Godpowers distinct
+  from external workflow products.
+- Build, executor, planner, spec-reviewer, stack-selector, and dependency
+  auditor contracts now require source grounding or package legitimacy evidence
+  where those checks apply.
+
 ## [2.2.1] - 2026-05-30
 
 ### Fixed
@@ -323,7 +381,7 @@ Dogfooding, host guarantees, extension authoring, and suite release dry-runs.
 ### Added
 - Added `lib/dogfood-runner.js`, `/god-dogfood`, and `npx godpowers dogfood`
   for deterministic messy-repo dogfood scenarios.
-- Added `fixtures/dogfood/` scenarios for half-migrated GSD import,
+- Added `fixtures/dogfood/` scenarios for half-migrated legacy planning import,
   degraded and full host guarantees, extension scaffolding, and Mode D suite
   release dry-run planning.
 - Added `lib/host-capabilities.js` and dashboard host guarantee reporting for
@@ -499,7 +557,7 @@ Feature awareness for existing Godpowers projects.
 Planning-system migration and sync-back.
 
 ### Added
-- Added `lib/planning-systems.js` to detect GSD, BMAD, and Superpowers
+- Added `lib/planning-systems.js` to detect legacy planning, BMAD, and Superpowers
   planning context and convert useful signals into Godpowers prep and seed
   artifacts.
 - Added `lib/source-sync.js` to write current Godpowers progress back into
@@ -509,11 +567,11 @@ Planning-system migration and sync-back.
   ambiguous.
 - Added `docs/planning-system-migration.md` with detection signals, import
   mapping, sync-back destinations, conflict rules, and return-path guidance.
-- Added behavioral tests for GSD, BMAD, Superpowers, imported seed artifacts,
+- Added behavioral tests for legacy planning, BMAD, Superpowers, imported seed artifacts,
   state recording, and idempotent sync-back.
 
 ### Changed
-- `/god-init` now auto-invokes planning-system import when GSD, BMAD, or
+- `/god-init` now auto-invokes planning-system import when legacy planning, BMAD, or
   Superpowers evidence is detected.
 - `/god-sync` now auto-invokes source-system sync-back when `state.json`
   records enabled source systems.
@@ -708,7 +766,7 @@ of leaving the user to infer the next action.
   `/god-roadmap-check`.
 
 ### Changed
-- Proposal-style outputs now mirror the clearer GSD pattern: implement a small
+- Proposal-style outputs now mirror the clearer legacy planning pattern: implement a small
   slice, implement the full route, discuss more, inspect status, or run
   `/god-mode` only when that is safe.
 - `/god-next` and `/god-status` now explicitly distinguish partial progress,
@@ -1234,7 +1292,7 @@ routing, or the full autonomous arc starts.
 ### Documented
 - The full recent init preparation flow is now documented together:
   automatic AI-tool context for explicit `god init`, quiet context writes,
-  GSD / Superpowers / BMAD import into `IMPORTED-CONTEXT.md`, and direct
+  legacy planning / Superpowers / BMAD import into `IMPORTED-CONTEXT.md`, and direct
   Godpowers repo findings in `INITIAL-FINDINGS.md`.
 
 ## [0.15.7] - 2026-05-11
@@ -1243,7 +1301,7 @@ Planning import release. Lets `/god-init` preserve useful context from nearby
 planning systems without making those systems authoritative.
 
 ### Added
-- `/god-init` now detects GSD, Superpowers, BMAD, and similar planning context
+- `/god-init` now detects legacy planning, Superpowers, BMAD, and similar planning context
   during project preparation.
 - Added `.godpowers/prep/IMPORTED-CONTEXT.md` as a non-authoritative
   preparation artifact for imported product, delivery, architecture, and stack

package/INSPIRATION.md

@@ -7,7 +7,9 @@
 Godpowers was shaped by ideas from several existing AI coding workflow
 systems. The four direct ancestors were:
 
-- **GSD** by Hanns Princivil ([github.com/aihxp/gsd](https://github.com/aihxp/gsd)) - pure-skill model, slash commands inside AI tools, TDD enforcement, critical-finding gate with autonomous-mode carve-out
+- **Prior internal planning-system experiments** - pure-skill model, slash
+  commands inside AI tools, TDD enforcement, critical-finding gate with
+  autonomous-mode carve-out
 - **Superpowers** by Anthropic ([github.com/anthropics/skills](https://github.com/anthropics/skills)) - subagent specialization with strict hand-off contracts, fresh-context isolation, two-stage review pipelines
 - **BMAD-METHOD** ([github.com/bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)) - story-file workflow for incremental delivery, multi-phase methodology
 - **arc-ready / arc-anything** - artifact-quality discipline (substitution test, three-label test, named have-nots catalog)
@@ -35,7 +37,7 @@ Beyond what was inherited, godpowers added:
   AGENTS.md / CLAUDE.md / GEMINI.md and 11 other tool-specific paths
 - **Feature awareness and host guarantee reporting** so existing projects and
   AI coding hosts can state what Godpowers capabilities are actually available
-- **Messy-repo dogfood fixtures** for GSD migration, sync-back, extension
+- **Messy-repo dogfood fixtures** for legacy planning migration, sync-back, extension
   authoring, host capability, and Mode D suite release dry-run behavior
 - **Autonomous repo documentation and surface sync** for badges, route
   metadata, recipes, package payloads, release gates, and extension packs

package/README.md

@@ -2,7 +2,7 @@
 
 [![CI](https://github.com/aihxp/godpowers/actions/workflows/ci.yml/badge.svg)](https://github.com/aihxp/godpowers/actions/workflows/ci.yml)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](LICENSE)
-[![Version](https://img.shields.io/badge/version-2.2.1-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-2.3.1-blue)](CHANGELOG.md)
 [![npm](https://img.shields.io/npm/v/godpowers.svg)](https://www.npmjs.com/package/godpowers)
 
 **Ship fast. Ship right. Ship everything. Ship accountably.**
@@ -21,17 +21,15 @@ Godpowers makes AI coding accountable: every serious run should leave disk
 state, artifacts, validation gates, host guarantees, and a next action. Code is
 only one output. The project memory and proof trail matter too.
 
-Version 2.2.1 keeps the proof loop executable. `npx godpowers quick-proof
---project=.` now renders a shipped fixture with real `.godpowers/state.json`,
-computed next action, missing-artifact visibility, and host guarantees. The
-2.0 line also ships a proof transcript, adoption canary harness, published npm
-install verifier, package checks that require the proof fixture to ship, and
-request-trace review guardrails for narrower implementation diffs. The 2.0.2
-release also hardens the dependency-free YAML subset, route file checks,
-installer file copying, and maintainer release gates.
-
-Maintainer hardening continues on the 2.x line without expanding the public
-command surface. The 2.1.0 patch closes a command-injection vector in the
+Version 2.3.1 keeps the proof loop executable and adds release-surface
+hardening. Extension authors get `/god-extension-scaffold`, public starter
+paths are regression-tested against the actual router, host capability reports
+include optional code-intelligence tooling, clean user dashboards avoid
+maintainer-repo drift, and symlink handling is hardened across extension,
+planning-system, and cache paths.
+
+Maintainer hardening continues on the 2.x line with small, audited public
+surface updates when they close real workflow gaps. The 2.1.0 patch closes a command-injection vector in the
 agent-browser driver, guards runtime file parsing against corrupt state,
 makes data-directory installs a clean replace, and reconciles documentation
 drift. The 2.0.3 patch range-checks workflow agent references,
@@ -78,6 +76,8 @@ should prove:
 - Planning artifacts, code changes, reviews, and launch checks can be inspected.
 - Host guarantees are explicit, including degraded or simulated agent behavior.
 - Release confidence covers tests, package contents, install surfaces, and docs.
+- Build plans cite real files and symbols before execution starts.
+- New dependencies have registry and legitimacy evidence before they enter the stack.
 
 ## Install
 
@@ -96,6 +96,19 @@ The installer copies:
 - Codex agent metadata to `<runtime>/agents/*.toml`
 - SessionStart hook (Claude Code only) to `<runtime>/hooks/`
 
+Installer profiles keep the visible command surface calm:
+
+```bash
+npx godpowers --claude --global --profile=core
+npx godpowers --codex --local --profile=builder
+npx godpowers --all --profile=maintainer
+```
+
+Profiles are `core`, `builder`, `maintainer`, `suite`, and `full`. `full`
+preserves the complete command surface, while the smaller profiles install the
+commands most relevant to the role. `--minimal` is an alias for
+`--profile=core`.
+
 Agent spawning is host-native. Claude uses its native agent/task interface,
 Codex uses installed `agents/*.toml` metadata backed by the same Markdown agent
 contracts, and the other runtimes use their supported agent or subagent
@@ -174,13 +187,13 @@ learn the next command when Godpowers recommends it.
 
 | Goal | Starter path |
 |---|---|
-| Start a product | `/god-init`, `/god-prd`, `/god-design`, `/god-arch`, `/god-roadmap`, `/god-stack`, `/god-build` |
-| Add a feature | `/god-feature`, `/god-reconcile`, `/god-build`, `/god-review`, `/god-sync` |
-| Fix production | `/god-hotfix`, `/god-debug`, `/god-harden`, `/god-postmortem` |
-| Audit an existing repo | `/god-preflight`, `/god-audit`, `/god-archaeology`, `/god-tech-debt` |
-| Ship a release | `/god-status`, `/god-harden`, `/god-launch`, `npm run release:check` |
+| Start a product | `/god-init`, `/god-prd`, `/god-design`, `/god-arch`, `/god-roadmap`, `/god-stack`, `/god-repo`, `/god-build` |
+| Add a feature | `/god-reconcile`, `/god-feature`, `/god-sync`, `/god-review` |
+| Fix production | `/god-hotfix`, `/god-postmortem`, `/god-status` |
+| Audit an existing repo | `/god-preflight`, `/god-archaeology`, `/god-reconstruct`, `/god-audit`, `/god-tech-debt` |
+| Ship a release | `/god-sync`, `/god-docs`, `/god-version`, `/god-automation-setup`, `npm run release:check` |
 | Maintain project health | `/god-hygiene`, `/god-update-deps`, `/god-docs`, `/god-check-todos` |
-| Extend Godpowers | `/god-extension-add`, `/god-extension-list`, `npx godpowers extension-scaffold --name=@godpowers/my-pack --output=.` |
+| Extend Godpowers | `/god-extension-scaffold --name=@godpowers/my-pack --output=.`, `/god-test-extension`, `/god-extension-add`, `/god-extension-list` |
 
 The same status engine is available from the installer CLI for humans, CI,
 Codex, Claude, Cursor, Gemini, OpenCode, Windsurf, Antigravity, and any host
@@ -240,7 +253,7 @@ extension files, with parser coverage in `scripts/test-yaml-parser.js`.
 | `/god-automation-status` | Show host automation provider support | (built-in) |
 | `/god-automation-setup` | Prepare opt-in automation setup | (built-in) |
 | `/god-dogfood` | Run messy-repo dogfood scenarios for release and autonomy readiness | (built-in) |
-| `/god-migrate` | Detect GSD, BMAD, and Superpowers context; import and sync back | god-greenfieldifier when needed |
+| `/god-migrate` | Detect legacy planning, BMAD, and Superpowers context; import and sync back | god-greenfieldifier when needed |
 | `/god-preflight` | Read-only intake audit before project-run readiness and pillars | god-auditor |
 | `/god-audit` | Score artifacts against have-nots | god-auditor |
 | `/god-debug` | 4-phase systematic debug | god-debugger |
@@ -327,7 +340,7 @@ Godpowers can dogfood itself against shipped messy-repo fixtures:
 npx godpowers dogfood
 ```
 
-The dogfood suite covers a half-migrated GSD project, full and degraded host
+The dogfood suite covers a half-migrated legacy planning project, full and degraded host
 guarantee detection, extension scaffold validation, and a Mode D suite release
 dry-run. `/god-dogfood` reports failures with scoped specialist ownership
 rather than treating fixture checks as silent background work.
@@ -343,7 +356,7 @@ Godpowers can migrate from adjacent planning systems:
 /god-migrate
 ```
 
-This detects GSD `.planning/` or `.gsd/`, BMAD `_bmad-output/` or `.bmad/`,
+This detects legacy planning `.planning/` or `.legacy-planning/`, BMAD `_bmad-output/` or `.bmad/`,
 and Superpowers specs or plans. It writes
 `.godpowers/prep/IMPORTED-CONTEXT.md`, optional imported seed artifacts, and
 managed sync-back files such as `.planning/GODPOWERS-SYNC.md`,
@@ -485,7 +498,7 @@ Pi. T3 Code inherits from the underlying agent (Codex / Claude / OpenCode).
 - [Getting Started](docs/getting-started.md)
 - [Quick Proof](docs/quick-proof.md)
 - [Concepts](docs/concepts.md)
-- [Command reference (all 111 skills + 40 agents)](docs/reference.md)
+- [Command reference (all 112 skills + 40 agents)](docs/reference.md)
 - [Feature awareness](docs/feature-awareness.md)
 - [Adoption Canary](docs/adoption-canary.md)
 - [Repository documentation sync](docs/repo-doc-sync.md)

package/RELEASE.md

@@ -1,47 +1,68 @@
-# Godpowers 2.2.1 Release
+# Godpowers 2.3.1 Release
 
-> Status: Ready for release
-> Date: 2026-05-30
+> Status: Ready for package verification
+> Date: 2026-06-08
 
-Godpowers 2.2.1 is a patch release for the 2.2 deliverable-progress line. It
-keeps the public slash-command surface stable and fixes ledger persistence,
-idempotence, and release-state reconciliation.
+Godpowers 2.3.1 is an accountability and release-surface hardening release for
+the 2.x line. It strengthens planning grounding, package legitimacy, install
+profiles, atomic persistence, executor recovery, extension authoring,
+front-door route coverage, host capability reporting, and dashboard behavior.
 
 ## What's in this release
 
-- 111 slash commands
+- 112 slash commands
 - 40 specialist agents
 - 13 executable workflows
-- 41 intent recipes
+- 42 intent recipes
 
 ## Highlights
 
-- `.godpowers/REQUIREMENTS.md` no longer rewrites on timestamp-only no-op
-  regenerations, and the generated ledger no longer carries an extra blank line
-  at EOF.
-- `lib/reverse-sync.js` now persists deliverable summaries into
-  `state.json.deliverables`, matching the documented `/god-sync` behavior.
-- The Godpowers self-ledger now reports the shipped deliverable-progress feature
-  as done across roadmap, requirements ledger, and state cache.
-- Regression tests cover no-op ledger writes, state-cache persistence, and
-  no-op reverse-sync stability.
+- `/god-extension-scaffold` gives extension authors a first-class
+  slash-command path before `/god-test-extension` and `/god-extension-add`.
+- Public `/god` intent matching now covers the starter phrases users are most
+  likely to type: start a product, add a feature, fix production, audit an
+  existing repo, ship a release, maintain health, and extend Godpowers.
+- Quick Proof and README starter paths are now regression-tested against the
+  actual router and recipe engine.
+- User project dashboards no longer show maintainer-repository documentation
+  drift when a clean non-Godpowers project is inspected.
+- Host capability reporting now includes optional code-intelligence tooling
+  without treating missing optional tools as a host degradation.
+- Extension install, planning-system detection, and agent-cache cleanup are
+  hardened around symlinked paths that point outside trusted source trees.
+- Source-grounded planning records existing files, existing symbols, planned new
+  artifacts, and unchecked references before build execution.
+- Package legitimacy checks give stack and dependency decisions a concrete npm
+  evidence gate before recommending package-backed choices.
+- Installer profiles let users install a smaller role-based command surface
+  with `--profile=<name>` or `--minimal`.
+- Atomic write helpers now protect core state and ledger writes from partial
+  file updates.
+- Executor repair classification names whether a failed attempt should retry,
+  decompose, prune, or escalate.
+- Public migration language now uses neutral legacy-planning terminology so
+  Godpowers is not confused with external workflow products.
+- Architecture docs now include an executable audit map for disconnected
+  commands, actions, workflows, recipes, and package surfaces.
 
 ## Validation
 
 - `npm test` green across the full suite
 - `npm run lint` clean
 - `npm run release:check` green (tests, audit, package contents)
+- `npm pack` creates a local `godpowers-2.3.1.tgz` tarball for package
+  inspection
 
 ## Upgrade
 
-- `npm install -g godpowers@2.2.1` or `npx godpowers@2.2.1`
+- `npm install -g godpowers@2.3.1` or `npx godpowers@2.3.1`
 - Re-run `/god-context` in each project to refresh installed runtime metadata
-- No breaking changes; existing `.godpowers/` state is compatible. Projects gain
-  a `REQUIREMENTS.md` ledger the next time `/god-progress` or `/god-sync` runs.
+- No breaking changes; existing `.godpowers/` state is compatible. Users who
+  want a compact install can run `npx godpowers --profile=core`.
 
 ## Notes
 
-- GitHub release creation for `v2.2.1`
+- GitHub release creation for `v2.3.1`
 - The tag should match the npm package version
-- The `v2.2.1` tag should point to the release commit that matches the npm
-  `godpowers@2.2.1` package.
+- The `v2.3.1` tag should point to the release commit that matches the npm
+  `godpowers@2.3.1` package.

package/SKILL.md

@@ -297,7 +297,7 @@ Run these local runtime helpers automatically when their trigger is present:
   `PROGRESS.md` mutation.
 - Lightweight reverse-sync or linkage scan after code or artifact edits.
 - Pillars sync planning after durable artifact truth changes.
-- `lib/planning-systems.importPlanningContext` when GSD, BMAD, or
+- `lib/planning-systems.importPlanningContext` when legacy planning, BMAD, or
   Superpowers planning context is detected during `/god-init` or
   `/god-migrate`.
 - `lib/source-sync.run` when `state.json` records enabled `source-systems`
@@ -351,7 +351,7 @@ Spawn these agents only when the trigger is direct and scope is bounded:
 - `god-automation-engineer` after the user approves provider, template,
   cadence, and scope for multi-template, write-capable, background-agent,
   scriptable-scheduler, or provider-uncertain automation setup.
-- `god-greenfieldifier` when imported GSD, BMAD, or Superpowers context has
+- `god-greenfieldifier` when imported legacy planning, BMAD, or Superpowers context has
   low confidence, conflicting systems, or missing canonical Godpowers seed
   artifacts after local import.
 - `god-greenfieldifier` when feature-awareness detects unimported or imported

package/agents/god-auditor.md

@@ -250,7 +250,7 @@ Mode: [brownfield | bluefield]
 - This audit does not rewrite artifacts.
 - This audit must be followed by `god-greenfieldifier` in brownfield and
   bluefield workflows when the user wants the audit acted on.
-- This audit does not treat imported GSD, Superpowers, BMAD, or org context as
+- This audit does not treat imported legacy planning, Superpowers, BMAD, or org context as
   source of truth.
 - This audit does not block the project run unless it finds a Critical security or
   impossible planning contradiction.

package/agents/god-debugger.md

@@ -1,8 +1,9 @@
 ---
 name: god-debugger
 description: |
-  Systematic 4-phase debugger: Observe, Hypothesize, Test, Conclude. No
-  guess-and-check. Evidence-driven root cause analysis with regression tests.
+  Systematic debugger: Observe, Minimize, Instrument, Hypothesize, Test,
+  Conclude. No guess-and-check. Evidence-driven root cause analysis with
+  regression tests.
 
   Spawned by: /god-debug, when build encounters failures
 tools: Read, Edit, Bash, Grep, Glob, WebSearch
@@ -22,10 +23,44 @@ Gather evidence before forming any hypothesis:
 - Can you reproduce it RELIABLY? (if not, find a reliable repro first)
 - All error messages, stack traces, logs (full text, not paraphrased)
 - What is NOT happening that should be? (sometimes the silence is the clue)
+- When available, use `ast-grep`, `sg`, or LSP diagnostics/references to
+  narrow impacted symbols before forming a hypothesis.
 
 Output an observation document. Don't proceed until observations are complete.
 
-## Phase 2: Hypothesize
+## Phase 2: Minimize
+
+Reduce the failure to the smallest reliable reproduction before proposing a
+root cause:
+
+- Remove unrelated inputs, branches, services, files, data, and timing from the
+  reproduction while keeping the failure present.
+- Identify the smallest command, test, request, or user flow that still fails.
+- Record the exact boundary where removing one more thing makes the failure
+  disappear.
+- If minimization is impossible, record why and name the remaining broad
+  dependency that keeps the repro large.
+
+Do not proceed until the minimized reproduction is clear enough that another
+agent could rerun it without guessing.
+
+## Phase 3: Instrument
+
+Add or use focused evidence probes before forming a hypothesis:
+
+- Prefer existing logs, traces, diagnostics, failing assertions, and debugger
+  output when they already expose the state transition.
+- Add temporary probes only when they answer a specific question, then remove
+  them before the final fix unless they become a useful permanent test or log.
+- Instrument the boundary between expected and actual behavior, not every
+  nearby function.
+- Capture the observed values and the point where reality diverges from the
+  expected path.
+
+Do not proceed until the instrumentation either narrows the failure boundary or
+proves that more observation is needed.
+
+## Phase 4: Hypothesize
 
 Based on observations, list 2-3 most likely root causes:
 
@@ -35,7 +70,7 @@ For each hypothesis:
 - What evidence would REFUTE this hypothesis?
 - Rank by probability (1-10) with rationale
 
-## Phase 3: Test
+## Phase 5: Test
 
 Take the highest-probability hypothesis. Design a SPECIFIC test:
 - The test should produce different evidence depending on which hypothesis is true
@@ -43,11 +78,12 @@ Take the highest-probability hypothesis. Design a SPECIFIC test:
 - Record the evidence
 - Compare to predicted outcomes
 
-If hypothesis confirmed: proceed to Phase 4.
+If hypothesis confirmed: proceed to Phase 6.
 If hypothesis refuted: cross it off, move to next hypothesis.
-If all hypotheses refuted: return to Phase 1, expand observation scope.
+If all hypotheses refuted: return to Phase 1, then revisit minimization and
+instrumentation with the new evidence.
 
-## Phase 4: Conclude (Fix and Verify)
+## Phase 6: Conclude (Fix and Verify)
 
 1. **Write the regression test FIRST**
    - The test should reproduce the bug
@@ -74,4 +110,4 @@ If all hypotheses refuted: return to Phase 1, expand observation scope.
 - **Never apply multiple fixes at once** (can't tell which one worked)
 - **Always write the regression test first** (locks in the contract)
 - **If the bug is in a dependency**: document the workaround, file upstream, link in commit
-- **Time-boxing**: if Phase 1-3 takes >2 hours with no progress, ask for help (the observations are likely incomplete)
+- **Time-boxing**: if Phase 1-5 takes >2 hours with no progress, ask for help (the observations are likely incomplete)

package/agents/god-deps-auditor.md

@@ -31,6 +31,15 @@ For each dependency, classify:
 - **Minor behind**: only minor/patch updates available
 - **Up to date**: no action needed
 
+For each new replacement candidate, run the package legitimacy gate before
+recommending it:
+- Registry existence
+- Package age and recent publish signal
+- Repository URL
+- Maintainer or ownership signal when visible
+- Typo-squat similarity to better-known packages
+- Known vulnerability status where available
+
 ### 2. Triage
 
 Priority order:
@@ -109,3 +118,5 @@ Deps audit FAILS if:
 - Changelog not consulted (so breaking changes unknown)
 - Lockfile not committed alongside package.json
 - Bulk update without per-package commits (loses bisect-ability)
+- Replacement package recommended without legitimacy evidence or accepted-risk
+  note

package/agents/god-executor.md

@@ -22,6 +22,8 @@ You receive:
 - The slice's dependencies (what must already exist)
 - Optional repair payload: failing command, error counts, focused diagnostics,
   and files implicated by a previous verification run
+- Optional source-grounding report: pass/fail status for existing files and
+  symbols cited by the slice plan
 
 ## TDD Sequence (mandatory)
 
@@ -73,6 +75,14 @@ requirement as "not started" even after you ship it.
 - **Unrelated cleanup**: VIOLATION. Do not reformat, rename, refactor, or
   delete adjacent code that is not required for this slice. Mention it as a
   follow-up instead.
+- **Ungrounded existing references**: VIOLATION. Do not implement against a
+  file, symbol, route, or API that the source-grounding preflight failed to
+  locate unless the plan explicitly declares it as a new artifact or the user
+  accepted it as unchecked risk.
+- **Unverified new dependency**: VIOLATION. Before installing or adding a new
+  third-party package, run the package legitimacy gate from
+  `lib/package-legitimacy.js` or record why network verification was unavailable
+  and who accepted the risk.
 
 ## Request Trace Discipline
 
@@ -86,6 +96,34 @@ Every changed line must trace back to that contract, the failing test, or a
 cleanup created by your own change. If you cannot explain the trace, revert
 that line before returning control to the orchestrator.
 
+## Optional Style Profile
+
+If `CODEDNA.md` exists at the project root or appears in the provided context
+loadout, read it before editing:
+- Match the repo's naming, file organization, comment density, extraction
+  threshold, error handling style, and test idioms when they do not conflict
+  with the slice plan.
+- Treat formatter, linter, tests, and explicit project conventions as
+  higher-priority evidence when they conflict with the profile.
+- Do not invent or generate a `CODEDNA.md` profile in executor scope.
+- If no profile exists, continue by matching the surrounding code directly.
+- Preserve required `// Implements: P-...` annotations even when the profile
+  prefers fewer comments.
+
+## Optional Code Intelligence
+
+When host capabilities or local probing report `ast-grep`, `sg`, or LSP tools:
+- Use `ast-grep` or `sg` for structural search before broad text rewrites.
+- Use LSP diagnostics, definitions, references, or rename support when the
+  host exposes them for the touched language.
+- Treat these tools as evidence helpers, not authority. Tests, source
+  grounding, and request trace still decide whether the slice is complete.
+- Record the tool only when it shaped file selection, rewrite scope, or a
+  repair decision.
+
+If optional code intelligence is unavailable, continue with Grep, Glob, and
+Bash evidence. Absence of these tools is not a blocker.
+
 ## After All Behaviors Complete
 
 1. Run the full test suite. All tests must pass.
@@ -122,8 +160,15 @@ happen.
 
 ## Repair Mode
 
-If invoked with a repair payload, stay narrowly focused on the failing command.
-Do not reopen PRD, ARCH, roadmap, or stack unless the diagnostic proves the
-artifact is stale. Fix code, config, imports, tests, generated types, or
-tooling until the command passes. If the same root failure survives 3 focused
-attempts, return the smallest human-only question needed to continue.
+If invoked with a repair payload, classify the failure before editing:
+
+| Strategy | Use when | Action |
+|---|---|---|
+| retry | The approach is right but a command, import, path, dependency, timeout, or environment failed | Make one focused adjustment and rerun the exact verification |
+| decompose | The task is too broad or the done criteria combines multiple outcomes | Split into at most 3 smaller verified steps for this run |
+| prune | A task is infeasible in this slice because a prerequisite is missing or out of scope | Skip only with a recorded reason and a downstream review marker |
+| escalate | The repair budget is exhausted or the fix changes architecture, product behavior, or user intent | Stop and return the smallest human-only decision needed |
+
+Log every repair decision in the slice closeout as
+`[Executor Repair - STRATEGY] task: reason`. Do not reopen PRD, ARCH, roadmap,
+or stack unless the diagnostic proves the artifact is stale.

package/agents/god-greenfieldifier.md

@@ -137,7 +137,7 @@ After approved rewrites:
 
 ## Rules
 
-- Imported GSD, Superpowers, BMAD, org context, and reconstructed artifacts are
+- Imported legacy planning, Superpowers, BMAD, org context, and reconstructed artifacts are
   evidence, not source of truth.
 - Never erase existing specific evidence to replace it with a generic
   greenfield default.

package/agents/god-orchestrator.md

@@ -161,7 +161,7 @@ Before each tier, check whether this repo is part of a registered suite:
 
 ## Planning-system context import
 
-During `/god-init`, scan for adjacent methodology artifacts from GSD,
+During `/god-init`, scan for adjacent methodology artifacts from legacy planning,
 Superpowers, BMAD, and similar systems. Treat them as preparation context,
 not as source of truth.
 
@@ -210,7 +210,7 @@ conflicts with user intent, state.json, PROGRESS.md, or completed Godpowers
 artifacts, the Godpowers artifact wins.
 
 Detection signals:
-- GSD: `.gsd/`, `.planning/`, `GSD.md`, `gsd*.md`
+- legacy planning: `.legacy-planning/`, `.planning/`, `LEGACY-PLANNING.md`, `legacy-planning*.md`
 - Superpowers: `.superpowers/`, `superpowers/`, `SUPERPOWERS.md`,
   `.claude/skills/`, `.codex/skills/`
 - BMAD: `.bmad-core/`, `bmad-core/`, `.bmad/`, `BMAD.md`,

package/agents/god-planner.md

@@ -35,6 +35,12 @@ Plan the build.
    - **Slice name**: user-visible behavior
    - **Requirements**: the PRD requirement ids this slice delivers (so the
      executor can annotate the code and the deliverable ledger can trace it)
+   - **Source grounding**:
+     - Existing files this slice depends on
+     - Existing symbols, functions, classes, routes, commands, or APIs this
+       slice depends on
+     - New artifacts this slice will create
+     - Unchecked references that need human acceptance before execution
    - **Files to create/modify**: exact paths
    - **Tests to write FIRST**: with expected behavior
    - **Implementation steps**: ordered
@@ -55,6 +61,11 @@ Write `.godpowers/build/PLAN.md`:
 ## Wave 1 (parallel)
 ### Slice 1.1: User can create an account
 - Requirements: P-MUST-01
+- Source grounding:
+  - Existing files: src/auth/index.ts
+  - Existing symbols: createSession
+  - New artifacts: src/auth/signup.ts, src/auth/signup.test.ts
+  - Unchecked references: none
 - Files: src/auth/signup.ts, src/auth/signup.test.ts, src/db/users.ts
 - Tests first:
   - signup_creates_user_record
@@ -76,6 +87,9 @@ Write `.godpowers/build/PLAN.md`:
 - `.godpowers/build/PLAN.md` exists
 - Every slice has tests-first sequence
 - Every slice names the PRD requirement ids it delivers
+- Every slice separates existing references from new artifacts
+- Every existing reference is grounded by `lib/source-grounding.js` before
+  execution
 - Every member requirement id of the increment is covered by at least one slice
 - Every slice has verification criteria
 - Dependencies are explicit

package/agents/god-pm.md

@@ -62,7 +62,7 @@ reflects what Godpowers observed during init: codebase shape, tests, docs,
 risks, and methodology systems detected.
 
 If `.godpowers/prep/IMPORTED-CONTEXT.md` exists, read it before drafting the
-PRD. Use product signals from GSD, Superpowers, BMAD, or similar systems as
+PRD. Use product signals from legacy planning, Superpowers, BMAD, or similar systems as
 hypothesis-level input only.
 
 If `.godpowers/domain/GLOSSARY.md` exists, read it before drafting the PRD.