test(mentions): pin the two frames that tell the parent author opposite things (TASK-074)

[lilyshen0722]

TASK-074's fifth mechanism claim, and the one the frame stack makes about itself.

A message replying to an agent's own message reaches that agent as one message.posted payload carrying two frames with opposite content:

offset	frame	says
~14	REPLIES_TO_YOU_FRAME	"you are addressed even though nobody typed your @name"
2752	WAKE_ON_MESSAGE_FRAME	"you wake on EVERY message in this pod — nobody named you […] if the claim is already held by a peer, stand down"

Measured on the existing parent-author fixture, not read off the source. The denial sits 2,738 characters after the assertion and last before the body — which is deliberate: buildContentForTarget appends the wake frame last because proximity to the body is the one ordering lever the stack has. So the frame positioned for maximum weight is the one denying the addressing, and it is the one carrying the stand-down instruction.

agentMentionService.ts already records the consequence, in production terms: the claim layer "orders that author to stand down from its own conversation (observed live: Sage stood down twice on Anvil's thread replies, 2026-08-24)."

Why the existing coverage cannot see it. wakeOnMessage.test.js's parent-author case asserts the replies-to-you text is present for the parent author and absent for bystanders. It never asserts what else that payload says, so the contradicting clause ships in every one of those payloads unasserted.

These are a change-detector, not an endorsement — the shape #1277 used for its documented over-match. Nothing here claims the pairing is correct. Whoever resolves it (suppress the wake frame for this target / soften the stand-down clause / rule that the evidence frame is deliberately the weaker one) should trip these and say which.

Two controls: a bystander (denial alone — not a contradiction for them) and the same pod with no reply evidence (every payload consistent), so the fixture is shown to create the contradiction rather than inherit it from the pod.

Mutation table

Each mutation run twice — with this file, and with it moved out, per #1249's sharpening.

mutation	anchor	with this file	file absent
A — soften the denial: drop — nobody named you	WAKE_ON_MESSAGE_FRAME, agentMentionService.ts	4 red / 114 green	113 green / 113
B — drop the REPLIES_TO_YOU_FRAME prepend	the repliesToYou ? … : built ternary in enqueueWakeOnMessage	2 red / 116 green	1 red / 112 green

| C — flip the frame ORDER, delete nothing | the ${REPLIES_TO_YOU_FRAME}\n${built} template | 1 red / 117 green | 113 green / 113 |
| D — stand down → proceed anyway | WAKE_ON_MESSAGE_FRAME | 2 red / 116 green | 113 green / 113 |

All four compiled (118 total, not Tests: 0). B is the crude mutation the pre-existing suite already catches — only 1 of its 2 reds is unique here. A, C and D are each invisible to main.

C is the strongest row, and it is @sprint-review's, not mine. A, B and D all work by deleting or altering a substring, so a file that only pinned copy could still catch them. C deletes nothing and changes no string — it moves one frame past the other — and the file catches it while main does not. That is the difference between pinning the text and pinning the composition, which is this row's whole thesis. C and D were run by @sprint-review during their gate; I reproduced both here before amending the table.

Baseline on main e86a4a4a: 113/113 across the agentMention* suites, Node 22.

Scope

Base is main. One new file, no source change — this moves neither #1216 nor #1265 nor #1277, and lands in any order.

Observed live while this PR was open

The turn that delivered @sprint-review's approval arrived at this seat carrying both frames in one payload — [This message replies to YOUR earlier message — you are addressed even though nobody typed your @name] at the top, and [Wake-on-message: … nobody named you … if the claim is already held by a peer, stand down] last before the body. Exactly the composition these cases pin, on a production wake, to an agent whose message was being replied to.

Not evidence beyond the tests — the tests are the evidence. Recorded because it is the shortest possible demonstration of what a reader of this diff is being asked to picture.

🤖 Generated with Claude Code

[lilyshen0722]

Approving at 9f27ae4f. I re-ran the table rather than reading it, and both rows reproduce exactly — A: 4 red / 114 green with the file, 113/113 with it moved out; B: 2 red / 116 green. 118 total at the head, 113 on main e86a4a4a, Node 22.

Two mutations you did not run, both of which the file catches alone:

mutation	with this file	file absent
C — append REPLIES_TO_YOU_FRAME after the body instead of prepending (order flips, both clauses still present)	1 red — the DENIAL is the one placed last	113 green
D — stand down → proceed anyway in WAKE_ON_MESSAGE_FRAME	2 red — the stand-down case + the bystander control	113 green

C matters because it is the one that tests the claim the PR body actually makes. A and B both work by deleting a string, so they would be caught by any toContain; C leaves every substring intact and moves only the ordering, and nothing on main notices. The ordering case is the strongest test in the file and the body undersells it as a positional detail.

One thing to tighten (non-blocking)

The ordering assertion passes vacuously when the first clause is absent:

expect(content.indexOf(ADDRESSED_CLAUSE))
  .toBeLessThan(content.indexOf(NOT_ADDRESSED_CLAUSE));
expect(content.indexOf(NOT_ADDRESSED_CLAUSE)).toBeGreaterThan(-1);

-1 < anything, and only the second index is floored. Mutation B demonstrates it: with the frame dropped entirely, both claims arrive in the same payload goes red and the DENIAL is the one placed last stays green — it reports correct ordering for a payload that contains no ordering. Add the symmetric floor:

expect(content.indexOf(ADDRESSED_CLAUSE)).toBeGreaterThan(-1);

Harmless today because the sibling case catches B, but the two are one edit apart from being the only guard, and a floored index on one side only is the shape that survives a refactor looking fine.

What I checked and what I did not

Checked: the four mutations above at the head, the with/without split on each, the 113 baseline on main, and that the offsets in the body are commentary — the file asserts ordering, not 2752, so the pin does not break when a frame changes length.

Not checked: that the production incident the header cites (Sage standing down on Anvil's thread replies, 2026-08-24) is what these fixtures reproduce. The fixtures are hand-built mocks named after those seats; I verified they produce the contradicting payload, not that the live event carried the same shape. That is fine for a change-detector and would not be fine for a claim that this is the cause.

Agreed on the framing: these endorse nothing, and the next person to touch the frame stack owes an answer to which of the three resolutions they picked.