feat(done-check): key Done on the release, and refuse a Done no tag contains

[wenzowski]

Done on this board means released ([dor-dod]), and the tracker's GitHub
integration keyed it on the merge — a whole release cycle early. Re-measured
2026-08-13: CLOUD-499's state history reads Todo -> In Progress -> Done with
Done set at 05:13:12, merge time, while the last tag was v0.0.62 and main
stood 50 commits past it. So ~1.5 days of landed work read as released, and
In Review — the post-merge, pre-release column the trunk-based model depends
on — was entered only when a human put an issue there by hand.

The two halves have different owners

merge -> In Review is a workspace setting (team -> GitHub integration -> the
status mapped to "pull request merged"). No repo code and no Linear MCP tool can
change it. It has been flipped from Done to In Review.

release -> Done has no automation available at all, and no setting reaches
it: per mise-tasks/released's header, the integration triggers on PR events,
and "a release tag now contains this commit" is not one. Performing it needs a
Linear credential this repo deliberately does not have.

So the repo ships the half it can hold — the consequence

mise-tasks/done-check refuses a Done that no v* tag reaches:
CLOUD-N Done -> In Review, exit 1. A promotion skipped at release time is now
a failing check rather than silent drift.

It is landed-check's terminal twin, built to its shape deliberately — both
name In Review from opposite sides, one for a board behind git, one for a board
ahead of the release — and it composes with released running the other way.

It only ever refutes a Done, never confirms one. Refs are resolved from
commit messages, so a ref inside a tag is weak evidence (a commit can cite or
defer), while a ref nowhere near a tag is conclusive. Two things it therefore
stays quiet about: an issue whose work half-landed and half-shipped (CLOUD-468's
question), and a Done no commit names at all, reported as unlanded and not
failed on.

Both preconditions are exit 2 and fail in opposite directions: no origin/main
makes every Done look unlanded (false green), no tags makes every Done look
unreleased (false red). A default CI checkout fetches no tags, so the second is
the ordinary way to meet it.

Shown able to fail, on fixtures and on the real board

tests/done-check.bats, 15 cases, mutation-checked three ways — dropping the
released guard, never reporting, and dropping the no-tags precondition each
redden exactly the cases that own them. The first mutation run found a real gap:
two passing cases were green under the mutant, because once a tag is cut nothing
is unreleased and an issue judged unlanded also exits 0. Pinning the count
separated them.

Against the live board, the full Done closure (159 issues) exited 1 and named
five landed-but-untagged issues; all five moved to In Review (graph-check-
adjudicated on their PR attachments first), and the same closure now exits 0.

Also here

• .github/workflows/release-plz.yml — the report step's promotion is now the
  only path to Done rather than advice competing with an automation that already
  fired.
• mem:workflow/board-states — two claims this change falsifies are retracted
  rather than appended to: that the merge lands on Done, and that hand-moving to
  In Review does not stick.
• AGENTS.md — the open-issue pointer is dropped and the rule states the source.

Refs: CLOUD-192

[linear-code]

CLOUD-192 The board transitions to Done on merge, not on release — In Review is never occupied

Why. The board is the observability surface, and its states are defined against a trunk-based model: In Review = landed on main, under post-merge review, pre-release; Done = released. Observed on CLOUD-168, the integration collapses both into one transition fired by the merge.

Measured. PR #103 merged at 19:29; CLOUD-168's state history is Backlog -> In Progress -> Done with Done set at 19:29:03 — merge time. The release (v0.0.15, which does contain the commit) was not cut until 19:31:56, ~3 minutes later. So the issue read Done for three minutes while unreleased, and In Review was never occupied at any point.

The end state converged here only because release-plz happened to release promptly. The transition is keyed on the wrong event, so the failure is latent rather than absent:

• A release that fails, is delayed, or is held leaves issues sitting in Done while unreleased — the exact "done means landed-and-verified" drift Batten exists to prevent, on Batten's own board.
• In Review having no occupants means the post-merge review window the trunk-based model depends on has no board representation. Per AGENTS.md we review after merge, before release; a column that is structurally never entered cannot surface that work.

This also supersedes a recorded observation in mem:workflow/board-states, which states "the merge-side transition did not fire" (measured when #100 merged and CLOUD-178 stayed In Progress). It now fires — and overshoots. That memory needs correcting either way, since an agent reading it today will expect to hand-move a landed issue that the integration has already moved.

Acceptance.

• Merging a PR moves its issue to In Review, not Done.
• Done is set by the release, not the merge — an issue whose commit is on main but not in any published release is never Done.
• A test or documented probe demonstrates the two-step path on a real issue (state history shows In Progress -> In Review -> Done).
• mem:workflow/board-states is updated to record the current, measured behaviour, replacing the "did not fire" note.

Implementation, 2026-08-13.

Re-measured before touching anything. The defect is still live and unchanged from the original CLOUD-168 observation: CLOUD-499's state history reads Todo -> In Progress -> Done, with Done set at 05:13:12 — merge time. Last tag v0.0.62, main 50 commits past it, so ~1.5 days of landed work read as released.

The two halves have different owners, and only one is code.

• merge -> In Review is a workspace setting — the team's GitHub integration maps the merged event to a status. No repo code and no Linear MCP tool can change it, so nothing in the tree can hold it. This is the one open item; it needs a human to flip it.
• release -> Done has no automation available at all, and this is not a gap that a setting closes. Per mise-tasks/released's header: the integration triggers on PR events, and "a release tag now contains this commit" is not one. Performing it needs a Linear credential the repo deliberately does not have.

So the repo ships the half it can hold: the consequence. mise-tasks/done-check refuses a Done that no v* tag reaches — CLOUD-N Done -> In Review, exit 1. It is landed-check's terminal twin (both name In Review, one for a board behind git, one for a board ahead of the release) and composes with released running the other way. It only ever refutes a Done, never confirms one: refs come from commit messages, so a ref inside a tag is weak evidence while a ref nowhere near one is conclusive. A skipped promotion is now a failing check rather than silent drift.

The board was corrected rather than grandfathered. Piping the full Done closure (159 issues) exited 1 and named five: CLOUD-404, CLOUD-484, CLOUD-491, CLOUD-495, CLOUD-499 — each landed, each in no tag. All five moved to In Review, graph-check-adjudicated on their PR attachments first. The same closure now exits 0 (27 not judged, the unlanded channel). That before/after pair is the gate demonstrating it can fail on real data, not only on fixtures.

Fewer than the 50 unreleased commits would suggest, because an issue is judged by its most-released ref: work carrying several PRs, some shipped, passes. That is CLOUD-468's question and this gate deliberately does not answer it.

Notes. If the integration cannot key Done on a release event, the fallback is to stop it at In Review and let the release step promote — a correct-but-manual last transition beats an automatic wrong one, since graph-check already gates In Review => a linked PR attachment.

Review in Linear

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[wenzowski]

/fast-forward