enforce release checklist via CI workflow

[JFK]

Goal

Mechanize the dogfooding release checklist introduced in #8 (v0.2.1) as a CI gate, so maintainers cannot tag a v* release without attached dogfooding evidence.

Context

#8 landed the checklist as human-enforced documentation in CONTRIBUTING.md. The optional CI workflow (.github/workflows/release-checklist.yml) was deliberately carved out of that issue per PM/QA review to avoid scope crosstalk — the core value of #8 was the written rule; automation is a separate concept with its own design decisions.

Scope

• .github/workflows/release-checklist.yml: when a PR is labeled release, fail the job unless dogfooding-evidence files are attached per the bundle schema defined in CONTRIBUTING.md#evidence-bundle-schema-minimum.

Open design questions (must be resolved before coding)

Evidence attachment mechanism — pick one before implementation:

1. PR body markdown block: parse ## Dogfooding evidence section from the PR body, require presence of state JSON excerpts.
2. Release artifact upload: require .github/release-artifacts/<branch>.{json,gate1.md,gate2.md} to be committed on the release PR branch.
3. GitHub Release asset attachment: check asset presence on the draft release after gh release create.

The decision depends on how tolerable false positives are and whether evidence should live in the repo history or only in Releases.

Dependencies

Blocked on #10 (eval framework / golden tests for reviewer skill outputs). The eval framework will define the canonical shape of gate1/gate2 output, which this CI workflow must parse — building it before #10 means rewriting the parser later.

Acceptance criteria

• .github/workflows/release-checklist.yml exists and triggers on PRs labeled release.
• The workflow fails cleanly with a human-readable error if evidence is missing or malformed, pointing at the CONTRIBUTING.md#release-checklist--dogfooding-gate section.
• The workflow is dogfooded on its own release PR (v0.3.0) — the first release to pass the automated check.
• The evidence attachment mechanism (option 1/2/3 above) is chosen, documented in CONTRIBUTING.md, and consistent with eval framework / golden tests for reviewer skill outputs #10's golden-test schema.

Phase

v0.3.0. This is the second half of the dogfooding gate story: #8 establishes the rule, this issue enforces it mechanically.

Non-goals

• Evidence tampering detection (out of scope; trust the maintainer).
• Historical back-fill of v0.1.x / v0.2.x releases (retroactive compliance is documented in CHANGELOG exemption notes).

---

Filed as a follow-up to #8 during gate1 design review. See ~/.claude/cache/gh-issue-driven/8-docs-release-checklist-in-contributing-dogfoo.gate1.md for the PM + QA Lead + COO synthesis that led to carving this out.

[JFK]

Moved from v0.3.0 → v0.4.0 after PM re-evaluation.

Reason: defense-in-depth value, not immediate-incident value. The plugin has been dogfooded religiously through v0.1.2 / v0.2.0 / v0.2.1 — human discipline has been sufficient, and no "forgot the checklist" incident has occurred. Automating it now pays the implementation cost (workflow design, evidence bundle schema decision, self-application risk on the first release PR) against a hypothetical future lapse.

Revisit trigger: move back to the active milestone after any actual skipped-dogfooding incident, or if the release cadence increases enough that human discipline becomes unreliable.

Also: the stated dependency on #10 has been withdrawn — #10 is closed (not planned), and #43's parser can read .review.exit_reason directly from state JSON using the canonical shape already defined in commands/config.md:23 and commands/ship.md. So when this issue is revisited, it is independent and no longer blocked.