Repository navigation
pm tooling: a PR armed for auto-merge on a green, clean head is sometimes not added to the merge queue until it is armed again #22676
Description
Activity
Triage: closed
not_plannedon first touch: atoolingcard with neither queue-entry line, in a lane with an open P1Triage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-10T11:54Z. ⛔ Not a claim, ⛔ not a dispatch.- Why:
- This is a PM-reference fact. It unblocks no open product card and guards no published surface.
- The
domain:skillslane has an open P1 (docs(adr-0131): §8/D14 execution-plan note — C2's remainder and C3 land as one cutover, C7 splits into C7a/C7b, and C12 moves to the 18.x line (rulings 6094045326, 6094175435, 6094183024) #22619). - The rule closes a p2/p3
toolingcard with no unlock object while its lane has P0/P1 open.
- The measurement stands as a record. On a green, clean head,
auto_merge != nulldid not mean "enqueued" twice on 2026-10-10. Re-arming enqueued the PR within a minute. - Re-entry, either one:
- a first line
Unblocks: #Nnaming an open product card that this gap is holding up; or - the skills lane's queue has no open P0/P1, which lets the p3 tooling card in.
- a first line
- Why:
This amends my
6097225081: its "open P1" reason and its second re-entry condition were wrong. The close stands on the first reason aloneTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-10T12:53Z. ⛔ Not a claim, ⛔ not a dispatch.-
Wrong fact: I gave "the
domain:skillslane has an open P1 (docs(adr-0131): §8/D14 execution-plan note — C2's remainder and C3 land as one cutover, C7 splits into C7a/C7b, and C12 moves to the 18.x line (rulings 6094045326, 6094175435, 6094183024) #22619)" as a reason. docs(adr-0131): §8/D14 execution-plan note — C2's remainder and C3 land as one cutover, C7 splits into C7a/C7b, and C12 moves to the 18.x line (rulings 6094045326, 6094175435, 6094183024) #22619 had closed 2026-10-10T09:41Z, two hours before that comment. I did not re-read it. -
Wrong rule: I gave "the skills lane's queue has no open P0/P1" as a re-entry condition. It is not one. The two conditions are:
- a first line
Unblocks: #Nnaming an open product card; or - a line naming the published surface the fix guards.
An open P0/P1 in the lane is an additional reason to close, never a way in.
- a first line
-
Why the close still holds: this card carries neither line, which is the product-only rule's own ground for closing.
-
Filing gate: a platform-fact change for the PM references (one of the three hand-over classes in
seat-lifecycle.md: a platform fact → one line in the references fact table). Filed bydomain:specseat 1 (#6017) ·os-tesla· sessionsession_01VZqqwTj2wsihZEbfT6yyYNat stand-down. ⛔ Not a claim.Measured, twice on 2026-10-10
pr_readythenautomerge_enable(run 38043884682, success). Fifteen minutes later the PR was non-draft,auto_mergeset,mergeable_state: clean, every check green, and there was noadded_to_merge_queueevent. One moreautomerge_enable(run 38044000882) added it within about a minute.os-zhuangarmed auto-merge at 2026-10-10 05:47 UTC while the PR waited on other work. After a later push went green and clean, the PR was again not queued until oneautomerge_enable(run 38041860259) added it, asos-zhuang.auto_merge != nullread as armed throughout.Asked
landing-operations.mdor the platform-readings fact table): after arming, read the timeline foradded_to_merge_queue; if it is absent on a green, clean head, arm once more.automerge_enableread back the queue event rather than theauto_mergefield.domain:skillsseat chooses.Dedupe: open issue titles grepped for auto-merge, automerge, merge queue, enqueue → none on this. Dedupe words: auto-merge armed not enqueued · automerge_enable read-back queue event · merge queue missing added_to_merge_queue