Repository navigation
Description
What should happen
release-verify-rc should display an interactive live verification checklist in a persistent terminal review pane (ui.render Pane) when running under Claude Code, updating each verification check (signatures, checksums, RAT headers, NOTICE/LICENSE, prohibited binaries, symlinks, version manifests, and reproducibility) with real-time status indicators as steps complete.
Why
During release candidate verification in plugins/magpie-release-management/skills/verify-rc/SKILL.md, verifying an Apache Release Candidate executes 8–9 distinct mechanical checks. Currently, progress and verdicts are reported exclusively via sequential conversational text turns, which clutters the LLM context window and gives the Release Manager or voter no persistent dashboard showing what has passed, what is running, and what remains.
As identified in #1497:
release-verify-rcchecklist pane: One row per check, filled in as the steps finish.
Providing a dedicated, additive Claude Code mod pane gives Release Managers and voters a zero-token visual status dashboard while strictly preserving vendor-neutral text fallbacks across non-Claude harnesses.
Which layer
Other / unsure
Boundary conditions (optional)
- Vendor Neutrality: When running on non-Claude harnesses (Codex, Antigravity, Cursor, CI) or when mods are disabled/unsupported,
release-verify-rcmust continue operating via standard sequential CLI output without error. - Fail-Open Execution: Intercepting commands (
release-config preflight,release-verify, and RAT checks) viatool.callmust unconditionally invokenext(e)so tool execution is never blocked or gated. - Dual Execution Modes: The mod must handle both individual subcommand runs (
release-verify signatures,release-verify checksums, etc.) and the bundledrelease-verify allexecution cleanly. - Step Status Fidelity: Steps should visually distinguish between
pending,running,passed,failed,warning, andskipped(e.g. when--skip-reprois passed). - Session Hygiene: The state atom should reset on session start and initialize freshly when a new RC pre-flight check begins.
Out of scope (optional)
- Changing or bypassing ASF voter obligations: mechanical verification remains an aid, not an autonomous vote (Golden Rule 4).
- Modifying underlying CLI logic in
tools/release-verify/ortools/release-management/. - Private key handling or automatic GPG signing (Golden Rule 5).
References (optional)
- Part of Explore Claude Code mods across the skill families #1497 (
Explore Claude Code mods across the skill families) docs/when-to-use-mods.mdplugins/magpie-release-management/skills/verify-rc/SKILL.mdtools/release-verify/README.md
Activity
Kaap10 commentedon Nov 5, 2026
To keep reviews focused and easy to follow, I plan to break the implementation into two small, sequential PRs:
plugins/magpie-release-management/hooks/, define the state atom and types (verifyRcState), implement the presentationalPanecomponent with status badges, and add full unit tests (claude plugin test).tool.callinterceptor on Bash to capturerelease-configandrelease-verifycommands (supporting both individual checks andrelease-verify all), updateverify-rc/SKILL.mddocumentation, and add end-to-end simulation tests.Will start on PR-1 shortly!
feat(release-management): add verify-rc live checklist pane mod scaff…
feat(release-management): live verification checklist tool-call feed …
feat(release-management): live verification checklist tool-call feed …