@1aboveio/skills 0.20.1 → 0.20.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@1aboveio/skills",
-  "version": "0.20.1",
+  "version": "0.20.2",
   "description": "Install the 1AboveIO first-party skill groups through the native Skills CLI.",
   "license": "MIT",
   "type": "module",

package/runtime/skills/distribution/generated/recipes.json

@@ -24,7 +24,7 @@
       "id": "first-party",
       "type": "first-party",
       "package": "@1aboveio/skills",
-      "version": "0.20.1",
+      "version": "0.20.2",
       "updatePolicy": "pinned-npm-version",
       "members": [
         {
@@ -218,7 +218,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -252,7 +252,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -296,7 +296,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -329,7 +329,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -372,7 +372,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -400,7 +400,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -438,7 +438,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -466,7 +466,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -504,7 +504,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -533,7 +533,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -572,7 +572,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -604,7 +604,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime",
@@ -644,7 +644,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime"
@@ -670,7 +670,7 @@
             "sourceId": "first-party",
             "sourceType": "first-party",
             "package": "@1aboveio/skills",
-            "version": "0.20.1",
+            "version": "0.20.2",
             "installPath": null,
             "members": [
               "harness-runtime"
@@ -702,7 +702,7 @@
           "sourceId": "first-party",
           "sourceType": "first-party",
           "package": "@1aboveio/skills",
-          "version": "0.20.1",
+          "version": "0.20.2",
           "installPath": null,
           "members": [
             "harness-runtime",
@@ -756,7 +756,7 @@
           "sourceId": "first-party",
           "sourceType": "first-party",
           "package": "@1aboveio/skills",
-          "version": "0.20.1",
+          "version": "0.20.2",
           "installPath": null,
           "members": [
             "harness-runtime",

package/runtime/skills/engineering/engineering-runtime/scripts/workflow-policy.mjs

@@ -86,7 +86,7 @@ export const WORKFLOW_TRUSTED_SOURCES = deepFreeze({
     id: 'first-party',
     type: 'first-party',
     package: '@1aboveio/skills',
-    version: '0.20.1',
+    version: '0.20.2',
   },
   matt: {
     id: 'matt-pocock',

package/skills/cicd-pipeline/cloud-build/SKILL.md

@@ -361,7 +361,7 @@ gcloud builds triggers create github --name="{service}-prod" \
 
 So under GitHub Flow the SHA-keyed staging verdict is a **pre-filter, not the release gate**. The gate is the prod candidate at 0% traffic, which validates the *exact shipped SHA* on real infrastructure before any user reaches it. That is sound precisely because of the 0%-candidate design — under a deploy-then-smoke pipeline the same topology would ship unvalidated commits straight to users.
 
-**Order is forced: merge first, then tag.** `version.mjs tag` refuses a SHA that is not an ancestor of the production branch, so the release branch cannot be rc-tagged before it lands on `main`. Merge the release PR, then mint the rc on the merge commit. Release-lane sequencing: `resolve-release` step 1.
+**Order is forced: merge first, then tag.** The release tag must name a SHA on the production branch, so the release branch cannot be rc-tagged before it lands on `main`. Merge the release PR, then mint the rc on the merge commit. `rush-release` owns this sequencing.
 
 ## Build Notifications
 
@@ -377,8 +377,8 @@ A "deploy SUCCESS" only proves the revision is `Ready` — not that the real bui
 
 **Where it blocks depends on who the environment serves.** The blocking placement protects *users*, so it belongs on the **production** path. An integration environment (`dev`) has no users to protect — there, a blocking smoke only converts small bugs and infra flakes into failed builds and full rebuild cycles. So the same seam cuts differently per fork, and each fork's contract output is different:
 
-- **`dev` output: a SHA-keyed verdict.** Deploy at 100%, smoke as a non-blocking recorder, publish the verdict as a commit status. Nothing is gated here; the verdict blocks later, at the dev→main promotion, where the release lane pins its candidate to a validated SHA (`resolve-release` principle 11).
-- **prod output: a 0%-traffic candidate revision.** Deploy with `--no-traffic`, surface the revision name and candidate URL, and **stop**. The build does not smoke it and does not shift traffic — `resolve-release` does both.
+- **`dev` output: a SHA-keyed verdict.** Deploy at 100%, smoke as a non-blocking recorder, and publish the verdict as a commit status. When configured as required CI, it helps `rush-release` select the newest green trunk SHA; the production candidate smoke remains the definitive release gate.
+- **prod output: a 0%-traffic candidate revision.** Deploy with `--no-traffic`, surface the revision name and candidate URL, and **stop**. The build does not smoke it and does not shift traffic — `rush-release` does both.
 
 **Why the prod gate moved out of the build.** The gate did not disappear; it moved to where it can be operated:
 
@@ -397,7 +397,7 @@ The prod fork's entire contract is three facts:
 ```
 tag v*-rc.* → build → deploy --no-traffic --tag candidate → publish {revision, url} → END
                                                                     │
-        resolve-release: smoke --profile prod-preview (read-only) ──┤
+          rush-release: smoke --profile prod-preview (read-only) ──┤
                                         ALIVE → update-traffic 100%, tag v<version>
                                         DEAD  → delete the 0% revision (traffic never moved)
 ```
@@ -468,7 +468,7 @@ Because traffic never moved, a DEAD verdict is not a rollback and has no user im
         cat /workspace/candidate.json
 ```
 
-**The `candidate` tag moves; the revision name does not.** Each prod build re-points `--tag=candidate` at its own new revision, so the tag URL always means "the newest candidate," not "the candidate I built." That is why the published JSON carries the **revision name** and why the release lane deletes a failed candidate **by name** — and it is a second reason `resolve-release` principle 7 serializes releases: two candidates in flight would leave the earlier one addressable only by revision, its URL silently repointed at the later build.
+**The `candidate` tag moves; the revision name does not.** Each prod build re-points `--tag=candidate` at its own new revision, so the tag URL always means "the newest candidate," not "the candidate I built." That is why the published JSON carries the **revision name** and why the release lane deletes a failed candidate **by name**. `rush-release` therefore refuses a second release in flight: its moving URL would silently point the earlier release at the later build.
 
 **Surface the coordinates as a GCS object keyed by the RC tag, not as log output.** The release lane already knows the tag it pushed, so it can fetch `candidates/{service}-<rc-tag>.json` without knowing the build ID — no build lookup, no log scraping, and the object outlives log retention. The `cat` at the end is a convenience for humans reading the build, not the interface. Derive the URL from `gcloud run services describe` rather than from `gcloud run deploy` output: the tag URL lives in `status.traffic[]`, and describing the service after the deploy also proves the tag actually landed (the guard above fails the build if it did not).
 
@@ -535,7 +535,7 @@ availableSecrets:
 ```
 
 - After traffic shifts, **confirm the serving revision is running this commit's image**, then run smoke against the live service URL. Capture the exit code instead of letting it fail the step. Compare **images, not revision names** — Cloud Run names revisions from its own counter, so a name-based check silently never matches and degrades to no check at all. On a mismatch, publish `failure` and **run no smoke**: traffic is on older code, so any verdict it produced would be a green light keyed to a SHA that never served.
-- **Publish the verdict as a commit status on the SHA** (context `dev-smoke`, state `success`/`failure`, description naming the broken path on DEAD). This is the artifact the release lane reads: `resolve-release` pins its release candidate to a SHA with green CI **and** `dev-smoke` ALIVE. The image for a SHA is immutable, so the recorded verdict stays valid after `dev` moves on — no re-run at release time.
+- **Publish the verdict as a commit status on the SHA** (context `dev-smoke`, state `success`/`failure`, description naming the broken path on DEAD). When branch protection requires that status, it is part of the green CI set from which `rush-release` selects its trunk SHA. The image for a SHA is immutable, so the recorded verdict stays useful after `dev` moves on; production still gets its own `prod-preview` gate.
 - The step then **exits 0 regardless of verdict**: a DEAD verdict marks the SHA unpromotable; it must not block the next dev iteration.
 - **Non-blocking must not mean silent.** On DEAD, still notify (a Pub/Sub message from the step, or a webhook on the `dev-smoke` status change) so a broken dev is known in minutes, not discovered at release time.
 

package/skills/engineering/engineering-runtime/coherence/workflow.json

@@ -342,7 +342,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "eff6c7b5931bce5b2265a619bccddd371a89df6ce7bc2edc74f11d00060a71dd",
       "digestExcludes": []
@@ -355,7 +355,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "d97abeff7bdc5ae2e4be2f631d09dba46d4753ce1e67334793364329af59f066",
       "digestExcludes": []
@@ -368,7 +368,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "00cfdd3e5bfbc3e37b1369ad93aae91161e671829760a8867ea9be25047ba461",
       "digestExcludes": []
@@ -381,7 +381,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "58b0556228a9271cf9e33727a05fc08a4fdfd29512ec0936b169f0a55d60e6ef",
       "digestExcludes": []
@@ -394,7 +394,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "4664873230f22de2fcf46b7b529570cfedabdc850620031d8f96baf89fcdc5b4",
       "digestExcludes": []
@@ -407,9 +407,9 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
-      "contentDigest": "01c192d8b4fd416af4ea02e8000e5fce0cee723a6ac2f8c0c48372087e1a262e",
+      "contentDigest": "cd9f398f6d8d1df7c2d944d3bec014e788535638014f327783f074757bfb4f49",
       "digestExcludes": []
     },
     {
@@ -420,7 +420,7 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
       "contentDigest": "f048fd00c69f2dc666fc7a3096cfeee6dfba73933bfb69602f3f0e26159798cc",
       "digestExcludes": []
@@ -433,9 +433,9 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
-      "contentDigest": "27861f6dac89c32a97a7d249ce2695cea2d3d80dd2e9bc0607b0c4048a0e3b25",
+      "contentDigest": "d533684db4483cfc90be2aa7161980b6548057ef18a4b54f0cdbcd53c79dd46d",
       "digestExcludes": []
     },
     {
@@ -446,15 +446,15 @@
         "id": "first-party",
         "type": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1"
+        "version": "0.20.2"
       },
-      "contentDigest": "3e0952beee7078463464872943d414fa944b395ae723ec78b385a28a3548897a",
+      "contentDigest": "f7f56f7e33b2b12c3043df0f4729447dfccd181daa79936ff62da38df91d5175",
       "digestExcludes": [
         "coherence/workflow.json"
       ]
     }
   ],
-  "releaseIdentity": "baec385a2bc0414623c97a83ac4ebf3c44ede2654185b748a03ef955cb3f1c8d",
+  "releaseIdentity": "455424f618fddc62d553f7c89282887d6b449b278eb0335b72bf415f760f1b34",
   "lifecycleAuthority": "native-skills-cli",
   "repairRecipe": {
     "id": "engineering-workflow-dependency-first",
@@ -512,7 +512,7 @@
         "sourceId": "first-party",
         "sourceType": "first-party",
         "package": "@1aboveio/skills",
-        "version": "0.20.1",
+        "version": "0.20.2",
         "installPath": null,
         "members": [
           "harness-runtime",
@@ -528,7 +528,7 @@
         "commands": [
           {
             "transport": "npm",
-            "command": "npx @1aboveio/skills@0.20.1 install --group engineering-workflow --yes"
+            "command": "npx @1aboveio/skills@0.20.2 install --group engineering-workflow --yes"
           }
         ],
         "onFailure": {

package/skills/engineering/engineering-runtime/scripts/workflow-policy.mjs

@@ -86,7 +86,7 @@ export const WORKFLOW_TRUSTED_SOURCES = deepFreeze({
     id: 'first-party',
     type: 'first-party',
     package: '@1aboveio/skills',
-    version: '0.20.1',
+    version: '0.20.2',
   },
   matt: {
     id: 'matt-pocock',

package/skills/engineering/rush-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rush-release
-description: "Slash/explicit-only (/rush-release). Cut a GitHub Flow release from main: freeze the latest CI-green trunk SHA, write the changelog, choose SemVer, merge the metadata cut through a verified PR, tag the exact merged main SHA, and watch Cloud Build or npm publish. Do not auto-select. Use only on explicit user/orchestrator invoke. NOT for GitFlow/release-branch/0%-traffic promotion (resolve-release) and NOT for implementing a spec (rush-issues)."
+description: "Slash/explicit-only (/rush-release). Cut a GitHub Flow release from main: freeze the latest CI-green trunk SHA, write the changelog, choose SemVer, merge the metadata cut through a verified PR, publish npm artifacts, or validate a Cloud Run candidate at 0% before shifting it to 100%. One complete-plan confirmation covers the conditional release. Do not auto-select. Use only on explicit user/orchestrator invoke. NOT for GitFlow/release-branch promotion and NOT for implementing a spec (rush-issues)."
 disable-model-invocation: true
 ---
 
@@ -10,9 +10,10 @@ Cut a **GitHub Flow** release from **main**. Freeze one already-green trunk
 SHA, write a metadata-only version cut on that parent, merge it through a
 verified PR, tag the exact merged SHA on `main`, and watch the publisher.
 
-The orchestrator sequences local programs and one confirmation. It does not
-assemble a release branch, shift traffic, or verify production like
-`resolve-release`.
+The orchestrator sequences local programs and exactly one user confirmation per
+release plan. It does not assemble a long-lived release branch. For Cloud Run,
+it owns one bounded candidate-at-0% -> validate -> shift-to-100% -> verify-live
+sequence; the confirmation conditionally authorizes that whole sequence.
 
 ```text
 preflight (main + publisher)
@@ -21,8 +22,9 @@ preflight (main + publisher)
   -> confirm
   -> bump version files + commit the cut
   -> merge metadata PR + verify merged main SHA
-  -> annotated tag on the merged SHA
-  -> push tag -> watch Cloud Build or npm
+  -> npm: final tag -> watch publish
+  -> Cloud Run: rc tag -> candidate at 0% -> validate -> shift to 100%
+     -> verify live -> final tag
 ```
 
 This file is the workflow and index. Read the linked procedure immediately
@@ -33,7 +35,8 @@ before its stage; do not invent an unlinked substitute.
 | Trunk, publisher, version files | [references/preflight.md](references/preflight.md) |
 | Latest CI-green HEAD | [references/candidate.md](references/candidate.md) |
 | Changelog, SemVer, file bump, commit | [references/cut.md](references/cut.md) |
-| Tag, push, watch deploy | [references/publish.md](references/publish.md) |
+| Tag, push, watch publisher | [references/publish.md](references/publish.md) |
+| Cloud Run 0% -> 100%, verification, rollback | [references/promotion.md](references/promotion.md) |
 
 Run every script as
 `node <skillsRoot>/rush-release/scripts/<name>.mjs …` with the absolute skill
@@ -54,8 +57,22 @@ target repo and will not find these files.
   release tree's CI evidence.
 - Tags are immutable annotated `vMAJOR.MINOR.PATCH` names. Do not move, delete,
   or force-push a tag that reached a remote.
-- Show the plan and wait for confirmation before any git mutation or push.
-- A failed watch is a hand-back. This lane does not roll back production.
+- A Cloud Run release uses one immutable `vMAJOR.MINOR.PATCH-rc.N` tag to build
+  the candidate at 0%. The final tag is created only after that exact candidate
+  serves 100% and passes live verification; it must not trigger another deploy.
+- Ask once, on the complete plan, before any git mutation or push. That answer
+  authorizes the listed branch/commit, metadata PR delivery, candidate build,
+  conditional traffic shift, rollback, final tag, optional GitHub Release, and
+  publisher watch as one operation. Do not ask separate cut, merge, RC,
+  exposure, tag, finalization, or publish questions.
+- Preflight facts are detected, not confirmed by the user. Fold any genuinely
+  missing choice into the one plan question instead of asking a preliminary
+  question. If the plan's frozen SHA, version/tag, metadata diff, publisher, or
+  outward actions later change, stop and present one replacement plan; otherwise
+  continue without re-confirming.
+- A pre-exposure failure is a hand-back with production untouched. A known
+  post-exposure failure automatically restores and verifies the recorded
+  incumbent. Ambiguous production state is a stop for operator recovery.
 - The cut is metadata only (changelog + version identity files). Refuse a
   cut that changes product code.
 
@@ -63,8 +80,8 @@ target repo and will not find these files.
 
 ### 1. Preflight
 
-Confirm `main` is the trunk, detect whether the tag should fire Cloud Build,
-npm, or both, and list the files that carry the version. Details:
+Verify `main` is the trunk, detect npm and/or the staged Cloud Run contract,
+and list the files that carry the version. Details:
 [preflight.md](references/preflight.md).
 
 ### 2. Candidate
@@ -72,28 +89,32 @@ npm, or both, and list the files that carry the version. Details:
 Fetch `origin/main` and pick the newest green SHA. Freeze it. Details:
 [candidate.md](references/candidate.md).
 
-### 3. Plan and confirm
+### 3. Plan and confirm once
 
-Derive the changelog and SemVer bump from `baselineTag..frozenSHA`. Show SHA,
-bump, version, tag, files, publisher, and notes. Do not mutate until the human
-confirms. Details: [cut.md](references/cut.md).
+Derive the changelog and SemVer bump from `baselineTag..frozenSHA`. For Cloud
+Run, pass `--cloud-run` so the plan also reserves the next unused RC tag. Show
+SHA, bump, version, tags, files, publisher, notes, and every outward action. Ask one
+question that both settles any unresolved choice and authorizes the whole listed
+sequence. Do not mutate until the human confirms, and do not ask again while the
+approved plan remains unchanged. Details: [cut.md](references/cut.md).
 
 ### 4. Cut
 
 Branch from the frozen SHA, apply the changelog and version files, commit.
 Keep the diff metadata-only.
 
-### 5. Merge, tag, and watch
+### 5. Merge and publish
 
-Push the cut ref, merge its PR through the repository queue, verify the exact
-merged SHA on `main`, create the annotated tag on that SHA, push
-`refs/tags/<tag>` with hook-safe `--no-verify`, then watch Cloud Build and/or
-npm. Details: [publish.md](references/publish.md).
+Push the cut ref, merge its PR through the repository queue, and verify the
+exact merged SHA on `main`. An artifact-only release pushes the final tag and
+watches npm. A staged Cloud Run release pushes its RC tag, executes
+[promotion.md](references/promotion.md), and creates the final tag only after
+live verification. Details: [publish.md](references/publish.md).
 
 ## Done
 
-Success is the confirmed version tagged at the verified merged `main` SHA, the tag visible on the
-remote, and the chosen publisher reporting that version (Cloud Build SUCCESS
-and/or `npm view <pkg>@<version>`). Hand back the cut SHA, merged SHA, tag,
-changelog excerpt, publisher evidence, and the merged metadata PR. A publisher failure hands back the same identities without claiming
-the version shipped to users.
+Success is the confirmed version tagged at the verified merged `main` SHA and
+visible on the remote. npm must report the version when selected. Cloud Run
+must report the exact candidate serving 100%, the incumbent at 0%, and an ALIVE
+`prod-active` verdict. Hand back the cut SHA, merged SHA, RC/final tags,
+changelog excerpt, publisher and traffic evidence, and the merged metadata PR.

package/skills/engineering/rush-release/evals/evals.json

@@ -11,20 +11,21 @@
         "Proposes a minor SemVer bump to 1.5.0 because of feat: export csv.",
         "Includes changelog entries derived from both the feat and the fix.",
         "Tags only the queue-verified merged main SHA whose tree exactly equals the version-cut tree.",
-        "Watches npm publish (npm view) and does not describe a 0% traffic candidate or GitFlow release branch."
+        "Watches npm publish (npm view) and does not describe a 0% traffic candidate or GitFlow release branch.",
+        "Presents one complete-plan confirmation covering cut, PR delivery, tag push, and publisher watch, with no staged confirmations."
       ]
     },
     {
       "id": 2,
-      "prompt": "Dry-run only. Main is protected. Latest green HEAD is 2222222. Plan says v2.0.0 from a breaking change. The metadata PR merges through the queue as 3333333 and its tree exactly equals the approved cut. After you would push tag v2.0.0, Cloud Build returns FAILURE. What do you tag, how do you push it, and what happens after the failed watch? Assume cloudbuild.yaml is present.",
-      "expected_output": "A dry-run that verifies 3333333 is on main and tree-identical to the cut, tags merged SHA 3333333 with annotated v2.0.0, pushes refs/tags/v2.0.0 with --no-verify, watches gcloud builds list, and on FAILURE leaves the tag in place, treats the version as burned, and hands back without deleting the tag or rolling back production.",
+      "prompt": "Dry-run only. Main is protected. Latest green HEAD is 2222222. Plan says v2.0.0 from a breaking change. The metadata PR merges through the queue as 3333333 and its tree exactly equals the approved cut. The repository has a verified Cloud Run staged contract: RC tags deploy immutable candidates with --no-traffic and final tags do not deploy. After you would push v2.0.0-rc.1, Cloud Build returns FAILURE. What do you tag, how do you push it, and what happens after the failed watch?",
+      "expected_output": "A dry-run that verifies 3333333 is on main and tree-identical to the cut, tags merged SHA 3333333 with annotated v2.0.0-rc.1, pushes that fully qualified ref with --no-verify, watches Cloud Build for the RC tag and exact SHA, then on FAILURE leaves the RC tag immutable, keeps v2.0.0 unused, and hands back with production untouched.",
       "files": [],
       "expectations": [
-        "Creates an annotated v2.0.0 tag on the verified merged main SHA 3333333.",
-        "Pushes the fully-qualified tag ref with --no-verify.",
-        "Watches Cloud Build filtered by that tag.",
-        "On FAILURE, does not move or delete the tag and does not roll back production.",
-        "States the next attempt takes a new patch from a new green HEAD."
+        "Creates an annotated v2.0.0-rc.1 tag on the verified merged main SHA 3333333.",
+        "Pushes the fully-qualified RC tag ref with --no-verify.",
+        "Watches Cloud Build filtered by the RC tag and exact merged SHA.",
+        "On FAILURE, leaves the RC tag immutable and production untouched.",
+        "Does not create the final v2.0.0 tag or claim the final version is burned."
       ]
     },
     {
@@ -39,6 +40,19 @@
         "Restarts the changelog and SemVer plan from a new eligible main state before watching Cloud Build and npm.",
         "Does not squash-merge the metadata PR onto moved main."
       ]
+    },
+    {
+      "id": 4,
+      "prompt": "Dry-run only. One complete Cloud Run release plan was already confirmed. Candidate v1.8.0-rc.1 for merged SHA aaaaaaa is at 0%, incumbent revision old-42 is at 100%, and prod-preview is fresh, read-only, and ALIVE. Describe the rest of the release if the shift reaches candidate revision new-43 at 100% but prod-active is DEAD. Do not ask another question.",
+      "expected_output": "A dry-run that rechecks candidate identity and the 0/100 split, shifts under the existing authorization, observes the failed live smoke, automatically restores old-42 to 100%, verifies the restored incumbent with prod-active, leaves v1.8.0 final unused and the RC tag immutable, and hands back without another confirmation.",
+      "files": [],
+      "expectations": [
+        "Does not request a second exposure, rollback, or finalization confirmation.",
+        "Rechecks fresh ALIVE evidence, candidate identity, and candidate 0% / incumbent 100% immediately before shifting.",
+        "Treats prod-active DEAD after the shift as a post-exposure failure.",
+        "Automatically restores old-42 and verifies it at 100% with a prod-active ALIVE result.",
+        "Leaves the final v1.8.0 tag unused and v1.8.0-rc.1 immutable."
+      ]
     }
   ]
 }

package/skills/engineering/rush-release/references/cut.md

@@ -8,10 +8,16 @@ along for the ride.
 ```bash
 node <skillsRoot>/rush-release/scripts/plan.mjs --sha <candidateSha> --json \
   > /tmp/rush-release-plan.json
+# Add --cloud-run when preflight selected cloud-run-staged.
 ```
 
 The plan names `baselineTag`, `currentVersion`, `bump`, `reason`,
-`nextVersion`, `tag`, `changelogMarkdown`, and `versionFiles`.
+`nextVersion`, final `tag`, optional `candidateTag`, `changelogMarkdown`, and
+`versionFiles`.
+
+Before showing the plan, use `git ls-remote --tags origin` to prove the proposed
+candidate and final tags are both unused remotely. Local tag discovery chooses
+the next RC ordinal; remote absence is the collision authority.
 
 SemVer (0.x treats breaking as minor unless the human asks for strict):
 
@@ -26,13 +32,24 @@ Changelog entries come from conventional-commit subjects in
 tag). Keep an existing `## [Unreleased]` body — derived entries merge with it,
 they do not replace it.
 
-## 2. Confirm
+## 2. Confirm once
 
-Show the frozen SHA, proposed version/tag, bump reason, changelog, version
-files, and publisher. Wait for confirmation. A different bump the human names
+Show the frozen SHA, proposed version/tag(s), bump reason, changelog, version
+files, publisher/deployment mode, and the complete outward-action sequence: create the cut
+branch/commit, push it, deliver its metadata PR through the queue, push the
+immutable tag(s), validate and conditionally promote Cloud Run when applicable,
+create a GitHub Release when required, and watch the publisher.
+Ask exactly one question. Its answer both settles any displayed unresolved
+choice and authorizes that entire sequence. A different bump the human names
 wins, as long as it is still SemVer.
 
 Do not create a branch, edit files, or tag before that confirmation.
+After it, proceed through publication without asking separate cut, merge, RC,
+exposure, tag, finalization, or publish questions. Repository/provider checks
+are gates the orchestrator evaluates, not reasons to ask the human to confirm
+facts. Ask again only by replacing the whole plan when its frozen SHA,
+version/tag, metadata diff, publisher, or outward actions change. A retry or
+resume of the unchanged plan inherits the original authorization.
 
 ## 3. Apply and commit
 

package/skills/engineering/rush-release/references/preflight.md

@@ -1,12 +1,15 @@
 # Preflight
 
-Preflight has three outputs: trunk `main`, the publisher to watch, and the
-files that carry the version. It does not pick the SHA, bump the version, or
-push.
+Preflight outputs trunk `main`, publishers, deployment mode, release commands,
+and the files that carry the version. It does not pick the SHA, bump the
+version, or push. Resolve these facts from repository and provider state without asking the
+human to confirm each one. If a required choice cannot be inferred, carry it
+into the single complete-plan question in [cut.md](cut.md); do not create a
+separate preflight confirmation.
 
 ## 1. Trunk
 
-Fetch `origin`. Confirm the release trunk is `main` from those fetched refs
+Fetch `origin/main` and all remote tags. Verify the release trunk is `main` from those fetched refs
 (`origin/main` exists). A repo whose production branch is `master` or `release`
 is not this workflow.
 
@@ -17,12 +20,28 @@ otherwise look at the tree:
 
 | Signal | Publisher |
 |---|---|
-| `cloudbuild.yaml` / `cloudbuild.json`, or a Cloud Build trigger on `v*` / `v*-rc.*` tags | `cloudbuild` |
+| Cloud Build production trigger matching only `v*-rc.*`, whose prod path emits immutable candidate coordinates after `--no-traffic` | `cloudbuild`, mode `cloud-run-staged` |
 | `package.json` with a publish workflow, `publishConfig`, or an explicit npm release | `npm` |
 | both | watch both |
 | neither, and the human did not name one | refuse — nothing to watch |
 
-Record `publisher` as `cloudbuild`, `npm`, or `both`. If a GitHub Actions
+Cloud Build presence alone is not a staged contract. For `cloud-run-staged`,
+verify from repository policy and live trigger configuration:
+
+- the production trigger matches RC tags and excludes the final `vX.Y.Z` tag;
+- each affected service deploys an immutable revision with `--no-traffic` and
+  publishes one receipt binding RC tag, merged SHA, revision, image digest, and
+  candidate URL;
+- `smoke.manifest.json` defines read-only `prod-preview` and `prod-active`
+  profiles with at least one eligible path;
+- exact inspect, traffic-shift, rollback, and candidate-delete commands are
+  documented, including service dependency order;
+- any durable processing affected by a shift has exact pause, quiescence,
+  resume, and restoration checks.
+
+Refuse staged release when any applicable item is absent; never improvise
+production commands. Record `publisher` as `cloudbuild`, `npm`, or `both` and
+`deploymentMode` as `artifact-only` or `cloud-run-staged`. If a GitHub Actions
 workflow publishes on `release: published` rather than on tag push, note that
 `gh release create` is required at publish time.
 

package/skills/engineering/rush-release/references/promotion.md

@@ -0,0 +1,70 @@
+# Cloud Run staged promotion
+
+Promote one immutable candidate from 0% to 100% under the complete-plan
+authorization. Load `smoke` for both validation profiles and the applicable
+platform skill for repository-declared Cloud Run commands. Do not restore the
+archived `resolve-release` state machine or introduce another confirmation.
+
+## 1. Bind the candidate
+
+After the RC-tag build reports `SUCCESS`, read its durable candidate receipt.
+For every affected service, independently verify from one fresh Cloud Run
+snapshot that:
+
+- receipt RC tag and source SHA equal the approved plan and `<mergedSha>`;
+- the named immutable revision runs the receipt's image digest;
+- the candidate URL resolves to that revision;
+- the candidate has exactly 0% traffic and the recorded incumbent exactly 100%;
+- no second release or unknown traffic-bearing revision is in flight.
+
+Missing, duplicate, stale, or contradictory identity is a pre-exposure failure.
+Delete the candidate by immutable revision only when the preflight contract
+declared that deletion safe; otherwise leave it at 0% and hand back. Never move
+the RC tag.
+
+## 2. Validate at 0%
+
+Run the repository's smoke workflow against the exact candidate URL with
+`--profile prod-preview`. Accept only a non-empty `ALIVE` verdict whose stamped
+target is that URL, profile is `prod-preview`, and `noMutations` is `true`.
+Record its `generatedAt`. A failed or unavailable gate leaves production on the
+incumbent and does not consume the final tag.
+
+## 3. Recheck and shift
+
+Immediately before exposure, re-read candidate identity and traffic. Require
+the candidate still at 0%, incumbent still at 100%, and the ALIVE verdict still
+within the plan's declared freshness window. If durable processing is affected,
+run the preflight-declared pause order and prove quiescence before traffic moves.
+
+Shift all affected services to the candidate in the declared dependency order.
+After each command, read traffic back. If a later service cannot shift, restore
+already-shifted services in reverse order before doing anything else. The plan's
+single confirmation already authorized this conditional shift and restoration.
+
+## 4. Verify live
+
+From fresh control-plane and service observations, require for every service:
+
+- the exact candidate revision holds 100% and the incumbent 0%;
+- serving source SHA and image digest equal the candidate receipt;
+- the live URL passes a non-empty, read-only `prod-active` smoke as `ALIVE`.
+
+Resume durable processing only against the verified serving candidate, then
+prove scheduling/admission and any required publication advancement are healthy.
+Only this state permits the final release tag.
+
+## 5. Failure routing
+
+- **Before any traffic moved:** production is untouched. Delete or retain the
+  0% candidate according to the recorded policy and hand back.
+- **After a known failed shift or live check:** automatically restore every
+  service to its recorded incumbent in reverse dependency order, restore
+  durable processing against that incumbent, and verify incumbent 100%,
+  candidate 0%, and `prod-active` ALIVE before hand-back.
+- **Ambiguous traffic, identity, or processing state:** stop all writes and hand
+  back the last known-good evidence for operator recovery. Never guess, retry a
+  shift, delete a revision, or claim rollback succeeded.
+
+The final tag remains unused on every failure path. An RC tag is immutable and
+remains as attempt evidence.

package/skills/engineering/rush-release/references/publish.md

@@ -1,8 +1,16 @@
 # Publish
 
-Push the cut, tag it, and watch the publisher. The tag is the deploy trigger
-in this lane, so a pushed tag that fails to ship **burns the version** — the
-next attempt takes the next patch. Do not move or delete the tag to "reuse" it.
+Push the cut, tag it, and watch the publisher. A pushed final tag that fails to
+publish **burns the version**. A Cloud Run RC tag that fails burns that RC
+ordinal, not the final version. Do not move or delete either tag to "reuse" it.
+
+The complete-plan confirmation in [cut.md](cut.md) already authorizes every
+action in this procedure and [promotion.md](promotion.md). Do not insert another
+confirmation before the branch push, PR queue, candidate validation, traffic
+shift, rollback, tag push, GitHub Release, or publisher watch. A provider or
+repository gate either passes and the sequence continues, or fails and the run
+hands back. If resolving a failure would change the approved identity or action
+set, return to planning and ask once on the replacement plan.
 
 ## 1. Push and merge the metadata PR
 
@@ -27,7 +35,7 @@ documented release path, a successful fast-forward of `<cutSha>` to `main`
 may use `<cutSha>` as `<mergedSha>`. Never infer this from local state: re-fetch
 and verify the remote ref.
 
-## 2. Verify and tag the merged main SHA
+## 2. Verify the merged main SHA
 
 The release tag must name a commit reachable from the remote default branch.
 This is the ancestry gate used by release publishers to refuse off-main
@@ -40,8 +48,6 @@ git merge-base --is-ancestor "<mergedSha>" origin/main
 test "$(git rev-parse "<cutSha>^{tree}")" = \
   "$(git rev-parse "<mergedSha>^{tree}")"
 test "$(git show "<mergedSha>:package.json" | jq -r .version)" = "<nextVersion>"
-git tag -a "<tag>" "<mergedSha>" -m "Release <tag>"
-git push --no-verify origin "refs/tags/<tag>"
 ```
 
 The tree equality check proves the provider merge introduced no post-freeze
@@ -52,6 +58,30 @@ when it is not `package.json`. Re-read the exact required queue/CI result for
 `<mergedSha>` before tagging. A green cut head is not evidence for a different
 merge commit.
 
+## 3. Publish by mode
+
+**Artifact-only:** create and push the final annotated tag on `<mergedSha>`,
+then continue to the publisher watch:
+
+```bash
+git tag -a "<tag>" "<mergedSha>" -m "Release <tag>"
+git push --no-verify origin "refs/tags/<tag>"
+```
+
+**Cloud Run staged:** create and push `<candidateTag>` on `<mergedSha>`. Watch
+Cloud Build until it emits the exact candidate receipt, then execute
+[promotion.md](promotion.md). Only after live verification succeeds, create and
+push the final tag on the same `<mergedSha>`. The final tag must not trigger a
+second Cloud Run build.
+
+```bash
+git tag -a "<candidateTag>" "<mergedSha>" -m "Candidate <candidateTag>"
+git push --no-verify origin "refs/tags/<candidateTag>"
+# After promotion.md succeeds:
+git tag -a "<tag>" "<mergedSha>" -m "Release <tag>"
+git push --no-verify origin "refs/tags/<tag>"
+```
+
 `--no-verify` is for tag refs, because a Mergify (or similar) pre-push hook
 that rewrites `git push` into a stack push is correct for branches and wrong
 for immutable tags.
@@ -64,19 +94,21 @@ If preflight recorded a workflow that publishes only on
 remote (`gh release create <tag> --notes-file …`). Otherwise the tag push is
 the trigger.
 
-## 3. Watch
+## 4. Watch
 
 Launch one background watcher; do not poll in the foreground.
 
-**Cloud Build** (`publisher` `cloudbuild` or `both`):
+**Cloud Build** (`publisher` `cloudbuild` or `both`) is watched first for the RC
+tag and exact merged SHA. `SUCCESS` means only that candidate production
+succeeded; Cloud Run success requires [promotion.md](promotion.md):
 
 ```bash
 gcloud builds list --limit=1 --format='value(id,status,substitutions.TAG_NAME)' \
-  --filter="substitutions.TAG_NAME=<tag> OR tags=<tag>"
+  --filter="substitutions.TAG_NAME=<candidateTag> OR tags=<candidateTag>"
 ```
 
-Success is `SUCCESS` for that tag. `FAILURE` / `TIMEOUT` / `CANCELLED` is a
-hand-back. Load `cloud-debug` only to diagnose, not to rerun the release.
+`FAILURE` / `TIMEOUT` / `CANCELLED` is a hand-back. Load `cloud-debug` only to
+diagnose, not to rerun the release.
 
 **npm** (`publisher` `npm` or `both`):
 
@@ -92,9 +124,10 @@ When a GitHub Actions workflow is the npm publisher, `gh run list` /
 `gh run watch` for the tag SHA is the wait; `npm view` remains the proof the
 artifact exists.
 
-## 4. Failure
+## 5. Failure
 
-If the watch fails, leave the tag in place and hand back: cut SHA, tag,
-publisher logs, and that the version is burned. Do not delete the tag, do not
-roll back production, and do not open a `resolve-release` traffic shift. A
-fix ships as the next patch from a new green HEAD.
+If an artifact watch fails after the final tag, leave it in place and hand
+back that the version is burned. If a staged candidate build fails, leave its
+RC tag, keep the final tag unused, and hand back with production untouched.
+Promotion failures follow [promotion.md](promotion.md). A fix starts from a new
+green HEAD and a replacement plan; tags are never moved or deleted.

package/skills/engineering/rush-release/scripts/plan.mjs

@@ -2,7 +2,7 @@
 // Changelog + SemVer plan from baseline tag..SHA.
 //
 // Usage:
-//   node plan.mjs --sha <sha> [--trunk main] [--json] [--strict]
+//   node plan.mjs --sha <sha> [--trunk main] [--json] [--strict] [--cloud-run]
 //
 // Exit: 0 ok · 1 git/inspect failed · 2 usage
 import { existsSync, readFileSync } from 'node:fs'
@@ -50,6 +50,16 @@ export function latestReleaseTag(tags) {
   return parsed[parsed.length - 1]
 }
 
+export function nextReleaseCandidateTag(finalTag, tags) {
+  const escaped = finalTag.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')
+  const pattern = new RegExp(`^${escaped}-rc\\.([1-9]\\d*)$`)
+  const ordinals = tags
+    .map((tag) => pattern.exec(tag))
+    .filter(Boolean)
+    .map((match) => Number(match[1]))
+  return `${finalTag}-rc.${ordinals.length ? Math.max(...ordinals) + 1 : 1}`
+}
+
 export function classifySubject(subject, body = '') {
   const title = String(subject || '').trim()
   const match = TITLE_RE.exec(title)
@@ -207,9 +217,16 @@ function parseLog(stdout) {
     })
 }
 
-export function planRelease({ sha, trunk = 'main', strict = false, cwd = process.cwd(), now = new Date() } = {}) {
+export function planRelease({
+  sha,
+  trunk = 'main',
+  strict = false,
+  cloudRun = false,
+  cwd = process.cwd(),
+  now = new Date(),
+} = {}) {
   if (!sha) {
-    const err = new Error('usage: plan.mjs --sha <sha> [--trunk main] [--json] [--strict]')
+    const err = new Error('usage: plan.mjs --sha <sha> [--trunk main] [--json] [--strict] [--cloud-run]')
     err.exitCode = 2
     throw err
   }
@@ -230,6 +247,13 @@ export function planRelease({ sha, trunk = 'main', strict = false, cwd = process
   const { bump, reason } = bumpFor(changes, current, { strict })
   const next = nextVersion(current, bump)
   const version = formatVersion(next)
+  const tag = `v${version}`
+  const candidateTag = cloudRun
+    ? nextReleaseCandidateTag(tag, git(['tag', '--list', `${tag}-rc.*`], cwd)
+      .split('\n')
+      .map((line) => line.trim())
+      .filter(Boolean))
+    : null
   const date = now.toISOString().slice(0, 10)
   return {
     trunk,
@@ -239,7 +263,8 @@ export function planRelease({ sha, trunk = 'main', strict = false, cwd = process
     bump,
     reason,
     nextVersion: version,
-    tag: `v${version}`,
+    tag,
+    candidateTag,
     versionFiles: files,
     changes,
     date,
@@ -248,11 +273,12 @@ export function planRelease({ sha, trunk = 'main', strict = false, cwd = process
 }
 
 function parseArgs(argv) {
-  const opts = { json: false, strict: false, trunk: 'main', sha: null }
+  const opts = { json: false, strict: false, cloudRun: false, trunk: 'main', sha: null }
   for (let i = 0; i < argv.length; i += 1) {
     const arg = argv[i]
     if (arg === '--json') opts.json = true
     else if (arg === '--strict') opts.strict = true
+    else if (arg === '--cloud-run') opts.cloudRun = true
     else if (arg === '--sha') opts.sha = argv[++i]
     else if (arg === '--trunk') opts.trunk = argv[++i]
     else if (arg === '--help' || arg === '-h') opts.help = true
@@ -264,7 +290,7 @@ function parseArgs(argv) {
   }
   if (opts.help) return opts
   if (!opts.sha || !opts.trunk) {
-    const err = new Error('usage: plan.mjs --sha <sha> [--trunk main] [--json] [--strict]')
+    const err = new Error('usage: plan.mjs --sha <sha> [--trunk main] [--json] [--strict] [--cloud-run]')
     err.exitCode = 2
     throw err
   }
@@ -274,7 +300,7 @@ function parseArgs(argv) {
 export function main(argv = process.argv.slice(2)) {
   const opts = parseArgs(argv)
   if (opts.help) {
-    process.stdout.write('plan.mjs --sha <sha> [--trunk main] [--json] [--strict]\n')
+    process.stdout.write('plan.mjs --sha <sha> [--trunk main] [--json] [--strict] [--cloud-run]\n')
     return 0
   }
   const result = planRelease(opts)

package/skills/engineering/smoke/SKILL.md

@@ -63,7 +63,7 @@ node <smoke>/scripts/smoke.mjs plan --manifest smoke.manifest.json --profile pro
 
 `--target` is now **just the address to drive against** (the deployed candidate/service URL; defaults to `local`) — it no longer participates in selection. The profile does. For a `local` profile, boot the build yourself the `/verify` way (a `run-*`/`verifier-*` skill in `.claude/skills/`, else the **`run`** skill, else cold-start from README/package.json, timebox ~15 min → BLOCKED); for a deployed profile, point `--target` at the revision and confirm it is the SHA you mean to verify.
 
-**Prod safety is mechanical, and it lives on the profile.** A path runs in a profile only if it declares that profile AND the profile's `mutationPolicy` admits it. The **production profiles (`prod-preview`, `prod-active`) are read-only** — every `mutates:true` path is excluded, **tenant or not** (a synthetic tenant still writes to the real production database, and a revision at 0% traffic is not a reason those writes are safe: `resolve-release` principle 4). `dev-active` allows a `mutates:true` path **only with a declared synthetic tenant**; the local profiles allow isolated writes. This is the old `--no-mutations` flag turned into a property of the *named profile*, so nobody has to remember to pass it — and because one name drives both the run and the verdict, the two **cannot disagree** about the selected set (the old run/verdict flag-mismatch is unrepresentable).
+**Prod safety is mechanical, and it lives on the profile.** A path runs in a profile only if it declares that profile AND the profile's `mutationPolicy` admits it. The **production profiles (`prod-preview`, `prod-active`) are read-only** — every `mutates:true` path is excluded, **tenant or not** (a synthetic tenant still writes to the real production database, and a revision at 0% traffic is not a reason those writes are safe). `dev-active` allows a `mutates:true` path **only with a declared synthetic tenant**; the local profiles allow isolated writes. This is the old `--no-mutations` flag turned into a property of the *named profile*, so nobody has to remember to pass it — and because one name drives both the run and the verdict, the two **cannot disagree** about the selected set (the old run/verdict flag-mismatch is unrepresentable).
 
 **Gate before promote.** On a deployed target the smoke is a gate only if it runs *before* the revision is irreversible — a smoke after traffic shifts is a monitor, not a gate. Deploy the candidate at **0% traffic** (stable, addressable) → smoke that URL under `prod-preview` → **promote only on ALIVE** → confirm the serving revision is the one you smoked, then re-smoke the live service under `prod-active`. Bonus: a DEAD is re-investigable against the same 0%-traffic revision with no rebuild — most of what a deployed smoke catches is config/secret/packaging. **Reuse the platform's deploy notification** (the CI/deploy build-failure → Pub/Sub/webhook path), carrying `smoke-verdict.json` so the alert names the broken path; the concrete placement lives in `cloud-build` / `cloud-deploy`.
 
@@ -82,7 +82,7 @@ node <smoke>/scripts/smoke.mjs verdict --manifest smoke.manifest.json --profile
 ```
 **ALIVE** iff every selected path PASSED. Any `fail`, `blocked`, or `missing` → **DEAD**, naming the path(s). Exit code is the gate (0 = ALIVE, 1 = DEAD). Selection is a pure function of `--profile` + the manifest, so the run and the verdict select the **same** set by construction — there is no second flag assembly for the verdict to disagree with, which is the whole point: the run/verdict mismatch that free-form targeting permitted is now unrepresentable.
 
-`smoke-verdict.json` is stamped with the facts an automated consumer needs to judge the evidence rather than trust it: **`profile`** (the Validation Profile it selected under), **`target`** (which URL it ran against), **`noMutations`** (DERIVED from the profile's `mutationPolicy` — `true` for the read-only production profiles), and **`generatedAt`** (an ISO-8601 instant — *when*, so a consumer can bound how old the evidence is). `resolve-release`'s traffic-shift gate compares these; an ALIVE from the wrong target, a mutating run, or too long ago is not a green light.
+`smoke-verdict.json` is stamped with the facts an automated consumer needs to judge the evidence rather than trust it: **`profile`** (the Validation Profile it selected under), **`target`** (which URL it ran against), **`noMutations`** (DERIVED from the profile's `mutationPolicy` — `true` for the read-only production profiles), and **`generatedAt`** (an ISO-8601 instant — *when*, so a consumer can bound how old the evidence is). `rush-release`'s traffic-shift gate compares these; an ALIVE from the wrong target, a mutating run, or too long ago is not a green light.
 
 **`generatedAt` dates the verdict, not the run.** `verdict` reduces whatever `--results` file you hand it, however old, and stamps the current instant on the result — so re-running `verdict` alone re-mints freshness without re-validating anything, and a consumer bounding the age cannot tell the difference. That is not a substitute for a stale gate's re-check: when what expired is the *evidence about a live target*, re-drive the paths into a new `smoke-results.json` — re-minting a verdict is not re-validation.
 
@@ -113,8 +113,8 @@ The **per-PR golden-path liveness floor** (`ensure-coverage` CI contract, gate 8
 - **CI (gate 8, blocking)** — wired in `e2e-test/assets/ci-gates.*`; boots the app, drives the paths into `smoke-results.json`, runs `smoke.mjs verdict`. The mechanical backstop.
 - **`resolve-issues`** — final step of the [epic integration gate](../resolve-issues/references/deliverables.md#deliverables-the-shippable-component-not-the-whole-epic): boot the assembled integration branch and run the golden paths; a DEAD whose broken paths are `fail` belongs to a specific unit → reopen its fix loop. **A DEAD built from `blocked`/`missing` paths is a gate-environment problem, not a unit's defect** — report it and fix the environment; reopening a fix loop on it spends a producer spawn and an adversarial review on code that is fine, and the round lands in the unit's budget all the same.
 - **`/smoke`** — standalone, any time, against `local` or a URL.
-- **Legacy `resolve-release` flow (archived)** — the `prod-preview` profile against the 0%-traffic candidate URL (read-only, so it excludes every mutating path), then the `prod-active` profile against the live service after the shift. A DEAD **before** exposure deletes the candidate (no rollback, no user impact); a DEAD after it triggers the rollback policy.
-- **The dev-deploy recorder** (`cloud-build` → Post-deploy smoke gate) — the integration pipeline runs this gate after its 100%-traffic deploy and publishes the verdict as a **SHA-keyed commit status**, never failing the build; that recorded ALIVE is what `resolve-release` requires when pinning a release candidate (its principle 11).
+- **`rush-release` Cloud Run flow** — the `prod-preview` profile against the 0%-traffic candidate URL (read-only, so it excludes every mutating path), then the `prod-active` profile against the live service after the shift. A DEAD **before** exposure leaves production untouched; a DEAD after it triggers the recorded rollback policy.
+- **The dev-deploy recorder** (`cloud-build` → Post-deploy smoke gate) — the integration pipeline runs this gate after its 100%-traffic deploy and publishes the verdict as a **SHA-keyed commit status**, never failing the build; when configured as required CI, that recorded ALIVE helps `rush-release` select its green trunk SHA.
 
 ## Reference Map
 

package/skills/engineering/smoke/references/manifest.md

@@ -82,7 +82,7 @@ JSON (`smoke.manifest.json`). A repo may author in YAML and project to JSON —
 | `command` | cli | the command to run, for `cli` paths (alternative to `start`) |
 | `observable` | api/cli | the **concrete thing that proves the path worked** — the 200 body, the exit code. Required for `api`/`cli` (e2e-test doesn't cover them); for `browser` the referenced journey's assertions *are* the observable. |
 | `intent` | no | optional one-line human summary of what the browser journey proves — documentation only, not enforced. |
-| `mutates` | no | `true` if the path writes durable state. Forces a `tenant` and gates it out of read-only profiles. Under a **read-only profile** (any production profile), a tenant grants nothing: every `mutates:true` path is excluded regardless (`resolve-release` principle 4). |
+| `mutates` | no | `true` if the path writes durable state. Forces a `tenant` and gates it out of read-only profiles. Under a **read-only profile** (any production profile), a tenant grants nothing: every `mutates:true` path is excluded regardless. |
 | `tenant` | when `mutates` | a **synthetic/test tenant** id so the mutating path can run under a `synthetic-tenant` profile (e.g. `dev-active`) without touching real data. A `mutates:true` path with no `tenant` is excluded from a `synthetic-tenant` profile. This is **not** a production permit: the production database is real whether or not the revision serves traffic, so the read-only production profiles exclude the path either way. Name it with the **`e2e-` prefix** (`e2e-synthetic`) per the e2e-* account convention (`e2e-test` → `references/authoring/auth-flows.md`) — `validate` warns on an unprefixed tenant, because that's the one mistaken for live data. |
 | `profiles` | **when a `profiles` registry exists** | the [Validation Profiles](#validation-profiles-the-profiles-registry) this path is required in — a non-empty array of names from the registry. A path is only ever selected in a profile it declares; a path that declares none is a silent non-runner, so `validate` **fails closed** on it once a registry is present. (A per-path array, rather than the inverse profile→paths mapping, so a path's selection facts — `mutates`, `tenant`, `profiles` — all sit together on the path they govern.) |
 
@@ -123,11 +123,11 @@ Read-only paths always run in any profile they declare.
 | `prod-preview` | `pre-promotion` | `prod` | `preview` | `read-only` |
 | `prod-active` | `post-promotion` | `prod` | `active` | `read-only` |
 
-`resolve-release` consumes `prod-preview` at step 4a (validate the candidate at 0% traffic) and `prod-active` at step 4b (re-validate the live service after the shift). Each smoke **path** declares the profiles it is required in (`"profiles": ["pr-local", "prod-preview"]`); a path selected by zero eligible paths under a profile yields the existing **EMPTY** verdict — a gate that proves nothing must not look like a pass.
+`rush-release` consumes `prod-preview` before shifting the candidate from 0% traffic and `prod-active` after the shift. Each smoke **path** declares the profiles it is required in (`"profiles": ["pr-local", "prod-preview"]`); a path selected by zero eligible paths under a profile yields the existing **EMPTY** verdict — a gate that proves nothing must not look like a pass.
 
 **Recommended, not mandatory (for now).** A manifest with no `profiles` registry still `validate`s (legacy manifests don't break) but `validate` warns, and `plan`/`verdict --profile` cannot run against it. The moment a registry is present it is fully checked, and every path must declare its profiles.
 
-**Reserved names are pinned to their gate.** The five shipped names are consumed by `resolve-release` (and the other lanes) by **hardcoded string** — step 4a drives `--profile prod-preview`, 4b drives `prod-active` — so the name is itself a safety key, not just a label. `validate` therefore **pins each reserved name to its gate**: `pr-local`→`pull-request`, `queue-local`→`merge-queue`, `dev-active`→`trunk-integration`, `prod-preview`→`pre-promotion`, `prod-active`→`post-promotion`. From the gate, the `(environment, endpoint)` table and the prod-read-only rule force the rest — so an entry *named* `prod-preview` but *bound* to a writable dev gate **fails closed**, instead of letting `plan --profile prod-preview` inherit a `synthetic-tenant` write policy against the production candidate.
+**Reserved names are pinned to their gate.** The five shipped names are consumed by `rush-release` (and the other lanes) by **hardcoded string** — staged promotion drives `--profile prod-preview` before exposure and `prod-active` after — so the name is itself a safety key, not just a label. `validate` therefore **pins each reserved name to its gate**: `pr-local`→`pull-request`, `queue-local`→`merge-queue`, `dev-active`→`trunk-integration`, `prod-preview`→`pre-promotion`, `prod-active`→`post-promotion`. From the gate, the `(environment, endpoint)` table and the prod-read-only rule force the rest — so an entry *named* `prod-preview` but *bound* to a writable dev gate **fails closed**, instead of letting `plan --profile prod-preview` inherit a `synthetic-tenant` write policy against the production candidate.
 
 | Hazard | Failure mode | What to prove |
 |---|---|---|