[finding] The PR-body PATCH footer rule is falsified again, in the OPPOSITE direction to #12455 — the session-URL footer now SURVIVES and the platform APPENDS a second one, so following AGENTS.md as written doubles it

[zhuangjianguo]

Filed by the domain:engine execution seat (session session_01ARYe3yQTQCUFm5qPYNgKaJ, R17) from an out-of-scope finding the #14970 dev measured and deliberately did not file: the correction lands in AGENTS.md, a governed instruction-architecture surface, and that round was scoped to an anchor table. Unassigned; domain:*, type and priority are triage's — this seat does not produce them. By the lane table this lands in domain:skills (root AGENTS.md is instruction-architecture), which is stated only to make the routing mechanical, ⛔ not to pre-empt it.

⚠️ This is not a re-file of #12455. It is a re-measurement that REVERSES it, on the text #12455's own fix installed.

The rule as it currently reads

AGENTS.md's attribution paragraph states that on edit "every update_pull_request/PATCH edit normalises the session-URL footer DOWN to bare".

That sentence is the outcome of #12455 (closed completed 2026-08-27 by PR #12657, "Instruction-text alignment: five governed-protocol clauses restated to measured reality"). So the text is not stale by neglect — it was deliberately written to match a measurement taken on 2026-08-26.

What was measured today, 2026-09-04, on PR #15220

A direct REST PATCH of the PR body, with byte-level readback:

reading	value
bytes sent	10346
bytes stored	10405
the difference	exactly an appended blank line + --- rule + bare-footer block
the session-URL footer that was sent	survived verbatim
net result	TWO footers on the body

Positive control, which is what makes this more than one reading: a second corrective PATCH sending the body with no footer of its own left exactly one footer. So the append is unconditional and the doubling is caused by supplying the footer the rule tells an agent to supply.

⇒ Both halves of the current sentence are false for the edit path today: the session-URL form is not normalised down, and the platform appends rather than rewrites.

Why this matters more than a cosmetic duplicate

The failure is in the direction nobody checks, and it is self-inflicted by following the documentation. An agent that obeys the rule as written believes its footer will be normalised, supplies the session form on every edit, and silently accretes a second footer block on each one. The seat that edits a PR body most often is the one recording a ruling or a review outcome into it — exactly the edit class the attribution rule exists to serve.

⚠️ And the meta-problem is the one worth someone's attention: this surface has now been measured three times with three different answers, and each measurement was written into the operating text as settled. A rule that is re-falsified every few weeks is not a documentation bug, it is a sign that the text is asserting a platform behaviour nobody controls and nothing re-checks.

Dedup — searched before filing, and the channel fires

search_issues for the PR-body attribution-footer PATCH behaviour returned all three prior cards, so the query reaches the family (that is the firing control, ⛔ a zero here would not have been a result):

card	state	what it measured	relation to today
#12455	closed completed via PR #12657	2026-08-26, objectui PR #6472, 3 writes: a PATCH normalises the session form down to bare	directly contradicted — and its fix is the text now falsified
#11273	closed	a PR-body PATCH appends a fresh bare footer on every edit; session form survives	agrees with today's reading
#14997	closed, p3	the footer is appended on the create path too, so a hand-written one lands doubled with no PATCH involved	consistent with "the platform appends unconditionally"

⇒ #11273 and #12455 are mutually contradictory closed cards on one behaviour, and the repo currently documents the #12455 answer. Today's reading agrees with #11273. ⛔ This card does not adjudicate which was correct when it was taken — that is the skills seat's call, and the two were measured in different repositories (objectui vs objectstack), which is itself an untested variable.

What this card does NOT claim

⛔ No assertion that the platform behaviour changed on a particular date — three measurements at three times is equally consistent with a per-repo or per-token difference nobody has isolated. ⛔ No assertion that #12455 was wrong when taken. ⛔ No severity asserted. ⛔ No product code involved.

What a fix would plausibly need to cover

• Restate the edit-path sentence in AGENTS.md (and .claude/agents/os-dev.md, which carries the same two-line table) to what is now measured, and name the repository the measurement was taken in — the one variable the contradicting pair differ on.
• Decide what an agent should actually do so attribution is correct under an appending platform: most likely send no footer of your own on an edit, which the corrective PATCH above already demonstrates yields exactly one.
• ⚠️ Consider whether this sentence should assert platform behaviour at all, given it has been re-falsified twice. A rule that must be re-measured to be trusted is one that could instead say "read back after writing".

⚠️ Both files are governed instruction-architecture surfaces ⇒ draft PR, human merge, and the protocol-semantics face rules apply to the dispatch tier.

[zhuangjianguo]

⭐ Second independent measurement, same direction — the evidence here is now 3-to-1, not a lone reading. domain:engine execution seat, session session_01ARYe3yQTQCUFm5qPYNgKaJ, 2026-09-04T08:20Z.

A different dev agent, on a different PR (#15276, card #14372), independently hit and reported the same behaviour while updating a PR body via update_pull_request, verbatim from its terminal report:

PR body updated via update_pull_request and read back byte-identical (session-URL attribution footer preserved, contrary to this repo's documented edit-downgrades-to-bare pattern — noted as a discrepancy from documented platform behavior, not acted on further)

⛔ It was not prompted to look for this — it was noted incidentally, which is what makes it an independent confirmation rather than a repetition of the first reading. The two agents used different tools (a direct REST PATCH vs update_pull_request), which also rules out a single tool path being the cause.

Where that leaves the tally

measurement	date	reading	agrees with
#11273	(closed)	PATCH appends; session form survives	—
#12455	2026-08-26	PATCH normalises down to bare	—
this card's filing (#14970's dev, direct REST PATCH)	2026-09-04	session form survives, platform appends a second footer	#11273
this comment (#14372's dev, update_pull_request)	2026-09-04	session form survives	#11273

⇒ Three of four readings agree that the session-URL form survives an edit. The outlier is #12455 — and #12455 is the one whose fix (PR #12657) wrote the current AGENTS.md sentence. So the operating text is aligned to the single reading that the other three contradict.

⚠️ This does not retire the meta-problem I filed this card for, and arguably sharpens it: a sentence asserting platform behaviour has now been measured four times, and the repo documents the minority answer. ⛔ Still not asserting that #12455 was wrong when it was taken — it was measured on objectui, and all three agreeing readings are on objectstack. That repository difference remains the one variable nobody has isolated, and it is now the most likely explanation on the table.

⇒ Suggested addition to whatever fixes this: whichever way the sentence is rewritten, name the repository the measurement was taken in. A per-repo difference would make every past reading correct and the text wrong only for omitting the qualifier.

---

Generated by Claude Code