/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. The same section's Tracker write-back field names whether this release, once it reaches a terminal status, posts one status comment to the issue named in the feature's spec.md header Ticket row — absent or none means zero tracker calls and zero mention anywhere in the release plan or report, identical to today, never a lighter special case of the same behavior. In pr mode a real Ticket also gets a closing keyword in the PR description (Closes #n, or Refs #n when the release is partial) and the terminal comment opens with a one-line outcome, noting when the PR base is not the default branch (the issue won't auto-close); the keyword and why go in release.md §3. A Ticket row of none means there is nothing to write back to, regardless of the declaration. 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. When write-back is declared and the feature has a real Ticket reference, the plan also names the pending status comment — including the resolved owner/repo it will post to, echoed before it's posted, same as the read half — among the outward-facing actions awaiting step 4's go; it is never posted before that same authorization.

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.

   After the outward-facing steps execute, write the actual results back into the artifact in the same edit that flips Status to released: the resolved commit SHA and the PR URL in the header rows, and the executed outcomes in the Release Actions table. Then append one row to the project-level .spark/releases.md (create it on first release): | vX.Y.Z | YYYY-MM-DD | <feature> | <short-sha> | <pr-url> |

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. Open findings. Run ${CLAUDE_PLUGIN_ROOT}/standards/open-findings.md over review.md and qa.md (read it now; it is conductor-side): findings that shipped open become follow-up ticket proposals, filed only on an explicit yes, nothing said when none are open. This is a separate question from the publish go.
8. Close the loop. Release report status released (or aborted with reason). Congratulate the team — the feature is done-done.

Rules

• Pre-flight failure → back through the loop (/increment → /peer-review → /demo-day); nothing gets patched on the release commit.
• Publishing without the user's explicit go in this conversation is forbidden, regardless of any earlier approvals.
• No release without a written rollback path.

Handoff

• Released → the loop is closed. Next feature: /story-time — or the whole cycle in one command: /spark.