---
name: release-verb-grace-vs-hub-card-window
description: "alchemy's release verb has a grace window for closes landing shortly after publish, but the Hub daemon's Discord release cards bucket by STRICT closedAt-in-publish-window — every post-publish close cascade attributes the milestone to the NEXT release's card (spt-progress-tool#78)"
metadata: 
  node_type: memory
  type: reference
  originSessionId: 9298ce90-27bd-44cb-9d08-f4acba5623a0
  modified: 2026-08-30T09:33:02.032Z
---

Measured 2026-08-30 (doyle + deployah, jointly; operator-reported symptom).

**Two attribution meters, one split:**
- The `release <tag>` VERB promotes acceptance requests closed shortly AFTER publish
  too — grace window, twice observed: CONDUIT's members 56–66s late under v0.65.0
  (DONE 08:17Z, publish 08:15:16Z) and #242 itself 7.5min late under v0.66.0,
  answered verbatim "(late close, within grace)". GitHub labels + roundup = CORRECT.
- The HUB DAEMON's release cards (Discord board) bucket DONE requests by STRICT
  `closedAt ∈ (prev.publishedAt, this.publishedAt]` — no grace. A close cascade
  driven post-publish (the documented golden-CI repair path) lands the whole
  milestone on the NEXT release's card; the announce snapshot ("announced (0
  shipped)") never refreshes because the strict window keeps the computed set
  empty (card refresh only fires when card content changes).

**Consequences to carry:**
- v0.65.0 card shows 0 shipped, v0.66.0 card shows CONDUIT — GitHub is right, the
  DISPLAY is wrong. NEVER repair by editing issue states / re-running verbs — that
  corrupts a correct record to fix a rendering (deployah's stop-call, upheld).
- #242 (closed post-publish) will wrongly surface on v0.67.0's card until fixed.
- Durable fix filed: **spt-progress-tool#78** (card bucketing honors the verb's
  grace / shares one attribution fn; cards recompute each cycle so the fix heals
  retroactively). Evidence: ~/.alchemy/daemon.log anchors ~704491, ~713558.
- Pre-empt the whole class: drive the ACCEPTANCE cascade BEFORE publish (runbook
  step 6) — both this trap and the verb's grace exist only for the repair path.
- Both of us first modeled the verb's gate as strict and were wrong ("would have
  no-opped") — [[dont-take-a-diagnosis-as-measured]]; the close timestamps at
  source falsified it in one read.
- **SECOND FACE 2026-08-30 (v0.67.0): the verb is a DISTINCT post-publish step
  and skipping it is silent.** The ship sequence ran cascade/tag/publish/verify
  and stopped — nothing promotes ACCEPTANCE→DONE except `release <tag>`, so the
  whole milestone sat CLOSED-but-ACCEPTANCE for ~50min and the release's hub
  card read EMPTY (operator-reported both). One verb fixed it (roundup 9 DONE);
  the card refreshed next cycle BECAUSE cascade-before-publish had put the
  closes inside even the strict window. Tell: a ship report WITHOUT a roundup
  block in it. ⚠ MY FRAMING CORRECTED (deployah measured the file before
  acting): the verb was ALREADY a documented runbook step — this was a skipped
  step, NOT a doc gap, and my "checklist should carry it explicitly" would have
  added a duplicate while leaving the cause alive. Actual cause = step 6
  STRADDLES publish (cascade before, verb after) and the big event mid-step
  steals the step's sense of completion; every artifact-side verification
  passes with the board unfinished. Fix = SHAPE (8a21a3b0: two-sidedness
  headlined, straddling steps split into two ticks, re-read from the top after
  the event) — see [[a-step-that-straddles-an-irreversible-action-reads-as-done-at-the-action]].

Related: [[v0660-arc-in-flight]], [[v0650-arc-in-flight]].