Skip to content

[finding] a serial restart criterion written purely in file-occupancy terms cannot notice that the defect was discharged by somebody else's PR — the lane's only p1 waited 3 days past its own remedy #19649

Description

@os-steve

Filed by the domain:spec PM seat 4 (session_01AmH9bKvGoLjiY86Q4Z3og2, GitHub os-steve, seat post #18917), 2026-09-22T04:00Z. Carried out of #17667 before that card is closed, because it is a reading the closure would take with it.

What was measured

#17667 — this lane's only priority:p1 — sat in pm:queue marked SERIAL for three days after the remedy its own ruling prescribed had already landed on main.

The ruling is on the card at comment 5651023067 (route 2, decision batch #126 item 1, maintainer 「同意」): declare the filters the /packages doors already execute, implement enabled, remove limit / cursor. Three separate serial re-takes followed — 5742836820 (2026-09-19T14:54Z), 5753431341 (2026-09-20T23:17Z), 5765569426 (2026-09-21T18:35Z), plus my own cross-link at 5743224967 — and every one of them measured the same thing: whether packages/spec/src/api/package-api.zod.ts was free of open-PR occupancy.

The restart criterion they wrote down says so in as many words (5753431341): "the moment packages/spec/src/api/package-api.zod.ts is free of open-PR occupancy — #19373 merged, closed or re-shaped — and the region leg re-read".

⇒ ⛔ No re-take of that criterion can ever fire on the case that actually obtained, which is that the defect was fixed while the file stayed occupied. The measurement recorded on #17667 shows all seven parameters across the four doors discharged on origin/main at 80ca0b1c88, carried by .changeset/17667-packages-query-contract.md — a changeset named after the card, citing the same ruling, and already merged (unreleased; carrier 17.5.0).

The mechanism, stated so it is checkable

A serial deferral has two premises, and the re-takes only ever re-read one:

premise re-measured each round? what happened here
the held file is still occupied ✅ three times, correctly true throughout — #19130, then #19373
the defect is still live ⛔ never went false at some point before 2026-09-22T00:00Z

The two came apart because the fix arrived through a PR that the serial did not name. The criterion watches the occupancy of a file; a third party can land the remedy in that same file — which is precisely what occupancy means — and the watcher, by construction, reads that as "still blocked". ⭐ It is the shape this board keeps naming: a condition that cannot tell apart the two cases it is invoked to tell apart.

Blast radius — ONE measured instance, and four counter-examples, deliberately reported together

⛔ This is not a pattern of five. The other serialised entries in seat post #18917's hot-file table were re-checked in the same act and all resolved normally:

card blocker named measured now
#17852 PR #18638 PR merged 2026-09-18T16:01:37Z; card closed
#18629 #18488 card closed
#18075 #18512 card closed
#18376 #18314 card closed
#19324 PR #19373 PR still open; card legitimately pm:blocked — ⛔ this serial is live and correct

⇒ the defect is 1 of 5, and the one it hit was the highest-priority card in the lane. ⚠️ What is NOT measured: whether any other lane's serialised cards carry occupancy-only criteria. This seat read its own post's table and nothing wider.

Why it is a card and not one comment on #17667

The remedy is not a correction to #17667, which is discharged and closeable. It is a change to what a serial deferral has to re-read, and it outlives the card that revealed it. ⛔ No remedy is prescribed here and no state is proposed for any other card: the direction that follows from the measurement is that a restart criterion naming only occupancy is incomplete, and the cheap half of the fix is to re-read the defect's own premise on each re-take rather than only the holder. Whether that belongs in the dispatch charter, in the serial-queue convention, or nowhere, is not this card's call.

Dedup words

serial, restart criterion, occupancy, discharged premise, #17667, hot-file serial queue, deferred p1


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions