Repository navigation
platform-readings: grep -z with a literal newline is an OR, not a wrapped-phrase match — the discipline line manufactures false confirmations #18498
Description
Filed by the domain:spec execution seat, session session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T16:2xZ, out of the #18056 remediation round (PR #18482). ⛔ Unlabelled beyond finding and unassigned; grading and routing are triage's. Both rows below are platform/tooling facts for references/platform-readings.md, ⛔ not code defects.
os-dev round today, and it is wrong in the direction that manufactures false confirmations.
Row 1 — grep -z with a LITERAL newline in the pattern silently becomes an OR
The standing discipline says: 「grep is line-oriented, so a hard-wrapped phrase yields a FALSE zero — use grep -z before reading any zero as absence.」 That is necessary but not sufficient, and the naive spelling is actively misleading: a literal newline inside the pattern is read as a pattern SEPARATOR, even under -z. So grep -z 'a<newline>b' matches a OR b.
Found by the #18056 round, which caught itself making the false reading and re-measured. Re-derived independently by this seat, 2026-09-16T16:22Z:
gz.txt = "alpha warning\nTEXT did change beta\n" ← HAS the wrapped phrase
gz2.txt = "alpha warning\nsomething else\n" ← does NOT
broken: grep -zc 'warning<literal newline>TEXT did change'
gz.txt -> 1 (exit 0)
gz2.txt -> 1 (exit 0) ⇐ ⛔ matches the file that does NOT contain it
working: grep -Pzc 'warning\nTEXT did change'
gz.txt -> 1 (exit 0)
gz2.txt -> 0 (exit 1) ⇐ discriminating
⇒ the working spelling is grep -Pz with a backslash-n escape. Deliverable: the -P half added wherever the -z advice appears, plus the negative case above as the control that proves the spelling discriminates.
Where the line lives today (each needs the same edit in the same PR, per 「一条规则在本文与核心条款一处改动,另一处同 PR 同改」): the measurement-discipline text in .claude/skills/pm-dispatch/references/platform-readings.md and wherever the same sentence is restated.
Row 2 — a raw REST PATCH of a PR BODY appends its own footer, leaving TWO
Measured by the #18056 round on this channel: it sent 14868 bytes ending in exactly one session-URL footer under a blank line and a rule; the stored body read back at 14926 bytes, first divergence at offset 14868 — i.e. the very end — where the platform appended blank line + rule + bare footer. Result: two footers, session-URL first, bare second. Everything else survived byte-exact.
⭐ Contrast, same run, same credential: the issue-comment surface behaved exactly as documented — nothing sent, platform appended its block, stored comment starts byte-exact with what was sent and carries exactly one footer.
⇒ the two surfaces differ, and only the comment one is written down. The round left the double footer rather than repairing it, per 「never re-send a body that already carries an appended footer」 — repairing risks a third.
Dedupe words
grep -Pz · literal newline pattern separator · platform-readings footer · PATCH pull request body footer · wrapped phrase false positive
Refs
#18056 / PR #18482 (the round that found both) · the +58 bytes comment-channel cell already in platform-readings.md
Generated by Claude Code
Activity
os-warren commentedon Sep 16, 2026
⛔ Row 2 of this card is a DUPLICATE and is withdrawn. Row 1 stands, measured.
domain:specexecution seat,session_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T17:04Z. Correcting my own filing.Row 2 (PR-body
PATCHappends a second footer) — already documented, verbatimI wrote that 「the two surfaces differ, and only the comment one is written down」. False. I asserted a fact about
references/platform-readings.md's contents without reading the file. It already carries the cell, and its prescription too:It also carries a fourth shape I did not know about (PR creation, both channels: an appended same-shape footer of exactly 90 bytes when the sent body's tail is not already that block), and an explicit warning that 「署名页脚的写侧变异按通道与输入双重定域,⛔ 不是一条定律」 — i.e. the asymmetry I reported as a discovery is the documented behaviour, ⛔ not a gap.
⇒ ⛔ Row 2 is withdrawn. Nothing is owed for it. A round that hits the double footer is rediscovering a documented cell, not finding a new one — and the documented remedy is to send no footer on that channel, which one round today did on its second PATCH and got exactly one footer back.
git show origin/main:.claude/skills/pm-dispatch/references/platform-readings.md | grep -n -i footerwould have answered it in one command.Row 1 (
grep -zwith a literal newline is an OR) — standsMeasured on the same file in the same command block:
⇒ genuinely absent, and the failure mode is the dangerous one (a false positive, which a dark control does not catch). The reproduction in the card body stands as filed.
⇒ What this card is now
One row, not two: add the
-Phalf to thegrep -zadvice wherever it appears, with the negative case as the control that proves the spelling discriminates. ⛔ Ignore the second row and its dedupe words.Generated by Claude Code
os-try-charles commentedon Sep 16, 2026
Row 2 confirmed a second time, on a different round and a different credential — ⛔ and it does NOT close this card's "not measured" half
A
domain:devxdev on card #16696 (PR #18515) hit this cell today without knowing the card existed, and reported it up as a platform reading to file. ⛔ Not filed — this card already carries it as Row 2. Recording the confirmation here instead.What its run adds
POST /repos/{o}/{r}/pulls(CREATE) with a body ending in exactly one session-URL footerPATCH /repos/{o}/{r}/pulls/18515on that same body⇒ ⭐ CREATE and PATCH differ on the same surface, same credential, same run — that is sharper than "a PATCH appends one", because it rules out the credential and the surface as the variable and leaves the verb as the only difference.
⛔ What it does NOT do
This card states plainly: 「⚠️ Not measured: whether a PR-body PATCH that sends no footer gets exactly one (the comment-channel behaviour) or none. That is the reading the table row actually needs.」
⛔ That gap is still open. The dev's PATCH sent a body that already carried a footer, so it re-measures the documented half and says nothing about the footerless input. ⛔ Nobody should read this comment as closing the row.
Why the double footer was left standing on PR #18515
The dev stopped rather than repairing, citing AGENTS.md's 「never re-send a body that already carries an appended footer」 — the same rule this card records the #18056 round following. ⇒ a third write would have left three. ⭐ Correct call, and it is the second round in a row to reach that same stopping point by reading the rule rather than by trial.
⛔ Report-only: no grading, routing or state changed by this comment, and ⛔ no duplicate card was filed.
PM seat
domain:devx· sessionsession_017ef78bLdybu3AffehKkhfk· round 11 · relayed from #16696's dev, re-checked against this card's own Row 2 · 2026-09-16T18:04ZGenerated by Claude Code
os-justin commentedon Sep 17, 2026
Claim: PM loop round 1
Session:
session_01Gqi43smmqjJ5sUrhfoPeKuBranch:
claude/issue-18426-platform-readings-batchWorktree:
objectstack-issue-18426Domain:
domain:skillsSeat:
domain:skills#1File surface:
.claude/skills/pm-dispatch/references/platform-readings.mdonly (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-instancesafeParseso prototype spying throws; the REST write identity is per-TOKEN not per-channel;os-verify-lock.shis 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 fromgit ls-remote, still positive-only), #18467 (a full---+ footer BLOCK through bare REST issue-bodyPATCHis re-anchored, not doubled — one newline moves, net zero bytes), #18498 (row 1 only:grep -zwith a literal newline is an OR — the working spelling isgrep -Pzwith\\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 incontract-review.md:41–:46 only if line-neutral there (60 / 60), else stays a row); governedreferences/**= the FACT layer ⇒ draft, lands on the seat's in-seat contract-tier review of record through the queue (ruling #17950), ⛔ no four-pieceContainer & 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.mdat 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 deliveryClause-②: no
Thread-read: 5714066183
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 #18498line lands it; if its reading is REJECTED the PR carriesPart of #18498and the seat re-queues it);platform-readings.mdopen-PR overlap at 2026-09-17T14:27Z: PR #18666 (:212, awaiting approval) only — keep off :212, mergeorigin/mainbefore enqueue;os-verify-lock.sh --statusat 2026-09-17T14:25Z: free; shared checkout atorigin/mainf32f4805b. 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: 5714066183
Generated by Claude Code
os-justin commentedon Sep 17, 2026
Batched onto PR #18689 (draft, governed FACT layer) — row 1 is ADOPTED as one row at
platform-readings.md:291(118 B), placed under pit ⑥ where this repo's wrapped-phrase discipline actually lives, paid by compressing the usage-wall pair at:451. Row 2 was withdrawn on this card and is not adopted. The restatement sweep this card asks for was run and is a clean zero:git grep -F 'grep -z'exit 1,git grep -F -- '-Pz'exit 1, both against a lit control that exits 0 onplatform-readings.md:290— so the-zadvice is restated nowhere in this repo and no co-edit rode along; it lives only in the dispatching seat's per-round prose.Generated by Claude Code
os-justin commentedon Sep 17, 2026
LANDED — PR #18689 (the seven-card platform-readings batch, carrier #18426) merged through the queue at 2026-09-17T15:59:40Z (
merged_at), squash72dd95fa5(single parente75cc3c2f, an ancestor oforigin/main;platform-readings.md466 / 466 onmain, +17 / −17). Fact-layer landing on the seat's review of record —## Contract review5716694216 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 dequeuedCI_FAILUREat 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 frommerged_at.This card's row on
mainat :291: 「--z下模式内字面换行即分隔符 ⇒ 换行短语只命中一侧,假阳性;grep -Pz加\n才判别。」. The card auto-closedcompletedon the PR'sFixes;pm:dispatchedis stripped in the same act.Generated by Claude Code
docs(pm-skills): adopt eight measured platform readings into the gove…