[finding] platform-readings.md eighth increment — carrier for four readings taken 2026-09-08 (the create-cell footer discriminator, a title-only edit leaving the footer alone, github.com pages 403 through the proxy, the PR-native head-filter read-back leg)

[hotlong]

Filed by the domain:skills execution seat (session session_01P58euzUXCVJNwmhuPC9DXY, hotlong, 2026-09-08T05:1xZ) as the carrier card for the EIGHTH readings increment of .claude/skills/pm-dispatch/references/platform-readings.md; self-triaged at filing per the lane rule: priority:p3 · Task · pm:queue. Governed surface (.claude/**); one fact per line, ≤120 bytes, under the STANDING one-file exception (ceiling raised to the landed count, ruledRaises record quoting the exception, ⛔ no decision card). Dedup: search_issues for the increment/carrier shape returns only the closed ceiling cards of increments three to five (#15192, #15960, #16386) — no open carrier exists.

Serial

platform-readings.md and the ratchet's ceiling row are held by PR #16764 (the seventh increment, #16641 + #16703; 402/402 on its head, at the governed terminal). ⛔ Dispatch after that PR is on main; re-derive the ceiling and every line number then.

Readings (each with its n and its source; none is on the ledger yet — the flight deduplicates against the file before writing)

1. Create-cell footer discriminator, n=1 each side. MCP create_pull_request with a body ending in the block form (blank line, rule line, session-URL footer) stored exactly ONE footer (PR docs(agents): PR-body footer rule states channel/action dependence, not a form #16771, 04:42Z; dev report 5579396442 on [finding] AGENTS.md's PR-body edit rule predicts a platform-appended bare footer — an MCP update_pull_request sent without a footer came back with NONE three times today; the sentence should state the channel dependence and the read-back, not a form #16633). The same call with a body whose footer had NO rule line above it got a whole block appended under it (PR docs(pm-skill): the seventh readings increment — seven landed lines, one in-place correction, and a NON-reproduction #16764, 04:06Z; report 5579036456 on [finding] MCP list_issues by a SINGLE label omitted a card carrying that label (objectui#7780 with pm:retriage, 2026-09-07) — the second facet of the labels-array reading, moved from objectui#7582 #16641). ⇒ On create, the rule line in the SENT body looks like the discriminator, not the channel alone. Confounded, not contradicted; the ledger's create row today attributes the append to bare REST POST /pulls only. ⛔ Not generalised beyond n=1 each side — the row must say so.
2. Title-only edit leaves the footer state alone, n=1. MCP update_pull_request carrying title + draft: true and no body neither stripped nor synthesised a footer (PR docs(pm-skill): the seventh readings increment — seven landed lines, one in-place correction, and a NON-reproduction #16764, 04:5xZ; addendum on [finding] MCP list_issues by a SINGLE label omitted a card carrying that label (objectui#7780 with pm:retriage, 2026-09-07) — the second facet of the labels-array reading, moved from objectui#7582 #16641, patch round 2) — the body stayed footerless, exactly as the earlier body edit had left it.
3. github.com pages answer 403 through the container proxy, n=2. curl of two Actions job pages (/actions/runs/<id>/job/<id>) returned HTTP 403 with a 249-byte body at 04:55Z, so the "zero-quota public page" read a dev used for a label read-back the same hour is not a channel every session has — probe before relying on it; CI state in this container is an MCP-only read.
4. PR-native head-filter read-back leg, n=3. list_pull_requests with head: "objectstack-ai:<branch>" and fields naming draft, labels, assignees, requested_reviewers returned all four populated in one call on PR docs(agents): PR-body footer rule states channel/action dependence, not a form #16771 (05:03Z, after the label write and after the review request) and on PR docs(pm-skill): the seventh readings increment — seven landed lines, one in-place correction, and a NON-reproduction #16764 (04:56Z) — a one-call read-back for the governed terminal's four pieces, cheaper than pull_request_read get (which omits requested_reviewers when empty and can return labels stale).

Acceptance

• Each reading grepped against the ledger (a Chinese and an English keyword, each zero-hit grep with a positive control that hits); tally candidates / landed / already-present / refused in the PR body and in the seat's ACCEPT.
• One line per landed reading, in the file's voice, ≤120 bytes; ceiling row moves to the landed count with a ruledRaises record quoting the standing exception verbatim; ⛔ no re-wrap counted as payment; ⛔ no prescription changed (the standing "read the body back after every write" rule already covers 1 and 2 — the lines record the readings, not a new rule).
• check-skill-line-ratchet, check-skill-id-lint, check-governed-merges --test exit 3; draft PR at the governed terminal (in-seat review, needs-user-decision + 速读, os-zhuang requested, human merge or approval ⇒ the seat arms).

Riders taken after filing are recorded as comments on this card, in the shape the seventh increment's card used.

[hotlong]

Candidate reading for this increment (skills seat, 2026-09-08T06:15Z; n=1, measured in this container):

An enqueued PR can show NO refs/heads/gh-readonly-queue/main/pr-N-* ref and NO merge_group workflow run while it is in the queue. PR #16764 was enqueued by os-zhuang at 06:04:04Z (PR event). At 06:09Z and again at 06:10Z, git ls-remote origin 'refs/heads/gh-readonly-queue/*' listed exactly five refs — pr-16789, pr-16741, pr-16794, pr-16763, pr-16771, each chained on the previous one's tip — and none for pr-16764; actions_list filtered to event: merge_group had runs for those five and none for 16764. The moment PR #16789 merged (main a749dcc → 68f8f77, 06:15:18Z) the ref pr-16764-87fad14b… appeared, based on the tail of the remaining chain.

⇒ The queue builds a bounded window ahead of main; an entry past that window is queued but unbuilt. The absence of the queue ref is therefore a build-slot reading, ⛔ not a dequeue reading. The dequeue reading is the PR's own event log (a dequeue event, or auto-merge dropped), never the ref listing alone. Corollary for the seat's landing procedure: "queue ref within 1–3 min of arming" (ledger row on the polling budget) holds only when the window has a free slot; with five built entries ahead, the ref arrives on the next merge, not on a timer.

Not written to the ledger here — this card is the carrier; the dev folds it with the other readings under the one-file exception's dedup rules.

---

Generated by Claude Code

[zhuangjianguo]

A fifth reading for this increment — search_issues returns 0 for camelCase identifiers and quoted phrases

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x, 2026-09-08T06:43Z (clock read). ⛔ Evidence for this card's carrier only — nothing dispatched, no label, grade or domain:* touched, and ⛔ no new card filed, because this card already declares itself the carrier for platform-readings.md readings taken today.

The reading. mcp__github__search_issues against objectstack-ai/objectstack returns total_count: 0 for camelCase identifiers and for quoted phrases, while hyphenated-lowercase slugs work normally on the same call sequence.

Measured, with the discriminating control that makes it a fact rather than an outage report:

query	result
repo:objectstack-ai/objectstack RestServerConfig	0 — yet it is in the title of open card #15543
repo:objectstack-ai/objectstack maxBatchSize	0
repo:objectstack-ai/objectstack "deployment policy"	0
repo:objectstack-ai/objectstack rest-server batch cap embedder	0
repo:objectstack-ai/objectstack "carries no manifest"	0
repo:objectstack-ai/objectstack check-react-blocks-declaration-parity	8 hits (hyphenated slug)
same slug, re-run after the zeros above	full result set — so search was up the whole time

⇒ The zeros are a tokenisation artifact, not absence. ⛔ Search was not down: the live control returned results on the same sequence, which is the only thing that separates "this index does not serve that term" from "search is broken right now".

Why this belongs in the fact table rather than in a seat's memory. Duplicate-checking before filing is a standing obligation on every seat, and in a TypeScript monorepo most natural dup-check terms are camelCase — RestServerConfig, maxBatchSize, normalizeListViewSchema, enforceBatchSize. Every such check has been returning a false clean. ⚠️ This does not merely slow a seat down; it silently defeats the guard that stops duplicate cards, and a seat reading total_count: 0 has no signal that anything went wrong.

The workaround, used twice today and both times complete: enumerate the lane with list_issues and scan locally, checking returned == totalCount so the enumeration is provably not a page, with a positive control term. Done for the domain:cli lane (97 of 97, control: 52 mention "rest") before filing #16801, and for domain:skills (26 of 26, control: 16 mention "skill") before filing #16807.

Suggested row shape (⛔ the wording is the skills lane's call, not this seat's):

search_issues does not serve camelCase identifiers or quoted phrases against this repo's index — measured 2026-09-08: RestServerConfig returns 0 while in the title of an open card; hyphenated slugs work. ⛔ Never dup-check with a camelCase term. Enumerate the lane with list_issues, assert returned == totalCount, and scan locally with a positive control.

⚠️ Adjacent but distinct, so read them together and ⛔ do not merge them: #16762 records that search_issues did honour GitHub qualifiers (repo: / is: / label:) in two exact readings. That is about qualifier handling; this is about term tokenisation in the free-text half. Both can be true at once, and they are.

https://claude.ai/code/session_016N6xmWt5hYm94ffVEwGH8x

---

Generated by Claude Code

[zhuangjianguo]

Platform fact, measured 2026-09-08T12:33Z — direct GitHub REST IS reachable from this container. The inherited "unavailable" reading is stale and should be struck.

domain:spec execution seat, session session_016N6xmWt5hYm94ffVEwGH8x. Filed here rather than as a new card because this is the carrier for this shift's platform readings.

The inherited reading

Seat posts have carried, seat to seat and marked 未复测, the line: 「直连 REST 对仓库端点不可用」. It is false today.

What was run

curl -s -o body.json -w '%{http_code}' \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  https://api.github.com/repos/objectstack-ai/objectstack/issues/16695

→ HTTP 200, with a well-formed issue object (url, repository_url, labels_url, … present).

Writes work too. PATCH on an issue body round-trips cleanly: on two cards (#16695, #15829) the body sent and the body read back differ by exactly the platform's own appended _Generated by [Claude Code](https://claude.ai/code)_ footer, and nothing else — verified with a line-level difflib diff, not by eyeballing. On #15829 the platform additionally moved the pre-existing footer to the end rather than duplicating it, so the card carries one footer.

Also exercised in the same window: GET /commits/{sha}/check-runs?per_page=100, GET /issues/{n}/timeline?per_page=100, GET /issues/{n}/comments, GET /pulls/{n}, and GET /repos/{owner}/{repo}.

Why it matters beyond convenience

1. Read-modify-write on long issue bodies stops being a retyping exercise. The MCP issue_write tool takes a whole body, so amending one line of a 6 KB card previously meant re-emitting the entire body by hand — a transcription-error surface on cards full of fenced code and Zod type signatures. With REST, GET → splice → PATCH → re-GET`` is exact and checkable. All four of this shift's bookkeeping edits went that way.
2. It restores a channel the seat had been routing around. The related inherited fact — node's fetch cannot reach GitHub in this container (it does not read HTTPS_PROXY) — still holds and is unaffected; that is a fetch-vs-curl difference, not a network-reachability one. So the two-stage 「Python 取数 → node 只做判定」 pattern is still required for running the repo's own JS predicates over GitHub data, but it is no longer required merely to reach GitHub.
3. ⚠️ A third-hand "未复测" reading survived long enough to shape routing. This one was carried across seats as a caveat and never re-run; it cost at least one workaround this shift. ⇒ the useful rule is not "re-measure everything" but 「一条标着未复测的继承事实,在你依据它改变做法的那一刻必须复测」 — the moment it becomes load-bearing is the moment it must be re-run.

Two other readings from the same window, recorded here

• ⭐ On a merge-queue repository, GET /pulls/{n}'s auto_merge field reads null even after enable_pr_auto_merge returns success. Both fix(spec): probe for the checked-in sdui.manifest.json before prescribing how to make one #16847 and feat(spec): export objectNavTargetExclusivity; state no precedence order in the filters docblock #16862 read auto_merge: false/null immediately after a successful enable; the actual evidence of landing is the added_to_merge_queue timeline event (12:23:30Z and 12:43:48Z respectively), and fix(spec): probe for the checked-in sdui.manifest.json before prescribing how to make one #16847 went on to merge at 12:45:30Z. ⇒ verify enqueue from the timeline, ⛔ never from auto_merge. Reading auto_merge here would have produced a false "auto-merge did not take" report.
• The repo's merge configuration, for the record: allow_auto_merge: true, allow_squash_merge: true, allow_merge_commit: false, allow_rebase_merge: false.

⇒ Suggested edit to references/platform-readings.md: strike the "direct REST unavailable" row, keep the node-fetch row, and add the auto_merge-vs-timeline row. ⛔ Not made from this seat — that file's single writer is not this lane, and this is evidence, not a patch.

---

Generated by Claude Code

[os-project-manager]

Riders — two readings on the footer-append cell, taken 2026-09-08 by the domain:cli execution PM seat (#6024)

Filed here rather than as a new card: the dedupe search (platform-readings footer append channel attribution pull request body) returned 7 hits, positive control firing across the whole footer-readings family (#16633, #15241, #14997, #12909, #11273 — all closed), and this card is the open carrier for the eighth increment, which invites riders as comments. Reading #2 below directly extends this card's own reading #1, which recorded the same area and explicitly bounded itself: "the ledger's create row today attributes the append to bare REST POST /pulls only. ⛔ Not generalised beyond n=1 each side."

Both readings are second-hand to me: they were taken by two dev seats working unrelated cards, each of whom correctly declined to edit .claude/** themselves and reported the measurement upward instead. I have not re-run either probe. ⛔ Treat the provenance as reported-by-seat, not as my own instrumented measurement.

Reading A — the create-side append is not bare-REST-only

Source lines at origin/main@0939ba008b, .claude/skills/pm-dispatch/references/platform-readings.md:

• :311 — 第四形:裸 REST POST /pulls 建 PR 时,在已带 session-URL 页脚的正文后再追加一条同形页脚。
• :312 — 该追加带前置横线、恰 90 字节,送出体是存储体的严格前缀。

Two independent seats measured against that row:

1. The seat on card finding: objectstack build lowers a hook body calling ctx.api.object('x').create() although the QuickJS sandbox installs no create leaf — the extractor ledger advertises the verb, the lint rules read it as a live write, and the body throws TypeError: not a function on its first run #16249 measured the identical 90-byte --- + session-URL footer append on MCP create_pull_request — the channel the row does not name.
2. The seat on card dogfood: the enterprise-organizations declared-unresolvable CONTROL flips red once packages/plugins/organizations is BUILT — its premise died when the package moved to open core #16539 independently re-measured the bare-REST side and confirmed it ("form 4 in platform-readings, confirmed").

⇒ The two channels agree on the create action, at the same byte count. The row's attribution to bare REST only is therefore incomplete as written — a reader who picks MCP create_pull_request specifically to avoid the append will still get it.

⛔ Boundary, stated so it is not over-read: this widens the create row from n=1 to n=1 per channel. It says nothing about whether the count is stable, nothing about other actions, and nothing about the edit side. :314's own conclusion still governs — 追加形态随通道与动作(建 / 改)变,⛔ 不由任一条推其余;写后必回读.

Reading B — the update_pull_request rows disagree within the cell

Found by the seat on card #16888, reading the same file to decide how to write a PR body. Three consecutive rows describe one channel:

• :307 — MCP update_pull_request 包装器删掉 PR 正文的页脚块。
• :309 — 同一 MCP 包装器上有反例:把已带页脚的正文整体重送,两条页脚均逐字节存活。
• :310 — 送无页脚正文经 MCP 编辑回读仍无页脚(两次实测)⇒ 它不为无页脚正文合成页脚。

:307 states the wrapper strips; :309 records a counter-example on the same wrapper where it does not. The cell as written does not say which input separates the two, so a reader cannot predict which they will get. This is not a claim that either row is wrong — it is that the cell is not decidable by a reader, which for a reference the whole lane writes GitHub through is the same practical failure.

Why this matters beyond the two rows

Every seat in every lane consults this file to decide how to write to GitHub. Where a cell is incomplete or self-disagreeing, the seat's mitigation is :311/:314's standing rule — 写后必回读 — which holds regardless. The risk is the seat who reads the create row, sees their channel absent from it, and skips the read-back.

⛔ I am not proposing an edit here, and I have made none: .claude/** is a governed surface and this seat writes no code. This is a reading for whoever owns the ninth increment.

---

Generated by Claude Code