godpowers 1.6.10 → 1.6.12

package/CHANGELOG.md

@@ -5,6 +5,76 @@ 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.12] - 2026-05-16
+
+Executable dashboard CLI and shared runtime status engine.
+
+### Added
+- Added `lib/dashboard.js`, a shared executable engine for project status,
+  progress percentage, tier position, planning visibility, proactive checks,
+  open items, and recommended next command.
+- Added `godpowers status --project .` for human, CI, and host-runtime status
+  checks outside the slash command layer.
+- Added `godpowers next --project .` for direct next-action routing from disk
+  state.
+- Added `--json` output for the new status and next commands.
+- Added dashboard behavioral tests, CLI status and next tests, and git
+  porcelain parsing tests.
+
+### Changed
+- `/god-status`, `/god-next`, `/god-mode`, and `god-orchestrator` now point to
+  the shared dashboard engine when local runtime execution is available.
+- The installer help now documents status and next as first-class commands.
+- Release documentation now names the executable dashboard contract instead of
+  treating progress visibility as Markdown-only guidance.
+
+### Fixed
+- Fixed git porcelain parsing so leading-space worktree entries such as
+  ` M README.md` do not clip filenames in dashboard output.
+
+### Validation
+- Added tests prove dashboard computation, dashboard rendering, CLI JSON
+  output, proactive review suggestions, and staged path reporting.
+
+## [1.6.11] - 2026-05-16
+
+Auto-invoke visibility and platform-neutral spawning patch.
+
+### Added
+- Added a core auto-invoke visibility rule requiring Godpowers to show when it
+  automatically runs a command, spawns an agent, or calls a local runtime
+  helper.
+- Added a proactive auto-invoke policy with four levels: read-only
+  suggestions, visible local helpers, bounded specialist agent spawns, and
+  explicit-approval-only actions.
+- Added proactive checks to `/god-next`, `/god-status`, and God Mode closeouts
+  so users can see checkpoint, review, sync, docs, runtime, security,
+  dependency, and hygiene opportunities without asking.
+- Added docs drift, runtime verification, and review queue guidance for
+  proactive closeouts.
+- Added `docs/auto-invoke-visibility.md` as a local design note for the
+  auto-invoke policy.
+
+### Changed
+- Replaced Claude-specific "Task tool" spawning wording in high-traffic skills
+  with platform-neutral host-agent spawning language.
+- Clarified that Claude, Codex, Cursor, Windsurf, Gemini, OpenCode, Copilot,
+  Augment, Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, and Pi may expose
+  specialist spawning differently while sharing the same Markdown agent
+  contracts.
+- Updated the Codex installer path to replace skill directories before copying
+  `SKILL.md`, preventing stale nested files from older install shapes.
+- `/god-sync`, `/god-scan`, `god-updater`, and `god-orchestrator` now describe
+  local sync helpers separately from spawned agents.
+
+### Guardrails
+- Production launch, guessed staging URLs, provider dashboards, credentials,
+  destructive repair, review clearing, Critical security acceptance, git
+  staging, commits, pushes, packages, releases, and npm publishing still require
+  explicit user intent.
+- If a host platform cannot provide a true fresh-context spawn, Godpowers must
+  say so instead of pretending a background agent ran.
+
 ## [1.6.10] - 2026-05-16
 
 Progress visibility and plain-language closeout patch.

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.10-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.12-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,10 +12,10 @@ 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.10 keeps the stable Godpowers surface while making progress more
-visible: user-facing output now prefers "project run" over internal "arc"
-jargon and status closeouts show PRD, roadmap, milestone, and completion
-position when available.
+Version 1.6.12 adds an executable dashboard engine and CLI status surface:
+`godpowers status --project .` and `godpowers next --project .` now compute the
+same disk-derived progress, planning visibility, proactive checks, and next
+action used by `/god-status`, `/god-next`, and God Mode closeouts.
 
 It fuses four disciplines into one unified workflow:
 
@@ -50,6 +50,13 @@ The installer copies:
 - Codex agent metadata to `<runtime>/agents/*.toml`
 - SessionStart hook (Claude Code only) to `<runtime>/hooks/`
 
+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
+mechanism against the installed `agents/god-*.md` files. If a host cannot
+provide a true fresh-context spawn, Godpowers must report that limitation
+instead of pretending a background agent ran.
+
 ## Usage
 
 Open your AI coding tool in any project directory and type:
@@ -102,6 +109,16 @@ This reads `.godpowers/PROGRESS.md`, scans disk, reconciles any drift, and
 suggests the next logical command. The SessionStart hook does the same thing
 when you open a new session in a Godpowers project.
 
+The same status engine is available from the installer CLI for humans, CI,
+Codex, Claude, Cursor, Gemini, OpenCode, Windsurf, Antigravity, and any host
+runtime that can execute Node:
+
+```bash
+npx godpowers status --project=.
+npx godpowers next --project=.
+npx godpowers status --project=. --json
+```
+
 ### Slash Commands
 
 | Command | What it does | Spawns agent |
@@ -172,6 +189,14 @@ Under `--yolo`, Godpowers also auto-applies Pillars sync proposals when
 durable `.godpowers` artifacts change project truth. The decision is logged to
 `.godpowers/YOLO-DECISIONS.md`.
 
+Every completing command now ends with a **Godpowers Dashboard**. It shows the
+current phase, tier, step count, percent complete, PRD and roadmap visibility,
+recent work, proactive checks, open items, and the single recommended next
+action. `/god-status` and `/god-next` use the same shape so the project never
+ends in a vague "done" state. The dashboard is backed by
+`lib/dashboard.js`, so status and next-step commands share one executable
+source of disk truth instead of parallel Markdown-only contracts.
+
 For existing codebases and org-constrained new projects, God Mode now runs a
 greenfield simulation audit and then actions it through a greenfieldification
 plan. It pauses before risky artifact rewrites because that process can change

package/RELEASE.md

@@ -1,11 +1,10 @@
-# Godpowers 1.6.10 Release
+# Godpowers 1.6.12 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.10 makes progress easier to understand while work is running and
-when it closes. The goal of this patch is to keep user-facing output from
-requiring internal "arc" vocabulary and to show PRD, roadmap, milestone, and
-completion position wherever status is reported.
+Godpowers 1.6.12 turns progress visibility into executable product behavior.
+The same dashboard logic now powers slash command closeouts, direct CLI status
+checks, JSON status output, and next-action recommendations from disk state.
 
 ## What is stable
 
@@ -14,75 +13,70 @@ completion position wherever status is reported.
 - 13 executable workflows
 - 36 intent recipes
 - 15-runtime installer
-- Codex installs with 39 generated `god-*.toml` agent metadata files
-- Safe-sync routing before deploy, observe, harden, launch, or god-mode work
-- Critical harden finding gate before launch
+- 453 package files in the npm tarball
+- Codex installs with generated `god-*.toml` agent metadata files
+- Markdown specialist agent contracts at `<runtime>/agents/god-*.md`
+- Shared runtime bundle at `<runtime>/godpowers-runtime`
 - Native Pillars project context through `AGENTS.md` and `agents/*.md`
 - `.godpowers/` workflow state and artifact layout
-- Core schemas: intent, state, events, workflow, routing, recipes, extension
-  manifests
-- Extension pack compatibility range for the 1.x line
-- Domain precision through `.godpowers/domain/GLOSSARY.md` and DG-01 through
-  DG-05 checks
+- Safe-sync routing before deploy, observe, harden, launch, or god-mode work
+- Critical harden finding gate before launch
 - GSD-style proposition closeouts for exploratory, diagnostic, audit,
   lifecycle, status, reconciliation, and decision-support outputs
 - Plain-language project-run wording in user-facing reports
-- Planning visibility blocks for PRD, roadmap, milestone, and completion basis
 
 ## What is new
 
-- The core Godpowers skill now defines "arc" as internal vocabulary and tells
-  user-facing output to prefer "project run", "workflow", "phase", "current
-  step", or "current milestone".
-- `/god-mode`, `god-orchestrator`, `/god-status`, `/god-next`, and
-  `/god-lifecycle` now include planning visibility guidance for PRD, roadmap,
-  milestone, and percent complete when the information is available.
-- The installer, session-start hook, `/god` front door, routing descriptions,
-  workflow descriptions, and high-traffic skill propositions now use
-  project-run language instead of unexplained "arc" wording.
-- Checkpoint and session-start summaries display lifecycle `in-arc` as
-  "in progress" while preserving the internal state key for compatibility.
-
-## What 1.6.10 means
-
-Godpowers 1.6.10 does not expand the public command surface. It changes how
-Godpowers explains itself: the user should see the current project run, PRD,
-roadmap, milestone, completion percentage, open items, and next action without
-decoding internal terminology.
-
-Internal workflow names and state constants such as `full-arc.yaml` and
-`in-arc` remain unchanged for compatibility. Visible reports should translate
-them to plain language.
-
-Safe sync and unresolved Critical harden findings remain release-truth gates.
-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.10` git tag points to the release commit that matches the npm
-`godpowers@1.6.10` package. Public publishes should prefer the tag-triggered
-GitHub workflow so npm provenance, git history, and release notes stay aligned.
-
-Allowed changes:
-
-- Critical bug fixes
-- Documentation clarity
-- Test coverage for frozen behavior
-- Compatibility fixes for supported AI coding tools
-- Small fixes that make existing 1.x behavior work as documented
-
-Deferred changes:
-
-- New lifecycle phases
-- New schema versions
-- Pillars format changes
-- Major routing semantics
-- Large extension API changes
-
-## Adoption ask
-
-Run `npm run release:check` before publishing changes. Report any release path
-step that still depends on memory, manual inspection, or local machine state.
+- Added `lib/dashboard.js`, a shared executable status engine.
+- Added `godpowers status --project .`.
+- Added `godpowers next --project .`.
+- Added `--json` output for machine-readable status and next-step routing.
+- Dashboard output now reports current phase, tier position, percentage,
+  planning visibility, proactive checks, open items, and recommended action.
+- `/god-status`, `/god-next`, `/god-mode`, and `god-orchestrator` now reference
+  the same dashboard engine when local runtime execution is available.
+- Tests now cover dashboard computation, rendering, CLI output, review queue
+  detection, and git porcelain parsing.
+
+## Platform behavior
+
+Claude Code, Codex, Cursor, Windsurf, Gemini, OpenCode, Copilot, Augment,
+Trae, Cline, Kilo, Antigravity, Qwen, CodeBuddy, and Pi all receive the same
+portable Markdown agent contracts. Codex also receives `god-*.toml` files as
+its registry adapter.
+
+The dashboard engine ships in the installed runtime bundle so host tools can
+use one shared implementation instead of parallel command-specific Markdown
+contracts. If a host platform cannot provide a true fresh-context agent spawn,
+Godpowers must say so visibly and report the work as local runtime only or
+simulated in current context.
+
+## Safety policy
+
+Godpowers may proactively suggest next steps and may run directly evidenced
+local helpers. It may spawn bounded agents only when the current workflow owns
+that surface.
+
+Godpowers still must not auto-run these without explicit user intent:
+
+- deployed staging verification against a guessed URL
+- production launch
+- provider dashboard, admin console, DNS, credential, or secret checks
+- broad dependency upgrades
+- destructive repair, rollback, reset, delete, or cleanup
+- clearing `.godpowers/REVIEW-REQUIRED.md`
+- accepting Critical security findings
+- git stage, commit, push, package, release, or publish
+
+## Validation
+
+Release validation includes:
+
+- `node scripts/test-dashboard.js`
+- `npm test`
+- `npm run test:audit`
+- `node scripts/check-package-contents.js`
+- `git diff --check`
+
+The `v1.6.12` git tag points to the release commit that matches the npm
+`godpowers@1.6.12` package.

package/SKILL.md

@@ -49,6 +49,19 @@ unresolved Critical security findings.
 Every execution agent gets a fresh context window. The orchestrator is thin; it
 spawns workers with full context budgets. This defeats context rot.
 
+Spawning is platform-neutral. Use the host platform's native agent spawning
+mechanism and the installed `agents/god-*.md` contract:
+- Claude Code: spawn the matching Markdown agent from `~/.claude/agents/`.
+- Codex: spawn the matching Codex agent type from `~/.codex/agents/*.toml`;
+  the Markdown copy remains the source contract.
+- Cursor, Windsurf, Gemini, OpenCode, Copilot, Augment, Trae, Cline, Kilo,
+  Antigravity, Qwen, CodeBuddy, and Pi: use the platform's supported agent or
+  subagent mechanism against the installed Markdown files.
+
+When a platform cannot spawn a true fresh-context agent, say so plainly,
+preserve the same role contract, and report `Agent: none, local runtime only`
+or `Agent: simulated in current context` in the visible auto-invoked card.
+
 ### 6. TDD Enforcement
 Tests are written before implementation. Code written before its test is flagged
 and must be rewritten. RED-GREEN-REFACTOR is not optional.
@@ -99,12 +112,28 @@ that edits code or artifacts, do not stop at "complete" plus validation. End
 with a disk-derived closeout that tells the user the current state and what is
 next.
 
+Every closeout must include a **Godpowers Dashboard**. This dashboard is the
+same mental model across `/god-status`, `/god-next`, `/god-mode`, and every
+command that completes, pauses, or proposes work.
+
+When the runtime bundle is available, compute this with
+`lib/dashboard.compute(projectRoot)` and render it with
+`lib/dashboard.render(result)`. The executable dashboard engine is the shared
+source for phase, tier, step, progress, PRD and roadmap visibility, proactive
+checks, open items, and the next route. If the runtime module is unavailable,
+fall back to a manual disk scan and say `Dashboard engine: unavailable, manual
+scan used`.
+
 Use this shape:
 
 ```
+Godpowers Dashboard
+
 Current status:
   State: <complete | partial | blocked | complete with deferred item>
-  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>) when available
+  Phase: <plain-language phase> (tier <human ordinal> of <human total>) when available
+  Step: <sub-step label> (<step n> of <total steps>) when available
+  Progress: <pct>% (<done> of <total> steps complete) when available
   Worktree: <clean | modified files unstaged | staged changes | mixed>
   Index: <untouched | staged files listed>
 
@@ -121,8 +150,18 @@ What changed:
 Validation:
   + <command>: <result>
 
+Proactive checks:
+  Checkpoint: <fresh | refreshed | missing | stale | conflicts with state.json>
+  Reviews: <none | N pending, suggest /god-review-changes>
+  Sync: <fresh | missing | stale | local helper ran | suggest /god-sync>
+  Docs: <fresh | possible drift, suggest /god-docs>
+  Runtime: <not-applicable | known URL, suggest /god-test-runtime | no known URL, defer deployed verification>
+  Security: <clear | sensitive files changed, suggest /god-harden>
+  Dependencies: <clear | dependency files changed, suggest /god-update-deps>
+  Hygiene: <fresh | stale, suggest /god-hygiene>
+
 Open items:
-  1. <deferred staging, unstaged files, pending review, or none>
+  1. <deferred staging, unstaged files, pending review, blocker, or none>
 
 Next:
   Recommended: <one concrete command or user decision>
@@ -136,6 +175,11 @@ pre-existing unrelated changes, say the index was left untouched and recommend
 a scoped review or staging command rather than implying the project is fully
 shipped.
 
+When the command only recommends work, keep the same dashboard but set
+`State: proposal` and end with the proposition block from Section 9. When the
+command pauses, set `State: blocked` or `State: paused` and make `Next` the
+one exact user decision needed to continue.
+
 ### 11. User-Facing Vocabulary
 Godpowers may use internal words such as "arc" in routing, recipes, and agent
 implementation notes. Do not require the user to decode that word in visible
@@ -145,7 +189,7 @@ Use these plain-language substitutions in user-facing responses:
 - Say "project run" or "workflow" instead of "arc".
 - Say "phase" or "current step" instead of "tier" unless the user has asked
   for tier details. If tier detail helps, say both, for example
-  "Planning, Tier 1".
+  "Planning phase, tier 2 of 4".
 - Say "current milestone" or "roadmap step" when ROADMAP.md has a matching
   milestone.
 - If you must use "arc", define it once as "the end-to-end project workflow"
@@ -156,6 +200,103 @@ and roadmap visibility when those files exist or are expected. Show whether
 the PRD is done, whether the roadmap exists, which milestone or tier is active,
 how close the tracked workflow is to completion, and the next concrete move.
 
+### 12. Auto-Invoke Visibility
+When Godpowers automatically runs another command, agent, or local runtime
+helper, show the user what happened. Do not describe these as "background"
+unless they are truly detached from the current run. Most Godpowers sync work
+is auto-invoked but still part of the current workflow.
+
+Use this shape whenever an automatic step runs or is skipped:
+
+```
+Auto-invoked:
+  Trigger: <what caused this automatic step>
+  Agent: <god-updater | god-context-writer | none, local runtime only>
+  Local syncs:
+    + <reverse-sync | pillars-sync | checkpoint-sync | context-refresh>: <result or skipped reason>
+  Artifacts: <changed files, no-op, or deferred>
+  Log: <SYNC-LOG.md, CHECKPOINT.md, REVIEW-REQUIRED.md, or none>
+```
+
+If no agent was spawned, say so plainly:
+
+```
+Agent: none, local runtime only
+Why: this path calls lib/reverse-sync.run directly
+```
+
+Automatic steps that especially need visible reporting:
+- `/god-sync` spawning `god-updater`
+- `god-updater` calling reverse-sync, Pillars sync, checkpoint sync, or
+  AI-tool context refresh
+- `/god-mode` mandatory final sync
+- standards checks between routed stages
+- brownfield and bluefield automatic `/god-preflight`
+- DESIGN/PRODUCT change detection that spawns `god-design-reviewer`
+- `/god-scan` when it runs reverse-sync directly without an agent
+- checkpoint refresh after state mutations
+
+### 13. Proactive Auto-Invoke Policy
+Godpowers should be proactive from disk evidence, not from guesswork. Before
+auto-invoking anything, classify the action by risk and apply the safest
+allowed behavior.
+
+#### Level 1: Auto-suggest, read-only
+Run or apply these by default in every relevant closeout:
+- Compute `/god-next` routing after successful commands.
+- Show `/god-status` style progress after `/god-sync`, `/god-scan`, and
+  `/god-mode`.
+- Suggest `/god-review-changes` when `.godpowers/REVIEW-REQUIRED.md` has
+  pending items.
+- Suggest `/god-hygiene` after a full project run, after 30 days, or when
+  status shows stale docs, deps, or review queues.
+- Suggest `/god-locate` when `.godpowers/CHECKPOINT.md` is missing, stale, or
+  conflicts with `state.json`.
+
+#### Level 2: Auto-run local helpers, visible and logged
+Run these local runtime helpers automatically when their trigger is present:
+- `lib/checkpoint.syncFromState` after every `state.json` or
+  `PROGRESS.md` mutation.
+- Lightweight reverse-sync or linkage scan after code or artifact edits.
+- Pillars sync planning after durable artifact truth changes.
+- Context refresh dry-run after `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`,
+  `.cursor/rules/`, `.windsurfrules`, `.github/copilot-instructions.md`,
+  `.clinerules`, `.roo/`, or `.continue/` changes.
+- Progress recomputation after every command that changes artifacts.
+
+#### Level 3: Auto-spawn scoped specialist agents
+Spawn these agents only when the trigger is direct and scope is bounded:
+- `god-design-reviewer` when `DESIGN.md` or `PRODUCT.md` changed.
+- `god-updater` after feature, hotfix, refactor, build, deploy, observe,
+  launch, harden, docs, upgrade, or dependency workflows change code or
+  artifacts.
+- `god-docs-writer` in drift-check mode when docs changed after code changed,
+  or code changed after docs that claim current behavior.
+- `god-browser-tester` when frontend-visible files changed and a known local,
+  preview, staging, or production URL is evidenced.
+- `god-harden-auditor` suggestion after security-sensitive files changed;
+  auto-spawn only inside `/god-harden`, `/god-hotfix`, `/god-launch`, or
+  `/god-mode`.
+- `god-deps-auditor` suggestion after dependency files changed; auto-spawn only
+  inside `/god-update-deps`, `/god-hygiene`, or an explicitly approved project
+  workflow.
+
+#### Level 4: Explicit approval required
+Never auto-run these from inference alone:
+- deployed staging verification against a guessed URL
+- production launch
+- provider dashboard, admin console, DNS, credential, or secret checks
+- broad dependency upgrades
+- destructive repair, rollback, reset, delete, or cleanup
+- clearing `.godpowers/REVIEW-REQUIRED.md`
+- accepting Critical security findings
+- git stage, commit, push, package, release, or publish
+
+Every auto-invoke decision must be explainable from one of these inputs:
+changed files, Godpowers artifacts, `state.json`, `PROGRESS.md`,
+`CHECKPOINT.md`, `SYNC-LOG.md`, `REVIEW-REQUIRED.md`, routing YAML, recipe YAML,
+or explicit user intent.
+
 ---
 
 ## Operating Modes

package/agents/god-coordinator.md

@@ -134,7 +134,7 @@ For each operation, return to the spawning skill with:
 
 When you need work done IN a repo (version bump, patch slice, etc.),
 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.
+`god-orchestrator` via the host platform's native agent spawning mechanism with only a display-safe pointer.
 
 Per-repo handoff path:
 `.godpowers/runs/<run-id>/COORDINATOR-ORCHESTRATOR-HANDOFF.md`