godpowers 1.6.8 → 1.6.10

package/CHANGELOG.md

@@ -5,6 +5,73 @@ 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.10] - 2026-05-16
+
+Progress visibility and plain-language closeout patch.
+
+### Added
+- Added a core user-facing vocabulary rule: visible output should say
+  "project run", "workflow", "phase", "current step", or "current milestone"
+  instead of unexplained internal "arc" jargon.
+- Added `Planning visibility` blocks to status, next-step, God Mode, and
+  orchestrator closeout guidance. These blocks surface PRD status, roadmap
+  status, current milestone, and completion basis when those artifacts exist or
+  are expected.
+
+### Changed
+- Reworded installer, session-start, `/god`, `/god-mode`, lifecycle, status,
+  routing, workflow, and specialist guidance to use plain project-run language
+  in user-visible text.
+- Checkpoint and session-start summaries now display lifecycle `in-arc` as
+  "in progress" while preserving the internal state key for compatibility.
+- God Mode completion guidance now ends with current status, planning
+  visibility, open items, and a concrete next recommendation.
+
+### Guardrails
+- Internal workflow names and state constants such as `full-arc.yaml` and
+  `in-arc` remain unchanged for compatibility.
+- The patch changes guidance and display wording only. It does not add slash
+  commands, specialist agents, workflows, recipes, schemas, or public artifact
+  formats.
+
+## [1.6.9] - 2026-05-16
+
+Proposal closeout patch. Makes Godpowers end exploratory, diagnostic, audit,
+status, lifecycle, and decision-support answers with concrete choices instead
+of leaving the user to infer the next action.
+
+### Added
+- Added a core Proposal Closeout rule requiring a `Proposition:` block when
+  Godpowers gives a recommendation, proposal, exploratory plan, diagnostic
+  report, status report, audit report, lifecycle report, reconciliation report,
+  or decision-support response without directly launching work.
+- Added proposition closeouts to `/god`, `/god-next`, `/god-status`,
+  `/god-lifecycle`, `/god-locate`, `/god-context-scan`, `/god-preflight`,
+  `/god-doctor`, `/god-audit`, `/god-hygiene`, `/god-standards`, and
+  `/god-agent-audit`.
+- Added proposition closeouts to proposal-heavy planning and analysis commands:
+  `/god-discuss`, `/god-explore`, `/god-list-assumptions`, `/god-refactor`,
+  `/god-spike`, `/god-tech-debt`, `/god-archaeology`, `/god-map-codebase`,
+  `/god-reconstruct`, `/god-design-impact`, `/god-reconcile`, and
+  `/god-roadmap-check`.
+
+### Changed
+- Proposal-style outputs now mirror the clearer GSD 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,
+  full autonomous continuation, discussion, and inspection choices.
+- Diagnostic commands now avoid recommending broad automation when blockers or
+  disk-state inconsistencies make that unsafe.
+
+### Guardrails
+- Pure completion commands can still use their normal `Suggested next` line
+  after a verified artifact is produced.
+- `/god-mode` is not offered as a blanket answer when a blocker, failing gate,
+  manual repair, or unresolved ambiguity should be addressed first.
+- The patch changes guidance only. It does not add slash commands, specialist
+  agents, workflows, recipes, schemas, or public artifact formats.
+
 ## [1.6.8] - 2026-05-16
 
 Staging deferral patch. Keeps Godpowers moving through local and CI-verifiable

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.8-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.10-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,9 +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.8 keeps the stable Godpowers surface while making shipping less
-interruptive: deployed staging verification is deferred until you request
-staging, run deployed verification, or reach final project sign-off.
+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.
 
 It fuses four disciplines into one unified workflow:
 
@@ -57,7 +58,7 @@ Open your AI coding tool in any project directory and type:
 /god-mode
 ```
 
-That's the autonomous arc. It will run all tiers from idea to hardened
+That starts the autonomous project run. It will run all tiers from idea to hardened
 production, pausing only when it has a real question for you.
 
 ### Just describe what you want
@@ -66,7 +67,7 @@ If you don't know which command to run, type free text after `/god`:
 
 ```
 /god production is broken
-/god add a feature without breaking the current arc
+/god add a feature without breaking the current project run
 /god I'm coming back after a week
 ```
 
@@ -106,7 +107,7 @@ when you open a new session in a Godpowers project.
 | Command | What it does | Spawns agent |
 |---------|--------------|--------------|
 | `/god` | Front door: match free-text intent to a command sequence | (built-in) |
-| `/god-mode` | Full autonomous arc | god-orchestrator |
+| `/god-mode` | Full autonomous project run | god-orchestrator |
 | `/god-next` | Auto-detect and suggest the next command | (built-in) |
 | `/god-init` | Start a project, detect mode and scale | (built-in) |
 | `/god-prd` | Write the PRD | god-pm |
@@ -121,7 +122,7 @@ when you open a new session in a Godpowers project.
 | `/god-launch` | Launch (gated on harden) | god-launch-strategist |
 | `/god-harden` | Adversarial security review | god-harden-auditor |
 | `/god-status` | Re-derive state from disk | (built-in) |
-| `/god-preflight` | Read-only intake audit before arc-ready and pillars | god-auditor |
+| `/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 |
 | `/god-review` | Two-stage code review | god-spec-reviewer + god-quality-reviewer |

package/RELEASE.md

@@ -1,11 +1,11 @@
-# Godpowers 1.6.8 Release
+# Godpowers 1.6.10 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.8 keeps shipping work moving when a deployed staging URL is not
-ready yet. The goal of this patch is to finish local and CI-verifiable deploy,
-observe, harden, and launch gates first, then ask for `STAGING_APP_URL` only
-when the user requests staging or reaches final sign-off.
+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.
 
 ## What is stable
 
@@ -24,34 +24,35 @@ when the user requests staging or reaches final sign-off.
 - Extension pack compatibility range for the 1.x line
 - Domain precision through `.godpowers/domain/GLOSSARY.md` and DG-01 through
   DG-05 checks
+- 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
 
-- `god-orchestrator` now documents staging URL deferral as the default shipping
-  closure policy.
-- `/god-mode`, `/god-deploy`, and `/god-launch` now continue through local and
-  CI-verifiable gates when no live deployed origin is evidenced.
-- `god-deploy-engineer`, `god-observability-engineer`, and
-  `god-launch-strategist` now treat missing deployed staging as deferred unless
-  the user explicitly requested staging.
-- Missing deployed access is recorded in
-  `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` with the exact command to
-  run later.
-- At final sign-off, Godpowers offers three clear choices: provide
-  `STAGING_APP_URL=<deployed staging origin>`, sign off local-only with
-  deployed verification deferred, or run `/god-deploy --stage` later.
-
-## What 1.6.8 means
-
-Godpowers 1.6.8 does not expand the public command surface. It changes when
-staging access is requested: not during ordinary mid-arc progress, but at an
-explicit staging request, deployed verification command, or final project
-sign-off.
-
-The release keeps the no-guessed-domain rule intact. Godpowers must not invent
-a staging URL from a product name, brand name, README title, or common TLD.
-If only local URLs exist, it runs local smoke, records deployed verification as
-deferred, and continues.
+- 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.
@@ -61,8 +62,8 @@ Per-repo Quarterback ownership remains intact for Mode D suite work.
 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.8` git tag points to the release commit that matches the npm
-`godpowers@1.6.8` package. Public publishes should prefer the tag-triggered
+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:

package/SKILL.md

@@ -67,11 +67,100 @@ answer a question, inspect first. When a term is resolved, record it in
 `.godpowers/domain/GLOSSARY.md` with canonical spelling, avoided aliases,
 relationships, and any unresolved ambiguity.
 
+### 9. Proposal Closeout
+When you answer with a recommendation, proposal, or exploratory plan and do not
+make file edits, run commands, or hand off to another command, end with a
+proposition block. The block must give the user concrete next moves instead of
+leaving them at a dead stop.
+
+This also applies to diagnostic, status, audit, lifecycle, reconciliation, and
+decision-support reports when they end with suggestions, options, or a
+recommended sequence.
+
+Use this shape:
+
+```
+Proposition:
+  1. Implement partial: <smallest safe slice and command>
+  2. Implement complete: <larger command or project run>
+  3. Discuss more: <focused question or /god-discuss topic>
+  4. Run God Mode: /god-mode <optional flags or scope>
+Recommended: <one option and why>
+```
+
+Only include options that actually fit the situation. If `/god-mode` is too
+broad or unsafe for the request, say so and offer `/god-feature`,
+`/god-refactor`, `/god-spike`, or `/god-discuss` instead.
+
+### 10. Completion Closeout
+When you complete work, especially from `/god-mode`, `/god-build`,
+`/god-feature`, `/god-hotfix`, `/god-refactor`, `/god-quick`, or any command
+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.
+
+Use this shape:
+
+```
+Current status:
+  State: <complete | partial | blocked | complete with deferred item>
+  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>) when available
+  Worktree: <clean | modified files unstaged | staged changes | mixed>
+  Index: <untouched | staged files listed>
+
+Planning visibility:
+  PRD: <done | pending | missing | deferred> <artifact path when present>
+  Roadmap: <done | pending | missing | deferred> <artifact path when present>
+  Current milestone: <roadmap milestone, tier, or next planning gate when known>
+  Completion: <pct>% <brief basis, for example done steps over total tracked steps>
+
+What changed:
+  1. <highest-signal change>
+  2. <highest-signal change>
+
+Validation:
+  + <command>: <result>
+
+Open items:
+  1. <deferred staging, unstaged files, pending review, or none>
+
+Next:
+  Recommended: <one concrete command or user decision>
+  Why: <one sentence tied to current state>
+```
+
+If the command intentionally did not stage, commit, push, or deploy, say that
+plainly and explain what the user can do next. If deployed staging is deferred,
+include the deferred artifact path or exact missing input. If the worktree has
+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.
+
+### 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
+output.
+
+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".
+- 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"
+  and then return to plain language.
+
+Every status, completion, lifecycle, and next-step report should include PRD
+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.
+
 ---
 
 ## Operating Modes
 
-### Mode A: Full Arc (greenfield)
+### Mode A: Full Project Run (greenfield)
 Default. Idea to hardened production. All four tiers, all gates.
 
 ### Mode B: Gap Fill (existing codebase)
@@ -431,7 +520,7 @@ On resume:
 - `--conservative`: Lower threshold for pausing. More human touchpoints.
 - `--from=<tier>`: Start from a specific tier. Re-derives earlier state from disk.
 - `--audit`: Score existing artifacts. Build nothing. Report gaps.
-- `--dry-run`: Plan everything. Build nothing. Show the full arc.
+- `--dry-run`: Plan everything. Build nothing. Show the full project run.
 
 ---
 

package/agents/god-auditor.md

@@ -35,7 +35,7 @@ why.
 6. If running with `mode: preflight`, do not run the artifact linter as the
    main task. Inspect the repo and write `.godpowers/preflight/PREFLIGHT.md`.
 7. If running with `mode: greenfield-simulation`, do not build anything.
-   Simulate the canonical Godpowers greenfield arc and compare it against the
+   Simulate the canonical Godpowers greenfield project run and compare it against the
    current project evidence or org constraints.
 
 ## Mechanical vs interpretive split
@@ -252,16 +252,16 @@ Mode: [brownfield | bluefield]
   bluefield workflows when the user wants the audit acted on.
 - This audit does not treat imported GSD, Superpowers, BMAD, or org context as
   source of truth.
-- This audit does not block the arc unless it finds a Critical security or
+- This audit does not block the project run unless it finds a Critical security or
   impossible planning contradiction.
 ```
 
 Greenfield simulation rules:
 - Brownfield: compare reconstructed artifacts, archaeology, debt assessment,
   repo shape, tests, CI, deploy, observability, hardening, and launch evidence
-  against what the canonical greenfield arc would have created.
+  against what the canonical greenfield project run would have created.
 - Bluefield: compare org context and constraints against the canonical
-  greenfield arc before PRD so downstream agents know which choices are
+  greenfield project run before PRD so downstream agents know which choices are
   constrained, missing, or open.
 - Label every finding as DECISION, HYPOTHESIS, or OPEN QUESTION.
 - Do not invent missing intent. Mark unknowns as OPEN QUESTION.

package/agents/god-coordinator.md

@@ -5,7 +5,7 @@ description: |
   coordination: byte-identical file sync, cross-repo releases,
   meta-linter findings, suite-level state aggregation. NEVER bypasses
   individual orchestrators (the Quarterback rule holds per-repo);
-  spawns per-repo god-orchestrator for arc work inside each repo.
+  spawns per-repo god-orchestrator for project-run work inside each repo.
 
   Spawned by: /god-suite-init, /god-suite-status, /god-suite-sync,
   /god-suite-release, /god-suite-patch
@@ -30,7 +30,7 @@ suite (the collection of repos), not individual repos.
 
 ## What you do NOT do
 
-- Run an arc inside a single repo (that's the per-repo
+- Run a project run inside a single repo (that's the per-repo
   `god-orchestrator`'s job)
 - Make Quarterback-level decisions inside a repo (mode detection,
   scale detection, tier orchestration)
@@ -82,7 +82,7 @@ If a handoff path is provided:
 2. Run impact analysis: which sibling repos depend on this one?
 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)
+   `version-bump` directive (NOT a full project run)
 4. Aggregate results into a release report
 5. Update `.godpowers/suite-config.yaml` version-table
 6. Append to SYNC-LOG.md
@@ -114,7 +114,7 @@ If a handoff path is provided:
   only, you write the `suite.hubPath` field into each newly-registered
   sibling's state.json. Any other field, in any other mode, is the
   per-repo orchestrator's domain.
-- You run a full arc on a sibling (that's beyond your scope)
+- You run a full project run on a sibling (that's beyond your scope)
 - You promote `--strict` byte-identical drift to non-blocking when
   user passed `--strict` (gate must hold)
 - You write `.godpowers/suite-config.yaml` without user confirmation

package/agents/god-deploy-engineer.md

@@ -65,7 +65,7 @@ Build is complete. All tests pass. `.godpowers/build/STATE.md` shows green.
   only when needed by the next command, exact provider links only when a failed
   check proves they are needed, and the command Godpowers will run after access
   exists.
-- Default behavior: do not pause mid-arc only to ask for
+- Default behavior: do not pause mid-run only to ask for
   `STAGING_APP_URL=<staging-origin>`. Record deployed staging as deferred, keep
   the exact smoke command in the waiting artifact, and continue through local
   and CI-verifiable deploy readiness.

package/agents/god-greenfieldifier.md

@@ -63,7 +63,7 @@ The plan must include:
 
 - DECISION: Which findings are safe to action.
 - DECISION: Which artifacts would change.
-- HYPOTHESIS: Why each change better matches the canonical greenfield arc.
+- HYPOTHESIS: Why each change better matches the canonical greenfield project run.
 - OPEN QUESTION: Any product, org, risk, or architecture choice that needs the
   user.
 - A per-artifact impact table for PRD, DESIGN, PRODUCT, ARCH, ROADMAP, STACK,

package/agents/god-launch-strategist.md

@@ -86,7 +86,7 @@ For each channel:
   current. Never infer a launch URL from product name, repo name, package name,
   README title, brand name, or common TLDs.
 - If only production is known, do not treat it as staging. If no deployed
-  origin is known, do not pause mid-arc for the staging URL. Record deployed
+  origin is known, do not pause mid-run for the staging URL. Record deployed
   launch verification as deferred and ask for
   `STAGING_APP_URL=<deployed staging origin>` only when the user requests
   staging or final project sign-off begins.

package/agents/god-observability-engineer.md

@@ -71,7 +71,7 @@ For each PRD success metric, define an SLO:
   verification first.
 - If a credential is truly required, append one exact access item to the single
   waiting access bundle, with the command that will run next. Do not pause
-  mid-arc just to request the deployed staging origin unless the user has
+  mid-run just to request the deployed staging origin unless the user has
   explicitly asked to stage now.
 - Under `/god-mode --yolo`, continue through every local or CI-verifiable
   observability check before pausing for external access.