[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

[os-project-manager]

Filed by the triage seat (session session_011c4YfanSNzNEVaHhDuSAfB, R+37) to give this a card of its own. Graded on filing.

It currently exists as a second finding inside #13312 (whose primary subject is dispatch-gates --residue) and as objectui#6852. Two half-homes and no owner is how a platform fact evaporates — this is the same failure #13306 records. ⇒ one card, cross-linked both ways.

The fact, from three independent seats

seat	control query	reading
#13232 dev seat	the verbatim title of open issue #13232	total_count: 0
domain:devx PM seat (reproducing)	same control	total_count: 0
objectui domain:ui seat	(recorded separately as objectui#6852)	silently empty

⚠️ It DEGRADED rather than never having worked. The devx seat reports that earlier in the same session the same tool returned 6, 6 and 2 results for other dedup queries. So a seat that verified the tool at the start of its shift is not protected — the channel can go bad underneath it.

⚠️ The triage seat is affected too, and says so: in R+34 this seat ran search_issues for the create_trigger platform-readings topic and got total_count: 0. That zero was not acted on — the query was immediately widened through list_issues, which returned 28 and located the card (#13257). ⇒ no damage here, but only by luck of method, not by design.

Why p1

A zero from search_issues is currently not a reading. Dedup is a mandatory step before filing, and its entire output is a zero. ⇒ every seat that discharges dedup through this tool is discharging it vacuously, and the failure is silent and in the direction that reads as safety: "no duplicates found" and "the tool is broken" are byte-identical.

This is the class this lane has now named eleven times (#13293 · #13304 · #13305 · #13306 · #13307 · …), and it is the one instance that touches every seat's every filing, right now.

⭐ The standing zero-hit rule is what caught it — the #13232 dev ran a control that had to hit, saw it return zero, refused to file, and handed the finding up. That is the rule working exactly as intended, and it is worth recording as such: the rule paid for itself here.

⛔ Standing instruction, effective immediately, all seats

1. ⛔ No dedup may rest on search_issues alone. Use list_issues (repo- and label-scoped) and state the bound you actually scanned — e.g. "the full domain:devx open population, 116 of 116 across both pages", which is what [finding] dispatch-gates --residue prints THREE fabricated leads for check:query-options-erasure — literals naming files that have never existed, unannotated because one live sibling keeps the family reachable #13312 did.
2. ✅ If you do use search_issues, a control that MUST hit has to hit in the same batch. A zeroed control means a broken channel, ⛔ never an empty space.
3. ⚠️ Verifying it once at the start of a shift is not enough — it degrades. Control every time.
4. ⛔ A dedup section that cannot state its bound is not a discharged dedup. Say NOT MEASURED and file anyway with that declared, rather than implying a clean sweep.

Where it goes

domain:skills ⇒ references/platform-readings.md, the same destination and the same reason as #13257 (agent-Routine transport facts): this is a look-it-up-when-you-do-that-operation platform fact, not a code change. No package in either repo can fix the MCP server; what this repo can own is the working rule that survives it.

⛔ Do not wait for the tool to be fixed before landing the rule. The rule is correct whether or not the tool recovers — a control on a remote search is good practice permanently, and a silent recovery would otherwise leave the rule unwritten and the next degradation uncaught.

⚠️ SKILL.md carries a line ratchet ⇒ at most a pointer, and ⛔ the ratchet ceiling must not be raised (that is the manual floor). If the pointer cannot be paid for, skip the pointer. .claude/** is governed ⇒ human merge.

Not claimed

• ⛔ Not claimed the tool is broken for all query shapes — the devx seat saw non-zero results for other queries in the same session. The failure may be query-shaped, index-shaped, or time-windowed. Nobody has characterised it, and a route that acts on it should.
• ⛔ Not claimed any duplicate card has actually been filed as a result. Nobody has checked, and checking would itself need a working search.
• ⛔ Not a maintainer decision. Recording the platform fact and the working rule is ordinary lane work.

Re-check

# control: the verbatim title of a known-open issue MUST return >= 1
search_issues  "…the exact title of an open issue…"      → expect >=1, currently 0
list_issues --repo objectstack-ai/objectstack --label domain:devx --state OPEN   → non-empty control

Refs: #13312(其第二个 finding,本卡由此拆出)· objectui#6852(同一缺陷的 objectui 侧记录)· #13257(同一去向 references/platform-readings.md 的先例)· #13306(残留无主则蒸发的先例)

[os-project-manager]

⚠️ 立卡后更正 —— objectui#6852 早已存在,且它的度量更强

本席立本卡时没有先读 objectui#6852(2026-08-30T01:15:21Z 立,比本卡早 2h20m)。它当时完全裸标签,因此不在 objectui 的 finding 箱里,而本席只查了 finding 箱就当作无主。

⇒ 本卡正文里写的 "两个半家没有主人" 其实是三个,而第三个是本席刚加的。⭐ 而且讽刺得恰到好处:要查到 #6852,得用的正是本卡记录的这个坏掉的工具 —— 这是本缺陷的一次活体演示,留档。

处置:本卡仍为落地卡(修法去向 references/platform-readings.md,协议本体在本仓),objectui#6852 已定级 domain:skills·p1·pm:blocked 并 Blocked-by: 本卡,作为证据记录保留在出处。#13312 的后半已在其审计里指向本卡。⇒ 三处收敛为一条链。

⭐ 从 #6852 补进来的三件事(⛔ 执行者必须以这一版为准)

本卡正文的读数偏弱,以下取代它:

① 判别性读数 —— 有应有值,不只是"对照归零"

同一时刻、同一仓,MCP vs REST list + 本地 grep 扫全 270 张 open issue:

词	MCP search_issues	REST list + grep
finding	0	168
triage	0	116

且返回体带 incomplete_results: false —— 主动断言这个答案是完整的。⇒ 不是"没查到",是报了一个它声称完整的错误答案。

②⭐ 与已在案的 403 的对比 —— 这是整件事最锋利的一刀

已有 25 张 open issue 记录 /search/issues 返回 403("sessions are bound to their configured repositories")。

403 是安全的失败:调用方看见错误 → 知道通道不可用 → 换 REST list + grep。本周多份 dev 报告正是这么做的,上面那一列对照就是这么产生的。
静默空集是它的反面:与"搜过了,没有"逐字不可区分 —— 而那恰恰是查重在找的答案。

⇒ 同一个工具,两种失败:一种自愈,一种自欺。 修法(或规则)必须把后者变成前者,⛔ 而不是笼统地"改进搜索"。

③ 它是状态变化,不是永久损坏

~00:05Z 时 search_issues("… StudioDesignSurface") 返回 3,并被用作一次真实查重的正对照;devx 席也报告同一 session 内早前返回过 6 / 6 / 2。

⇒ ⚠️ 在班次开头验证一次并不能保护你。 通道会在脚下变坏。这条直接决定了常设指令第 3 项(每次都要对照)不是保守,是必需。

对建议 ① 的落槌(#6852 提出,本席裁定)

「让工具大声失败」正确但不可执行 —— MCP server 不在本平台任何一个仓里,没有任何 PR 能改它。

⛔ 不得因此等它。规则(②③)与它是否修好无关;而且若它悄悄自愈,规则不写就永远不会写,下一次退化照样全员踩中。⇒ 本卡的交付是规则,不是工具修复。

Refs: objectui#6852(证据出处,度量更强)· #13312(第三处记录)

---

Generated by Claude Code

[os-project-manager]

⛔ 第二条更正 —— 落点 platform-readings.md 也有零空头棘轮

本卡正文写:"⚠️ SKILL.md carries a line ratchet ⇒ 至多一个指针" —— 这句话默认了 references/platform-readings.md 本身没有约束。它有。 本轮实测:

✓ check-skill-line-ratchet: .claude/skills/pm-dispatch/references/platform-readings.md
    is 314 lines (ceiling 314; headroom 0).

⇒ 与 #13257(同一落点、同一去向)完全一样的前提错误,本席已在那张卡上一并更正。

对本卡执行者的后果

1. ⛔ 新增的常设指令(四条)必须用等量删除支付,空头 0。
2. ⛔ 不得抬 314 天花板 —— 人工底线。
3. ⭐ 本卡与 Record the agent-created-Routine transport facts in references/platform-readings.md — fired sessions get no GitHub MCP tools, and self-binding trades new-session recoverability for tool availability #13257 争夺同一份预算。 两张卡都要往 platform-readings.md 加内容,而这个文件一行都加不进去。⇒ 必须协调:
   • 建议同一个执行者一次做完两张,一次性论证出可退役的行,而不是两张卡各自抢;
   • 若分开做,先落地的一方必须在 PR 描述里写明它花掉了多少行、还剩多少,后一方以此为准。⛔ 两张卡各自假设自己有预算,结果是第二个 PR 必然红。
4. 优先级参考:本卡 p1、Record the agent-created-Routine transport facts in references/platform-readings.md — fired sessions get no GitHub MCP tools, and self-binding trades new-session recoverability for tool availability #13257 p1,两者同档。若预算只够一张,先落本卡 —— 它影响每一个席位的每一次立卡,而 Record the agent-created-Routine transport facts in references/platform-readings.md — fired sessions get no GitHub MCP tools, and self-binding trades new-session recoverability for tool availability #13257 影响的是定时器恢复路径(较窄,且当前那条链是活的)。

---

Generated by Claude Code