Release Plan

---
name: release-plan
description: |-
  Design a pre-deploy release and rollout strategy: pick the rollout pattern (feature flag, canary, blue-green, or full progressive delivery) by risk and infra, then specify the exposure ramp, the promotion metric and threshold that advances each step, and the rollback trigger and mechanism. Produces RELEASE_PLAN.md. Stack- and infra-agnostic; it designs the rollout, it does not execute it. Gated --godot-mobile and --godot-desktop modes plan a store or desktop ship, both off by default. Use when a change is approaching deploy and needs a deliberate rollout. Do not use for post-deploy live-signal verification (use post-deploy-verifier, which consumes this plan's promotion metric and rollback mechanism), or for a trivial fully reversible change.
metadata:
  category: "planning-and-validation"
  primary-cursor-mode: "Plan"
  multi-repo-aware: "false"
  context-layers-consumed: "memory, retrieved"
  context-layers-produced: "memory"
  tools: "Read, Write, Edit, Bash, Glob, Grep"
  x-wos-profiles: "full"
  provenance: "first-party"
  suggested-model: "claude-sonnet-5-5"
---
> **Output contract, in brief.** This body is over the per-skill re-injection cap, so
> after a compaction the sections below are truncated away while this summary survives.
> They remain authoritative in full; re-read this file before emitting if you need them.
>
> - `Standard output layout (required)`: Produce the command output using this structure (English only):
> - `Artifact changes`: Follow `## Global output contract` in `WORKFLOW_OPERATING_SYSTEM.md` for `APPLIED` / `PROPOSED` / `SKIP` rules. Every listed file...
> - `Command transcript`: Brief audit trail (max 4 lines; max 3 in no-op runs with `NO_OP_TRACE`).
> - `Handoff`: Use the adaptive ending format of `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract`. Every Handoff is one fenced `text` b...
> - `Definition of done (command output)`: RELEASE_PLAN.md exists with the chosen pattern + rationale, an exposure ramp (steps + advance conditions), a promotion metric + th...


Act as a senior release engineer designing how a change reaches production safely, before it ships.

Goal:
Design the pre-deploy rollout strategy so a change is exposed deliberately, advanced on evidence, and reversible on a known trigger, instead of shipped all at once and rolled back by improvisation. The load-bearing differentiator is the per-change rollout design: the pattern chosen by risk and infra, the exposure ramp, the promotion metric that advances each step, and the rollback trigger and mechanism, all decided before deploy. It is distinct from post-deploy-verifier (which verifies live signals AFTER ship and consumes this plan's promotion metric and rollback mechanism) and from the future pipeline-gate-review (which audits whether the standing pipeline even has a safe rollback mechanism). The deliverable is a RELEASE_PLAN.md no other command produces. Use when a slice's scope touches a login, auth, or biometric surface and is approaching merge to main, even for a small-looking change.

Mandatory context bootstrap (before any output):
- Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first:
  - `## LLM execution contract`
  - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mappings.md` and needed only for non-Claude-Code tools)
  - `## Global output contract` (including **Adaptive handoff** and **Mode selection rule**)
  - `## Cross-cutting workflow guardrails`
- **Bootstrap tiers:** the light-weight commands (`branch-commit`, `what-next`, `where-we-at`, `slice-closure`, `compact-task-memory`) plus the high-frequency `implement-approved-slice` and `sync-task-state` (v3 wave1 item D) read the four sections above with two subsections of `## Cross-cutting workflow guardrails` skipped: `### External web access (centralized)` and `### Sequencing heuristics (by phase)`. Everything else is read at every tier, including `### Proposal vs approved persistence` and `### Substrate peer ownership (per ADR-0034)`, since all seven write substrate sections and reason about PROPOSED (`state-reconcile` stays on the full tier for cross-artifact judgment). The full tier is measured at 12109 tokens, the four always-read sections combined; the two skipped subsections are 1,034 of those (measured 2026-09-28), so the reduced tier is about 11,074. The leaf-reviewer tier (`verify-against-rubric`, ADR-0226) reads only `## Global output contract`, measured at 5215 tokens, plus its rubric.
- **Session bootstrap reuse (skip-if-unchanged; v3 wave1 item D):** WHEN this conversation already read the bootstrap sections in an earlier turn still VISIBLE in the context window AND `WORKFLOW_OPERATING_SYSTEM.md` has not changed since, the command MAY skip the re-read and cite the earlier one, emitting one Command transcript line: `Bootstrap: reusing turn <N> read, WOS unchanged`. Scoped exception to the context-budget re-fetch rule (`wos/context-budget.md`, "The re-fetch rule"), because these sections are one large, static, byte-identical read repeated every turn; every other tool result still re-fetches. VISIBLE means the section text itself is still present and quotable now, not merely that a record of the earlier read exists: a harness that clears a tool result while the record survives (ADR-0114) has not satisfied VISIBLE, and self-declared memory after a compaction never qualifies. A stateless-per-turn harness is excluded. The transcript line is mandatory; a silent skip is invalid output.
- **Resolving the spec and `wos/<topic>.md`:** canonical repository FIRST. Otherwise use active-adapter docs: `~/.claude/workflow-docs` (`CLAUDE_WORKFLOW_DOCS_DIR`), `~/.cursor/workflow-docs` (`WORKFLOW_DOCS_DIR`; project `.cursor/workflow-docs` on project installs), `~/.codex/workflow-docs` (`CODEX_WORKFLOW_DOCS_DIR`), or `<kimi-home>/workflow-docs` (`KIMI_WORKFLOW_DOCS_DIR`). Nonempty overrides win. Kimi home: `KIMI_CODE_HOME`, else existing `~/.kimi-code`, else existing `~/.kimi`, default `~/.kimi-code`. Use one root for both paths; try other adapters if absent or unknown. Report resolved root, fallback to other adapters, or missing mandatory context in `### Command transcript`. Installed snapshots refresh and prune retired topics only on sync.
- Read additional sections only when relevant to this command's role.
- Align all routing recommendations and next-command suggestions with the current command set.
- **Official next-command names only:** recommendations, including `Run now`, use registered names from `commands/<name>.md` or `commands/<name>/SKILL.md`; installed mode uses the available Fhorja command or skill inventory. No invented aliases. `Run now: none` with `Mode: N/A` ends only if no honest next step exists, defined under `### Official command names (routing integrity)` (ADR-0126).
Required inputs:
- active task folder path
- TASK_STATE.md
- SOURCE_OF_TRUTH.md
- DECISIONS.md
- IMPLEMENTATION_PLAN.md
- the change under release and its blast radius (user-facing surface, schema/data impact, reversibility)
- the available infra for rollout (feature-flag system, traffic routing, parallel environments, metrics for gating); when absent, the plan degrades to a manual go/no-go
- optional: the SLO_SPEC.md (from slo-define) to use as the promotion-metric basis
- optional: `--godot-desktop` to plan a Godot desktop ship (Windows, macOS, Linux) instead of an infra rollout
- optional: `--godot-mobile` to plan a Godot mobile store ship (Android + iOS) instead of an infra rollout, including the 2026 store-compliance gate (Play Data Safety, target API 36, iOS privacy manifest, ATT, Restore Purchases) (DECISIONS D-5, D-6, ADR-0069; off by default)
- last completed step from TASK_STATE.md (command + summary)

Task repository files to create or update (only if materially changed):
- RELEASE_PLAN.md
- TASK_STATE.md only when state materially changes (per the canonical 5-section write pattern); otherwise prefer `/sync-task-state` after execution

Operating rules:
- **Handoff:** end with the adaptive `### Handoff` block per `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract` (Mode A compact or Mode B full).
- **Substrate write protocol (per ADR-0034, K.2 2026-06-04):** for every write to a substrate section (the 4 task-memory files plus the fleet-substrate files per `wos/substrate-peers.md ## Fleet-substrate files`), emit the transaction header AND append one `.wos/VERIFICATION_LOG.jsonl` line per `commands/_shared/substrate-write-protocol.md`. Enforced, not shadow mode: `scripts/verify-substrate-batch.sh` blocks closure at `slice-closure` and `task-close` (`wos/closure-floors.md`).
- Do not implement code or run a deploy; this command designs the rollout, it does not execute it.
- **Step 1: Gate on a rollout-worthy change.** If the change is trivial and fully reversible with no exposure concern (internal tooling, a copy fix, a pure refactor), STOP and return a SKIP/NO_OP verdict routing to the normal delivery path (branch-commit / pr-package); do not manufacture a rollout plan for a change that does not need one.
- **Step 1.5: Pre-deploy experience-preview gate (site dogfood F3, ADR-0099).** WHEN the rollout ships a deliverable tagged `user-facing-content` or `new-user-facing-surface` (or plainly a user-facing visual surface even when untagged), this release plan SHALL NOT be finalized for deploy without at least one recorded human preview: a cited `## Experience verdict` with `Overall: PASS`, OR a cited preview run the reviewer saw (serve the build per `wos/frontend-preview-and-experience-verdict.md`), OR an explicit one-line skip reason. Machine-green evidence (build exit 0, lint, tests) SHALL NOT substitute. IF none is present THEN classify the release `not ready to deploy`, name the missing preview, and route the operator to produce it before proceeding to Step 2. This moves part of the ADR-0091 experience-verdict floor ahead of the deploy path so a public surface cannot march to deploy-prep with zero human preview (the site-dogfood failure: the flow headed toward domain-attach-equals-announcement before the maintainer had ever seen the site; the human, not the workflow, caught it). WHILE the Godot task signature is present this gate stands down in favor of the D-4 feel-verdict floor at closure.
- **Step 2: Pick the rollout pattern by risk and infra.** Reason over the abstract model (exposure unit, advance signal, rollback action), not a specific vendor: two parallel environments favor blue-green (instant router-flip rollback); fractional traffic routing favors canary; app-level conditionals favor feature flags; reliable live metrics unlock full progressive delivery (metric-gated auto-promote/rollback). A schema or data-shape change needs a flag plus an expand-contract path. Name the chosen pattern and why, mapping each primitive to the consuming repo's actual mechanism (named only from what the repo states, never invented).
- **Step 3: Specify the exposure ramp.** The concrete steps (feature-flag cohort percentages, canary percentages with widening steps, or the blue-green switch point) and who is in the first cohort. Each step has an entry and an advance condition.
- **Step 4: Define the promotion metric and threshold.** The metric and bound that advances each step. WHEN an SLO_SPEC.md exists (from slo-define), use the SLO as the promotion-metric basis; otherwise name the metric and mark its threshold PROPOSED-pending-baseline rather than inventing a number.
- **Step 5: Define the rollback trigger and mechanism.** The observation that triggers rollback and the exact mechanism for the chosen pattern (router flip, flag off, traffic to 0%). This mechanism is what `post-deploy-verifier` consumes for its post-deploy rollback-trigger checklist (per DECISIONS.md D-1).
- **Step 6: Build RELEASE_PLAN.md.** Sections: chosen pattern + rationale, exposure ramp (steps + advance conditions), promotion metric + threshold, rollback trigger + mechanism, and a go/no-go checklist gated before first exposure.
- **Step 7: State the D-1 boundary and route.** In the plan, state that release-plan owns the per-change rollout design; post-deploy-verifier consumes the promotion metric and rollback mechanism for the post-deploy trigger; the standing-pipeline rollback-existence audit is out of scope (reserved for the future pipeline-gate-review). Stage a PROPOSED DECISIONS.md block for any rollout policy that should be locked, and route via Handoff.
- **Godot desktop export-and-ship mode (gated, off by default; ADR-0117 D-9, D-2).** When invoked with `--godot-desktop` (or when the change is a Godot desktop game ship), the RELEASE_PLAN.md becomes a desktop delivery plan rather than an infra rollout or a store submission. **Grounding gap, stated first because it changes how this mode is used:** no source captured in this project covers Windows, macOS, or Linux Godot export. Every step below is a structural prompt, not a documented procedure, and each MUST be marked `[to confirm]` until verified against the engine's export documentation or a real export run; route that verification through `capture-references` rather than filling it in from assumption. Plan: the export targets in scope and the renderer tier each ships (per ADR-0117 D-9 a 3D build states its tier, and Forward+ is the desktop default); the distribution channel and what it implies (a storefront's review and submission requirements, or direct distribution with no review but no update channel either); code signing and notarization per OS, the step most likely to block a first ship; and the rollback mechanism, which for a desktop binary is a previous-version re-publish rather than a traffic shift, so the plan states how a shipped build is pulled or superseded. The mobile mode above stays the authority for Android and iOS; this mode does not duplicate it. Platform posture per ADR-0117 D-2 is desktop-leaning and asymmetric, so a Godot 3D ship reaches this mode by default and the mobile mode by exception.
- **Godot mobile export-and-ship mode (gated, off by default; DECISIONS D-5, D-6, ADR-0069).** When invoked with `--godot-mobile` (or when the change is a Godot mobile game ship in either dimension), the RELEASE_PLAN.md becomes a mobile store-delivery plan with two asymmetric platform paths instead of an infra rollout. Android: install the Android build template, name the version-pinned toolchain (OpenJDK 17, Android SDK Platform 35, Build-Tools 35.0.1, NDK r28b), choose APK (sideload/test) vs AAB (Google Play requires AAB for new apps since August 2021), and surface the re-export gotcha (an app with the same package name but a different signing key must be removed from the device first); Android export is host-OS-flexible. iOS: a hard macOS-plus-Xcode preflight, the App Store Team ID and a reverse-DNS Bundle Identifier, export an `.xcodeproj` then build/deploy in Xcode, and surface the experimental-C#-iOS caveat (since Godot 4.2, per D-6) and the simulator Compatibility-renderer limit. Stay version-flexible (D-5), noting Godot 4.6+ for editor device-mirroring on-device testing. The exposure ramp follows the first-publication or update branch in the Play track ladder below; rollback uses the store controls available for that release type, since a shipped mobile app has no instant router-flip. Before submission, gate on the 2026 store-compliance artifacts: for Google Play, the Data Safety form covering every bundled SDK (one undisclosed SDK blocks the release) and target API level 35; for iOS, the `PrivacyInfo.xcprivacy` privacy manifest with required-reason API declarations, the ATT `NSUserTrackingUsageDescription` string when the app tracks the user, and a Restore Purchases path for non-consumables. When the ship includes in-app purchases or ads, route the entitlement and store checks to the `godot-monetization-integrity` bug-class (server-side purchase verification, acknowledge or consume within three days, reward only on the `user_earned_reward` callback). End with a store-submission go/no-go checklist that includes these compliance artifacts. This mode adds a platform-ship variant; it does not change the default infra-rollout flow, and it invents no device-specific numbers (those defer to `performance-budget`).
  - **Export preflight (checkable, before any store step).** Android: the Play artifact MUST be an AAB (per the captured Godot export doc, all new apps on Google Play after August 2021 must be an AAB; an APK is for sideloading and device testing only), built with the pinned toolchain from that capture (OpenJDK 17, Android SDK Platform-Tools 35.0.0+, Build-Tools 35.0.1, Platform 35, NDK r28b) wired through Editor Settings (Java SDK Path and Android SDK Path). These versions come from the captured `Exporting for Android` reference (accessed 2026-06-29) and MUST be re-verified against the current official docs at execution: pinned versions go stale. The signing gotcha is a MUST rule, not a note: a device build with the same package name but a different signing key MUST be uninstalled from the device before re-export, because a stale-keyed install breaks iterative device testing silently. iOS: the export REQUIRES a macOS host with Xcode, an App Store Team ID, and a Bundle Identifier; it produces an `.xcodeproj` that is built and deployed like any other iOS app; per the captured `Exporting for iOS` reference, C# export is experimental (since Godot 4.2) and the iOS simulator supports only the Compatibility renderer.
  - **Play track ladder and rollout binding.** The store-side release path is Internal testing (up to 100 testers), then Closed testing, then Open testing, then Production; pre-launch reports are the automated pre-release gate. Declare whether this is first publication or an update. For eligible updates, the Production rollout MUST use staged percentages and Android vitals monitoring. Google Play does not permit staged percentages on first publication: document the testing-track preparation, production-launch controls, monitoring, and available recovery mechanism instead, grounded in the current Play documentation. Bind this ladder to the command's existing rollout vocabulary: each track promotion is an exposure-ramp step with a named promotion metric, and the rollback trigger names an available mechanism for that release type; halt a staged rollout only when one exists, and do not imply that a store action removes versions already installed. The iOS store-side path (TestFlight, App Store review, phased release) is a named capture gap: no captured reference grounds it, so the mode MUST NOT specify it from memory; route to `capture-references` first and mark the plan's iOS store-side section blocked on that capture.

Required output:
1. RELEASE_PLAN.md with the chosen pattern + rationale, the exposure ramp, the promotion metric + threshold, the rollback trigger + mechanism, and the go/no-go checklist.
2. The promotion-metric basis: cite the SLO_SPEC when present, or mark the threshold PROPOSED-pending-baseline.
3. The D-1 boundary statement (release-plan designs; post-deploy-verifier consumes; pipeline-gate-review audits the standing pipeline).
4. PROPOSED DECISIONS.md block for any rollout policy to lock; otherwise an explicit "no policy to lock" line.
5. Recommended next command (must exist as `commands/<name>.md` or `commands/<name>/SKILL.md`; verify against directory listing before output). Typical choices: `post-deploy-verifier` (author the post-deploy checks that consume this plan), `decision-interview` (lock a rollout policy), `pr-package` (deliver the change), `slo-define` (when the promotion metric needs an SLO basis first). In installed mode use the available Fhorja inventory.

### Substrate digest fallback
**Digest fallback when the canonical helper is unreachable.** `sha_of_section` extracts a section's body with `awk` and pipes it to `shasum -a 256`. A run executing inside a permission boundary that admits `shasum` but refuses `awk` and `sed` cannot invoke that helper, and MUST NOT reimplement it: an `awk` or `sed` program operand can call `system()` and write files, so a boundary that refuses those verbs refuses them for a reason. Assume the helper is unreachable whenever the workflow repository's `scripts/` directory is not readable from the working directory.

WHERE the canonical per-section digest helper is unreachable, the write SHALL use a whole-file SHA-256 and SHALL declare the reduced scope:

```bash
# One call per file. `shasum -a 256 <file>` needs no extraction step, so no
# refused verb is involved. Read the hash (the first field) out of the output;
# do not pipe it through `cut` or `awk` to trim it.
shasum -a 256 TASK_STATE.md
```

Then add `"sha_scope":"file"` to that JSONL line, so a validator distinguishes a file digest from a section digest instead of inferring it. Everything else about the protocol is unchanged: the transaction header still goes above the section heading, and there is still exactly one JSONL line per section write.

Do NOT rebuild the helper by writing each section out as its own file so it can be hashed separately. That workaround is coherent and it is what this rule exists to prevent: a 2026-08-04 run wrote 31 numbered section fragments to compute per-section digests by hand, spent the whole run doing it, and produced no product code.

What the fallback costs, stated so the trade is explicit rather than discovered later: the digest chain exists to detect an unlogged change to a SECTION. At file scope, two sections written in the same run share a digest, so the chain detects tampering with the file without attributing it to a section. That is a declared reduction in resolution, not a silent one, which is why the `sha_scope` field is mandatory rather than optional.
### Claim grounding (active epistemic humility)
**Claim grounding (active epistemic humility).** This block governs what you may assert and how you record it. It is keyed to the substrate section you are writing, not to which command is running, and it is INERT on any output that writes none of the claim-bearing sections below. Full contract and rationale: `wos/active-epistemic-humility.md`.

1. When this applies. This block fires ONLY while you are writing a claim-bearing substrate section: `TASK_STATE.md ## Current known facts`, `## Risks to watch`, `## Observations`, `## Active files in scope`, `## Canonical decisions`; `DECISIONS.md ## Locked decisions`; `IMPLEMENTATION_PLAN.md ## Current gaps`, `## Risks and mitigations`; `IMPACT_ANALYSIS.md`; `EXTERNAL_RESEARCH.md`; `REFERENCES.md`; or any section whose content is a statement a later command or a human decision will act on. WHEN your output writes none of these, this block imposes nothing: skip it and proceed. This is the D-13 inert clause; a fully-grounded or claim-free output pays nothing.

2. The unit is the load-bearing claim. A load-bearing claim is one a downstream command or a human decision consumes. A passing aside is not load-bearing; a statement someone will act on is. Apply the rest of this block per load-bearing claim, not per sentence.

3. Ground it or abstain. Before you assert a load-bearing claim, trace it to the enumerable grounded set: a captured `REFERENCES.md` entry, a file read in this session, command output actually seen, or a passing deterministic gate. A claim supported only by model memory is OUTSIDE the grounded set, including when you are right, because that support is not observable. WHEN a load-bearing claim falls outside the set, do NOT assert it: either investigate until it is grounded, or abstain per rule 6.

4. Status records provenance, never confidence. WHERE you attach an epistemic status to a claim, the status names WHERE THE CLAIM CAME FROM: a `REFERENCES.md` entry title, a file path plus line, or the gate output it came from. It SHALL NOT express a degree of certainty. Do NOT add a confidence field, a numeric threshold, or a self-assessment prompt anywhere; a self-reported confidence signal is not a usable control signal (`wos/active-epistemic-humility.md` Part 1.3). A status whose referent slot is empty is read as UNKNOWN, not as a weak yes.

5. Persisted claims carry the status; chat-only claims carry it when they route. Every load-bearing claim you write into a task-memory artifact carries its provenance referent, and that referent travels with the claim so a later command reads it too; do not drop it at the write boundary. A load-bearing claim that appears only in a chat-turn output carries a status only when it crosses the grounding boundary and triggers a route (an abstention, an escalation).

6. Abstain as a routed continuation, never a bare refusal. WHEN you abstain, name the specific investigation that would settle the question AND route to the command that runs it (`capture-references`, `code-locate`, `incident-triage`, or the fitting one). A withholding that stalls the work is invalid output. Abstention is distinct from `NO_OP`: `NO_OP` means there is no work to do; abstention means there is work and the grounding to do it is missing.

7. An unfired gate is not evidence. The absence of a fired check does not mean grounding existed. Do not read silence here as a pass.
### Standard output layout (required)
Produce the command output using this structure (English only):

### Artifact changes
Follow `## Global output contract` in `WORKFLOW_OPERATING_SYSTEM.md` for `APPLIED` / `PROPOSED` / `SKIP` rules. Every listed file carries one of those three tokens, in Lean output too; a prose verb like "written" is not a label.

### Command transcript
Brief audit trail (max 4 lines; max 3 in no-op runs with `NO_OP_TRACE`).

### Handoff
Use the adaptive ending format of `WORKFLOW_OPERATING_SYSTEM.md` `## Global output contract`. Every Handoff is one fenced `text` block with all four lines, `Run now:`, `Mode:`, `Work complexity:` and `Reason:`, on a stop and on a refusal too; the terminal form is `Run now: none` with `Mode: N/A`. A new `Mode:`, a model or a fresh session is never a stop, an offered choice is one, and `Reason:` names a role, never a model.
### Definition of done (command output)
- RELEASE_PLAN.md exists with the chosen pattern + rationale, an exposure ramp (steps + advance conditions), a promotion metric + threshold, a rollback trigger + mechanism, and a pre-exposure go/no-go checklist.
- The promotion-metric threshold cites the SLO_SPEC when present, or is marked PROPOSED-pending-baseline; no invented number.
- The rollback mechanism is concrete and named from what the repo actually has; it is the mechanism post-deploy-verifier consumes (D-1).
- The D-1 boundary is stated (designs vs consumes vs standing-pipeline audit); release-plan does not author the post-deploy live-signal checklist itself.
- A trivial reversible change gets a SKIP/NO_OP, not a manufactured rollout plan.
- The command designs the rollout only; it never runs a deploy or a traffic shift.
- The `--godot-desktop` mode (when invoked) produces a desktop delivery plan naming the export targets and the renderer tier each ships, the distribution channel and its implications, code signing and notarization per OS, and the previous-version re-publish rollback mechanism; every step is marked `[to confirm]` because no captured source covers desktop Godot export, and a step presented as documented procedure is invalid output.
- The `--godot-mobile` mode (when invoked) produces asymmetric Android and iOS store-ship paths (toolchain, the iOS macOS+Xcode preflight, AAB/signing/simulator gotchas, version-flexible per D-5, C# iOS caveat per D-6), the export preflight checklist, the Play track ladder with first publication distinguished from updates and bound to applicable promotion and rollback mechanisms, with the iOS store-side named as a capture gap, the 2026 store-compliance gate (Play Data Safety, target API 36, iOS privacy manifest, ATT, Restore Purchases), and a store go/no-go; without the flag the default infra-rollout flow is unchanged, and no device-specific performance numbers are invented.
- Before declaring this output done, confirm it satisfies the shared **Definition of done (command outputs)** and **Gate conditions** in WORKFLOW_OPERATING_SYSTEM.md.

Quality bar:
A load-bearing release plan names a rollout pattern justified by the change's risk and the repo's actual infra, a concrete exposure ramp, a promotion metric that advances each step on evidence, and a rollback trigger with the exact mechanism, so a deploy is reversible on a known signal rather than on improvisation under pressure. The failure mode it prevents is the all-at-once ship with no staged exposure and no agreed abort condition, where a regression reaches every user before anyone decides whether to roll back. It stays stack- and infra-agnostic by reasoning over the abstract rollout model and mapping each primitive to whatever the repo actually has, and it holds the D-1 line: it designs the rollout and hands the post-deploy watch to post-deploy-verifier, never authoring the live-signal checklist or running the deploy itself.