RELEASES.md gives a release epic's Blocked by two jobs and the sweep reads one set — 0.6.0 reported two standing windows on crew, neither of them the one standing

[dan-claude-bot]

Measured on heavy-duty/crew, the first consumer to adopt 0.6.0 (pins bumped and RELEASES.md vendored at 10:23:05Z today, crew#350). The first sweep at the merged head reported two standing release windows, neither of which was the window actually standing, and would have flagged every member of the real window at its next flip. The cause is not crew's prose alone — that half is repaired — it is that RELEASES.md gives a release epic's Blocked by two different jobs and issueflow-reconcile.sh reads one parsed set.

Everything below is executed with blocked_references at the 0.6.0 tag over the bodies the API returned.

The two jobs

Gates:

"Each version epic declares Blocked by <predecessor>."

One primary window:

"While a window stands — an open release-labeled issue with a non-empty enumerated gate — its members form a DAG whose sink is the release issue… the sink records membership only"

And the detector:

"A standing window is an open release-labeled issue whose gate still holds an OPEN member (#292 D1)."

A predecessor is open until it ships. So a version epic that follows the Gates sentence correctly declares an open reference, and is therefore read as a standing window — for the entire interval in which its window is precisely not open, ending when its predecessor closes. The two readings are exact opposites on the same string.

The corollary is worse than the defect: the real window is the one that cannot be detected. crew's 0.1.2 epic (crew#346) has an empty gate because its predecessor already closed — which is what opening a window means. It parsed to {162} (closed), so instead of being recognised as standing it drew release-init due for an init that is not due but underway: wave 0 flipped at 09:48:50Z and landed at 10:23:05Z.

crew issue	parsed gate	open members	what 0.6.0 concluded
#163 (0.2.0, eight windows out)	{109, 128, 163, 225, 296}	{163}	standing window
#348 (0.2.5, parallel track)	{163}	{163}	standing window
#346 (0.1.2, the window actually standing)	{162}	none	not standing; release-init due
#207 (an acceptance gate, not a version window)	{116, 162, 212, 283}	none	release-init due — a false positive
the other 13 version epics	{}	—	dormant

Follow the Gates sentence on all fifteen and the sweep reports fifteen standing windows, none standing.

A second, independent finding: the sink can become its own gate member

crew#163's gate contained #163. Its body quotes other issues' Blocked by #163 declarations while describing them, and blocked_reference_records unions every clause. window_flags assumes this is impossible, in a comment:

"The release issue is the graph's SINK, never one of its own members (#292 D2), so it can never be its own non-member."

It is not impossible — it is one narrating sentence away, on exactly the kind of issue whose body is mostly narration about its children. The self-reference was the only open number in that gate, so it alone made the epic a standing window. Worth a guard: a carrier's gate could exclude the carrier's own number cheaply.

What it costs a consumer

window_flags flags every unblocked_claimable issue not in the gate. crew's phantom gate was {109, 128, 163, 225, 296}; none of the real window's 21 members is in it. So the next blessed act on that board — flipping wave 1 — would have commented on every issue triage flipped, telling triage that the members it had just admitted by the documented procedure were illegitimate. It was already live rather than theoretical: crew#350 was flagged at 10:31:31Z.

A third, smaller one, same run. That flag fired two seconds after the same pass moved #350 to post-merge, because the flags are computed from a BOARD_RECORDS snapshot taken at pass start. The posted comment asserts "neither one of its gate members nor an epic or post-merge issue" about an issue that was post-merge when the sentence was written, and post-merge is exempt by window_in_scope's own reasoning. Re-reading the label set for a flagged issue before posting, or computing flags after the transition stage, would close it.

Not a request for a specific fix

crew is unblocked: all 17 of its open release-labeled bodies now parse to {}, so the carrier set is empty and the flag is dormant. The shape of the answer is ceremony's — separate markers for gate and membership, a carrier-excludes-itself guard, deriving the window from something other than the same parsed set, or narrowing the doctrine so only one of the two jobs uses Blocked by. Whatever it is, RELEASES.md and issueflow-reconcile.sh should agree about which sentence a release epic's Blocked by line is answering.

I have deliberately not enumerated crew#346's 21 members at the sink to make the invariant enforceable there. That is a real membership write, and RELEASES.md says membership is a decision the operator blesses — so it is put to crew's operator rather than taken, and it should not be assumed when reading crew as the worked example.

Related and separate: #324 (release-init step 1 and re-opened carried members), filed this morning against the same file.

Filed by crew's triage, 2026-08-05.

[dan-claude-bot]

🧭 needs-ruling — which job does a release epic's Blocked by line answer: the predecessor gate, or the window's membership enumeration?
Options: A — it means membership only, and the predecessor moves to a non-parseable declaration B — it keeps the predecessor gate, and membership gets its own marker on the release issue C — it keeps both jobs, and the sweep discriminates by excluding the carrier's own number and any reference that is itself an open release issue
Recommend: B, because the predecessor line is the sentence every version epic in every adopting repo already carries and a human reads, while membership is the machine's newer job — splitting the newer one costs no existing body and leaves the release-init trigger correct.
Blocked: the doctrine edit to RELEASES.md's Gates, One primary window and Flip mechanics sentences, and the matching change to the detector, stop here; #292's invariant stays unenforceable on any real window until this is answered. Everything else continues: #327 lands unchanged under all three options, 0.7.0's shut window and the eight issues behind it are untouched, and no flag is firing on either board today.
Default: none — hard block. The answer changes vendored doctrine and what every governed repo writes on its epic bodies, so the cost lands outside this repo (#50 D13).

Analysis

The finding survived re-measurement at home

Everything in the opening post was executed against crew. Re-measured here, on ceremony's own board, at 8c3a4d1 — the defect is not a consumer artifact:

• Before 11:12Z today. 0.7.0's epic #317 declares its predecessor exactly as Gates instructs, and its gate parsed to {#249} with Release 0.6.0 — the board empties into the tag: family doctrine, the reconciler fixes, the green-gated blocker #249 open. So this repository read as a standing window carrier for the entire interval in which its window was deliberately shut — @danmt ruled at that epic's mint that clearing the gate does not open the window. It drew no comment only because nothing on this board was ready.
• After 11:12Z. #249 closed, and #316 — whose only declaration named it — becomes ready. 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317's gate now parses to {#249}, non-empty but all-closed. The sweep says no window stands, so a ready non-member is legal. RELEASES.md says a window stands "while … an open release-labeled issue with a non-empty enumerated gate" exists, and then "every ready issue is a gate member" — under which CONTRIBUTING.md — the vendored set is declared once: both hand-written listings route to docs/VENDORED.txt #316 is an illegal ready non-member the moment it flips.

Two readings of one sentence, disagreeing about this board's legality right now. Triage has recorded the machine's reading on #316 and let it flip, and that call is what a ruling would confirm or overturn.

What each option costs

	A — membership only	B — gate only, new membership marker	C — one marker, smarter reader
existing epic bodies	every version epic in every adopting repo rewrites its predecessor line out of Blocked by (crew: 15)	untouched	untouched
RELEASES.md	Gates rewritten	Gates untouched; One primary window + Flip mechanics name the new marker	one sentence in One primary window, plus a new rule that a member never carries the release label
release-init trigger	breaks — an all-closed gate would then mean ship, not init, so the nudge needs its own redesign	correct, unchanged	correct, unchanged
detector	unchanged	reads the new marker	two exclusions
how it fails	a repo that forgets the rewrite reads as a standing window forever	a repo that forgets the new marker reports no window — silence, not a false flag	the day a member legitimately carries release, it vanishes from its own window

B's failure mode is the safe direction — a missing marker means the flag says nothing, where A's and C's mean it says something false. C is the cheapest patch and the one I would take if the answer had to be free, but the rule it needs (a window member never carries release) is a new constraint on consumers' label use that nothing today enforces, and it is invisible until it bites. Measured rather than assumed: none of #249's 16 members carried release, so C would work on this board today.

Not part of this question

• Both mechanism defects are already decided and minted as #327: a carrier is never a member of its own gate (which TRIAGE.md + RELEASES.md — a standing window is a graph: every mint is placed into it, or behind it #292 D2 already states, so the code catches up to doctrine and no ruling is needed), and a board flag must not assert a queue label its own pass has just changed. actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 holds under all three options above — a sink is never its own member however membership is spelled — so nothing here waits on it, and it waits on nothing here.
• No needs-ruling label is set anywhere, because nothing on the board is waiting: actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 is complete as specified, and every other open issue is held behind 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 for reasons this question does not touch. The flag is a board state, and setting it with no board item to carry it would be noise. There is therefore no labeled event and no 24-hour ladder running; triage re-raises the ask on a flagged item the moment this starts blocking work — the next mint that has to make a membership call is the likeliest trigger.
• A rider, not an option. actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 currently stands behind 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 like everything else minted since that epic, so the fix ships whenever 0.7.0 opens. If you would rather have it sooner — a 0.6.1, or as a member admitted at init — say so in the same breath and triage flips one edge; it is not one of the three options above and does not change any of them.

What crew is left holding

crew is unblocked and the flag is dormant there: all 17 of its open release-labeled bodies now parse to {}, re-verified in this pass with this repository's own parser at the 0.6.0 tag. The cost of that repair is that crew's real window (crew#346, 21 members) enumerates no membership at its sink, so #292's invariant is unenforced there rather than wrongly enforced. Enumerating those 21 is a membership write that RELEASES.md makes crew's operator's, not triage's, and it is the write option B would ask for anyway — which is the practical reason not to leave this open long.

Escalated by triage, 2026-08-05, from the finding above after re-measuring it on this repository.

[dan-claude-bot]

Status, 2026-08-07 — the ask still stands, and its stated wake condition fired today without biting

A refresh, not a re-ask: no new option, no change to the recommendation, and no default. Everything below is re-measured at 7cef387 and against the live board, because the escalation above rests on board facts that have since moved.

What moved

• 0.6.1 and 0.6.2 both shipped and both closed today. #333 and #338 were single-member patch cuts taken from main, minted with no dependency edges at all, built and merged while #317 stayed gated shut. So did their payloads — RELEASES.md — a member that lands post-merge never releases its successors, so the window silently stops advancing #329, BUILDER.md — the green-check rule is read as "hold the signal", which trades a wait the engine already owns for the round's only wake #330 and BUILDER.md — two ways a finished session stops: parking on an operator-owned remainder before the handoff, and blocking on a producer it cannot prove alive #336 were each minted ready after Release 0.6.0 — the board empties into the tag: family doctrine, the reconciler fixes, the green-gated blocker #249 closed and none of them stood behind 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317.
• The rider offered above was answered by action, twice. It asked whether #327's fix should come out sooner, as a 0.6.1 or as a member admitted at init. Two cuts have since gone out without it; Release 0.6.2 — the parked-claim ordering ships, and the doors are still the ones 0.6.0 rehearsed #338's D2 names actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 and RELEASES.md — release-init step 1 covers the re-opened member: the declaration is re-pointed before the re-open, never after #325 as deliberately out of its gate. actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 is still blocked — re-read from its label events, not from prose: three labeled events at its mint, bug / blocked / scope:labels, and nothing since.
• This board now has a ready issue again — #341, minted today from discussion #340, a four-file correction to the doors-unchanged drill records. It is the only claimable issue on the board.

That last one retires a premise in the analysis above. It read: "this repository read as a standing window carrier for the entire interval in which its window was deliberately shut… It drew no comment only because nothing on this board was ready." Something is ready now.

What the detector actually does with it — run, not reasoned

Sourced actions/issueflow-reconcile/issueflow-reconcile.sh at 7cef387 and driven over the live open-issue set:

open set: 341 327 325 322 321 320 319 318 317 313
release issue #317 -> gate parses to: {249}
  -> no open member: NOT a carrier
WINDOW_CARRIERS   = []
window_flags      = []
collision_flags   = []
claimable set     = #341 [bug,ready,scope:release-flow]

#317 is the board's only release-labeled issue since #333 and #338 closed. Its gate parses to {249}, and #249 is closed, so the carrier test at issueflow-reconcile.sh:1239 rejects it, WINDOW_CARRIERS is empty, and window_flags returns at its first line (L560). #341 draws nothing. The false-positive half of the defect is dormant on this board today, exactly as the analysis predicted for the all-closed-gate state.

Which makes today a data point, not a trigger

The escalation named its own wake: "the next mint that has to make a membership call is the likeliest trigger." That mint happened. The call it had to make was resolved without strain — both readings agree that no window stands right now, because #317's window is shut by ruling and the 0.6.0 window closed with #249. #341 therefore took no window edge, which is the same placement #329, #330 and #336 took.

The ambiguity did not bite because the window is shut, not because the sentence got clearer. The moment the operator opens #317 at release-init, its gate holds open members, WINDOW_CARRIERS becomes non-empty, and every ready non-member on the board is flagged against a gate whose meaning is the unanswered question.

No label, and why

Re-read across the whole repository in the same tick as this write: zero items carry needs-ruling, and zero carry attention. Nothing on the board waits on this answer — #341 is buildable today under all three options, #327 holds under all three, and #325 and #322 are held behind #317 for reasons this question does not touch. Setting the flag with no board item to carry it would still be noise.

The block is unchanged and unchanged in kind: hard, with no default. The answer edits vendored doctrine and what every governed repo writes on its epic bodies, so the cost lands outside this repo and triage does not get to pick it (#50 D13). The one thing that has changed is the clock: the doctrine edit, the detector change, and #292's invariant on any real window have now been waiting two days, and RELEASES.md's two sentences are being vendored into consumers at each pin bump in the meantime — 0.6.1 and 0.6.2 both carried them out unchanged.

@danmt — A, B or C above; the recommendation is still B.

[danmt]

@dan-claude-bot lets go with B. does it make sense to do a fast release for 0.6.3 so crew 0.1.2 comes with it?

[dan-claude-bot]

Ruled: B, recorded as a decision — and the answer to the second question is yes to the cut, no to putting it in crew's 0.1.2

@danmt's word above at 20:30:22Z closes the ask that has stood since 2026-08-05T11:16Z. Recording it, then answering the cut question with the measurements it turns on.

The decision

A release epic's Blocked by line answers the predecessor gate and nothing else. Window membership gets its own marker on the release issue. Gates is byte-unchanged, no epic body in any adopting repository is invalidated, and the release-init trigger keeps working as it does today. A repository that has not yet written the new marker reports no window — silence, not a false flag, which is the direction B was recommended and taken for.

Minted whole as #343, blocked. What the ruling left to triage, made there rather than left open: the marker's form. It is a ## Members section on the release issue, read by anchored heading — the shape epic_references already implements for ## Task list — with one member per row and the row's first token the member, everything after it prose. A marker phrase (Members: #N) was considered and rejected in the spec, because blocked_reference_records unions every occurrence of its marker and runs each clause to a sentence terminator: a second phrase inherits that, and a release epic's body is mostly narration about its members. The concrete case is in the file already — heavy-duty/crew#346 carries a literal ## The members, in claim order heading, which an anchored match will not read and a phrase parser would. That form is mine and overturnable at merge; D1, D3 and D4 are the ruling and are not.

No label to clear. Re-read across the whole repository in the same tick as this write: zero items carry needs-ruling, zero carry attention, and no open issue has an assignee — the flag was never set, for the reason recorded in both comments above (no board item was waiting on it). Nothing to remove, and no claim whose next move this delivers.

0.6.3 — the ceremony half is yes, and the crew half does not hold up

Everything below is executed at 2d1d52c, sourcing this repository's own reconciler over both live boards.

Why crew's 0.1.2 is the wrong vehicle — three measurements:

1. crew is not on 0.6.0 any more. Nine pin sites moved 0.6.0 → 0.6.2 at 2026-08-07T11:52:08Z (216242dc, PR crew#399, merged 12:41:26Z, 0.6.1 skipped rather than stepped through), and the mirror was re-vendored with it. The premise that crew is stranded on the version that surfaced this is spent — it is one patch behind, today.
2. The defect is dormant there, run rather than reasoned. Over crew's live open set: 31 open issues, 19 carry release, and all 19 parse to {}. WINDOW_CARRIERS is empty, so window_flags returns at its first line and nothing on that board can draw a window flag before its cut. crew bought that silence by emptying every gate, and the price is on the record: crew#346 holds 21 members and enumerates none, so TRIAGE.md + RELEASES.md — a standing window is a graph: every mint is placed into it, or behind it #292's invariant is unenforced there rather than wrongly enforced.
3. What 0.1.2 would actually buy is a few hours of enforceability. RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343 lets crew#346 record those 21 members — on a window that closes at its own cut. Meanwhile crew#400 is claimed and waiting on the real-host drill, so shipping 0.6.3 into 0.1.2 means a third pin bump inside one window, landing between the drill and the tag — and RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343's entire diff is doctrine rewording in two vendored files, which is the exact class that reddened crew's main at the last re-vendor (crew#363, 1h 37m to surface because the guard cannot see .ceremony/**; crew#406 is still open on that shape).

Where it does buy something: crew's next window. crew's own established shape is that a ceremony integration opens a window — crew#350 was 0.1.2's wave-0 opening act, minted cross-repo-blocked on ceremony's cut and flipped by hand when the tag existed, and crew#398 repeated it for 0.6.2. So 0.6.3 arrives naturally as 0.1.3's first member, before that window's membership calls are made, under the same procedure crew has now run twice. That is the outcome the question is reaching for, and it does not require the pin to move mid-drill.

Why the fast cut is still worth taking, on this repository's clock and for reasons that are not crew's:

1. There is no claimable work on this board at all. drills/ — the four doors-unchanged records name the job that actually checks the pin #341 closed at 16:07:13Z; all nine open issues are blocked, every one transitively behind 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317. Executed at 2d1d52c: eight of nine blocked_decisions are KEEP, 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 is READY, WINDOW_CARRIERS is empty and the collision index is empty. Until either release-init or a patch cut, a builder has nothing to pick — and actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 plus RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343 are exactly the shape the last two cuts took (Release 0.6.1 — the signal is not the request, and a post-merge member releases nothing #333 and Release 0.6.2 — the parked-claim ordering ships, and the doors are still the ones 0.6.0 rehearsed #338: single-purpose, taken from main, no window edge).
2. The real deadline is 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 opening, not crew's tag. The sweep posted release-init due on 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 at 2026-08-05T11:13:28Z and your ruling holds the window shut. The moment it opens, WINDOW_CARRIERS becomes non-empty and every ready non-member is flagged against a gate — and 0.7.0 would be the first window whose membership has to be written in the new marker. Landing RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343 first makes 0.7.0 the first window described correctly; landing it inside 0.7.0 means opening that window under the sentence it replaces.
3. RELEASES.md is fenced behind the whole rc build. RELEASES.md — release-init step 1 covers the re-opened member: the declaration is re-pointed before the re-open, never after #325 stands behind The rc doctrine on paper — RELEASES.md gains the ladder, README loses its one manual remedy, CONSUMERS.md names availability #322, which stands behind release.yml — the rc door: --prerelease, notes assembled from surviving fragments, automatic re-arm #320, which stands behind lib/version.sh — version_is_rc, and version_next_dev learns the one rc rule: X.Y.Z-rcN → X.Y.Z-rc(N+1)-dev #318 and changelog-armed + changelog-assembled — the guards learn the bare-rc state: fragments survive, the changelog stays untouched #319. So the next edit to that file is at the end of the 0.7.0 chain unless a cut re-points it. RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343 declares its collision edges in mint order today; on your word triage flips actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327's window edge — which actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327's own Dependencies already provides for — and re-points the RELEASES.md chain head-first, two body edits on issues held behind 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317 either way, delaying nothing.

The cost of the cut, stated plainly: two builds and two panels (#327, then #343 — they touch the same functions and #343 inherits #327's guard), plus a release issue in #333's and #338's shape. That release issue must be minted with no declaration at all, because a release-labeled issue with a non-empty gate holding an open member is read as a carrier — the defect itself. 0.6.3 therefore still ships under the workaround; #343 is what makes the next cut able to say what it contains.

Recommendation

Cut 0.6.3 with #327 and #343, nothing else, and let crew take it as 0.1.3's opening member rather than as a 0.1.2 payload. If you would rather clear RELEASES.md's fence in one go, #325 is a small doc fix that could ride along — say so and triage re-points the chain accordingly. If you want crew's 0.1.2 to carry it after all, that is your call and triage will file it with crew's triage the way crew#398 was filed; the honest price is the third re-vendor between the drill and the tag, for an invariant on a window that is closing.

Nothing is flipped in advance. #343 and #327 are both blocked and the chain runs in mint order until the word comes; the cut itself is yours either way (#50 D13), and this discussion stays open until it is taken.

Ruling recorded and answered by triage, 2026-08-07.

[dan-claude-bot]

Board note, 21:20Z — one live claim in the comment above has gone stale, and the board now carries the flag.

That comment said "zero items carry needs-ruling". As of 21:20:51Z that is no longer true: #327 carries it, alongside blocked, with the reasoning recorded there.

Nothing about the ask changed — no new option, and the recommendation is still to cut 0.6.3 with #327 and #343 and let crew take it as 0.1.3's opening member. What changed is that the reason the flag was withheld twice is spent: it rested on something being ready and buildable under every option, and #341 closed at 16:07:13Z. Re-measured with this repository's own reconciler over the live open set: nine KEEP, zero open PRs, zero assignees, zero claimable issues. The board had no item saying whose turn it is; now it does.

No answer is owed to this note — @danmt's word on A, B or C is the only thing it waits on @danmt's word on the cut is the only thing it waits on, and nothing is flipped in advance.

(Referent corrected by triage 2026-08-08. In this thread **A**, **B** or **C** had one established meaning — the marker options of the ask above, which the comment before this one re-put verbatim as "@danmt — A, B or C above". @danmt answered those at 20:30:22Z, 51 minutes before this note, and triage recorded B at 21:08:30Z, 13 minutes before it — so the closing line sent the decider back to letters that were already spent. The letters meant were the cut's, and they are lettered only on #327, where they also name a different set from the three routes the recording comment offered in prose: there, C is no cut, while this thread's third route was crew's 0.1.2 carries it. Struck rather than rewritten, because the sentence's point — that this note is a board report and not a second ask — was and is correct.

The ask is unchanged and still open, and it is the one on #327: A — cut 0.6.3 with #327 and #343 and nothing else (recommended); B — the same cut plus #325; C — no cut, both wait for release-init on #317. Nothing else in this note moves: the board measurement and the recommendation stand as written, and the board still reads the same today — nine issues, all held, zero claimable, zero open PRs, zero assignees, re-measured 2026-08-08 with this repository's own reconciler.)

Triage, 2026-08-07.

[dan-claude-bot]

Converged — this thread's own question is answered, and the residual has one venue, which is not here

Closing this as resolved. The reason is not that everything it raised is finished; it is that this thread now has two live letterings of A/B/C and, by triage's own record, that has already sent the decider back to spent letters once. One venue removes the collision, and the venue is the flagged board item, not the discussion.

What this thread asked, and how it ended

The ask was which job a release epic's Blocked by line answers. @danmt ruled B at 2026-08-07T20:30:22Z — the line keeps the predecessor gate, and window membership gets its own marker on the release issue. Triage recorded it as a decision at 21:08:30Z and minted it whole as #343 (blocked, enhancement, scope:labels, scope:docs), with the marker's form — an anchored ## Members heading, one member per row, first token wins, no fallback — decided there rather than left open, and flagged as triage's and overturnable at merge.

That is outcome 3 run to completion: escalated, decided by the human who owned it, recorded, and turned into work. This discussion has nothing further to converge.

The two findings that never needed a ruling went to #327 at the mint and are unchanged by B — a sink is never its own member however membership is spelled.

The residual, and why it lives on #327 rather than here

@danmt's second question in the same breath — a fast 0.6.3 — is still open, and it has its own carrier: the needs-ruling flag on #327, set 2026-08-07T21:20:51Z. Re-read from that issue's label events in the same tick as this write, not from prose: bug, blocked, scope:labels at its mint, needs-ruling at 21:20:51Z, and nothing since. The flag stands.

Its letters are the ones to answer, and they are not this thread's:

• A — cut 0.6.3 with actions/issueflow-reconcile — a carrier is never a member of its own gate, and a flag reads the queue state its own pass concluded #327 and RELEASES.md + TRIAGE.md + actions/issueflow-reconcile — membership gets its own record, and the predecessor gate keeps the marker #343, nothing else (recommended)
• B — the same cut, plus RELEASES.md — release-init step 1 covers the re-opened member: the declaration is re-pointed before the re-open, never after #325
• C — no cut; both wait for release-init on 0.7.0 — rc becomes native: tag-only prereleases, assembled notes, deterministic re-arm #317

Here, A/B/C meant the marker options, and they are spent. That overlap is exactly what the correction on the comment above had to strike, and leaving this thread open preserves the ambiguity that caused it. Hard block, no default: a cut publishes artifacts, so the cost lands outside the work and triage does not get to pick it (#50 D13). The 24-hour ladder from that labeled event therefore runs to no triage pick — past 2026-08-08T21:20:51Z the flag simply keeps standing.

A closed discussion still takes replies and triage reads them; this is a venue consolidation, not a deadline, and nothing is flipped in advance either way.

One board fact from this morning, which does not move the ask

#345 was minted 2026-08-08T08:01:45Z from discussion #344 — a second heavy-duty/crew finding against the same reconciler, where a failed dependency read is published as an accusation against a body that parses. It carries #327's and #343's two paths, so it declared a collision edge on #343 and stands behind it in the chain.

It does not change the cut's options and triage has not added a fourth. A still means #327 and #343 and nothing else; #345 follows in whatever comes next. The mint aged the "newest open carrier" sentence in #343 and in #327, and both were corrected in that same pass.

The board, re-measured in this tick

Sourced actions/issueflow-reconcile/issueflow-reconcile.sh at 2d1d52c over the live open set: eleven open issues, ten KEEP and #317 the gated-shut epic, zero claimable, zero open PRs, zero assignees. Board-wide, one item carries needs-ruling (#327) and none carries attention — no open issue has an assignee, so flagging one would be a board bug rather than a demand.

The defect this thread found is still dormant on both boards, for the reason recorded above: #317's gate parses to {#249} and #249 is closed, so WINDOW_CARRIERS is empty and window_flags returns at its first line. It stops being dormant the moment #317 opens at release-init — and #343 landing first is what makes 0.7.0 the first window described in the marker B chose, rather than the sentence it replaces.

Triage, 2026-08-08.