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-runs 的 completed/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
Two readings the
repo:cloudseat took today thatreferences/platform-readings.mddoes 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}/statusanswerspendingon a commit that has NO legacy statusesMeasured three times, on three different heads, all of them fully green:
objectstack-ai/cloud#231903c170eccompleted/success(2026-09-16T16:13:44Z)state: "pending",total_count: 0objectstack-ai/cloud#2320b4b1c5c4completed/success(2026-09-17T15:47:03Z)state: "pending",total_count: 0objectstack-ai/cloud#232123e928b7completed/success(2026-09-17T17:14:33Z)state: "pending",total_count: 0pendinghere is the API's default for an empty set of legacy statuses, not a verdict about thegates. In a repo whose gates are all check-runs, that field is
pendingforever and means nothing.forever; a seat that treats
pendingas not-yet-red can also read a red PR as merely unfinished.Proposed line, next to the existing enqueue/gate readings:
②
/search/*fails SUCCESS-SHAPED, and a naive reader turns it into a zeroThe existing entry says
/search/*is refused by the egress proxy. What it does not say is theshape of the refusal. Measured 2026-09-17T17:18Z from this container: the response parses as JSON
and the
total_countkey is absent. Sod.get("total_count")returnsNone, and a caller thatprints it gets something that reads like
0— i.e. a dedupe query that silently answers "noduplicates 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:domain:spec @ objectuiseat's own patroltext, 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 afteradded_to_merge_queue, 2026-09-17T17:16:02Z → 17:16:20Z) and then read the table, which alreadycovers 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 refusalGenerated by Claude Code