godpowers 1.6.5 → 1.6.6

package/CHANGELOG.md

@@ -5,6 +5,33 @@ All notable changes to Godpowers will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.6.6] - 2026-05-16
+
+Non-God-Mode handoff privacy patch. Extends the display-safe handoff pattern
+from `/god-mode` to other orchestrator entrypoints.
+
+### Added
+- Added private handoff guidance for `/god-init` before it spawns
+  `god-orchestrator`.
+- Added private handoff guidance for `/god-suite-init`,
+  `/god-suite-release`, and `/god-suite-patch` before they spawn
+  `god-coordinator`.
+- Added `god-coordinator` guidance for display-safe per-repo
+  `god-orchestrator` spawns.
+- Added regression coverage for non-`/god-mode` handoff entrypoints.
+
+### Changed
+- `god-orchestrator` now documents handoff files from `/god-init`,
+  `god-coordinator`, or any other caller, not only `/god-mode`.
+- `/god-hygiene` routing no longer lists `god-orchestrator` as a secondary
+  spawn because the skill only runs the three hygiene audits.
+
+### Guardrails
+- This patch does not add slash commands, agents, workflows, recipes, schemas,
+  or public artifact formats.
+- The handoff change affects transcript hygiene only. It does not weaken
+  release-truth gates or per-repo Quarterback ownership.
+
 ## [1.6.5] - 2026-05-16
 
 God Mode handoff privacy patch. Keeps the 1.6 command surface stable while

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-1.6.5-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.6-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.**
@@ -12,11 +12,11 @@ idea to hardened production. It runs as **slash commands inside your AI coding
 tool** (Claude Code, Codex, Cursor, etc.) that orchestrate **specialist agents**
 in fresh contexts to do the work.
 
-Version 1.6.5 keeps the stable Godpowers surface while making Codex
-`god-orchestrator` spawns transcript-safe: `/god-mode` now writes detailed
-orchestration context to a private handoff file and spawns with only a small
-display-safe pointer. Safe-sync and unresolved Critical harden findings still
-gate direct Tier 3 commands, `/god-mode`, and `/god-mode --yolo`.
+Version 1.6.6 keeps the stable Godpowers surface while making more Codex
+orchestrator spawns transcript-safe: `/god-mode`, `/god-init`, and Mode D
+suite coordinator paths now use private handoff files with small display-safe
+pointers. Safe-sync and unresolved Critical harden findings still gate direct
+Tier 3 commands, `/god-mode`, and `/god-mode --yolo`.
 
 It fuses four disciplines into one unified workflow:
 

package/RELEASE.md

@@ -1,11 +1,11 @@
-# Godpowers 1.6.5 Release
+# Godpowers 1.6.6 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.5 keeps the stable 1.6 surface while fixing Codex God Mode
-transcript hygiene. The goal of this patch is to make `god-orchestrator`
-spawn correctly from `/god-mode` and `/god-mode --yolo` without exposing the
-detailed orchestration payload in the visible transcript.
+Godpowers 1.6.6 extends transcript-safe spawn handling beyond `/god-mode`.
+The goal of this patch is to keep Codex-visible spawn messages small and safe
+for `/god-init` and Mode D suite coordination while preserving the same
+orchestrator and coordinator behavior.
 
 ## What is stable
 
@@ -27,35 +27,40 @@ detailed orchestration payload in the visible transcript.
 
 ## What is new
 
-- `/god-mode` now writes detailed orchestration context to
-  `.godpowers/runs/<run-id>/ORCHESTRATOR-HANDOFF.md`.
-- `/god-mode` now spawns `god-orchestrator` with only a display-safe project
-  root, flags, and handoff file path.
-- `god-orchestrator` now knows to read the handoff file before planning,
-  spawning, or mutating project state.
-- `god-orchestrator` now treats handoff contents as private orchestration
-  context and keeps them out of the visible transcript.
-- Agent validation and smoke tests now inspect `agents/god-*.md` specialist
-  files while allowing Pillars context files like `agents/context.md` and
-  `agents/repo.md` to coexist.
-
-## What 1.6.5 means
-
-Godpowers 1.6.5 does not expand the public command surface. It fixes the Codex
-spawn integration path so the right specialist agent is still started, but the
-host UI only sees a small pointer to disk state instead of raw checkpoint,
-routing, and local-file details.
+- `/god-init` now writes detailed initialization context to
+  `.godpowers/runs/<run-id>/INIT-ORCHESTRATOR-HANDOFF.md` before spawning
+  `god-orchestrator`.
+- `/god-suite-init`, `/god-suite-release`, and `/god-suite-patch` now write
+  suite coordination context to
+  `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` before spawning
+  `god-coordinator`.
+- `god-coordinator` now writes per-repo orchestrator context to
+  `.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md` before
+  spawning a target repo's `god-orchestrator`.
+- `god-orchestrator` now treats handoff files as a general caller protocol,
+  not only as a `/god-mode` protocol.
+- `/god-hygiene` routing no longer lists `god-orchestrator` as a secondary
+  spawn because the skill only runs artifact, dependency, and documentation
+  audits.
+
+## What 1.6.6 means
+
+Godpowers 1.6.6 does not expand the public command surface. It fixes more
+Codex spawn integration paths so the right agent is still started, but the host
+UI only sees a small pointer to disk state instead of raw project description,
+suite metadata, release notes, patch directives, dependency graphs, routing
+rules, or local-file details.
 
 Safe sync and unresolved Critical harden findings remain release-truth gates.
-`--yolo` can still auto-pick defaults, but it cannot bypass those blockers.
+Per-repo Quarterback ownership remains intact for Mode D suite work.
 
 ## Stability policy
 
 During the 1.x stability window, do not add broad new command families, change
 schema formats, or rename public artifacts without evidence from real use.
 
-The `v1.6.5` git tag points to the release commit that matches the npm
-`godpowers@1.6.5` package. Public publishes should prefer the tag-triggered
+The `v1.6.6` git tag points to the release commit that matches the npm
+`godpowers@1.6.6` package. Public publishes should prefer the tag-triggered
 GitHub workflow so npm provenance, git history, and release notes stay aligned.
 
 Allowed changes:

package/agents/god-coordinator.md

@@ -44,6 +44,20 @@ suite (the collection of repos), not individual repos.
 - Per-repo `state.json` files
 - Optionally: a specific operation (sync, release, patch, status)
 
+## Coordinator Handoff
+
+When spawned by a suite command, the visible spawn message may include only a
+display-safe operation summary plus a path like
+`.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md`.
+
+If a handoff path is provided:
+1. Read the handoff file before planning, spawning, or mutating suite state.
+2. Treat the handoff as private suite coordination context.
+3. Do not quote, summarize, or expose the full handoff in the visible
+   transcript.
+4. If the handoff conflicts with durable suite artifacts, prefer disk
+   artifacts and record the conflict as an open question or repair target.
+
 ## Process per operation
 
 ### Mode 1: status (`/god-suite-status`)
@@ -66,7 +80,8 @@ suite (the collection of repos), not individual repos.
 
 1. User provides repo + new version
 2. Run impact analysis: which sibling repos depend on this one?
-3. For each affected sibling: spawn its `god-orchestrator` with a
+3. For each affected sibling: write a per-repo orchestrator handoff file and
+   spawn its `god-orchestrator` with only a display-safe pointer for the
    `version-bump` directive (NOT a full arc)
 4. Aggregate results into a release report
 5. Update `.godpowers/suite-config.yaml` version-table
@@ -75,8 +90,9 @@ suite (the collection of repos), not individual repos.
 ### Mode 4: patch (`/god-suite-patch`)
 
 1. User describes a change that touches multiple repos
-2. For each repo in scope: spawn its `god-orchestrator` with the
-   patch description
+2. For each repo in scope: write a per-repo orchestrator handoff file and
+   spawn its `god-orchestrator` with only a display-safe pointer for the
+   patch directive
 3. Coordinate atomicity: if any repo fails, mark the suite-level
    patch as incomplete and report
 4. Append to SYNC-LOG.md
@@ -117,8 +133,25 @@ For each operation, return to the spawning skill with:
 ## Coordination with per-repo orchestrators
 
 When you need work done IN a repo (version bump, patch slice, etc.),
-spawn that repo's `god-orchestrator` via the Task tool with the
-specific directive. Do not bypass it. The Quarterback rule:
+create a private handoff in that repo first, then spawn that repo's
+`god-orchestrator` via the Task tool with only a display-safe pointer.
+
+Per-repo handoff path:
+`.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md`
+
+Put the version-bump directive, patch directive, suite impact analysis,
+affected dependency facts, release notes, and repo-specific notes in the
+handoff file. The visible spawn message may include only:
+- The target repo root
+- The suite operation name
+- The handoff file path
+- "Read the handoff file first, then run the requested scoped work from disk
+  state. Return only user-facing progress and final status."
+
+Do not put suite metadata, dependency graphs, local file lists, release notes,
+patch descriptions, hidden routing rules, or detailed instructions in the
+visible spawn message. Do not bypass the target repo orchestrator. The
+Quarterback rule:
 
 > Each repo has exactly one orchestrator. The coordinator is a peer
 > at suite scope, not a higher-tier overseer.

package/agents/god-orchestrator.md

@@ -21,10 +21,11 @@ You orchestrate the full Godpowers arc. You DO NOT do the heavy lifting yourself
 Your job is to spawn the right specialist agent for each sub-step, verify their
 output passes the gate, update PROGRESS.md, and move to the next step.
 
-## God Mode Handoff
+## Orchestrator Handoff
 
-When spawned by `/god-mode`, the visible spawn message may include only a
-display-safe summary plus a path like
+When spawned by `/god-mode`, `/god-init`, `god-coordinator`, or any other
+caller, the visible spawn message may include only a display-safe summary plus
+a path like
 `.godpowers/runs/<run-id>/ORCHESTRATOR-HANDOFF.md`.
 
 If a handoff path is provided:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "godpowers",
-  "version": "1.6.5",
+  "version": "1.6.6",
   "description": "AI-powered development system: 106 slash commands and 39 specialist agents that take a project from raw idea to hardened production. Runs inside Claude Code, Codex, Cursor, Windsurf, Gemini, and 10+ other AI coding tools.",
   "bin": {
     "godpowers": "./bin/install.js"

package/routing/god-hygiene.yaml

@@ -12,7 +12,7 @@ prerequisites:
 execution:
   spawns: [god-auditor]
   context: fresh
-  secondary-spawns: [god-deps-auditor, god-docs-writer, god-orchestrator]
+  secondary-spawns: [god-deps-auditor, god-docs-writer]
   writes:
     - .godpowers/HYGIENE-REPORT.md
 

package/skills/god-doctor.md

@@ -48,7 +48,7 @@ GODPOWERS DOCTOR
 Install: claude (~/.claude/)
   [OK] 106 skills installed
   [OK] 39 agents installed
-  [OK] VERSION matches (1.6.5)
+  [OK] VERSION matches (1.6.6)
   [WARN] routing/god-doctor.yaml exists but skill file did not until now
 
 Project: /Users/.../my-project/.godpowers/

package/skills/god-init.md

@@ -81,10 +81,27 @@ needs to specify a mode.
    - Code present + org context: "Detected: existing codebase + org standards.
      I'll archaeology, reconstruct, and respect your org's standards."
 
-4. Ask the user to describe what they want to build. Accept any format.
-
-5. Spawn **god-orchestrator** in fresh context with the user's description and
-   the detected mode/context.
+5. Ask the user to describe what they want to build. Accept any format.
+
+6. Create a private disk handoff before spawning the orchestrator:
+   - Path: `.godpowers/runs/<run-id>/INIT-ORCHESTRATOR-HANDOFF.md`
+   - Create parent directories if needed.
+   - Put the user's description, detected mode, detected context, initial
+     findings summary, imported context summary, Pillars status, and next-step
+     routing notes in this file.
+
+7. Spawn **god-orchestrator** in fresh context with only a display-safe
+   payload:
+   - Name the project root.
+   - Name the invocation as `/god-init`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then initialize or resume from disk
+     state. Return only user-facing progress and final status."
+
+   Do not put recovered planning context, local file lists, org standards,
+   imported planning-system summaries, hidden routing rules, or detailed
+   instructions in the visible spawn message. Assume the host UI may display
+   the raw spawn message to the user.
 
    The orchestrator will:
    - Run Mode Detection (announced in plain English; stored as A/B/C/E internally)
@@ -100,14 +117,14 @@ needs to specify a mode.
    - Write PROGRESS.md with mode, scale, timestamp, tier states
    - Return mode/scale/announcement to this skill
 
-4. Detect scale by analyzing the description:
+8. Detect scale by analyzing the description:
    - **Trivial**: Single file change, bug fix, config tweak
    - **Small**: One feature, one service, <1 week
    - **Medium**: Multiple features, 1-3 services, 1-4 weeks
    - **Large**: Multiple services, team coordination, 1-3 months
    - **Enterprise**: Multiple teams, compliance, 3+ months
 
-5. Create the directory structure:
+9. Create the directory structure:
    ```
    AGENTS.md
    agents/
@@ -140,9 +157,9 @@ needs to specify a mode.
      harden/
    ```
 
-6. Write PROGRESS.md with mode, scale, timestamp, all tiers set to `pending`
+10. Write PROGRESS.md with mode, scale, timestamp, all tiers set to `pending`
 
-7. Report to the user:
+11. Report to the user:
    - Detected mode and scale
    - Which tiers and personas will activate
    - What to run next (suggest `god prd` or `god mode`)

package/skills/god-suite-init.md

@@ -32,12 +32,23 @@ are listed manually; godpowers does NOT auto-walk parent dirs.
    - Byte-identical files to track (one per line; e.g., LICENSE, .editorconfig)
    - Version-table entries (optional; can be added later)
    - Shared standards (node-version, linter; optional)
-3. Spawn `god-coordinator` agent in `init` mode with collected inputs.
-4. god-coordinator writes `.godpowers/suite-config.yaml` and updates
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the
+   collected suite name, sibling paths, byte-identical files, version-table
+   entries, shared standards, and init-mode instruction.
+4. Spawn `god-coordinator` agent in `init` mode with only a display-safe
+   payload:
+   - Name the hub path.
+   - Name the operation as `init`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then perform suite init from disk
+     state. Return only user-facing progress and final status."
+   Do not put sibling paths, version-table entries, shared standards, local
+   file lists, or detailed instructions in the visible spawn message.
+5. god-coordinator writes `.godpowers/suite-config.yaml` and updates
    each sibling's state.json with `suite.hubPath`.
-5. Initial `lib/suite-state.refreshFromRepos` runs to populate
+6. Initial `lib/suite-state.refreshFromRepos` runs to populate
    `.godpowers/suite/state.json` and `STATE.md`.
-6. Report registration complete; suggest `/god-suite-status` next.
+7. Report registration complete; suggest `/god-suite-status` next.
 
 ## Output
 

package/skills/god-suite-patch.md

@@ -22,11 +22,23 @@ locally; the coordinator tracks atomicity.
    - Patch description (what's the change)
    - Repos in scope (defaults: all siblings; user can subset)
    - Per-repo any specific notes
-3. Spawn `god-coordinator` in `patch` mode.
-4. For each repo in scope:
-   - Spawn that repo's `god-orchestrator` with the patch directive
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the patch
+   description, repos in scope, per-repo notes, dry-run flag, and patch-mode
+   instruction.
+4. Spawn `god-coordinator` in `patch` mode with only a display-safe payload:
+   - Name the hub path.
+   - Name the operation as `patch`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then coordinate the suite patch from
+     disk state. Return only user-facing progress and final status."
+   Do not put patch descriptions, per-repo notes, sibling paths, local file
+   lists, or detailed instructions in the visible spawn message.
+5. For each repo in scope:
+   - Write a per-repo orchestrator handoff file and spawn that repo's
+     `god-orchestrator` with only a display-safe pointer for the patch
+     directive
    - Track success/failure
-5. Coordinator aggregates results:
+6. Coordinator aggregates results:
    - All succeeded: report success; append to SYNC-LOG.md
    - Some failed: report partial; suggest manual continuation OR
      rollback (`/god-suite-patch --rollback <patch-id>`)

package/skills/god-suite-release.md

@@ -17,15 +17,27 @@ A version bump that knows about dependents. Different from `/god-launch`
 
 1. Verify suite is registered.
 2. Prompt for: which repo, new version, release notes.
-3. Spawn `god-coordinator` in `release` mode.
-4. god-coordinator:
+3. Create `.godpowers/runs/<run-id>/COORDINATOR-HANDOFF.md` with the repo,
+   new version, release notes, propagation flags, and suite release
+   instruction.
+4. Spawn `god-coordinator` in `release` mode with only a display-safe
+   payload:
+   - Name the hub path.
+   - Name the operation as `release`.
+   - Name the handoff file path.
+   - Say: "Read the handoff file first, then coordinate the suite release
+     from disk state. Return only user-facing progress and final status."
+   Do not put release notes, dependency impact, sibling paths, local file
+   lists, or detailed instructions in the visible spawn message.
+5. god-coordinator:
    - Scans suite version-table for repos that depend on the bumped repo
-   - For each dependent: spawns its `god-orchestrator` with a
+   - For each dependent: writes a per-repo orchestrator handoff file and
+     spawns its `god-orchestrator` with only a display-safe pointer for the
      `version-bump` directive (NOT a full arc)
    - Aggregates results per-repo
    - Updates `.godpowers/suite-config.yaml` version-table to match
    - Appends to `.godpowers/suite/SYNC-LOG.md`
-5. Reports aggregated outcome (bumped + propagated repos).
+6. Reports aggregated outcome (bumped + propagated repos).
 
 ## Forms
 

package/skills/god-version.md

@@ -14,7 +14,7 @@ Print version and a short capability summary.
 ## Output
 
 ```
-Godpowers v1.6.5
+Godpowers v1.6.6
 Install: /Users/.../.claude/  (matches package.json)
 Surface: 106 skills, 39 agents, 13 workflows, 36 recipes
 Schema: intent.v1, state.v1, events.v1, workflow.v1, routing.v1, recipe.v1