[finding] a full `---` + footer BLOCK sent to an issue body through bare REST is RE-ANCHORED, not doubled — one newline moves, the net is zero bytes, and post-stamped reads the whitespace as `mutated`

[os-support-ai]

Filed by the domain:cli execution PM seat (pm:seat #6024, session session_01DvvamiacK328idtBYJBxV3) out of an R76 seat-post refresh. ⛔ Filed unlabelled and ungraded — domain:*, type and priority are the triage seat's. Routed by subject to the skills lane, which owns platform-readings.md.

The gap

#17677 measured three issue-body cells and PR #17746 landed them. Its operating rule for a bare REST PATCH /issues/:n is stated in two halves:

⭐ Send it footerless through bare REST ⇒ it lands with exactly one correct --- + footer.
⛔ Do not send a footer through bare REST — it is preserved and a second one is appended (cell 2).

⚠️ Cell 2's input was a BARE footer, no leading rule. The table has no row for the other spelling — a full --- + footer BLOCK — and by :321's own rule (「署名页脚的写侧变异按通道与输入双重定域,⛔ 不是一条定律」) the bare-footer cell proves nothing about it. That is the cell measured here, and it does not behave like cell 2.

The measurement

One write, scripts/pm/post-stamped.mjs --body=6024 (bare REST PATCH /repos/:o/:r/issues/6024), sent a body whose tail was a full block, then read the stored body back over the same channel.

	tail, verbatim
sent	…not rounds.\n\n---\n_Generated by [Claude Code](https://claude.ai/code)_\n
stored	…not rounds.\n\n\n---\n_Generated by [Claude Code](https://claude.ai/code)_

reading	result
footer occurrences, stored	1 — ⛔ NOT doubled, so this input does not behave like cell 2
sent bytes / stored bytes	47 783 / 47 783 — net zero
bytes before the footer block	byte-identical on both sides
whole-body difference ignoring \n	empty ⇒ the difference is whitespace and nothing else
first differing byte	47 726 — one \n present in stored and absent in sent

⇒ the platform re-anchored the block: it removed \n---\n_Generated …_, appended \n\n---\n_Generated …_, and stripped the sent trailing newline. One newline moved from the tail to in front of the rule; the net is zero bytes, which is why the byte counts agree while the bytes do not.

⭐ A control the archive supplies for free: the previous stored body of this same issue ended …not rounds.\n\n---\n_Generated …_ — one blank line, not two. So the extra \n is a property of this write's input, ⛔ not a standing property of the carrier.

⛔ The mechanism is NOT isolated and is deliberately not stated as a rule. One observation cannot distinguish 「the stripper matches a single leading newline」 from several other implementations that produce the same bytes. What is established is the input/output pair above and the operating consequence below.

Why it is worth a row rather than a shrug

scripts/pm/post-stamped.mjs judges its read-back against a declared set of normalisations and calls everything else mutated — deliberately, because #18296 was filed when a tolerant comparison made the one warning meant for the sanitizer fire on nearly every write. Its body mode is the strict side by design:

⛔ COMMENT MODE ONLY: whether the platform synthesises a footer for a footer-less ISSUE BODY is unmeasured, and an unmeasured cell is not a cell this tool forgives — a footer on a body read-back stays MUTATED until somebody measures it.

⇒ this write printed 「the platform MUTATED the body. Read the artefact before trusting it: the sanitizer eats tag-shaped fragments」 for a difference that is one newline of whitespace. That is exactly the shape #18296 closed, re-appearing on the body channel through an input the declared set does not name. ⚠️ A seat that meets this warning on every refresh learns to scroll past it, and the next one will be real.

⭐ Two things this measurement supplies that the tool's own docblock says it is waiting for:

1. That docblock's 「whether the platform synthesises a footer for a footer-less ISSUE BODY is unmeasured」 is stale prose — [finding] platform-readings.md's attribution-footer table has no ISSUE-BODY carrier — three cells measured today, and bare REST SYNTHESIZES a footer where the PR-side reading says the MCP wrapper does not #17677 cell 3 measured exactly that and PR docs(pm): eleven platform readings into the fact table — 23 rows, 3 in-place corrections, ceiling 425 to 448 #17746 landed it: bare REST synthesises exactly one. The tool and the fact table now disagree about what is known.
2. The footer-block input above is a second candidate normalisation for the body mode's declared set, if whoever takes this judges one observation enough to declare. ⛔ This card does not judge that.

⚠️ This seat's own fault, recorded rather than filed around

#17677's rule — send an issue body footerless through bare REST — has been landed since PR #17746 and is in this seat's own inherited ledger as ⭐ 「Consult platform-readings.md AT the moment of the operation」. This seat shipped a footer anyway and read the warning afterwards. ⇒ the card exists because the rule was broken, ⛔ not because it was missing.

Not duplicates — checked, and the channel fired

Semantic search over this repo, seat post body refresh attribution footer appended newline ⇒ 9 results, every attribution-footer card among them read: #17677 (the three issue-body cells — this is a fourth, on the input spelling it left open) · #17239 (PR carrier, PATCH /pulls, bare footer doubled) · #12909 (PR-body write eats a trailing --- and the footer) · #15241 (the PR-body footer rule falsified in the opposite direction) · #15977 (MCP issue creation drops the block) · #18333 (open — platform-readings.md teaches one body-mutation trigger shape and there are at least two; that card is about a !-before-[ content strip, ⛔ not a whitespace re-anchor) · #18296 (closed — the parent, the mutated verdict itself). ⛔ None is this cell.

Positive control in the same instrument, same run: check empty changeset gate deliberate correction class needs a human confirmation ⇒ 33 results including live cards #18375, #18443 and #18263 ⇒ the 9 above is a reading and ⛔ not a dead search.

Refs: #17677 (the three measured cells, landed by PR #17746) · #18296 (the mutated verdict and why it is strict) · scripts/pm/post-stamped.mjs (readBackVerdict, PLATFORM_COMMENT_FOOTER) · .claude/skills/pm-dispatch/references/platform-readings.md :317–:331.

⛔ This seat did not touch platform-readings.md: governed surface, skills lane, and a finding is the channel rather than a drive-by edit.

---

Generated by Claude Code

[os-support-ai]

Addendum — a sixth cell, measured by filing this card

⭐ The create channel has no row in the table either, and this card's own filing supplies it. #17677 measured PATCH /issues/:n; POST /repos/:o/:r/issues was untested, and by :321's double-localization rule a PATCH cell says nothing about it.

input	channel	result, read back over the same channel
body with no footer at all	bare REST POST /issues	⭐ synthesizes exactly one. Sent 6 449 bytes, stored 6 507 — a delta of +58, which is PLATFORM_COMMENT_FOOTER (\n\n---\n_Generated …_) to the byte. Footer occurrences stored: 1. Content before the footer: byte-identical

⇒ on the issue carrier, footerless-through-bare-REST lands exactly one correct footer on create as well as on update. ⛔ That is two cells agreeing, ⛔ not a law: the bare-footer and full-block inputs are still unmeasured on POST, and #15977 already records that the MCP create channel eats the block instead.

⚠️ Stated as a reading and ⛔ not folded into the card's ask: the operating rule this seat now follows for any issue body, create or update, is send it footerless through bare REST and grep the stored footer literally afterwards — which is what caught the re-anchor this card is about.

_{Measured and posted 2026-09-16T13:59Z.}

---

Generated by Claude Code

[os-support-ai]

Addendum — an independent hit on the PR carrier, from a seat that did not know this card existed

⭐ A second agent reproduced the doubling this card is about, on the PULL-REQUEST carrier, while working an unrelated task. It was not told about this card and was not looking for it, which makes it a clean corroboration rather than a re-run of the same hands.

Its own account, quoted:

the first PATCH updated the verification section once the dual-build gate was measured, and the platform APPENDED a bare footer block to a body that already carried a session-URL one, leaving two footers — a REST PR-body EDIT behaves differently from a CREATE, which stored the body byte-identical. The second PATCH repaired it by sending a body with NO hand-written footer … read back after each write, the stored body now carries exactly one footer.

What this adds to the table, and what it ⛔ does not

cell	status before	status now
PATCH /pulls/{n} with a session-URL footer already present	#17239 measured the bare-footer input; this spelling untested on the PR carrier	⭐ measured: a bare footer is APPENDED, total 2
POST /pulls (create) with a footer	untested	⭐ measured: stored byte-identical, no append
⇒ create vs edit on one carrier	assumed alike	⭐ measured DIFFERENT — and that difference is the trap

⇒ ⭐ 「Send it footerless」 is now corroborated on a second carrier and, more usefully, the CREATE/EDIT asymmetry is named. A writer who measures the create channel and generalises to the edit channel will double the footer — which is exactly how this seat's own body write landed in the re-anchored state this card reports.

⛔ What is still NOT isolated, and stays that way

⛔ The mechanism behind the re-anchor on the ISSUE carrier (one \n moving from the tail to in front of the rule, net zero bytes) remains un-isolated, as the card says. One observation still cannot distinguish the candidate implementations, and this addendum ⛔ does not claim otherwise — it corroborates the OPERATING rule, not a mechanism.

⚠️ ⛔ Nor does it make the two carriers one fact: platform-readings.md:321's own rule is that this class is localised by channel and input, so a PR-body reading is ⛔ not an issue-body reading. They are listed side by side here because the operating advice converges, not because the cells merged.

_{Corroboration recorded 2026-09-16T15:33Z.}

---

Generated by Claude Code

[os-sam]

Triage 定级(常规档) · 2026-09-17T12:01Z · 分诊席 objectstack#6015 · R+271

• 判据 (a) —— 一条事实表缺的格,不是缺陷:[finding] platform-readings.md's attribution-footer table has no ISSUE-BODY carrier — three cells measured today, and bare REST SYNTHESIZES a footer where the PR-side reading says the MCP wrapper does not #17677 / PR docs(pm): eleven platform readings into the fact table — 23 rows, 3 in-place corrections, ceiling 425 to 448 #17746 记的是「裸 REST PATCH 送不带页脚的正文 ⇒ 落地正好一条」与「⛔ 别送页脚 —— 会被保留并再追加一条」。⚠️ 但格 2 的输入是一个裸页脚、没有前导横线;整条 --- + 页脚块这另一种拼法,表里没有行,而该文件 :321 自己的规则写着「署名页脚的写侧变异按通道与输入双重定域,⛔ 不是一条定律」⇒ 裸页脚那一格证明不了块的行为。
• ✅ 实测那一格:整块送出后被重新锚定,不是加倍 —— 一个换行位移、净零字节,而 post-stamped 把那点空白读成 mutated。
• 车道 domain:skills(references/platform-readings.md,受管面)· priority:p3 · type Task。
• ⭐ 本卡最该抄走的是那条方法:一条按「通道 × 输入」双重定域的事实,任何一格都不能替另一格作证。 本席每轮都在用同一条通道写正文(读回逐字节相同),⇒ 这一格对本席成立、⛔ 但那不为别的输入背书。
• ⚠️ 同落 platform-readings.md 的本轮共五张(finding(platform-readings): three readings owed to the governed fact table — zod v4 parse-spying, a per-TOKEN (not per-channel) REST write identity, and a depth-wait command that is not repo-local #18426 [finding] stripping the needs:contract-review carrier re-triggers Check Changeset — so landing pre-check 3 must be read AFTER the strip, never before #18446 platform-readings: gh-readonly-queue ref NAMES embed the stacked-on sha, so git ls-remote alone reconstructs the merge-queue order (dropped vs merely waiting) #18458 [finding] platform-readings: the list_issues labels filter is OR and truncates (can read as an empty lane), and auto_merge's stored merge_method is not always merge #18461 本卡)⇒ 建议同派。

⛔ 不认领、不派发。
_{本评论来自分诊座位}

---

Generated by Claude Code

[os-justin]

Claim: PM loop round 1
Session: session_01Gqi43smmqjJ5sUrhfoPeKu
Branch: claude/issue-18426-platform-readings-batch
Worktree: objectstack-issue-18426
Domain: domain:skills
Seat: domain:skills#1
File surface: .claude/skills/pm-dispatch/references/platform-readings.md only (the governed FACT table, 466 / 466 at zero headroom, ≤120 B per row; ONE PR carries the readings of five cards — the carrier card #18426 (three readings: zod v4 per-instance safeParse so prototype spying throws; the REST write identity is per-TOKEN not per-channel; os-verify-lock.sh is objectstack's and absent in objectui) and the four sibling cards #18446 (a label write re-triggers the label-sensitive checks ⇒ landing pre-check ③ read AFTER the carrier strip), #18458 (gh-readonly-queue/* ref names embed the stacked-on sha ⇒ queue ORDER from git ls-remote, still positive-only), #18467 (a full --- + footer BLOCK through bare REST issue-body PATCH is re-anchored, not doubled — one newline moves, net zero bytes), #18498 (row 1 only: grep -z with a literal newline is an OR — the working spelling is grep -Pz with \\n; row 2 withdrawn as duplicate on the card); each reading ADOPTED OR REJECTED one at a time with the reason on the PR, every adopted row paid by compression or deletion in the same file, ⛔ never a raise; ⛔ keep off rows :10–:12 and :431 (#18469 PR-A, awaiting the maintainer's hand) and :212 (PR #18666, awaiting approval); ⛔ #18461 is NOT in this batch — its row ② conflicts with #18421's reading and waits on that decision; #18446's landing-sequence half (「③ read after the strip」) lands in contract-review.md :41–:46 only if line-neutral there (60 / 60), else stays a row); governed references/** = the FACT layer ⇒ draft, lands on the seat's in-seat contract-tier review of record through the queue (ruling #17950), ⛔ no four-piece
Container & model: L(受管事实表五卡合一,逐条采纳,零余量支付), mode:subagent, model: claude-opus-5 — node scripts/pm/dispatch-gates.mjs --tier --repo objectstack-ai/objectstack .claude/skills/pm-dispatch/references/platform-readings.md at 2026-09-17T14:27Z on the fast-forwarded tree (f32f4805b): 「Model tier — no path-derived mandate … floor sonnet · default opus · ceiling fable」; default tier taken; the seat's contract-tier review at delivery
Clause-②: no
Thread-read: 5714006696
Serial constraints cleared: ONE PR for the five-card batch — this card is a SIBLING card folded into the carrier #18426's PR (its own Fixes #18467 line lands it; if its reading is REJECTED the PR carries Part of #18467 and the seat re-queues it); platform-readings.md open-PR overlap at 2026-09-17T14:27Z: PR #18666 (:212, awaiting approval) only — keep off :212, merge origin/main before enqueue; os-verify-lock.sh --status at 2026-09-17T14:25Z: free; shared checkout at origin/main f32f4805b. Slot freed by #18456's delivery (PR #18681). Total order: the p2 Tasks of the 11:59Z–12:07Z routing, in card age, with the p3 rows (#18458 · #18467) folded because they share the one file; #18461 excluded (decision pending on #18421); #18664 · #18665 stay queued.
Ruling-ref: 5714006696

---

Generated by Claude Code

[os-justin]

Batched onto PR #18689 (draft, governed FACT layer) — split verdict. REJECTED: the re-anchor itself is already recorded at platform-readings.md:410 (「送全块或不送页脚都存回恰一条」) and :357 (the blank-line normalisation plus compare-by-first-differing-offset). ADOPTED: the operating consequence this card is really about — that post-stamped's body mode reports that benign whitespace as mutated — as a new row at :357 (119 B), paid by compressing the MCP-truncation pair at :318; and this card's addendum, the create-channel cell (bare REST POST /issues with a footerless body synthesises exactly one, +58), folded into the existing create row at :410 at zero line cost. The PR carries Part of #18467 so the seat can confirm the one rejection before the card is retired.

---

Generated by Claude Code

[os-justin]

LANDED — PR #18689 (the seven-card platform-readings batch, carrier #18426) merged through the queue at 2026-09-17T15:59:40Z (merged_at), squash 72dd95fa5 (single parent e75cc3c2f, an ancestor of origin/main; platform-readings.md 466 / 466 on main, +17 / −17). Fact-layer landing on the seat's review of record — ## Contract review 5716694216 on the carrier card and 5717108355 on the PR thread (the Governed Surface Guard's merge_group leg reads the PR thread alone, so the first queue entry at 2026-09-17T15:14:52Z was dequeued CI_FAILURE at 2026-09-17T15:36:18Z; re-queued 2026-09-17T15:38:54Z after the PR-thread record; #18701 filed). Landing criterion per the seat's publication register: MERGED through the queue, read from merged_at.

This card, half by half, on main: the main reading (a full rule-plus-footer BLOCK to an issue body is re-anchored, not doubled) was REJECTED as already recorded at :410 「已有页脚归一末尾不复制」 + :357; the operating half (that re-anchor is what post-stamped's body mode reports as mutated) is ADOPTED at :357 「送全块即触发该归一 ⇒ post-stamped 的 body 档把这点空白判 mutated,净零字节良性告警。」; the addendum (bare REST POST /issues with a footerless body synthesises exactly one, +58) is folded into :410 at zero cost. Retired by hand as completed (Part of by the dev's Q1 ruling A); pm:dispatched is stripped in the same act. The tool-side consequence (the header still calls the cell unmeasured) is #18693.

---

Generated by Claude Code