Reported by the domain:services dev that delivered #18252 (card #16166) as an out-of-scope finding, and filed here by the domain:services execution PM seat because the natural home for it is a governed file this seat may ⛔ not edit: .claude/skills/pm-dispatch/references/platform-readings.md.
The reading
Over the same repo-scoped raw REST channel, on the PR-body surface:
| cell |
measured behaviour |
CREATE (POST /pulls) |
stored the sender's own session-URL footer verbatim and appended nothing — 9349 bytes sent, 9348 stored, the delta being the trailing newline and nothing else, confirmed by a line-by-line diff |
EDIT (PATCH /pulls/{n}) |
APPENDED a bare footer block (blank line, rule line, bare footer) UNDER the surviving session-URL one, leaving TWO |
That two-footer shape is what platform-readings.md already records for the COMMENT surface. What is new is that it is now measured on the PR-body EDIT cell, while the PR-body CREATE cell on the same channel does not do it.
⭐ This is exactly the generalisation that file exists to forbid: a cell is a cell. "REST appends nothing on a PR body" was true of the create cell and false of the edit cell, and nothing about the channel predicted which.
The repair the reporting dev applied, which is the transferable part
Per AGENTS.md (⛔ never re-send a body that already carries an appended footer; durable attribution belongs in body prose): it stripped both footer blocks, moved the session URL into an ordinary prose sentence, and re-sent with no footer block at all.
⭐ That repair is robust in BOTH directions — an unconditional append and a recognition-conditional append each leave exactly one. Read back afterwards: footer blocks 1, session-URL occurrences 1, and the only delta between sent and stored was the platform's own appended block.
⚠️ A non-reading this seat is deliberately NOT offering as a counter-example
This seat appended to issue #6021's body by PATCH in the same hour and read back exactly one footer, which looks like a contradiction. It is not evidence either way: the stored length grew by exactly the length this seat believed it appended, but this seat did not record that length independently, so "the original carried no footer and the platform appended one" and "the original carried one, it was stripped from mid-body, and one was appended at the end" are both consistent with what was observed.
⇒ ⛔ That observation does not discriminate and must not be weighed against a measurement that does. It is recorded here only so that a later reader does not rediscover it and mistake it for a conflict. The ISSUE-body edit cell is simply NOT MEASURED; whoever takes this card should measure it rather than infer it from this paragraph.
What the taker owes
- The ISSUE-body EDIT cell, measured with a sent-vs-stored diff (⛔ not a footer count alone — a count cannot tell an append from a strip-and-append).
- Whatever cells
platform-readings.md still carries as unmeasured on these two surfaces.
- The file edit itself, which needs the maintainer-authorised
.claude/ route.
Dedupe words: platform-readings PR-body edit-cell footer append
⛔ Ungraded, and ⛔ no domain: label: the surface is PM tooling under .claude/, which is not this seat's to route. Grading and routing are triage's.
Generated by Claude Code
Reported by the
domain:servicesdev that delivered #18252 (card #16166) as an out-of-scope finding, and filed here by thedomain:servicesexecution PM seat because the natural home for it is a governed file this seat may ⛔ not edit:.claude/skills/pm-dispatch/references/platform-readings.md.The reading
Over the same repo-scoped raw REST channel, on the PR-body surface:
POST /pulls)PATCH /pulls/{n})That two-footer shape is what
platform-readings.mdalready records for the COMMENT surface. What is new is that it is now measured on the PR-body EDIT cell, while the PR-body CREATE cell on the same channel does not do it.⭐ This is exactly the generalisation that file exists to forbid: a cell is a cell. "REST appends nothing on a PR body" was true of the create cell and false of the edit cell, and nothing about the channel predicted which.
The repair the reporting dev applied, which is the transferable part
Per AGENTS.md (⛔ never re-send a body that already carries an appended footer; durable attribution belongs in body prose): it stripped both footer blocks, moved the session URL into an ordinary prose sentence, and re-sent with no footer block at all.
⭐ That repair is robust in BOTH directions — an unconditional append and a recognition-conditional append each leave exactly one. Read back afterwards: footer blocks 1, session-URL occurrences 1, and the only delta between sent and stored was the platform's own appended block.
This seat appended to issue #6021's body by
PATCHin the same hour and read back exactly one footer, which looks like a contradiction. It is not evidence either way: the stored length grew by exactly the length this seat believed it appended, but this seat did not record that length independently, so "the original carried no footer and the platform appended one" and "the original carried one, it was stripped from mid-body, and one was appended at the end" are both consistent with what was observed.⇒ ⛔ That observation does not discriminate and must not be weighed against a measurement that does. It is recorded here only so that a later reader does not rediscover it and mistake it for a conflict. The ISSUE-body edit cell is simply NOT MEASURED; whoever takes this card should measure it rather than infer it from this paragraph.
What the taker owes
platform-readings.mdstill carries as unmeasured on these two surfaces..claude/route.Dedupe words:
platform-readingsPR-bodyedit-cellfooterappend⛔ Ungraded, and ⛔ no
domain:label: the surface is PM tooling under.claude/, which is not this seat's to route. Grading and routing are triage's.Generated by Claude Code