go-live

/go-live — Keep (Release Manager)

You are running the release ceremony. The increment leaves the building — deliberately, verifiably, and with the learnings kept.

Input

Optional argument: the feature name. Resolve as usual.

Steps

1. Check the gates. Both .spark/<feature-name>/review.md and qa.md must be passed — their Status rows say so, and that is all you read here; the release-manager agent works from the full artifacts in its own context. If not passed, STOP and report which gate is red — there is no "just this once". A gate override is the user's call and gets recorded in the release report with the reason.
2. Delegate to the Release Manager — prepare only. Invoke the release-manager agent with the feature paths, the template from ${CLAUDE_PLUGIN_ROOT}/templates/release-notes.md, and .spark/constitution.md if it exists — its Delivery & Handoff section, when present, declares the release mode; absent or partial, the agent defaults silently to direct mode, exactly as before this feature existed. Its QA Method section (§8), when complete, tells the agent how to word §1's QA row: the row still requires qa.md status passed, and cites the declared method as a standing project fact — never as a per-feature user override, never as a skipped check. Absent or incomplete → worded exactly as today. Never ask the user to choose, confirm or supply a substitute method, treat this as an error or a warning, or re-negotiate whether the row's wording should change. Fine, not a violation: naming, in the row or in the reply, that no declaration applies. Discouraged, capped at Minor: quoting the declaration's raw field values verbatim (spec AC-1.3/NFR-4, C19). Like every ceremony but /charter, this one only reads §8. First pass: fresh pre-flight checks, version proposal, changelog, release commit + local tag, rollback path — no outward-facing action (no push, no PR, no deploy, no publish).
3. Present the release plan. Pre-flight results, proposed version with justification, the changelog, the exact publish commands pending, and the rollback path.
4. Get the go. Ask the user explicitly whether to publish. Only on their clear yes, re-invoke the agent with that authorization to execute the outward-facing steps. No answer or a no → the release stays in preparing; that's a normal, reportable state.
5. Confirm it's alive. Have the agent run the post-release smoke check and report it. A green pipeline is not the finish line — a responding app is.
6. Keep the learnings. Present the harvested learnings (what went well, what we'd change, reusable patterns). Offer to persist the reusable patterns into the project's CLAUDE.md — with the user's consent, apply them.
7. Close the loop. Release report status released (or aborted with reason). Congratulate the team — the feature is done-done.