Release Status

A read-only snapshot of release state across all letterbox services. This is the passive sibling of /release-manager — it shows the same picture but takes no action and asks no questions. Safe to run anytime.

When to Use

• A quick "what's the release situation right now" glance
• Before starting a /watch-release loop, to see the baseline
• To sanity-check what /release-manager would act on, without being prompted

For the interactive version that prompts to push / defer / cancel and auto-files CI-failure beads, use /release-manager. For a deep gate on one service, use /ready-to-release <service>.

Usage

/release-status                 # all services
/release-status dispatch        # one service

Instructions

1. Gather. Run the shared mechanical digest (pass through any service arg to scope it):

   ./scripts/release-digest        # git + ci + deploy + toggles, one parsed result

Parse the delimited sections (already ANSI-free):

• ---META---: context=<kubectl ctx>, ci=<available|unavailable> — when ci=unavailable

(no CIRCLECI_TOKEN/.env.circleci) every ci field is unknown; show it as such.

• ---SERVICES---: one pipe-delimited line per service after the header line:

service|unpushed|uncommitted|ci|ciBranch|gitBranch|head|deploy|tag|age.

• unpushed (int, commits ahead of origin), uncommitted (true|false), head = short

sha of the current local HEAD (- if no checkout).

• ci ∈ success|failed|running|error|unknown; ciBranch/gitBranch are the pipeline branch

and the repo's current branch.

• deploy = a Deployment's <ready>/<desired> (1/1 = rolled out; N/M, N<M = rolling out;

0/1 = failing); for CronJob-backed services (digest, patrol, reconciler) it's a marker: cron = settled / rolled out, cron:rollout = images differ (Flux mid-bump). Also notfound/unknown (e.g. no kubectl). tag/age = live image tag + pod-or-run age.

• ---TOGGLES---: FLAG=value lines — compact by default: only false-valued and

manifest-referenced (toggles:/parked:) flags, with a trailing # compact: … summary of what was hidden. This covers the TOGGLE READY cross-reference (manifest flags show at any value; everything still-false is present). For the full map run ./scripts/release-digest --full-toggles; for disabled-only, make feature-toggles-disabled.

1. Read the manifest at docs/release-manifest.yaml for the order block

(derived / manual / suppress), the toggles map, and the ignore list. The effective dependency map = (derived ∪ manual) − suppress.

2b. Scan dependencies + contract coverage (both read-only, no tokens/network):

   ./scripts/pact-graph              # dependency ordering authority
   ./scripts/contract-check coverage # CI verification coverage

Both are project symlinks installed by their owning skills — pact-graph by /release-manager (see its Setup), contract-check by /contract-check.

From pact-graph parse:

• ---GRAPH--- — consumer: [providers], derived live from pact filenames.
• ---DRIFT--- — status: in-sync, or new:/removed: edge lines = the manifest's

order.derived block no longer matches the pacts.

From contract-check coverage parse the GAP/OK lines: a GAP <provider> … not-verified=… means that provider's CI doesn't verify all its synced consumer contracts. (Contract health lives in /contract-check, not pact-graph — the dependency graph is purely the rate limiter.)

2c. Read in-flight pushes from .release-state.json at the repo root, read-only — if the file is absent or unreadable, skip this (do NOT create it; that's /release-manager's job). Parse rolloutWatch: each entry <service>: { sha, fromTag } is a service /release-manager pushed in a prior tick whose new image hasn't been confirmed live yet. This is the only source for the pushed-but-not-rolled-out state — once a service is pushed, its unpushed count drops to 0, so nothing in the release-digest output reveals that a rollout is still in flight. Keep these for step 4.

1. Render a single table, one row per service (skip ignored services), columns:

service | unpushed | uncommitted | CI | deployed (ready/tag/age).

1. Below the table, observations only (no prompts):

• ⤴️ PUSHED — rolling out <service> — for each rolloutWatch entry from step 2c: compare the

live deploy tag against the recorded fromTag. If the live tag still equals fromTag (or deploy is unknown), the rollout is in flight — Flux hasn't applied the new image yet; show was <fromTag>, awaiting new tag. If the live tag has moved off fromTag (Deployment ready, or CronJob marker cron), it has effectively rolled out — /release-manager will clear it from rolloutWatch on its next tick; you may note ✅ rolled out <service> <tag>. (Read-only: this skill never edits rolloutWatch.)

• READY — has unpushed commits, CI green, and no co-changing prereq (see WAITING below).
• WAITING ON <prereq> — has unpushed commits AND a provider it depends on (effective

map) is co-changing: that provider also has unpushed commits, is mid-rollout (a Deployment N/M, N<M, or a CronJob service showing cron:rollout), or was pushed-but-not-confirmed (it's in step 2c's rolloutWatch with its live tag still at fromTag). A stable, already-live provider does not trigger this — only a provider that is itself changing right now. (This is the deploy rate limiter: a consumer waits a tick for its provider's rollout to confirm.)

• 📊 DEPENDENCY DRIFT — if ---DRIFT--- is not in-sync, list the new/removed

edges and note /release-manager can reconcile them into order.derived.

• 🔗 CONTRACT COVERAGE GAP — for each contract-check coverage GAP line, show

provider: <not-verified=…> (e.g. contactform: not-verified=digest,patrol,…). This is a prod-safety signal — a provider whose CI doesn't verify all its consumer contracts can break them silently. (For full contract health — staleness, sync-gaps — run /contract-check.)

• CI RED — CI failed/errored (note: /release-manager would auto-file a bead here).
• TOGGLE READY — a toggles entry whose gating service is rolled out (a Deployment showing

deploy ready, or a CronJob service showing the settled cron marker) but whose flag is still false in prod (cross-reference the ---TOGGLES--- map from step 1). Exceptions:

• A toggle with status: dark-release is not "ready" — show it as `🌓 DARK RELEASE

<flag> — flip is a manual call once validated`, never as TOGGLE READY.

• Never treat a parked flag as ready — those are intentionally off; list them once

under a quiet "parked" footnote (flag, superseded_by, reconsider_if) and do not nudge.

1. Keep it to one screen. End with a one-line summary (e.g. "3 ready, 1 waiting, 1 CI red, 1

toggle ready, 2 coverage gaps").

Notes

• Strictly read-only. If you find yourself wanting to push, file a bead, or reconcile drift,

that's /release-manager.

• CIRCLECI_TOKEN and kubectl context paperboy are needed for full data; degrade gracefully to

unknown for any section that isn't available rather than failing the whole dashboard.

• ./scripts/pact-graph (ordering) and ./scripts/contract-check coverage (contract health)

are pure-filesystem, need no network/tokens, and always run. The dependency graph is the deploy rate limiter; coverage gaps are a standing prod-safety signal independent of the current release. Full contract health (staleness, sync-gaps) is /contract-check.