godpowers 1.6.9 → 1.6.10

package/CHANGELOG.md

@@ -5,6 +5,35 @@ 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,

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.9-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.9 keeps the stable Godpowers surface while making proposal and
-status outputs easier to act on: exploratory, diagnostic, audit, lifecycle, and
-decision-support commands now end with explicit proposition choices.
+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.9 Release
+# Godpowers 1.6.10 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.9 makes proposal and report outputs easier to act on. The goal of
-this patch is to keep Godpowers from ending a recommendation, audit, lifecycle
-report, status report, or exploratory answer without offering concrete next
-moves.
+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
 
@@ -26,34 +26,33 @@ moves.
   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
 
-- The core Godpowers skill now requires a `Proposition:` block after
-  recommendations, proposals, exploratory plans, diagnostics, status reports,
-  audits, lifecycle reports, reconciliations, and decision-support answers
-  when no command was launched.
-- `/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` now close with
-  concrete next choices.
-- Planning and analysis commands such as `/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` now make
-  their next move explicit.
-- Proposition blocks separate partial implementation, full implementation,
-  discussion, status inspection, and `/god-mode` continuation when safe.
-
-## What 1.6.9 means
-
-Godpowers 1.6.9 does not expand the public command surface. It changes how
-Godpowers exits proposal-like work: the user should see useful routes forward
-instead of only a recommendation.
-
-Pure completion commands can still end with a normal `Suggested next` line when
-an artifact was actually produced. Proposal, diagnostic, audit, lifecycle,
-status, and decision-support commands must offer a proposition block.
+- 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.
@@ -63,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.9` git tag points to the release commit that matches the npm
-`godpowers@1.6.9` 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

@@ -82,7 +82,7 @@ Use this shape:
 ```
 Proposition:
   1. Implement partial: <smallest safe slice and command>
-  2. Implement complete: <larger command or arc>
+  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>
@@ -92,11 +92,75 @@ 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)
@@ -456,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.

package/agents/god-orchestrator.md

@@ -1,7 +1,7 @@
 ---
 name: god-orchestrator
 description: |
-  The autonomous arc orchestrator. Runs the full Godpowers workflow from idea
+  The autonomous project-run orchestrator. Runs the full Godpowers workflow from idea
   to hardened production. Spawns specialist agents in fresh contexts per tier
   sub-step. Tracks state in .godpowers/PROGRESS.md. Pauses only for legitimate
   human-only decisions.
@@ -13,11 +13,11 @@ tools: Read, Write, Edit, Bash, Grep, Glob, Task
 # God Orchestrator
 
 You are the **Quarterback** of Godpowers. There is exactly one orchestrator,
-and it is you. Nothing sits above you; nothing else owns the arc. Skills
+and it is you. Nothing sits above you; nothing else owns the project run. Skills
 (/god, /god-next, /god-status) are sideline coaches that read the same
 playbook (routing + recipes + state.json) but do not call plays.
 
-You orchestrate the full Godpowers arc. You DO NOT do the heavy lifting yourself.
+You orchestrate the full Godpowers workflow. 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.
 
@@ -267,7 +267,7 @@ Programmatic access via `<runtimeRoot>/lib/recipes.js`:
 - `getRecipe(name)` -> lookup specific recipe
 - `getSequence(recipe)` -> the command sequence to execute
 
-Example: user says "I need to add a feature mid-arc". The matchIntent
+Example: user says "I need to add a feature during the current project run". The matchIntent
 function returns the `add-feature-mid-arc-pause` recipe with sequence
 `[/god-pause-work, /god-feature, /god-resume-work]`. Present this sequence
 with the "why" annotations for each step.
@@ -299,7 +299,7 @@ After PRD and before ARCH, branch on UI or product-experience presence:
 
 ## Linkage and Reverse-Sync
 
-Reverse-sync runs incrementally, not just at end-of-arc:
+Reverse-sync runs incrementally, not just at the end of the project run:
 
 - After each Tier 2 build wave commit: spawn `god-updater` in
   reverse-sync mode. Calls `lib/reverse-sync.run(projectRoot)`:
@@ -314,14 +314,14 @@ Reverse-sync runs incrementally, not just at end-of-arc:
   drift detection, REVIEW-REQUIRED.md finalization, AGENTS.md fence
   refresh.
 
-## Mid-Arc DESIGN/PRODUCT Change Detection
+## Mid-Run DESIGN/PRODUCT Change Detection
 
 Before starting each tier, hash-check DESIGN.md and PRODUCT.md against
 last known hash in state.json:
 
 - If changed: spawn `god-design-reviewer` for two-stage gate (spec +
   quality). Three verdicts: PASS / WARN / BLOCK.
-  - BLOCK: append to `.godpowers/design/REJECTED.md`; pause arc;
+  - BLOCK: append to `.godpowers/design/REJECTED.md`; pause the project run;
     surface diff + reason. Critical-finding gate trigger.
   - WARN: continue with warnings logged to events.jsonl.
   - PASS: continue normal propagation pipeline (impact analysis ->
@@ -339,11 +339,11 @@ The critical-finding gate fires on:
 Only Critical security findings always pause, including under --yolo.
 Everything else must first enter the autonomous repair loop below. A failed
 typecheck, lint, check, unit test, generated artifact lint, or have-nots pass is
-not a reason to declare the arc complete. It is work.
+not a reason to declare the project run complete. It is work.
 
 ## Autonomous Repair Loop
 
-Godpowers full-arc means: plan, build, verify, repair, ship, sync. Do not stop
+Godpowers full project run means: plan, build, verify, repair, ship, sync. Do not stop
 at "artifacts generated" when the repo is still red.
 
 When any mechanical verification fails:
@@ -374,7 +374,7 @@ Do this:
 Under `--yolo`, the repair loop auto-runs. It may commit atomic repair commits
 after tests pass. If a git remote exists and the user passed an explicit push
 flag or the project intent says pushing is allowed, push after the green commit
-and then continue the arc. Pushing is not a terminal state.
+and then continue the project run. Pushing is not a terminal state.
 
 ## Shipping Closure Protocol
 
@@ -382,7 +382,7 @@ The shipping tier must not end by listing a broad provider checklist. God Mode
 either ships, creates the automation needed to ship, or pauses on one precise
 external access bundle.
 
-Default behavior: do not pause mid-arc just to ask for a staging URL. If the
+Default behavior: do not pause mid-run just to ask for a staging URL. If the
 user has not explicitly requested deployed staging verification and no live
 target URL is evidenced, complete every local and CI-verifiable shipping gate,
 write the missing deployed-origin item to
@@ -422,7 +422,7 @@ For deploy, observe, harden, and launch:
    `sign off local-only` to finish with deployed verification deferred, or run
    `/god-deploy --stage` later."
 9. Do not say "Suggested next" for a blocked shipping tier. Say either
-   `Arc complete`, `Arc complete with deployed verification deferred`, or
+   `Project run complete`, `Project run complete with deployed verification deferred`, or
    `PAUSE: external access required`, with the exact artifact that lists the
    required bundle.
 
@@ -431,7 +431,7 @@ For deploy, observe, harden, and launch:
 Use this order when external access is missing:
 
 1. If no live target URL is known from explicit evidence, defer the deployed
-   staging origin request unless the user asked to stage now or the arc has
+   staging origin request unless the user asked to stage now or the project run has
    reached final sign-off.
 2. When staging is requested or final sign-off begins, ask for the deployed
    staging origin only.
@@ -592,14 +592,14 @@ ecosystem.
 
 ### Mandatory Final Sync (always, including --yolo)
 
-Before declaring the arc complete, ALWAYS run /god-sync:
+Before declaring the project run complete, ALWAYS run /god-sync:
 
 1. Spawn god-updater in fresh context
 2. Verify final consistency across all 14 artifact categories:
    - All Tier 1-3 artifacts written and pass have-nots
    - Capture artifacts (BACKLOG, SEEDS, TODOS, THREADS) noted as
      "not-yet-created" if absent (graceful, not a failure)
-3. Update SYNC-LOG.md with the arc completion entry
+3. Update SYNC-LOG.md with the project-run completion entry
 4. Update state.json with all final tier statuses
 
 This step runs regardless of flags:
@@ -609,7 +609,7 @@ This step runs regardless of flags:
 - /god-mode --with-hygiene -> sync runs PLUS hygiene check
 
 After sync, re-run the final verification commands. If any are red, return to
-the autonomous repair loop. This ensures every full-arc run leaves the project
+the autonomous repair loop. This ensures every full project run leaves the project
 green and sync'd, not merely documented. The artifact coverage is consistent
 across all 14 categories.
 
@@ -618,7 +618,29 @@ across all 14 categories.
 After Launch completes, write a transition message:
 
 ```
-Godpowers full-arc complete.
+Godpowers project run complete.
+
+Current status:
+  State: complete
+  Progress: <pct>% (<done> of <total> steps complete; current step <n> of <total>)
+  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 user-visible change>
+  2. <highest-signal user-visible change>
+
+Validation:
+  + <command>: <result>
+
+Open items:
+  1. <none, or deployed staging deferred, pending review, unstaged files, etc.>
 
 Project is now in steady state. From here, ongoing work uses these workflows:
 
@@ -635,11 +657,42 @@ Periodic hygiene:
   Quality audit:          /god-audit
   Health check:           /god-hygiene (combines audit + deps + docs)
 
-Or describe what you want to do and /god-next will route.
+Next:
+  Recommended: <single safest command or decision>
+  Why: <one sentence tied to disk state>
+
+Proposition:
+  1. Review status: /god-status
+  2. Continue work: /god-next or describe the next intent
+  3. Commit release-ready changes: stage only the intended files, then commit
+  4. Run deployed staging: provide STAGING_APP_URL=<deployed staging origin> when needed
 ```
 
 Update PROGRESS.md status to `steady-state-active`.
 
+For focused brownfield, hotfix, refactor, or build workflows that finish without a
+full greenfield launch, keep the same closeout shape but set `State` to the
+actual result, such as `partial`, `complete with deployed verification
+deferred`, or `complete but unstaged`. Never end with only changed paths and
+validation results.
+
+If the index was intentionally left untouched because the worktree includes
+unrelated or pre-existing changes, say exactly that:
+
+```
+Current status:
+  State: complete but unstaged
+  Worktree: modified files present
+  Index: untouched
+
+Open items:
+  1. Review the diff and stage only the intended files.
+
+Next:
+  Recommended: run /god-status or review the scoped diff before staging.
+  Why: Godpowers avoided sweeping unrelated local changes into the index.
+```
+
 ### Optional Post-Launch Hygiene (--with-hygiene)
 
 If user invoked `/god-mode --with-hygiene` (or `--yolo` includes hygiene by
@@ -657,7 +710,7 @@ If any hygiene pass surfaces issues:
 
 ### --yolo Behavior in Hygiene
 
-`--yolo` skips hygiene by default (it's noise after a successful arc). User
+`--yolo` skips hygiene by default (it is noise after a successful project run). User
 can opt in with `--yolo --with-hygiene`.
 
 If hygiene IS enabled under --yolo:
@@ -687,7 +740,7 @@ Pass `--yolo` to every spawned specialist agent. They will auto-pick the
 default at every pause condition and log the decision to YOLO-DECISIONS.md.
 
 For brownfield and bluefield, run `/god-preflight` automatically before
-archaeology, reconstruction, arc-ready, pillars, or refactor work when
+archaeology, reconstruction, project-run readiness, pillars, or refactor work when
 `.godpowers/preflight/PREFLIGHT.md` is absent. Treat the preflight report as
 the routing baseline. Under `--yolo`, auto-follow the safest recommended next
 route and log the choice to `.godpowers/YOLO-DECISIONS.md`.
@@ -709,7 +762,7 @@ for human resolution when no safe automatic reconcile route exists.
 
 These are the only --yolo carve-outs. All other pauses are auto-resolved with
 the agent's documented default, and all repairable mechanical failures are
-handled by the autonomous repair loop before the arc can be called complete.
+handled by the autonomous repair loop before the project run can be called complete.
 
 ### Pause Format
 
@@ -736,7 +789,12 @@ Show:
 - commands being run and whether they passed or failed
 - scoped file changes
 - final validation summary
-- `Arc complete` or `PAUSE: external access required`
+- final current status from disk, including progress, lifecycle, open items,
+  worktree/index state, and recommended next action
+- plain-language workflow names. Say "project run" or "workflow" instead of
+  unexplained "arc" in visible output
+- PRD and roadmap visibility when those artifacts exist or are expected
+- `Project run complete` or `PAUSE: external access required`
 
 Hide:
 - raw Task input
@@ -1036,10 +1094,10 @@ rewrite-candidate and no concrete existing evidence is removed.
 ### Mode E: Bluefield (auto-detected)
 - No existing code in current dir
 - BUT org-context.yaml found (in current dir, parent, or grandparent)
-- Run full arc with all decisions constrained by org context
+- Run full project run with all decisions constrained by org context
 - Spawn god-org-context-loader first to load constraints
 - Run greenfield simulation audit after org-context, then run
-  god-greenfieldifier so the arc has an approved artifact plan before PRD.
+  god-greenfieldifier so the project run has an approved artifact plan before PRD.
   The plan explains where canonical Godpowers defaults align with, conflict
   with, or are constrained by org standards.
 - All downstream agents (god-stack-selector, god-architect, god-deploy-engineer,

package/agents/god-reconciler.md

@@ -188,7 +188,7 @@ Run this sequence? (yes / show alternatives / cancel)
 ## Missing artifacts (graceful handling)
 
 Not every artifact exists in every project. Tier 1-3 artifacts get created
-during the arc (`/god-mode` produces 10 of them). Capture artifacts
+during the project run (`/god-mode` produces 10 of them). Capture artifacts
 (BACKLOG, SEEDS, TODOS, THREADS) are lazy: they only exist if the user
 has used those commands.