releaselisted

# Release Run Moraine releases end to end with the shared `moraine-dev` contributor workflow. Invoke it as `$moraine-dev:release X.Y.Z` in Codex or `/release X.Y.Z` in Kiro. Both forms mean: publish `vX.Y.Z`, not just prepare a plan. ## Goal Contract In Codex, make the release a durable goal before doing release work: - If `create_goal` is available and there is no active goal, call it with: `Cut Moraine vX.Y.Z, including version bump PR, merged code, annotated repo tag, GitHub release notes, release workflow verification, and PyPI package verification.` - If a goal already exists, continue inside it and keep it current with `update_plan`. - Do not call `update_goal(status="complete")` until all public release evidence exists: merged PR, pushed tag, successful workflow, GitHub release body/assets, and PyPI `moraine-cli` artifacts. In Kiro, maintain an explicit checklist in the session. Do not mark the release complete until the same public release evidence exists. ## Preconditions Normalize the argument first: - `X.Y.Z` and `vX.Y.Z` both mean `VERSION=X.Y.Z` and `TAG=vX.Y.Z`. - Refuse ambiguous input, missing versions, or a target older than the latest stable GitHub release. Before editing: 1. Read the active `AGENTS.md`. 2. Use Moraine session search if available. Start broad, then narrow: - `release process Moraine PyPI GitHub tag` - `v0.5.4 release workflow pypi release notes` - `package-moraine-release release-moraine gh release edit` 3. Inspe