Launch readiness

launch-readiness

When to use

• A change is about to merge that crosses a release boundary (new feature on main, version bump, public-facing comms attached).
• An ops handoff is implied — the on-call rotation, support team, or downstream consumers need to know.
• A rollback criterion has not been written down yet.

Do NOT use for routine internal merges (finishing-a-development-branch) or for the comms text itself (release-comms). This skill produces the decision to ship and the rollback contract.

Cognition cluster

• Mental model 10 — Reversible vs irreversible. Map every step of the rollout to a reversibility class; the rollback criteria must name the irreversible steps and the abort threshold for each. See docs/contracts/mental-models.md § 10.
• Mental model 29 — Pre-mortems. Imagine the rollout failed in six hours; what failed first? The pre-mortem becomes the rollback criteria, not a separate document. See mental-models.md § 29.
• Mental model 4 — Second-order thinking. Enumerate what becomes harder after the launch (rollback cost, contributor ergonomics, doc churn). See mental-models.md § 4.
• Team + product context-spine slots. Read team for the on-call rotation and ops handoff path; read product for the segment / cohort exposure of the rollout. See context-spine.

Procedure

1. Identify the launch shape

One sentence: "This change ships X to segment Y behind rollout mechanism Z." If you cannot, the change is not release-shaped; route to finishing-a-development-branch.

2. Inspect the pre-merge checklist

Walk the diff with the following gates:

• Tests green on the integration suite (cite the run).
• Quality gates green (static analysis / linters / type-checks).
• Migrations are reversible OR the irreversibility is explicit.
• Feature flag / kill switch named, default off unless intended.
• Doc / changelog / release notes present (hand off to release-comms for the prose).
• Rollback path tested at least mentally; named in step 4.

Cells without evidence block the launch — surface, do not hand-wave.

2b. Epistemics block — the diagnostic report (contract-backed)

For a consumer-facing diagnostic (not just the merge decision), emit a report per docs/contracts/prelaunch-diagnostics.md (schema: prelaunch-report.schema.json). Rules:

• Coverage backbone — diagnose exactly the fixed area vocabulary (prelaunch-areas.yml): auth · migrations · secrets · observability · rollback · agent-governance. No ad-hoc areas.
• Every area gets one state: pass (cited evidence REQUIRED) · finding (IDs listed) · unknown (honest default — absence of findings is Unknown, never an automatic Pass) · not-applicable (reason required).
• Findings carry immutable IDs (AC-<AREA>-NNN) — retitle freely, never re-assign; the ID is the diff key across runs.
• Verdict: any open P0 → NOT ready, regardless of every other area; any open P1 or a launch-gate area not at pass/N-A → NOT ready. Ready is the residual state, never the default.
• Questions section — list the questions that would change the diagnosis; the next run converts them into evidence or findings.
• Validate + verdict via ./scripts-run src/scripts/prelaunch_diagnostics validate <report.json>; regression-gate against the committed baseline via … diff <baseline> <current> --ci (contract § 4–6).

2c. Fix loop (approval-gated, read-only diagnostic)

Rank open findings by severity, then launch-gate membership; propose the safest first approval batch (reversible, small blast radius — explicitly not the full backlog). Status vocabulary per finding: open · fixed · accepted-risk · deferred-with-reason · suppressed-with-evidence · not-applicable — everything except open/fixed carries a reason. Rescore whenever evidence changes. The diagnostic itself never mutates the project; fixes flow through the normal approval-gated engines.

3. Plan the rollout

• Mechanism — flag, canary cohort, blue-green, immediate.
• Order — internal → trusted segment → general; cite the segment per stage from the product spine slot.
• Telemetry — the metric that proves rollout health.
• Owner — named role per stage (not name); from the team spine slot.

4. Write rollback criteria

For each stage:

• Trip wire — the metric value that fires rollback.
• Decision window — how long the trip wire must hold.
• Abort path — what the on-call does (revert PR, flip flag, drain queue), pre-rehearsed.
• Irreversible steps — explicit list; if any irreversible step is in scope, the launch needs a written sign-off, not implicit.

Pre-mortem rule: every trip wire must answer "what would have caused this in six hours?" If you cannot, the trip wire is wrong.

4b. Post-deploy verification fragments (manual checks, not an auto-canary)

Right after deploy, the on-call runs these quick checks by hand. They are checklist items, not an automated canary loop — a real canary is a runtime and out of scope here; these are cheap "did the deploy silently break a thing that doesn't page" probes. Include only the ones that apply to the stack:

• SSE / streaming heartbeat — if the app serves Server-Sent Events or a long-lived stream, confirm a connection stays open and emits a heartbeat past the proxy's idle timeout (a deploy that changes proxy/buffering config silently kills streaming while every other endpoint looks fine).
• Static-asset content-type drift — fetch a built asset and assert the Content-Type (JS as text/javascript/application/javascript, CSS as text/css); a CDN/build change that serves assets as text/plain or application/octet-stream breaks the app in the browser but returns HTTP 200.
• LCP delta — spot-check Largest-Contentful-Paint on the top route against the pre-deploy baseline; a regression beyond the agreed delta is a trip wire even when no error fires.

Each fragment is a one-shot check with a pass/fail an on-call can eyeball; failures feed the § 4 trip wires. Do not build a standing canary service for them.

5. Ops handoff

• Who is paged on which alert (from team spine slot).
• Where the rollback runbook lives (link).
• Date / time of the handoff conversation; sign-off from the receiving role.

6. Hand back

Hand the artefact below to whoever requested the launch decision; route comms to release-comms and post-launch metrics tracking to the team's monitoring stack.

Related Skills

WHEN to use this

• A release-shaped PR is about to merge.
• Rollback criteria need to land in writing before the merge button is pressed.
• Ops handoff is implied and not yet executed.

WHEN NOT to use this

• The change is internal and routine — route to finishing-a-development-branch.
• The output is the public comms — route to release-comms.
• The rollout decision involves stakeholder conflict — route to stakeholder-tradeoff first.
• The decision is reversible-and-cheap — write a one-line note, skip the full artefact.

When the agent should load this

• "Sind wir launch-ready?"
• "Bau mir die Rollback-Kriterien für Phase X."
• "Ops-Handoff für die Release morgen."
• "Was bricht, wenn wir den Flag flippen?"
• "Pre-merge-Checklist für PR #N."

Output

1. Launch shape — one-sentence statement of the change.
2. Pre-merge checklist — gate · status · evidence (citation).
3. Rollout plan — stages × mechanism · order · telemetry · owner.
4. Rollback contract — per stage: trip wire · decision window · abort path · irreversible steps.
5. Ops handoff — pager mapping · runbook link · sign-off.
6. Outstanding — anything blocking the launch; explicit, not collapsed.

Gotcha

• A checklist with all green and no citations is theatre; every green needs an artefact.
• A trip wire without a decision window is unactionable — "if errors spike" is not a trigger; "5xx > 2% for 10 min" is.
• Irreversible steps without written sign-off are the most common post-mortem ancestor — surface, do not skip.

Do NOT

• Do NOT write the comms text here — that is release-comms.
• Do NOT lock the rollback contract verbally — it lives in the output block, citable.
• Do NOT let any stage own itself — every stage names a role from the team spine slot.
• Do NOT hand the artefact to a receiver who has not signed off on ops handoff.