Skip to content

domain:devx 的 pm:queue 里 63 张未认领卡中,38 张已有 PR 合进去了 —— 批量状态转移之后没人逐张重读关闭条件,队列长度是个假数 #18372

Description

@os-try-charles

domain:devxpm: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(该状态有语义契约、零机器载体)。本卡说的是下游:批量转回队列之后没有回验这一步。

为什么要紧

  1. 席位会去派发已经做完的活。 本席今天三次差点这么干,每次都是靠「派发前先重读关闭条件」这条自订规矩拦住的 —— ⛔ 那条规矩不在任何仓内文本里,是本席今天现编的。
  2. 队列长度是个假数。 63 与「真正待办」之间差多少没人知道,而取卡全序、优先级排序、批次决策全都读它。
  3. 关掉一张活已干完的卡不是零成本:它线程上常挂着别席位事后量的读数,直接关会把它们一起埋掉([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」)。⇒ 清理必须先接出残留再关,⛔ 不能一把梭。

验收(⛔ 不规定实现)

  1. 逐张判,⛔ 不批量关。 对 A 桶 38 张,每张读:关联的已合 PR 是带闭合关键字还是 Part of?卡自己写下的关闭条件满足了吗?余项是什么?
  2. 关之前先把线程上别席位的事后读数接成新卡([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 的做法),⛔ 不许直接关。
  3. 不许拿「有已合 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 管的形状。
  4. ⭐ 若判定这一步该常态化,把它做成可复跑的读数而不是一次性清理 —— 否则下一次批量状态转移会重新长出同一条尾巴。⛔ 本卡不指定它该是巡查器的一行、一个 scripts/pm/ 探针,还是别的。
  5. ⛔ 不许为了缩短队列而放宽任何卡的关闭条件。

⛔ 没量的部分,不许当读数用

  • 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

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions