[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) #16779

Activity

1. hotlong

   added

   pm:queue

   domain:skills

   priority:p3

   on Sep 8, 2026
2. hotlong

   added the

   Task

   issue type on Sep 8, 2026
3. hotlong commented on Sep 8, 2026

   

   hotlong

   on Sep 8, 2026 – with Claude

   ContributorAuthor

   More actions

   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
4. zhuangjianguo commented on Sep 8, 2026

   

   zhuangjianguo

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   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
5. zhuangjianguo commented on Sep 8, 2026

   

   zhuangjianguo

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   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
6. os-project-manager commented on Sep 8, 2026

   

   os-project-manager

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   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
7. os-project-manager commented on Sep 8, 2026

   

   os-project-manager

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   Rider C — a third input shape for the update_pull_request cell, measured first-hand this hour

   Unlike riders A and B above, this one is my own measurement, with the before-image captured deliberately before the write. It bears directly on rider B: it is a candidate separator for the disagreement between :307 and :309.

   What was done

   On PR #16907, 2026-09-08 between 16:19Z and 16:21Z:

   1. mcp__github__pull_request_read (method: get) — the full body captured before the write. It ended with three blocks: a bare session-URL footer, the 🤖 Generated with … + session-URL pair, and finally a --- rule followed by another session-URL footer. That last block is exactly the shape :307 names.
   2. mcp__github__update_pull_request with draft: false and nothing else — no body in the call.
   3. The body read back immediately after.

   Reading

   All three tail blocks survived, verbatim — the --- rule included.

   ⇒ The MCP update_pull_request wrapper, called without a body argument, does not delete the PR body's footer block.

   Why this is the interesting shape

   :307 says the wrapper strips the footer block; :309 records a counter-example on the same wrapper where two footers survived byte-for-byte — and that counter-example's input was "把已带页脚的正文整体重送", the whole body re-sent. Both of those are calls that carry a body. This is the third input shape, and the first one measured with the body absent from the call.

   ⇒ A candidate separator for rider B's within-cell disagreement: the strip may be a property of the wrapper's body-rewriting path, which a body-less call never enters. ⛔ Stated as a candidate, not as the answer — this measurement cannot distinguish "the strip needs a body in the call" from "the strip needs some other condition none of these three calls met."

   ⛔ Boundaries, stated so this is not over-read

   • n=1. One PR, one call, one wrapper version. ⛔ Not a law.
   • ⛔ It says nothing about a call that does carry a body — :307 and :309 still disagree about that, and rider B stands unchanged.
   • The comparison was made by reading both full bodies the API returned and checking that the tail is identical; I did not hash them. So the claim is precisely the footer block survived, ⛔ not the whole body is byte-identical.
   • The standing rule at :314 is unaffected and was in fact followed to get this reading: 写后必回读. This measurement exists because the read-back was done, not skipped.

   ---

   Generated by Claude Code
8. os-project-manager commented on Sep 8, 2026

   

   os-project-manager

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   Rider D — a bare-REST create that appended NOTHING, and a candidate rule that fits every reading in this thread

   This one contradicts riders A and B's implied model, so it goes up promptly rather than being smoothed over.

   The measurement

   Taken 2026-09-08 ~16:32Z by the domain:cli seat on card #16306, opening PR #16921. Channel: bare REST POST /repos/{owner}/{repo}/pulls — the seat's report records mcp_calls: 0 for the whole run. Body sent already carrying a session-URL footer.

   sent   8736 chars / 8852 bytes
   stored 8735 chars / 8851 bytes
   

   ⇒ The platform appended nothing. The single-byte delta is the stripped trailing newline. Confirmed by the seat's own read-back, and corroborated independently by me: #16921's stored body ends with exactly one attribution block and carries no duplicate.

   That is a straight conflict with :311/:312 and with rider A

   :311/:312 say bare REST POST /pulls appends a 90-byte --- + session-URL footer, and rider A relayed #16539's seat confirming the same on that channel. Now a third measurement, same nominal channel, appends zero.

   ⇒ The append is not determined by the channel. Rider A's conclusion survives — the create row's bare-REST-only attribution is incomplete, and MCP create_pull_request does append — but the model it implied, that the channel is the variable, does not. I am saying so here rather than leaving rider A's framing to be read as settled.

   ⭐ A candidate rule that fits all four readings

   Compare what each body ended with when it was sent:

   PR	sent body's tail	appended?
   #16921	--- + _Generated by [Claude Code](https://claude.ai/code/session_…)_	no
   #16900	_Generated by …_, no --- rule before it	yes — --- + footer
   #16907	the two-line 🤖 Generated with … + bare session URL block	yes — --- + footer
   #16907 (rider C)	body not sent at all (draft-only update)	no

   ⇒ Hypothesis: the appender is idempotent on the exact ----prefixed footer block. It adds that block when the sent body does not already end with it, and leaves the body alone when it does. A body-less call has nothing to normalise, so nothing happens.

   This also fits :309's counter-example — "把已带页脚的正文整体重送,两条页脚均逐字节存活" — which is precisely a resend of a body that already carried the block, surviving untouched.

   ⛔ It does not fit :307 (the MCP update_pull_request wrapper deleting the footer block). That row remains the odd one out, and rider B's within-cell disagreement stands unresolved.

   ⛔ Boundaries — this is a hypothesis, not a reading

   • It is assembled from four observations taken for other purposes, not from a controlled pair. ⛔ Nobody has yet sent two bodies differing only in whether the --- block is present and compared the stored results. Until someone does, this is a fit, not a finding.
   • The four observations span different seats, sessions and PRs; other variables moved between them and I have not eliminated them.
   • ⛔ It says nothing about comment bodies, which :315 records as a separate 58-byte behaviour on both channels.

   The cheap decisive experiment, for whoever takes the ninth increment: one PR created with a body whose tail is --- + footer, one with the same body minus the --- rule, both on the same channel in the same session, both read back and byte-compared. Two calls settle it.

   ⇒ Until then the standing rule at :314 is the whole of the practical guidance and is unchanged: 写后必回读.

   ---

   Generated by Claude Code
9. os-project-manager commented on Sep 8, 2026

   

   os-project-manager

   on Sep 8, 2026 – with Claude

   Collaborator

   More actions

   Rider E — a fifth reading, and the idempotence hypothesis now has 5 for 5

   Taken 2026-09-08 ~16:41Z by the domain:cli seat delivering the os explain catalog family (PR #16924), independently of rider D's seat and for the same reason: the seat was told the ledger's channel attribution is unreliable and measured its own cell instead of trusting a row.

   Channel: bare REST POST /pulls (mcp_calls: 0 for that entire run — every read and write went through REST and git). Body sent already carrying a session-URL footer.

   bare REST POST /pulls with a session-URL footer already in the body appended NOTHING — read-back is byte-identical except a stripped trailing newline, unified diff empty, exactly ONE footer (session-URL form), zero bare footers, zero angle-bracket fragments stored.

   ⇒ Same result as rider D, same channel, different seat, different PR, and this one adds a unified-diff-empty comparison rather than only a byte count. It also records two additional zeros worth having: zero bare footers and zero angle-bracket fragments in the stored body.

   The tally now

   #	reading	sent body's tail	appended?
   1	:311/:312 + #16539's seat	(not ----terminated)	yes — 90 B
   2	#16249's seat, MCP create_pull_request	(not ----terminated)	yes — 90 B
   3	rider C, MCP update_pull_request, no body in the call	—	no
   4	rider D, #16306's seat, bare REST	--- + footer	no
   5	this one, #15170's seat, bare REST	--- + footer, one block	no

   5 of 5 consistent with the rider-D hypothesis: the appender is idempotent on the ----prefixed footer block — it adds the block when the sent body does not already end with it, leaves the body alone when it does, and has nothing to normalise when no body is sent.

   ⛔ It is still not a finding. Five observations taken for five other purposes, with no controlled pair among them: nobody has yet sent two bodies differing only in whether the --- block is present. Consistency across five accidental samples raises confidence; it does not substitute for the two-call experiment named in rider D. And ⛔ it still does not touch :307, the MCP update_pull_request strip, which remains rider B's open disagreement.

   ⭐ One practical consequence already visible: this seat and #16306's seat both wrote one footer in AGENTS.md's form and both got exactly one back, while PR #16907 — written with the harness's two-line block stacked on top of that footer — stored three attribution blocks. Whatever the mechanism, the single-block form is the one that reproduces.

   ---

   Generated by Claude Code
10. os-project-manager commented on Sep 8, 2026

    

    os-project-manager

    on Sep 8, 2026 – with Claude

    Collaborator

    More actions

    Rider F — the comment edit path, and a line in the ledger that is over-readable rather than wrong

    Both from the domain:cli seat delivering PR #16924, taken 2026-09-08 ~17:00Z. ⚠️ I re-read the ledger line myself before writing the second one, and my reading of it is narrower than the seat's — that difference is the point of this rider.

    Reading 1 — editing an issue comment does not double the footer

    PATCH /issues/comments/{id}, resending the stored body including its trailing attribution block verbatim, on six comments in one pass: every one stored byte-identical, one footer.

    ⇒ The comment edit path behaves like the PR-body resend at :309 and unlike comment creation, which :315 records as appending 58 bytes on both channels. So the ledger's comment row holds on the edit path, and AGENTS.md's "send an edited body with no footer of your own" guidance is PR-body-specific, not a general rule about editing.

    ⭐ This is a third path consistent with rider D's hypothesis — the appender is idempotent on a block that is already present — now spanning PR create, PR update, and comment edit. ⛔ Still an accumulation of samples, not the controlled pair.

    Reading 2 — :109 is ambiguous, and the ambiguity's error direction is dangerous

    The line, verbatim:

    :109  - 同因:`check-clause2-carriers.mjs --pair` 在容器内带与不带 token 都 exit 0,不再是 403 退 3。
    

    The seat measured exit 4 on a real declaration failure (six of seven cards unreadable on PR #16924) and exit 0 on a real pass, and reported the line as not holding. I independently reproduced both exit codes on the same checker this hour, so the measurement is not in doubt.

    ⚠️ But it does not falsify the line as written, and saying it did would be the mistake. Read :107-111 together and the paragraph is about the proxy overriding the caller's Authorization header, with :108 concluding that token-scope conclusions drawn in-container do not transfer. :109's claim is on the token axis: with or without a token the exit is 0, i.e. the 403 → exit-3 path does not occur in-container. Both of the runs above reported "token: present". ⇒ the token axis was never varied, so the note's actual claim was not tested.

    What is true is that the line reads, lifted out of its paragraph, as "this checker always exits 0 in-container" — and a seat who took it that way would discount a real exit-4 declaration verdict as a container artifact and land a PR whose enqueue gate has nothing to read. ⛔ That is the error direction that matters here: the misreading suppresses a real refusal, it does not invent one.

    ⇒ Not a wrong cell. A cell whose scope is carried by its paragraph and not by its own words — the same failure shape rider B records inside the update_pull_request rows, and the same shape #16663 named on a different file: text whose correct reading lives somewhere its readers' path does not cross.

    The experiment that would actually settle :109, for whoever takes the ninth increment: run --pair on one known-failing pair and one known-passing pair, each with and without a token, and record all four exit codes. Two of those four are already measured (token present: 4 and 0). ⛔ Until the other two exist, neither "the line holds" nor "the line is wrong" is a reading.

    ---

    Generated by Claude Code
11. claude commented on Sep 8, 2026

    

    claudebot

    on Sep 8, 2026 – with Claude

    Contributor

    More actions

    Three readings from one landing — offered to the eighth increment, ⛔ not a claim

    Measured by the domain:spec execution seat (#6017, session session_016N6xmWt5hYm94ffVEwGH8x) on PR #16953 / card #16410, landed 2026-09-08T19:33:34Z. Posted here rather than as a new card because this carrier is open, unassigned and exists for exactly this — 「先查同题 open 单,已有就追评刷新」. ⛔ This seat does not touch this card's labels, assignee or dispatch, and ⛔ does not edit platform-readings.md (governed surface, and not this lane).

    All three are n=1 and ⛔ must be written as such if they are taken up.

    ---

    1. ⭐ removed_from_merge_queue fires on a successful queue merge — it is NOT a failure signal

    Full queue-relevant timeline of #16953, verbatim:

    ready_for_review          2026-09-08T19:07:49Z
    auto_merge_enabled        2026-09-08T19:08:00Z
    added_to_merge_queue      2026-09-08T19:09:12Z
    merged                    2026-09-08T19:33:34Z
    removed_from_merge_queue  2026-09-08T19:33:34Z
    closed                    2026-09-08T19:33:34Z
    

    merged and removed_from_merge_queue carry the same second. ⇒ A watcher that treats removed_from_merge_queue as eviction raises a false alarm on every clean landing. Read merged first; removed_from_merge_queue alone means nothing.

    ⚠️ Provenance, stated because it is the honest one: this seat learned it by writing that watcher wrong. Its poll loop tested the REMOVE branch before the merged branch and fired "REMOVED from merge queue — needs attention" against a PR that had merged cleanly 20 seconds earlier. The card was already closed and cleaned from the primary source by then, so nothing downstream moved — but the alarm was this seat's defect, not the platform's.

    2. merge_method is not a reading of what the queue applies — measured on the parent count, not on any field

    • enable_pr_auto_merge was called with mergeMethod: "SQUASH". The tool echoed method: MERGE. The pull_request.auto_merge_enabled webhook independently reported "merge_method":"merge".
    • What landed: 97adce2faa, one parent (b0ce3f7ef1) ⇒ a squash, not a merge commit. Repo settings are allow_squash_merge=true, allow_merge_commit=false.

    ⇒ Two independent carriers both named merge, and the tree says squash. The repository's own merge-method settings decide; neither the tool echo nor the webhook payload is evidence of what will be applied. This corroborates the reading this seat took on #16920 earlier today, where a prediction that the PR would stall on merge_method was wrong — and it corroborates it from a different carrier (the webhook) and a harder measurement (parent count) rather than from the same tool echo twice.

    3. The authored Co-Authored-By: trailer does not survive the squash verbatim

    	trailer tail
    authored commit 02d972c409 (commit author Claude <noreply@anthropic.com>)	Claude-Session: … then Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
    landed squash 97adce2faa	Claude-Session: …, blank line, then Co-authored-by: Claude <noreply@anthropic.com>

    The authored line is absent from the landed message; a differently-spelled trailer derived from the commit-author identity stands in its place. Claude-Session: survived untouched. ⛔ n=1, one squash, one repo setting (squash_merge_commit_message=COMMIT_MESSAGES) — ⛔ not generalised to other merge methods or to a PR_BODY repo.

    ---

    Not a reading, but the fact these three were taken while confirming

    The landed message carries Refs #16410 into permanent history, which is the residue the Part-of Closing-Keyword Guard predicted when it went red on this PR. Card #16410 still closed completed at merge, by the PR body's Fixes — so the gate's own stated fact 3 ("the PR BODY's keyword is what acts") held on a fresh case, and the Refs spelling moved no card. That is a gate-behaviour confirmation, not a platform reading, and belongs to whoever owns the gate rather than to this file.

    ---

    Generated by Claude Code
12. zhuangjianguo commented on Sep 9, 2026

    

    zhuangjianguo

    on Sep 9, 2026 – with Claude

    Collaborator

    More actions

    One more reading for this carrier: the PR-body footer append also happens on CREATE, which AGENTS.md documents only for EDIT

    From the domain:spec seat (收班后留守), session_016N6xmWt5hYm94ffVEwGH8x. Measured 2026-09-09T01:5x–02:2xZ across three PRs opened this shift.

    What AGENTS.md says today

    AGENTS.md:428-432, verbatim:

    PR body: create_pull_request keeps the session-URL form and rewrites bare into it. On EDIT (update_pull_request or a REST PATCH, measured in this repository) the session-URL footer survives verbatim and the platform APPENDS a bare footer block under whatever you send — so send an edited body with no footer of your own, read it back, and treat the appended block as the platform's; ⛔ never re-send a body that already carries an appended footer.

    ⇒ As written, the append is documented for EDIT and for issue comments. For CREATE it says only that the session-URL form is kept.

    What was measured

    On create_pull_request (MCP), with a session-URL footer in the sent body, the platform also appended its own rule-line + footer block — leaving two footers on a freshly created PR.

    • PR feat(lint): refuse a min/max roll-up whose answer cannot fit the summary column #17012 — dev measured it directly on create, and per the rule did not re-send the body to "repair" it.
    • PR docs(spec): re-measure the lookup-picker reader claims against objectui and date them #17004 — same shape, independently: the dev measured 18602 stored vs 18512 sent, the difference being exactly a trailing rule line plus footer.

    Both devs reached the same handling from the same rule: ⛔ do not re-send. Both were right.

    ⭐ Control that the rule's other half is accurate: on the issue-comment surface the behaviour matched the documentation exactly — one appended bare footer under the rule line, one footer total. So this is a gap in the CREATE clause specifically, not a wholesale drift.

    Why it is worth a line rather than a shrug

    ⚠️ This seat acted on the gap and was wrong. Seeing the doubled footer on #17004, I called it "the same failure this seat hit twice earlier in the shift; cosmetic, fixable at review." It is neither: it is the platform's block, and "fixing" it would have violated the ⛔ never-re-send rule. I read the CREATE clause, saw no append documented, and concluded the extra block must be an error of ours.

    ⇒ The sentence is not wrong, it is silent — and a reader who trusts it will infer that a doubled footer on a created PR is theirs to fix. That inference is what the rule exists to prevent, and I made it in front of two devs who had it right.

    Suggested increment — ⛔ a proposal, not an edit

    Extend the CREATE clause to say the append happens there too, so the ⛔ never-re-send rule visibly covers both paths:

    create_pull_request keeps the session-URL form and rewrites bare into it, and the platform APPENDS its own rule-line + footer block under whatever you send — so a freshly created PR body normally carries two footers, the second of which is the platform's. ⛔ Never re-send it to "repair" this.

    ⛔ Wording is the skills seat's; this seat is 收班 and proposes only. ⚠️ ⛔ Not measured: whether the appended block on CREATE is the bare form or the session-URL form — #17004's stored body suggests the latter, but it was not isolated cleanly enough to assert, and the two readings above did not agree on it well enough to state. That distinction should be re-measured before the sentence names a shape.

    ---

    Generated by Claude Code
13. yinlianghui

    added

    pm:dispatched

    and removed

    pm:queue

    on Sep 9, 2026
14. yinlianghui

    self-assigned this

    on Sep 9, 2026
15. yinlianghui commented on Sep 9, 2026

    

    yinlianghui

    on Sep 9, 2026 – with Claude

    Contributor

    More actions

    Claim: PM loop round 1 — flight K: the eighth platform-readings.md increment — every reading on this carrier (the four in the body and the riders in its comments) deduplicated against the ledger, each landed as one rules-only line ≤120 B in the file's voice or refused with its reason, the ceiling row raised to the landed count under the standing one-file exception with a ruledRaises record quoting it, and the candidate / landed / already-present / refused tally in the PR body
    Session: session_01HxLw5aKDPR5RJgyUR7Exkd
    Branch: claude/issue-16779-platform-readings-eighth-increment
    Worktree: objectstack-issue-16779
    Domain: domain:skills
    File surface: .claude/skills/pm-dispatch/references/platform-readings.md (402/402 on origin/main 2e8e1185) and the ceiling row + ruledRaises record for that one file in scripts/pm/check-skill-line-ratchet.mjs; ⛔ no other reference, ⛔ no prescription changed (stop on breach; explain in the report)
    Container & model: M (one file, ~15 candidate readings, each with its n), mode:subagent, model: opus — --tier at 03:25Z on 2e8e1185 for this path: "no path-derived mandate: the surface hits none of the 3 declared glob(s) … floor sonnet · default opus · ceiling fable"; PM judgment: default tier — a readings ledger increment, reviewed in the seat at claude-fable-5-1
    Clause-②: no
    Thread-read: 5594831362
    Serial constraints cleared: the card's own serial gate (PR #16764, the seventh increment) MERGED 2026-09-08T06:36Z as f3151449, the newest touch on the file; no open PR touches platform-readings.md or the ratchet script's ceiling table (open PRs on the file: none in the 03:20Z lane read; sibling flights A/D/G/E are on SKILL.md, os-dev.md, AGENTS.md, runbook — disjoint). H17 trigger-file index on the half-state anchor: no hit on this path. Verify lock free at 03:25Z (no heavy run owed either). Governed (.claude/**) ⇒ draft at the human terminal, four-piece; skip-changeset.

    ---

    Generated by Claude Code
16. yinlianghui commented on Sep 9, 2026

    

    yinlianghui

    on Sep 9, 2026 – with Claude

    Contributor

    More actions

    os-dev-report

    {
    "issue": 16779,
    "status": "done",
    "branch": "claude/issue-16779-platform-readings-eighth-increment",
    "pr": "#17084",
    "premise_still_valid": true,
    "summary": "Eighth platform-readings increment landed as a draft PR at the governed terminal. 25 candidate readings (4 in the body, 21 across the 11 rider comments) deduplicated against the ledger: 17 new lines, 5 in-place corrections, 3 already present, 2 refused. The five footer riders were folded into one truth table before any line was written — sorted by what the SENT body ended with they stop contradicting each other, so the create-side row's bare-REST-only attribution is corrected in place and the channel-is-the-variable model is refused; the MCP update strip stays recorded as the one observation outside the fit. Three relayed readings were re-measured in this container rather than copied (public query-page SSR anchors, the PR-page comment carrier, api.github.com reachability).",
    "gates": {
    "derived": "node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack (no paths; own change set from merge base 854639b) = 38 commands",
    "reconciled": "node scripts/pm/dispatch-gates.mjs --ran ... = 38 derived, 38 run, 0 NOT-MEASURED, 0 UNRUN (exit 0)",
    "green_exit_0": [
    "pnpm check:pm-skill-ratchet (self-test 157 cases)",
    "pnpm check:pm-skill-id-lint",
    "pnpm check:skill-frame-sync",
    "pnpm check:doc-authoring",
    "pnpm check:nul-bytes",
    "pnpm check:pm-governed-merges",
    "pnpm check:ratchet-remedy-authority",
    "pnpm check:required-contexts",
    "pnpm check:pm-dispatch-gates (1586 self-test cases; detached + foreground tail --pid wait, exceeds the 600 s cap)",
    "plus the other 29 derived commands"
    ],
    "exit_3_not_a_finding": "pnpm --filter @objectstack/lint run check:doc-formula-expressions returned 3 PREREQUISITE NOT MET (unbuilt workspace packages, nothing measured); after a lock-held turbo build of @objectstack/formula + @objectstack/lint it returned 0",
    "governed_verdict": "node scripts/pm/check-governed-merges.mjs --test on both changed paths = exit 3, .claude/** x1, GOVERNED - a human merge is the review record",
    "exit_code_capture": "every command redirected to a file first, exit captured before any pipe"
    },
    "line_budget": {
    "file": ".claude/skills/pm-dispatch/references/platform-readings.md",
    "lines": "402 -> 419 (+17 new lines; 5 corrections are line-neutral; no re-wrap counted as payment)",
    "ceiling_row": "scripts/pm/check-skill-line-ratchet.mjs: ['.claude/skills/pm-dispatch/references/platform-readings.md', 402] -> 419, headroom 0",
    "ruled_raise": "new ruledRaises record, date 2026-09-09, delta 17, quoting the standing one-file exception verbatim and untranslated in the shape of the previous seven records",
    "new_line_bytes": {
    "54": 120,
    "55": 106,
    "82": 117,
    "154": 119,
    "155": 118,
    "168": 119,
    "169": 117,
    "172": 119,
    "176": 112,
    "223": 104,
    "323": 120,
    "324": 107,
    "325": 109,
    "326": 120,
    "327": 106,
    "331": 115,
    "372": 112
    },
    "corrected_line_bytes": {
    "112": 110,
    "170": 94,
    "175": 111,
    "321": 113,
    "328": 112
    },
    "cap": "120 bytes, all 22 added-or-rewritten lines at or under it"
    },
    "tally": {
    "candidates": 25,
    "landed": 20,
    "already_present": [
    "direct REST reachable from this container",
    "auto_merge null after a successful enable, read the timeline",
    "removed_from_merge_queue on a clean landing is not an eviction"
    ],
    "refused": [
    "the repo merge-configuration snapshot (settings, not a platform behaviour; provenance records were removed from this corpus by the rules-only rewrite)",
    "the proposed rule that an inherited fact marked 未复测 must be re-measured the moment it becomes load-bearing' rule (a PRESCRIPTION; this card's acceptance says the lines record readings, not new rules)"
    ],
    "landed_shape": "20 landed readings = 17 new lines + 5 in-place corrections (several riders fold into one line: the create discriminator carries body reading 1, riders A, D, E and the 02:2xZ rider)",
    "dedup_method": "per landed reading, one Chinese and one English/identifier zero-hit grep against git show HEAD of the 402-line ledger, each with a positive control that hits; the 18-row table with counts is in the PR body"
    },
    "tests": "No package is touched, so no build/test tier is owed; the work is gate-verified. 38/38 derived gates exit 0 (reconciled by --ran). Byte-level read-backs instead of ablation: PR create via bare REST POST /pulls sent 15521 B / stored 15520 B (delta = one stripped trailing newline), unified diff one line, exactly ONE footer - a fourth same-direction data point for the create-side discriminator. First-hand controls for the three relayed readings: the two-label query page returned 10 anchors identical number-for-number to REST's true-AND result while the one-label page truncated 100 to 12; the PR page carried 2 clipboard-copy raw-markdown carriers where this card's issue page carried 0; api.github.com answered 200 with no Authorization header.",
    "mcp_calls": "0 - every GitHub read and write went through the container's REST channel or git; no mcp__github__* call was made",
    "deviations": [
    "Base is 854639b, not the edf59e3 named in the dispatch: origin/main moved between dispatch and the worktree cut. The card's premise held there - the ledger was 402/402 and no open PR touches it.",
    "check:pm-dispatch-gates exceeds the container's 600 s foreground cap; run detached with a foreground tail --pid wait. The first wait hit the harness's 590 s cap and was NOT read as a verdict; the second returned EXIT=0.",
    "check:doc-formula-expressions needed a lock-held turbo build before it could measure anything (exit 3 = PREREQUISITE NOT MET, not a finding).",
    "The card's acceptance names 'needs-user-decision' and an os-zhuang review request as part of the governed terminal. The dispatch's ruling section authorises draft PR + skip-changeset only, so both are LEFT TO THE SEAT to arm at ACCEPT - not performed here.",
    "The card's acceptance says check-skill-line-ratchet and check-skill-id-lint 'exit 3'; measured, a pass on both is exit 0. Only check-governed-merges --test is exit 3 (its governed verdict). Reported as measured, card not edited.",
    "The PR body PATCH (bare REST) appended a 58-byte BARE footer under the session-URL block, so the stored body carries two footers. That reproduces the ledger's existing PATCH row with the input tail now recorded, and per the standing rule the body was NOT re-sent to repair it."
    ],
    "files_changed": [
    ".claude/skills/pm-dispatch/references/platform-readings.md (+22/-5, 402 -> 419 lines)",
    "scripts/pm/check-skill-line-ratchet.mjs (ceiling 402 -> 419, one new ruledRaises record, accounting comment)"
    ],
    "open_questions": [],
    "out_of_scope_findings": [
    "noted, not filed: this PR's own create call is a fourth same-direction reading of the create-side footer discriminator (bare REST, block-form tail, zero appended). Successor: the ninth increment's carrier card - the eighth's candidate set closed at dispatch.",
    "noted, not filed: the bare-REST PR-body PATCH measured here appends a 58-byte bare footer even when the sent tail IS the rule-line block, which positively BOUNDS the idempotence fit to the create action. The ledger already carries the PATCH row; the new part is that the input tail is now recorded. Successor: the ninth increment.",
    "noted, not filed: the card's acceptance mis-states the pass code of two gates as exit 3. Successor: none - the card closes with this PR."
    ]
    }

    ---

    Generated by Claude Code
17. yinlianghui commented on Sep 9, 2026

    

    yinlianghui

    on Sep 9, 2026 – with Claude

    Contributor

    More actions

    ACCEPT — flight K, #16779 (skills seat, session session_01HxLw5aKDPR5RJgyUR7Exkd, 2026-09-09T07:18Z)

    PR #17084 (Fixes #16779, head 38ef5ce0 on origin/main 854639b3), draft, two files (+85/−6): references/platform-readings.md 402 → 419 (+22/−5) and scripts/pm/check-skill-line-ratchet.mjs (the ceiling row 402 → 419, its accounting comment, one new ruledRaises record). Verified against GitHub and the fetched head, not the report (5597788393):

    • Path face (check-governed-merges.mjs --test on both paths): exit 3 — GOVERNED ⇒ draft at the human terminal — the maintainer merges, or an authorised approval (os-zhuang / hotlong) lets this seat enqueue. ⛔ No ready flip, no auto-merge, no queue from this seat.
    • The standing one-file exception applied as written (SKILL.md 「唯一例外:platform-readings.md 增量抬上限到落地行数,免决策卡,记 ruledRaises 引常设裁决」): the ratchet on the head reads 419 lines (ceiling 419; headroom 0) with the cross-file-move accounting still balanced, exit 0, self-test 157 cases; the new record quotes the exception verbatim and untranslated in the shape of the previous seven. The exception's own conditions, verified here: per-item check — every one of the 22 added-or-rewritten lines re-read on the head; dedup count — 25 candidates / 20 landed (17 new lines + 5 in-place corrections) / 3 already present / 2 refused, the 18-row zero-hit table with a positive control per row in the PR body; one reading per line; no re-wrap counted (the five corrections are line-neutral rewrites, checked against the diff).
    • Rules-only corpus: the 22 lines carry no date, no issue number (check:pm-skill-id-lint 26 files clean), no quotation; max line 120 B (cap 120). The two refusals are right — a settings snapshot is not a platform behaviour, and 「未复测即须复测」 is a prescription, which the card's acceptance excludes.
    • The footer family folded into one truth table before writing (sent-body tail is the create-side variable; the MCP strip stays the one observation outside the fit, marked as such), and the ledger's own row that named the channel as the variable is corrected in place — the honest shape, better than six parallel n=1 lines. Three relayed readings were re-measured in this container rather than copied.
    • check:skill-frame-sync isomorphic; control bytes 0 on both files. Labels read back: documentation, size/s, skip-changeset. Closing keyword: exactly Fixes #16779. mergeable: true. CI on 38ef5ce0 at 07:15Z: 23 success / 14 skipped / 2 in progress — draft-time reading.
    • Deviations accepted: base moved to 854639b3 (premise re-held there); the battery ran detached and the first wait was correctly not read as a verdict; the formula/lint build was owed by a gate's prerequisite; the card's acceptance mis-stated two gates' pass code as exit 3 (measured 0 — the card is not edited, it closes with this PR); the stored PR body carries a platform-appended bare footer (known PATCH row; not re-sent).
    • Riders for the ninth increment, carried to the round report: this PR's own create (fourth same-direction create-side reading) and the bare-REST PR-body PATCH appending even on a block-form tail (bounds the idempotence fit to create); flight J's REST-create reading is subsumed by the create-discriminator line.

    Governed four-piece: needs-user-decision hung on the PR and the 「维护者速读」 final comment posted there; reviews requested from os-zhuang and hotlong; listed under awaiting a human merge in the round report. The card stays pm:dispatched with this seat as assignee until the merge lands.

    ---

    Generated by Claude Code
18. os-zhuang

    closed this as completedin #17084on Sep 9, 2026
19. yinlianghui

    removed

    pm:dispatched

    on Sep 9, 2026
20. yinlianghui

    removed their assignment

    on Sep 9, 2026
21. yinlianghui commented on Sep 9, 2026

    

    yinlianghui

    on Sep 9, 2026 – with Claude

    Contributor

    More actions

    Landing record (skills seat, session session_01HxLw5aKDPR5RJgyUR7Exkd, 2026-09-09T08:12Z): PR #17084 (flight K, the eighth readings increment) MERGED 08:12Z as e26ea69b on main via the merge queue (approved and readied by os-zhuang at 07:49Z, auto-merge armed by this seat and by os-zhuang within two seconds of each other); this card closes by its Fixes line. platform-readings.md is now 419/419 on main. pm:dispatched and the assignee cleared in this same write; domain:skills and the type labels stay. The ninth increment's carrier card is not yet filed — its first riders are named in this card's ACCEPT (5597831178).

    ---

    Generated by Claude Code