godpowers 1.6.7 → 1.6.8

package/CHANGELOG.md

@@ -5,6 +5,31 @@ 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.8] - 2026-05-16
+
+Staging deferral patch. Keeps Godpowers moving through local and CI-verifiable
+shipping work instead of pausing early for a deployed staging URL.
+
+### Changed
+- `god-orchestrator` now treats deployed staging verification as deferred by
+  default when no live target URL is evidenced and the user did not request
+  staging.
+- `/god-mode`, `/god-deploy`, and `/god-launch` now ask for
+  `STAGING_APP_URL` only when the user explicitly requests staging, invokes
+  deployed verification, or reaches final project sign-off.
+- Deploy, observe, and launch specialists now record missing deployed access in
+  `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` while continuing through
+  local and CI-verifiable gates.
+
+### Guardrails
+- Godpowers still never invents staging or production domains from names,
+  brands, titles, or common TLDs.
+- Provider keys, dashboards, DNS tokens, production secrets, and admin consoles
+  are requested only after a named scripted check proves that exact access is
+  needed.
+- Final sign-off can still run deployed smoke immediately when the user
+  provides `STAGING_APP_URL=<deployed staging origin>`.
+
 ## [1.6.7] - 2026-05-16
 
 Progress visibility patch. Makes Godpowers easier to follow while preserving

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.7-blue)](CHANGELOG.md)
+[![Version](https://img.shields.io/badge/version-1.6.8-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,9 @@ 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.7 keeps the stable Godpowers surface while making the live arc
-easier to follow: progress reports now show percent complete, current step,
-recent work, and what happens next. The orchestrator also documents compact
-"Next step" and "Step result" cards around visible tier/sub-step 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.
 
 It fuses four disciplines into one unified workflow:
 

package/RELEASE.md

@@ -1,10 +1,11 @@
-# Godpowers 1.6.7 Release
+# Godpowers 1.6.8 Release
 
 Date: 2026-05-16
 
-Godpowers 1.6.7 makes the live workflow easier to track. The goal of this
-patch is to answer "what is Godpowers doing, how far along is it, what just
-happened, and what happens next" from disk state.
+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.
 
 ## What is stable
 
@@ -26,36 +27,31 @@ happened, and what happens next" from disk state.
 
 ## What is new
 
-- `lib/state.progressSummary` computes percentage complete, completed step
-  count, total step count, current step number, and current tier/sub-step from
-  `state.json`.
-- `CHECKPOINT.md` can persist progress frontmatter and now includes
-  "What happened recently" and "What happens next" sections.
-- `god-orchestrator` now has a Step Narration Protocol for compact
-  "Next step" and "Step result" cards around visible tier/sub-step work.
-- `/god-mode`, `/god-next`, `/god-status`, and `/god-locate` now document
-  progress, path-ahead, recent-work, and next-action summaries.
-- `templates/PROGRESS.md` now includes a current step plan and recent step
-  result shape.
-- Package publication now allowlists `agents/god-*.md`, preventing local
-  Pillars files under `agents/` from entering the npm payload.
-- Package contents checks now fail if non-specialist files under `agents/`
-  would be published.
-- `AGENTS.md` now includes the Pillars Protocol for loading durable project
-  context and workflow-state files.
-- Installer local mode now resolves runtime destinations under the current
-  directory and installs only `god-*.md` specialist agent files.
-
-## What 1.6.7 means
-
-Godpowers 1.6.7 does not expand the public command surface. It makes the
-existing arc more legible by showing a disk-derived progress report, a short
-plan before visible work starts, and a short result after work completes or
-pauses.
-
-The release also tightens npm packaging around specialist agents. Local
-project Pillars can live under `agents/` during development, but only
-`agents/god-*.md` files are packaged as Godpowers specialist agents.
+- `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.
 
 Safe sync and unresolved Critical harden findings remain release-truth gates.
 Per-repo Quarterback ownership remains intact for Mode D suite work.
@@ -65,8 +61,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.7` git tag points to the release commit that matches the npm
-`godpowers@1.6.7` package. Public publishes should prefer the tag-triggered
+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
 GitHub workflow so npm provenance, git history, and release notes stay aligned.
 
 Allowed changes:

package/agents/god-deploy-engineer.md

@@ -65,11 +65,16 @@ 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 first pause: ask only for `STAGING_APP_URL=<staging-origin>` so the
-  real smoke command can run. Do not ask for provider keys, API tokens,
-  dashboards, DNS tokens, production secrets, admin consoles, or test users
-  until a named deploy, smoke, rollback, health, callback, webhook, export, or
-  observability check cannot run without that exact item.
+- Default behavior: do not pause mid-arc 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.
+- Ask for `STAGING_APP_URL` only when the user explicitly requested deployed
+  staging, invokes `/god-deploy` for deployed verification, or reaches final
+  project sign-off. Do not ask for provider keys, API tokens, dashboards, DNS
+  tokens, production secrets, admin consoles, or test users until a named
+  deploy, smoke, rollback, health, callback, webhook, export, or observability
+  check cannot run without that exact item.
 - Treat a staging or production origin as known only when it appears in direct
   evidence: current user input, env/config values, deployment config, CI
   variable references, IaC output, hosting CLI output, or deployment docs that
@@ -122,6 +127,6 @@ Write `.godpowers/deploy/STATE.md`:
 - Paper canary (label without traffic split)
 - Broad provider checklist with no scripts or exact access bundle
 - Marks deploy done when the only verified target is missing
-- Requests all provider keys before the staging URL smoke check has run
+- Requests provider keys before an exact scripted check proves they are needed
 - Invents or guesses a staging or production domain
 - Treats production as staging without explicit user approval

package/agents/god-launch-strategist.md

@@ -71,7 +71,8 @@ For each channel:
   `.godpowers/observe/STATE.md`.
 - If deploy or observe is waiting on external access, do not create a broad
   dashboard checklist. Reference only the smallest next access item from the
-  waiting bundle and write launch state as `waiting-for-external-access`.
+  waiting bundle and write launch state as local-ready with deployed
+  verification deferred unless the user explicitly requested staging now.
 - If a staging or production URL is available, run or specify the exact smoke
   command and record the result.
 - If only local staging is available, run local launch-readiness checks and
@@ -85,7 +86,10 @@ 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, pause for `STAGING_APP_URL=<deployed staging origin>`.
+  origin is known, do not pause mid-arc 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.
 
 ## Output
 

package/agents/god-observability-engineer.md

@@ -17,7 +17,8 @@ Wire observability.
 
 `.godpowers/deploy/STATE.md` exists. App is deployed and reachable, or deploy
 state documents a tested local staging harness plus a single external access
-bundle.
+bundle. A deferred staging URL must not block observability setup when local or
+CI-verifiable checks can still run.
 
 ## Process
 
@@ -69,7 +70,9 @@ For each PRD success metric, define an SLO:
   Prefer local definitions as code, runbook dry-runs, log-shape checks, and CI
   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.
+  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
+  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

@@ -382,6 +382,14 @@ 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
+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
+`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`, and continue. Ask for
+`STAGING_APP_URL` only when the user requests staging, invokes `/god-deploy`
+or `/god-launch` for deployed verification, or reaches final project sign-off.
+
 For deploy, observe, harden, and launch:
 1. Detect the target environment from deploy config, org context, env files,
    CI config, README, existing scripts, and provider CLIs.
@@ -399,29 +407,41 @@ For deploy, observe, harden, and launch:
      access bundle needed
 5. Under `--yolo`, auto-pick safe defaults for provider-neutral choices and
    continue through every local and CI-verifiable gate.
-6. Only pause when real external access is required and absent. The pause must
-   ask for the smallest next input needed to run the next concrete check. The
-   first pause should usually ask only for the deployed staging origin, for
-   example `STAGING_APP_URL=<staging-origin>`. Do not ask for API keys,
-   provider dashboards, DNS tokens, production secrets, or admin consoles until
-   a specific scripted check cannot run without that exact access.
-7. Do not say "Suggested next" for a blocked shipping tier. Say either
-   `Arc complete` or `PAUSE: external access required`, with the exact artifact
-   that lists the required bundle.
+6. If deployed verification is deferred by default, mark the shipping artifact
+   as local/CI ready and continue. Do not pause for `STAGING_APP_URL` yet.
+7. Only pause when the user explicitly requested deployed staging or final
+   sign-off requires a real deployed check. The pause must ask for the smallest
+   next input needed to run the next concrete check. The first external pause
+   should usually ask only for the deployed staging origin, for example
+   `STAGING_APP_URL=<staging-origin>`. Do not ask for API keys, provider
+   dashboards, DNS tokens, production secrets, or admin consoles until a
+   specific scripted check cannot run without that exact access.
+8. At final sign-off, if deployed verification is still deferred, present:
+   "Local and CI-verifiable closure is complete. Provide
+   `STAGING_APP_URL=<deployed staging origin>` to run deployed smoke now, say
+   `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
+   `PAUSE: external access required`, with the exact artifact that lists the
+   required bundle.
 
 ### External Access Ladder
 
 Use this order when external access is missing:
 
-1. Ask for the deployed staging origin only if no live target URL is known from
-   explicit evidence.
-2. Run the real staging smoke command against that origin.
-3. Ask for a provider key, dashboard, admin console, or test user only when a
+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
+   reached final sign-off.
+2. When staging is requested or final sign-off begins, ask for the deployed
+   staging origin only.
+3. Run the real staging smoke command against that origin.
+4. Ask for a provider key, dashboard, admin console, or test user only when a
    named smoke, callback, webhook, export, observability, or rollback check
    fails or cannot execute without that exact item.
-4. Add at most one new access item per pause unless several items are required
+5. Add at most one new access item per pause unless several items are required
    by the same command invocation.
-5. Every access request must include the command that will run next and the
+6. Every access request must include the command that will run next and the
    artifact that will be updated after it runs.
 
 Never request every possible key or API at the start of shipping. Keys and API
@@ -441,8 +461,10 @@ evidence:
 Never invent domains from the product name, package name, repo name, README
 title, brand name, or common TLDs. Never turn `scriven` into
 `https://scriven.app`, or any similar guessed URL. If only production is known,
-do not call it staging. If only local URLs exist, run local smoke only and pause
-for `STAGING_APP_URL=<deployed staging origin>` before deployed staging smoke.
+do not call it staging. If only local URLs exist, run local smoke only, record
+deployed staging as deferred, and ask for
+`STAGING_APP_URL=<deployed staging origin>` only when staging is explicitly
+requested or final sign-off begins.
 
 ## YOLO Behavior with Design + Linkage
 
@@ -726,8 +748,8 @@ Hide:
 
 When a private rule affects a pause, translate it into the smallest
 user-facing question. Do not expose the rule itself. Example: ask for
-`STAGING_APP_URL=<deployed staging origin>` rather than showing the Shipping
-Closure Protocol.
+`STAGING_APP_URL=<deployed staging origin>` at final sign-off rather than
+showing the Shipping Closure Protocol.
 
 ## Step Narration Protocol
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "godpowers",
-  "version": "1.6.7",
+  "version": "1.6.8",
   "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/skills/god-deploy.md

@@ -27,11 +27,12 @@ After god-deploy-engineer returns:
    - real staging or production target tested
    - local staging harness tested with equivalent health, smoke, and rollback
      commands
-   - paused on `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` with one
-     exact missing access bundle
-4. Update `.godpowers/PROGRESS.md`: Deploy status = done only for a tested real
-   target or tested local staging harness. If external access is missing, mark
-   Deploy = waiting-for-external-access, not done.
+   - local/CI deploy readiness complete with deployed staging verification
+     deferred in `.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`
+4. Update `.godpowers/PROGRESS.md`: Deploy status can be done when a tested
+   real target or tested local staging harness exists. If deployed staging is
+   deferred, annotate Deploy as done-local with the waiting artifact path and
+   do not pause unless the user explicitly requested staging.
 
 ## On Completion
 
@@ -44,11 +45,14 @@ Suggested next: /god-observe (wire SLOs, alerts, runbooks)
 Under `/god-mode --yolo`, do not stop with a provider checklist. Create or
 update the deploy scripts, smoke command, rollback command, health endpoints,
 env manifest, and local staging harness first. If real external access is still
-required, pause on the single access bundle in
-`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md`.
-
-The single access bundle must be incremental. Ask for the smallest next item
-needed to run the next command. If no live target URL is known, ask only for
+required, record the single access bundle in
+`.godpowers/deploy/WAITING-FOR-EXTERNAL-ACCESS.md` and continue until the user
+requests staging or final sign-off begins.
+
+The single access bundle must be incremental. Do not ask for
+`STAGING_APP_URL` mid-arc unless the user requested deployed staging. At final
+sign-off or explicit staging, ask for the smallest next item needed to run the
+next command. If no live target URL is known, ask only for
 `STAGING_APP_URL=<staging-origin>` and the exact smoke command that will run.
 Do not ask for provider keys, API tokens, dashboards, DNS tokens, production
 secrets, admin consoles, or test users until a specific scripted check proves
@@ -59,8 +63,8 @@ values, deployment config, CI variable references, IaC output, hosting CLI
 output, or deployment docs that explicitly label the URL as owned and current.
 Never invent a domain from the product name, repo name, package name, README
 title, brand name, or common TLDs. If only local URLs exist, run local smoke
-only and pause for `STAGING_APP_URL=<deployed staging origin>`. If only
-production is known, do not use it as staging without explicit user approval.
+only, record deployed staging as deferred, and continue. If only production is
+known, do not use it as staging without explicit user approval.
 
 
 ## Re-invocation contract

package/skills/god-launch.md

@@ -52,12 +52,15 @@ Or: /god-status (see the final state)
 Under `/god-mode --yolo`, do not stop by listing provider dashboards. Create
 the launch runbook, smoke command, source attribution plan, and local
 launch-readiness checks. If real launch is blocked by missing external access,
-pause on the single access bundle from deploy or launch state.
+record the single access bundle from deploy or launch state and continue until
+the user requests staging or final sign-off begins.
 
 The launch pause must not expand into every possible channel, analytics, or
 provider credential. Ask only for the next missing access item needed to run a
-named live smoke, launch-readiness, attribution, or monitoring check. If no
-live target URL is known, ask only for `STAGING_APP_URL=<staging-origin>`.
+named live smoke, launch-readiness, attribution, or monitoring check. Do not
+ask mid-arc for `STAGING_APP_URL` unless the user requested deployed staging.
+At final sign-off, if no live target URL is known, ask only for
+`STAGING_APP_URL=<staging-origin>`.
 
 Live target URLs must be evidence-backed. Never invent a domain from the
 product name, repo name, package name, README title, brand name, or common TLDs.

package/skills/god-mode.md

@@ -94,18 +94,20 @@ You are receiving a /god-mode invocation. Your job is to spawn the
        security or a genuine human-only decision.
      - Instruction that deploy, observe, harden, and launch must follow the
        Shipping Closure Protocol: verify a real environment when available,
-       otherwise create local/CI-verifiable deploy automation and pause only
-       for one exact external access bundle.
+       otherwise create local/CI-verifiable deploy automation, defer deployed
+       staging by default, and continue until the user requests staging or the
+       arc reaches final sign-off.
      - Instruction that keys, API tokens, dashboards, admin consoles, and
-       provider-specific access are last-mile inputs. The first external pause
-       should ask only for the smallest next item needed by a concrete command,
-       usually `STAGING_APP_URL=<staging-origin>`. Ask for additional provider
-       access only after a named check proves it is needed.
+       provider-specific access are last-mile inputs. Do not pause mid-arc for
+       `STAGING_APP_URL` unless the user requested deployed staging. At final
+       sign-off, ask only for the smallest next item needed by a concrete
+       command, usually `STAGING_APP_URL=<staging-origin>`. Ask for additional
+       provider access only after a named check proves it is needed.
      - Instruction that staging, preview, and production URLs must come from
        direct evidence. Never infer or invent a domain from project name,
        package name, repo name, README title, or brand name. If no deployed
-       origin is evidenced, pause for
-       `STAGING_APP_URL=<deployed staging origin>`.
+       origin is evidenced, record deployed staging as deferred and continue
+       until staging is requested or final sign-off begins.
      - Instruction that brownfield and bluefield greenfield simulation audits
        must be acted on by god-greenfieldifier. The greenfieldifier writes
        `.godpowers/audit/GREENFIELDIFY-PLAN.md`, pauses before risky canonical
@@ -181,8 +183,8 @@ Hide:
 
 If an internal instruction must influence a pause, translate it into the
 smallest user-facing question. For example, ask for
-`STAGING_APP_URL=<deployed staging origin>` instead of exposing the full
-Shipping Closure Protocol.
+`STAGING_APP_URL=<deployed staging origin>` at final sign-off instead of
+exposing the full Shipping Closure Protocol.
 
 ## Step Cards