domain:devx 的 pm:queue 里有 63 张未认领卡 。本席逐张读 timeline 的 cross-referenced PR 与其 merged_at,结果:
A 有已合 PR、且零个在开 PR 38
B 有在开 PR 0
C 完全没有关联 PR 25
⇒ 队列长度 63,而其中 38 张至少有一个 PR 已经合进去了。 ⚠️ 这 38 张不 等于「38 张已经做完」——见下「⛔ 没量的部分」。但它是一个必须逐张验的候选集,而没有人在验 :席位按取卡全序取卡时读到的是「63 张待办」。
⚠️ priority: 与 domain: 故意留空 —— 分诊的活,不是本席的。
本班的三个实例 —— 三张里有两张本该早就关掉
本席今天按全序取卡,连续三张 都撞上这个形状:
卡
读了它自己写下的关闭条件后发现
处置
#15815
两半都落了(AGENTS.md:599-605 就在 main 上),卡自己写着「it closes when #15885 lands 」,而 #15885 已合
先立 #18343 接出线程上三条别席位的事后读数,再关
#16529
第 1 段刚由本席派发落地;第 2、3 段是真余项(第 2 段还撞人工地板)
正确地留在队列 ,回 pm:queue + Release: 行
#16565
三项全落(.mdx / skills/** / stack.zod.ts 各带内容探针),只剩一项两次被判「可选」且前一任明确不取
先立 #18364 接出第 4 项,再关
⇒ 三张里 #16529 是健康的 (有真余项),另外两张的活已经干完,只是没人回去读关闭条件 。⭐ 这个比例本席不外推,但它是本卡的起因。
成因(已知的那一段)
#15815 线程上记着:2026-09-09 维护者把「C 桶那 24 张」批量转回 pm:queue 。批量转移把状态改对了,⛔ 但没有人逐张重读关闭条件 —— 而其中一部分在等待期间已经被别的 PR 交付掉了。
⚠️ 误落 pm:awaiting-maintainer 的根因另见 #17017 (该状态有语义契约、零机器载体)。本卡说的是下游 :批量转回队列之后没有回验这一步。
为什么要紧
席位会去派发已经做完的活。 本席今天三次差点这么干,每次都是靠「派发前先重读关闭条件」这条自订规矩拦住的 —— ⛔ 那条规矩不在任何仓内文本里,是本席今天现编的。
队列长度是个假数。 63 与「真正待办」之间差多少没人知道,而取卡全序、优先级排序、批次决策全都读它。
⭐ 关掉一张活已干完的卡不是零成本 :它线程上常挂着别席位事后量的读数,直接关会把它们一起埋掉([finding] git merge-tree honours merge=os-regen, so a local mergeability probe reports MERGES CLEAN where GitHub reports dirty — and the probe writes os-regen-pending into the SHARED git dir #15815 上有三条,写在那里的理由逐字是「a second card would be invisible to whoever fixes this one」)。⇒ 清理必须先接出残留再关 ,⛔ 不能一把梭。
验收(⛔ 不规定实现)
⭐ 逐张判,⛔ 不批量关。 对 A 桶 38 张,每张读:关联的已合 PR 是带闭合关键字 还是 Part of?卡自己写下的关闭条件满足了吗?余项是什么?
⭐ 关之前先把线程上别席位的事后读数接成新卡 ([finding] git merge-tree honours merge=os-regen, so a local mergeability probe reports MERGES CLEAN where GitHub reports dirty — and the probe writes os-regen-pending into the SHARED git dir #15815 / [finding] Nothing an app author reads says a type: 'app' package may hold only ONE app — the ui skill and ui/audience-based-interfaces both omit it, and ADR-0019 is two different records #16565 的做法),⛔ 不许直接关。
⛔ 不许拿「有已合 PR」当关卡判据。 Part of 的卡有已合 PR 且必须留着 (A consuming repo cannot ask "was this dist built from the tree I pin?" — the content stamp already exists, covers only the AMPLIFIERS list, and is not readable across the repo boundary #16529 就是),这是 H49 管的形状。
⭐ 若判定这一步该常态化,把它做成可复跑的读数 而不是一次性清理 —— 否则下一次批量状态转移会重新长出同一条尾巴。⛔ 本卡不指定它该是巡查器的一行、一个 scripts/pm/ 探针,还是别的。
⛔ 不许为了缩短队列而放宽任何卡的关闭条件。
⛔ 没量的部分,不许当读数用
⛔ 38 不是「38 张已做完」。 本席没有 逐张查这些已合 PR 带的是闭合关键字还是 Part of,也没有 查任何一张的关闭条件是否满足。⇒ 候选集,不是缺陷数。
⛔ 没量这 38 张里有多少属于那「C 桶 24 张」,有多少是别的来路。
⛔ 只量了 domain:devx 一条车道的未认领卡。其余车道没查 ,⚠️ 但成因(批量状态转移)与车道无关,⇒ 其它车道很可能有同形的尾巴,这是推测,不是读数 。
⛔ 判据是 timeline 的 cross-referenced 事件 + pull_request.merged_at。一个没有 在 timeline 上留下 cross-reference 的交付(例如 PR 正文只用分支名影射本卡)这个方法看不见 ⇒ C 桶 25 张可能偏高 。
发火对照 :本班本席新立的四张卡(#18211 #18224 #18225 #18341 )全部落在 C 桶 (没有关联 PR),与事实相符 ⇒ 分桶仪器会动。
Refs:#15815 (实例一,已关)· #16529 (实例二,健康余项)· #16565 (实例三,已关)· #18343 / #18364 (关卡前接出的残留)· #17017 (误落 awaiting 的上游根因)
domain:devx 执行席 · 座位贴 #6023 · 63 张卡逐张读 timeline,取数于 2026-09-16T05:1xZ
Generated by Claude Code
domain:devx的pm:queue里有 63 张未认领卡。本席逐张读 timeline 的 cross-referenced PR 与其merged_at,结果:⇒ 队列长度 63,而其中 38 张至少有一个 PR 已经合进去了。⚠️ 这 38 张不等于「38 张已经做完」——见下「⛔ 没量的部分」。但它是一个必须逐张验的候选集,而没有人在验:席位按取卡全序取卡时读到的是「63 张待办」。
priority:与domain:故意留空 —— 分诊的活,不是本席的。本班的三个实例 —— 三张里有两张本该早就关掉
本席今天按全序取卡,连续三张都撞上这个形状:
AGENTS.md:599-605就在 main 上),卡自己写着「it closes when #15885 lands」,而 #15885 已合pm:queue+Release:行.mdx/skills/**/stack.zod.ts各带内容探针),只剩一项两次被判「可选」且前一任明确不取⇒ 三张里 #16529 是健康的(有真余项),另外两张的活已经干完,只是没人回去读关闭条件。⭐ 这个比例本席不外推,但它是本卡的起因。
成因(已知的那一段)
#15815线程上记着:2026-09-09 维护者把「C 桶那 24 张」批量转回pm:queue。批量转移把状态改对了,⛔ 但没有人逐张重读关闭条件 —— 而其中一部分在等待期间已经被别的 PR 交付掉了。pm:awaiting-maintainer的根因另见 #17017(该状态有语义契约、零机器载体)。本卡说的是下游:批量转回队列之后没有回验这一步。为什么要紧
git merge-treehonoursmerge=os-regen, so a local mergeability probe reports MERGES CLEAN where GitHub reportsdirty— and the probe writesos-regen-pendinginto the SHARED git dir #15815 上有三条,写在那里的理由逐字是「a second card would be invisible to whoever fixes this one」)。⇒ 清理必须先接出残留再关,⛔ 不能一把梭。验收(⛔ 不规定实现)
Part of?卡自己写下的关闭条件满足了吗?余项是什么?git merge-treehonoursmerge=os-regen, so a local mergeability probe reports MERGES CLEAN where GitHub reportsdirty— and the probe writesos-regen-pendinginto the SHARED git dir #15815 / [finding] Nothing an app author reads says atype: 'app'package may hold only ONE app — the ui skill andui/audience-based-interfacesboth omit it, andADR-0019is two different records #16565 的做法),⛔ 不许直接关。Part of的卡有已合 PR 且必须留着(A consuming repo cannot ask "was this dist built from the tree I pin?" — the content stamp already exists, covers only the AMPLIFIERS list, and is not readable across the repo boundary #16529 就是),这是 H49 管的形状。scripts/pm/探针,还是别的。⛔ 没量的部分,不许当读数用
Part of,也没有查任何一张的关闭条件是否满足。⇒ 候选集,不是缺陷数。domain:devx一条车道的未认领卡。其余车道没查,cross-referenced事件 +pull_request.merged_at。一个没有在 timeline 上留下 cross-reference 的交付(例如 PR 正文只用分支名影射本卡)这个方法看不见 ⇒ C 桶 25 张可能偏高。发火对照:本班本席新立的四张卡(#18211 #18224 #18225 #18341)全部落在 C 桶(没有关联 PR),与事实相符 ⇒ 分桶仪器会动。
Refs:#15815(实例一,已关)· #16529(实例二,健康余项)· #16565(实例三,已关)· #18343 / #18364(关卡前接出的残留)· #17017(误落 awaiting 的上游根因)
domain:devx执行席 · 座位贴 #6023 · 63 张卡逐张读 timeline,取数于 2026-09-16T05:1xZGenerated by Claude Code