bdcc211a0b
Two advisory flags on the issue-flow sweep, the mechanical backstop for #288's collision rule and #292's window rule. Both are prose today, and both failed silently on the same morning: #284 was minted `ready` into a file another issue held claimed with a PR in flight, and six `ready` non-members raced an emptying gate. #262 measured the pattern — the same class of rule, once in a guard, produced zero misses. Comments only (D1): no label write, no state change, no new label. The sweep never guesses intent; it states the board fact and triage resolves. The collision key is the title's em-dash prefix NORMALIZED, because the 2026-08-04 miss spelled one deliverable two ways — `actions/issueflow-reconcile` against bare `issueflow-reconcile` — so exact-prefix matching would have missed the pair it was written for. One leading path segment comes off, then every extension; a `+`-joined title matches on any segment. The flag asks for a CHAIN, not a fan (#288 D3): within one key each issue names the newest open carrier below it, so the declaration it asks for releases exactly one successor per close. A standing window is a release issue whose gate still holds an OPEN member. The board read IS the open set, so membership decides openness with no extra call, and an all-closed gate is the emptied gate the release's own blocked -> ready promotion answers — which is why a `ready` release leaves the flag dormant instead of flagging the whole board. Dedup is the declaration echo's, extracted into state_marker / state_echo_needed and scoped per family (D4): the marker is keyed to the offending state's value and compared against that family's last word on the thread, so a state that changes always speaks. Fixtures replay the 2026-08-04 morning board whole and the post-ruling board beside it: the first draws exactly four collision flags and six window flags and writes not one label; the second draws none. Closes #293. |
||
|---|---|---|
| .. | ||
| 218.md | ||
| 230.md | ||
| 231.md | ||
| 232.md | ||
| 236.md | ||
| 237.md | ||
| 238.md | ||
| 241.md | ||
| 242.md | ||
| 247.md | ||
| 248.md | ||
| 251.md | ||
| 252.md | ||
| 253.md | ||
| 254.md | ||
| 257.md | ||
| 258.md | ||
| 260.md | ||
| 262.md | ||
| 264.md | ||
| 266.md | ||
| 267.md | ||
| 272.md | ||
| 276.md | ||
| 280.md | ||
| 281.md | ||
| 282.md | ||
| 284.md | ||
| 288.md | ||
| 292.md | ||
| 293.md | ||
| 302.md | ||
| 304.md | ||
| README.md | ||
| shape | ||
changelog.d/ — the next release's section, one fragment per issue
Machine-assembled by bin/changelog-assemble (#112): every PR that changes
behavior writes one file here — <issue>.md, the exact prose that will be
published, nothing else — and the release PR folds them all into the next
## X.Y.Z — DATE section of CHANGELOG.md, consuming them. Distinct
filenames never conflict, which is this directory's whole reason to exist.
This README is the marker that keeps the directory tracked when it holds no
fragments (#112 D1) — changelog-armed refuses a tree without it; do not
delete it. The shape sentinel beside it declares the set's shape —
grouped here, so every fragment carries ### headings (#182).