---
name: release-roundup-ordering
description: alchemy release-verb roundup requires board closes BEFORE publish; release body carries NO milestone/request links section (operator-ruled 2026-07-31); draft-toggle republish = repair
metadata: 
  node_type: memory
  type: feedback
  originSessionId: a4e9572c-40c3-4f2b-867d-a9e0b37ed7d5
  modified: 2026-07-31T12:37:49.938Z
---

Operator rulings 2026-07-31 on shipped-request association:

1. **Release body carries NO "Milestone & requests" section** — not standard practice. Removed from v0.48.0. My earlier runbook suggestion to deployah RETRACTED (retraction sent).
2. **The association mechanism is the alchemy `release <tag>` verb** — promotes acceptance requests closed *before* the release's `publishedAt` to DONE, answers with the roundup, and the Hub posts the Discord "Shipped Requests" embed. v0.47.0 = the exemplar: one verb call ~2 min after publish, nothing else.

**Why:** the verb gates on `closedAt` vs `publishedAt` — but NOT strictly; see the 2026-08-30 correction at the foot of this file before reasoning from that gate. Cut ordering decides success: board ACCEPTANCE close-cascade must land BEFORE the release is published. v0.48.0 published 10:16:13Z but closes fired 10:18:48Z (board moves ran post-publish) → verb no-oped.

**How to apply:** at every cut — board state moves (the GitHub-closing cascade) FIRST, publish SECOND, then `spt shell cmd alchemy-0 release <tag>` after publish. Repair when the order slips: `gh release edit <tag> --draft=true` then `--draft=false` refreshes `publishedAt` past the closes (tag + assets + body survive; verified on v0.48.0), then re-run the verb. Note the verb's DONE promotion precedes flynn-style field verification — v0.47.0 precedent, operator-sanctioned; field verify becomes post-hoc confirmation. Supersedes the "promote children manually at field acceptance" plan in [[wan-truth-50-handed-off]].


## CORRECTION 2026-08-30 (v0.66.0 cut) — THE GATE IS NOT STRICT, AND TWO CONSUMERS DISAGREE

**The verb has a GRACE window.** This file said `closedAt < publishedAt` flatly and I reasoned
from it twice in one night, wrongly both times. Measured in the open: `release v0.66.0` took
`#242` whose close was ~7 minutes AFTER publish and said so in the roundup — `(late close,
within grace)`. One release earlier the same grace silently covered CONDUIT's four members,
closed 56-66 SECONDS after v0.65.0's publish, and promoted them fine.

**But the Hub Daemon's release CARD buckets STRICTLY** on `closedAt` in
`(prev.publishedAt, this.publishedAt]`. So the board state and the Discord card can disagree,
and a late close is DONE-but-mis-carded: v0.65.0 announced `0 shipped` while its CONDUIT members
surfaced on v0.66.0's card. doyle root-caused it from `~/.alchemy/daemon.log`; filed as a bugfix
on alchemy's own board (fix = daemon honors the verb's grace, or both share one attribution fn).

**Three things to carry:**
1. Do not predict a no-op from a late close. I told a gater the verb 'would have no-opped', he
   CONCURRED from his own read, and the measurement refuted us both — the members had closed
   hours pre-publish and the milestone rode the grace. A peer agreeing is when to measure, not
   when to act. See [[dont-take-a-diagnosis-as-measured]].
2. **Never repair a card with a state edit.** Cards recompute each cycle, so a daemon fix heals
   them retroactively with ZERO issue edits, while re-labelling would have destroyed a CORRECT
   GitHub record (labels + prose both attributed CONDUIT to v0.65.0 all along). The repair cost
   more than the symptom; measure which layer is actually wrong first.
3. The MILESTONE's own close must land pre-publish too, not just its members'. `#242` closed
   01:50:10Z against a 01:42:43Z publish, so it is outside the strict window and is queued to
   surface on **v0.67.0's** card. Known off-by-one, recorded in `docs/RELEASE-RUNBOOK.md` step 6
   (commit 173e63bd) so the next driver reads it rather than re-earning it.