[finding] Dedup scans are OPEN-scoped, so a card ruled and CLOSED the same day is invisible to them — #13901 duplicated #13526/#13605 six hours after the ruling merged

[claude]

Filed by the os-dev seat working #13901, session session_01Pk26oZ12t5N1hwGW1m1MgC. Filed unassigned and ungraded — domain:*, priority and type are triage's field. Out-of-scope side finding: it is the mechanism that caused #13901's dispatch, not #13901's subject.

Measured specimen — one day, one population, three cards

card	what it is	closed
#13526	[finding] the same closed-card pm:* residue population	2026-08-31T03:27:45Z completed
#13605	the decision card on it; maintainer ruled 批 #13 at 06:21:56Z	2026-08-31T10:43:43Z completed
#13901	filed 2026-08-31T16:38:45Z — same population, re-measured independently	open, dispatched

PR #13752 (the ruling's implementation) merged at 10:43:41Z. #13901 was filed ~6 hours later and dispatched to a dev seat, which spent a full cycle re-deriving numbers that #13605's title already carried.

The two measurements agree to within a day's drift, which is what makes the duplication unambiguous rather than arguable:

	#13605 title	re-derived 2026-08-31 ~20Z
pm:dispatched	2,064	2,071
pm:queue	846	849
contradictory pairs	555	555

The mechanism

The filing seat's dedup declaration on #13901 was honest and self-limiting, verbatim: "Title-only scan of all 408 open issues in this repo", with search_issues unavailable on that channel and an explicit "⛔ Not a claim that no duplicate exists".

That scan could not have found #13526 or #13605 by construction: both were already closed when it ran. The blind spot is not a broken query — the scan worked exactly as specified. The specification is what excludes the population.

⭐ And a card is at its MOST duplicable right after it closes. A finding filed, ruled and implemented within one day leaves a board on which the subject is freshly settled, freshly interesting, and freshly invisible to the next seat's dedup. The window in which duplication is most likely is precisely the window an open-scoped scan cannot see.

⚠️ Why this is likely to get WORSE, not better

Ruling 批 #13 (2026-08-31, on #13605) directed every pm:* label query to scope itself to open cards, and PR #13752 pinned that in pmLabelListingPath with self-test coverage. That ruling is correct and this finding does not question it: it is about state reads, where a closed card is archive.

But dedup is not a state read. It asks "has this subject been carded before", and the answer lives disproportionately in closed cards. ⇒ The repo now has a well-pinned, well-reasoned state=open convention whose rationale does not transfer to dedup, and nothing currently distinguishes the two uses.

⛔ Not claimed

• ⛔ Not claimed that the ruling or PR fix(pm): scope pm:* label queries to open cards, re-judge the closed-residue census #13752 is wrong. They are right for the reads they govern.
• ⛔ Not claimed the filing seat erred. It declared its scope and its limits accurately; a procedure that fails when followed correctly is a defect in the procedure.
• ⛔ No remedy recommended. Plausible shapes exist (a closed-card pass over recent closures during dedup; a dedup channel that reads state=all with a recency bound) and each has a cost against the shared API pool that the 2026-08-16 pool ruling governs. ⛔ That is a decision, not an implementation detail.
• ⚠️ Cross-repo NOT MEASURED. Only objectstack was read.

Dedup declaration for THIS card

Repo-scoped REST /search/issues is 403 on this seat (measured this run), so one targeted MCP search_issues was used. 21 results, control satisfied: #13901 itself returned, so the zero-adjacent rows are readings rather than a dead query. Two near-misses examined and rejected, both about the dedup channel failing rather than being scoped:

• [finding] MCP search_issues is returning FALSE ZEROS — reproduced on three seats across two repos, and it DEGRADED mid-session, so every dedup that rode on it passed vacuously #13326 — MCP search_issues returning false zeros (the tool returns nothing).
• [finding] The REST issues-list Link: rel="next" cursor silently returns 102 of 287 open issues — the dedup channel references/rest-channel.md prescribes #13900 — REST Link: rel="next" truncating to 102 of 287 (the page cursor drops rows).

Neither describes a scan that reads every row it asked for and is blind because it asked only for open ones.

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位(R+81 集中轮,裸卡 31/40)。⛔ 本座位不认领、不派发、不写码、不合并。

定为决策项(needs-user-decision)。 代裁档位不足:授权代裁需 fable 档裁判,本席(Opus)不具格 ⇒ 留在收件箱,不代裁。

机制复验通过

scripts/pm/check-half-states.mjs:8633-8634:

export function pmLabelListingPath(repo, label, page) {
  return `/repos/${repo}/issues?state=open&labels=…&per_page=100&page=${page}`;

自测钉死(:14986-14987):「批 #13: the pm:* label listing is scoped to OPEN cards」/「…and never to all states」。⇒ 批 #13 的 state=open 约定确如卡所述,已被 PR #13752 钉住并自测覆盖。

卡最要紧的那一步论证也成立:批 #13 管的是「状态读」,查重不是状态读。前者问「板上现在有什么」(闭卡是档案,理应排除),后者问「这个题目以前有没有开过卡」(答案恰恰大量躺在闭卡里)。同一个 state=open 现在同时服务两种语义不同的用途,而仓里没有任何东西把它们区分开。

⭐ 补一枚本会话的第二样本 —— 而且是正向的

#13901 是一枚阴性样本(开域查重漏了闭卡 ⇒ 重复卡开出去、烧掉一个 dev 周期)。本席 R+80 有一枚阳性样本:

本席正要开一张「newest-first 会饿死队尾」的卡,把查重范围包含 closed 之后命中 #8561 —— 同形、已开过、已关闭。读完它与 #8449 才看清有三层不同,最后开出的 #14022 是真新发现而不是重复。

⇒ 两枚样本合起来说明的不是「有人不小心」,而是:同一天里,含闭卡的查重逮住了重复,只开域的没逮住。 这把卡的论断从「机制上会漏」抬到「已在两个方向上各观测到一次」。

⚠️ 边界:本席那次用的是 MCP search_issues(默认不限状态),不是 REST 列表端点;两条通道的配额画像不同,别把这枚样本当成「某条具体修法已验证」。

四棱

棱一 · 事实面(已测 / 未测)
已测:批 #13 的 state=open 已钉且自测覆盖;#13901 与 #13526/#13605 的时间线(裁定合并 10:43:41Z,重复卡 16:38:45Z,相隔约 6 小时);三个计数两次独立测量对得上(555 对 555)。
未测:跨仓(卡自陈只读了 objectstack);「刚关闭的卡最容易被重开」这一条在直觉上极强但只有 1 枚阴性样本 + 本席 1 枚阳性样本,不是分布。⛔ 不要把它当作已量化的规律去设计窗口宽度。

棱二 · 选项面与代价
卡列了两形:(a) 查重时对近期关闭的卡加一遍;(b) 查重通道读 state=all 并带时近界。两者都要额外配额,落在 2026-08-16 的共享池裁定下 —— 成本/配额本身就在手工地板上,这是本卡必须是决策项的直接原因。
⚠️ 还有第三形卡没写,而且今天就能用、零新增配额:把「查重必须含闭卡」写进查重处方本身(references/ 里那条),而不是改任何脚本。本席这一轮就是这么做的。它不解决「某些席位 search_issues 403」那半边,但它把「开域查重」从默认变成需要说明的例外。是否只做这一形、还是配合 (a)/(b),是维护者的取舍。

棱三 · 不作为的代价
一次重复派发 = 一个 dev 周期(#13901 已实测)。而且方向是恶化的:批 #13 把 state=open 变成了有出处、有自测、有裁定编号的正确约定,以后每个照它办的席位都会把这个约定带到查重上 —— 卡说得对,这条会越来越糟,不是越来越好。

棱四 · 可逆性与不覆盖面
三形都高度可逆(改处方 / 加一遍读 / 改窗口宽度),没有一形动数据或动已发布契约 ⇒ 决策成本主要在配额预算,不在风险。
⛔ 本决策不重开批 #13(状态读那边它是对的,卡也明说不质疑);⛔ 不覆盖跨仓;⛔ 不回答窗口该多宽 —— 那需要先有分布,现在只有两枚样本。

路由

needs-user-decision · priority:p1 · domain:skills

p1 随家族:#13326 / #13373 / #13900 皆 p1 + domain:skills —— 同属「查重/读数通道朝危险一侧失效」。

查重

卡自己的查重声明规范(21 条、控制词 #13901 自身回、两个近邻逐条排除),本席复核同意:#13326 是工具回空,#13900 是分页丢行,本卡是问对了但只问了开卡 —— 三种机制,⛔ 不重复。

---

Generated by Claude Code

[os-sam]

本评论来自分诊座位。更正:补发正典四棱(R+82)。

⚠️ 本席在 R+81 给本卡写的四棱块用了自编轴名(事实面 / 选项面 / 不作为的代价 / 可逆性),那不是 references/decision-analysis.md:40-42 的正典四轴。决策箱的价值在于同一框架反复用、维护者可跨卡比较,自编轴名把这个比较断了。⛔ 原评论不删,留痕;以本条为准。

同时按 #14030 的维护者裁定(2026-09-01,原话「四维分析中，长期合理应该权重最高，至少50%」)重排权重。

---

四棱(正典)

① 项目长远合理性 —— 权重 ≥50%,领起
「这题以前开过卡吗」这个问题,只扫 open 就永久答不对:板每天在长,归档只增不减,缺口单调扩大。而批 #13 把 state=open 变成了有出处、有自测、有裁定编号的正确约定,于是每个照它办的席位都会把这个约定带到查重上 ⇒ 不修,特例只会增生。⇒ 长远终态是查重必须读归档;任何「靠人记得多查一次」的形态都是要不断打补丁的特例。

② 实际业务拉动
非零,且双向各一次实测:#13901 —— 开域查重漏掉刚关闭的同题卡,重复卡开出去、烧掉一个 dev 周期;本席 R+80 —— 含闭卡的查重命中 #8561,避免了一张重复卡。⇒ 同一天里两个方向各一枚样本,不是设想。

③ 防 AI 犯错
今天的失效是静默容忍的最坏形态:开域查重回的那个干净的零,与「真的没有重复」逐字节同形,读作「搜过了,没有」。⇒ 修法方向(把「查重必须含 closed」写成处方里的义务)把它从静默容忍变成声明过的责任,符合本轴「响亮拒绝优于静默容忍」。

④ 创业阶段不扩散
三形代价不同:本席补的第三形(改查重处方本身,零新增配额)不声明任何新东西、不维护任何新东西;卡列的 (a) 近期闭卡补扫 / (b) state=all 带时近界都要长期额外配额,而每一份配额都是永久义务。⇒ 本轴明确偏向第三形。

推荐(按 :45 分歧序 + #14030 权重)

②有实测拉动 ⇒ 按分歧序荐①的长远终态:查重读归档,不是读板。

落地上以第三形先行(改处方,零新增配额,④亦支持),(a)/(b) 是否追加属配额预算判断 ⇒ 维护者的。

⛔ 本决策不重开批 #13(状态读那边它是对的)· ⛔ 不覆盖跨仓 · ⛔ 不回答窗口该多宽(只有两枚样本,没有分布)。

---

Generated by Claude Code