/go-live

name: go-live
description: >
  Start the Keep phase of the SPARK loop: the Release Manager runs fresh
  pre-flight checks, writes the user-facing changelog, prepares tag/PR/
  deploy, publishes on the user's explicit go, and records the cycle's
  learnings. Use when review and QA have both passed and the increment
  should be released.

/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. **Light path.** Read one more row: `Path` in the header table of `spec.md`. Only when it says `light`, a **missing** `qa.md` does not stop the release: `review.md` `passed` is the gate, and you tell the `release-manager` agent in step 2 that QA was not run by design, to say so in the release report's gate line as `QA: not run (light path)`, and to run the full test suite in its pre-flight. A `qa.md` that exists and is not `passed` stops the release on any path. No `Path` row, or `full`: nothing in this paragraph applies. 2. **Delegate to the Release Manager — prepare only.** Pick the model first: if `.spark/constitution.md` §11 names a model for `release-manager`, pass exactly that as the agent call's `model`; if it names none, or there is no constitution or no §11, pass no model, so the agent's own default (`sonnet`) applies. Then 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.** Rele