Ship the Go binaries as release assets installed through mise's github backend #333

Problem

.github/workflows/release.yml currently creates a GitHub-signed release commit and an SSH-signed annotated tag, but publishes no binary assets. Consumers must compile devtools commands through Go.

AGENTS.md, the release skill and tools/release-verify.sh explicitly say “The tag is the whole release.” Publishing assets changes that release contract.

Acceptance criteria

1. AC1: Define the released binary inventory, initially covering agenthooks, agentrepo, commit-lint, gh-post, gh-reviewer, guard-markdown and ssh-sign, for linux/amd64, linux/arm64, darwin/arm64 and windows/amd64.
2. AC2: Produce exactly one archive per platform containing every released binary, using executable names and archive layouts compatible with mise’s github: backend. Windows executables retain their .exe suffix.
3. AC3: Publish SHA-256 checksums and machine-readable release metadata identifying the version, full tagged commit, platform targets and binary inventory. Use the existing reproducible build flags and commit-derived build date.
4. AC4: Publish the archives, checksums and metadata on a GitHub Release associated with the signed tag. Build or upload failures fail the workflow; retries refuse to replace existing assets with different bytes.
5. AC5: Extend verify-devtools-release to check the requested release’s complete platform and binary inventory, downloaded archive checksums and metadata consistency. Missing or mismatched evidence fails verification while existing tag, commit, identity and ancestry checks remain.
6. AC6: Update release documentation, workflow comments and the release skill to replace the tag-only contract, explain the first asset-bearing release boundary and retain source installation as a development path.
7. AC7: Add automated coverage for packaging, metadata, upload failures and negative asset-verification cases.
8. AC8: Cut the first asset-bearing release through CI and record its tag, workflow run and successful verification result.

Scope and non-goals

This issue owns asset production, publication, verification, release-contract documentation and the first published assets.

Out of scope: migrating consumer pins, locks, adoption instructions or diagnostics; reusable release distribution; automatic publication and durable recovery.

Approach

Build from the exact API-created release commit referenced by the signed tag. Reuse the build settings behind .devtools/tasks/go.toml and .devtools/scripts/go-ldflags.sh.

Bundle all released commands together for each platform. Document stable archive naming, layout and metadata so consumer installation does not depend on guessing asset names. Publish checksums covering the archives and metadata.

Extend the existing verifier without weakening its signature checks. Document that earlier tags used the tag-only contract; do not backfill or move them.

Dependencies

No new implementation prerequisite within this split. Follow the binary-distribution direction in #174 and the thin-wrapper rule in #203.

#544 and the narrowed #382 depend on this issue. #359 tracks the subsequent release work.

Size

M. One PR for the publisher, asset verification and documentation, completed by one owner-run release after merge.

Verify plan

• AC1, AC2: Build all four targets and inspect archive contents against the complete binary inventory; smoke-test executable invocation on matching platforms.
• AC3: Check metadata against the tagged commit and recompute every published SHA-256 checksum.
• AC4: Exercise build and upload failures, matching existing assets and conflicting existing bytes.
• AC5: Test missing archives, omitted binaries, corrupted bytes, incorrect checksums and incorrect version, commit or platform metadata; retain existing signature and ancestry regressions.
• AC6: Review release guidance and search for obsolete statements that assets are absent by design.
• AC7: Run the relevant Go, Bats and workflow checks, followed by repository lint and tests.
• AC8: Run mise run verify-devtools-release <tag> against the first published asset-bearing release.

Risks

Assets can be published incompletely after a tag already exists. Fail clearly, preserve published evidence and never move or delete the tag to conceal a failure. Archive naming and layout become consumer interfaces.

Operator authority

Owner-only GitHub action: approve protected workflow changes under repository policy and authorize the first release dispatch. CI uses the configured release App and tag-signing credentials.