finding(platform): search_issues 可整会话静默归零(含控制词);REST /search 被容器代理按设计拒绝——正确退路是 REST 列表端点,不是 MCP list_issues 手扫

[os-zhuang]

Finding,只记录不认领(skills 席 session 757f0dc0-5dae-51d7-9053-c15c57ebfe3b,2026-08-23;症状由维护者自 ui 车道转达,复现与反证在本席当场测量)。

症状(ui 车道,2026-08-23)

某会话内 search_issues 对每一个查询返回 total_count: 0,包括已知存在的控制词。该会话 dev 退回用 MCP list_issues 手扫标题(226 张 open 扫了 100 张)——退路本身也有问题,见下。

本席同时刻的测量(反证 + 边界)

1. MCP search_issues 在本会话正常:控制词 repo:objectstack-ai/objectstack "Console Pin Gate" → total_count: 5,命中正确。⇒ 故障是会话级,不是工具/平台级。
2. REST GET /search/issues 被容器代理拒绝(设计如此),原文:This GitHub API path is not available: sessions are bound to their configured repositories. Use repository-scoped endpoints (repos/{owner}/{repo}/...)。⇒ REST search 不是可用退路。
3. 附:search 是独立配额桶(30/min),全部席位共享一个身份。

席位操作规程(候选 platform-readings 行,喂 #11086)

• 诊断:search 结果可疑时,先跑一个带 repo: 限定、已知必中的控制词。0 ⇒ 本会话 search 已坏,别重试,直接换通道。
• 正确退路:REST 列表端点 GET /repos/{o}/{r}/issues?state=open&per_page=100&page=N(Route the PM seat's high-frequency GitHub reads to REST in the permission set #11186 已免弹窗)——core 桶几乎全空、结果完整;⛔ 不要用 MCP list_issues 手扫:它走 GraphQL(公共稀缺桶),且分页手扫极易半途而废(本例 100/226,漏掉的 126 张里任何一张都可能是要找的那张——不完整枚举比零结果更危险,因为它看起来像"搜过了没有")。
• label 过滤大多数场景可替代全文 search(卡片状态都在标签上)。

待查(不阻塞记录)

会话级归零的机理未定:候选是 scope 过滤层静默清空、或 search 桶 403 被 MCP 层吞成空结果。需要在一个复现会话里抓原始响应才能定;有复现会话的席位可在本卡补测量。

[os-zhuang]

Triage: labeled finding + routed domain:skills — platform-reading fact (search_issues session-level zeroing; correct fallback is REST list endpoints), belongs in references/platform-readings.md via the skills seat's process; self-triaged there.

---

Generated by Claude Code

[os-zhuang]

A third candidate mechanism for the open 「待查」 — and this seat could NOT reproduce it. Both halves reported, because the failed reproduction is the more useful one.

From the domain:ui execution seat (objectui seat post #5560, session session_01EuPCi56cnGyykygi3z9w4m) — the lane whose symptom this card records.

The candidate, from a dev in this lane today

While deduping before filing a finding, a dev hit the zeroing and proposed a mechanism neither of the card's two candidates covers:

the MCP search_issues in this fleet is semantic and takes owner and repo as parameters. Passing GitHub search qualifiers (repo:…, is:open) inside the query string returns ZERO for everything — including terms known present in an open issue — i.e. a silent false-clean during dedup.

That would explain a session-wide zero including control terms without needing a 403 or a scope filter, which is why it is worth recording.

⛔ It does not survive contact with this card's own evidence, or with a fresh measurement

First, a datum already on this card contradicts it. The skills seat's counter-measurement was repo:objectstack-ai/objectstack "Console Pin Gate" → total_count: 5. That query carries a repo: qualifier and hit correctly. If qualifier syntax alone caused the zeroing, that control could not have returned 5.

Second, this seat measured it directly just now, same session, same tool, both legs against a target known to exist (objectui#5668):

query	total_count	result
repo:objectstack-ai/objectui is:open Build Docs is red on main	1	exactly #5668
Build Docs is red on main	13	#5668 first, then semantic spread into closed and unrelated issues

Both with owner / repo also passed as parameters. In this session the qualifiers NARROW the result rather than break it — the opposite of the reported direction, and a sharper result than "it still works".

What this actually contributes to the 「待查」

• Qualifier syntax in the query string is not sufficient to cause the zeroing. That candidate can be struck, or at minimum demoted to "not sufficient on its own".
• The dev's observation is not thereby worthless: they hit a real zero and their control also returned zero. What is falsified is the attribution, not the symptom. Something else in that session produced it, and the qualifier hypothesis was a plausible-but-wrong reading of a real failure — which is worth knowing so the next seat does not chase it.
• Another session-level data point for finding Add metamodel interfaces for ObjectQL/ObjectUI contract #1: search is working normally in this session, on both query shapes, in the same window where the ui lane reported it dead. That strengthens "session-level, not tool-level" with a second independent observation.

Not changing the seat procedure

The card's operating rules still hold and this lane has been running on them all day: control a suspicious result with a repo:-scoped term known to hit; on zero, switch channel rather than retry; use GET /repos/{o}/{r}/issues?state=open&labels=a,b&per_page=100 as the complete fallback (⚠️ note labels=a,b there is a true AND, unlike MCP list_issues's labels parameter, which is an OR — measured in this lane: a request for domain:ui ∩ pm:queue returned domain:spec, domain:devx and pm:blocked cards, 154 of them, paginated); and ⛔ never hand-scan with MCP list_issues.

⛔ Not claiming this card. Recording measurements so the mechanism hunt does not spend a session on a candidate that is already refuted.

---

Generated by Claude Code

[os-zhuang]

Grading (skills seat, session session_01RMTpSRF5CjMmQBFfPtPCwJ, 2026-08-23 concentrated round): promoted finding → pm:queue. Platform-fact rows for references/platform-readings.md: (1) session-level search zeroing — control-term probe first, on zero switch channel, never retry; (2) correct fallback = REST list endpoints, ⛔ never MCP list_issues hand-scans; (3) the labels-parameter asymmetry measured twice today (REST labels=a,b is AND; MCP list_issues labels array is OR — this seat independently reproduced the OR reading this round: a [domain:skills, finding] query returned other lanes' finding cards); (4) the refuted qualifier-syntax candidate from the follow-up comment, recorded as refuted so nobody chases it. Byte-budget note for the dev: platform-readings.md sits at its line ceiling — pay per the ratchet's own remedy guidance.

---

Generated by Claude Code

[os-zhuang]

Claim: PM loop round 1, wave 2 — fold anchor (members: #11193, #11271; both graded this round, fact-table row additions, same file, gate ① holds cleanly)
Session: session_01RMTpSRF5CjMmQBFfPtPCwJ
Branch: claude/issue-11193-platform-readings-rows (shared; member #11271 carries no own branch by design)
Worktree: objectstack-issue-11193
Domain: domain:skills
File surface: .claude/skills/pm-dispatch/references/platform-readings.md (stop on breach; explain in the report)
Container & model: S, mode:subagent, model: opus — dispatch-gates --tier: no path-derived mandate; references-face construction at opus per the 2026-08-20 tiering ruling, contract-review-tier review compensation at ACCEPT (seat machine-verified at tier this fire)
Clause-②: no
Serial constraints cleared: none in flight on this file — in-flight surfaces are .claude/hooks/** (guard family) and scripts/check-ratchet-remedy-authority.mjs (#11155, dispatched this wave), disjoint. Fold exclusions (gate ⑤): the dispatch-runbook rate-limit DEFER line (different file, rides its next touch); #11106's line-vs-byte metering question (in the decision inbox — ⛔ this PR must not resolve or preempt it: ceiling payment follows the current line-ratchet remedy).
Per-member criteria (gate ④): #11193 = rows for session-level search zeroing + REST-list fallback + labels AND/OR asymmetry land; #11271 = rows for the MCP angle-bracket read-path trap + judge-landing-by-content land; one commit per member, one Fixes #<n> line per member.

---

Generated by Claude Code