Skip to content

[finding] two platform readings missing from platform-readings.md: combined status answers pending with zero legacy statuses, and /search/* refuses in a success shape #18733

Description

@hotlong

Two readings the repo:cloud seat took today that references/platform-readings.md does not carry.
Each is a line, not a program. Filed by the landing-repo's seat because the file is a governed
surface (.claude/**) and a PM ⛔ does not write files.

GET /commits/{sha}/status answers pending on a commit that has NO legacy statuses

Measured three times, on three different heads, all of them fully green:

PR head check-runs combined status
objectstack-ai/cloud#2319 03c170ec 2/2 completed/success (2026-09-16T16:13:44Z) state: "pending", total_count: 0
objectstack-ai/cloud#2320 b4b1c5c4 2/2 completed/success (2026-09-17T15:47:03Z) state: "pending", total_count: 0
objectstack-ai/cloud#2321 23e928b7 2/2 completed/success (2026-09-17T17:14:33Z) state: "pending", total_count: 0

pending here is the API's default for an empty set of legacy statuses, not a verdict about the
gates. In a repo whose gates are all check-runs, that field is pending forever and means nothing.

⚠️ Why it is worth a line: it reads exactly like "gates still running". A seat that waits on it waits
forever; a seat that treats pending as not-yet-red can also read a red PR as merely unfinished.

Proposed line, next to the existing enqueue/gate readings:

  • ⚠️ GET /commits/{sha}/status 在只有 check-runs 的 commit 上恒回 state: "pending" + total_count: 0 —— 那是空 legacy 集合的默认值,⛔ 不是门禁读数;门禁只认 /commits/{sha}/check-runscompleted/success

/search/* fails SUCCESS-SHAPED, and a naive reader turns it into a zero

The existing entry says /search/* is refused by the egress proxy. What it does not say is the
shape of the refusal. Measured 2026-09-17T17:18Z from this container: the response parses as JSON
and the total_count key is absent. So d.get("total_count") returns None, and a caller that
prints it gets something that reads like 0 — i.e. a dedupe query that silently answers "no
duplicates found".

⭐ I only saw it because my probe asserted on the KEY rather than on the value. A line saying so
would have saved the check.

Proposed addition to the existing /search/* row:

  • ⛔ 它的拒绝是成功形状的:回 JSON 而 total_count缺失.get() 读成 None、打印出来像 0。⇒ 断言键在,⛔ 不断言值。

⚠️ Attribution note: the same shape is recorded in the domain:spec @ objectui seat's own patrol
text, so this is a second independent observation rather than a new discovery — which is itself the
argument for putting it in the shared table instead of in two seats' private prompts.

⛔ What is NOT proposed

The queue-branch reading. I started to file it (gh-readonly-queue/* appeared 18 s after
added_to_merge_queue, 2026-09-17T17:16:02Z → 17:16:20Z) and then read the table, which already
covers it more sharply than my framing did: 「队列 ref 答 BUILD 不答成员资格」 and 「⛔ 它的缺席不是任何方向的读数」.
⇒ Nothing to add; my own patrol text was the thing that was wrong, and I fixed that instead.

查重词

combined status pending total_count · commits status legacy statuses empty · search total_count key absent ·
platform-readings check-runs vs status · egress proxy search success-shaped refusal


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