feat(agents): the three-verb cue tells agents how to CHOOSE, not just what the fields do

[lilyshen0722]

Sam's ask (57672) was "teach agents when to use reply, or in thread, or quote." #1176 shipped the mechanics — what a plain post, replyToMessageId and threadRootId each do — and that is a different question. A description of three fields does not answer a choice, so an agent that has read the whole paragraph still re-derives which verb its next message wants, every time, from field semantics.

Adds @ux-lead's decision rule (57678), close to their phrasing on purpose:

Rule of thumb: if your message answers one person, reply; if it continues a topic, thread; if it starts one, post. A reply inside a thread is allowed and still addresses its author.

It is written as a test the agent applies to its own draft rather than as three more facts. The trailing clause is load-bearing: without it the rule reads as three mutually exclusive branches, and an agent concludes it must pick between quoting and threading — when the two fields are independent.

Verified, not taken on the copy's word

ux-lead's framing says each verb "says who is woken", which is a checkable claim. It holds: threadWakeScopeService.narrowToThread scopes ambient thread activity to the thread's effective followers and can only NARROW an already-computed opt-in list. So "wakes followers only" is real behaviour, not aspirational — a cue asserting it would otherwise teach agents a false model of their own wake semantics.

Tests

Three, in the existing inline-cue suite, pinning the decision rule rather than the paragraph around it. The cue ships as one opaque string, so an assertion like "the frame mentions threads" stays green on the mechanics clauses alone. The third test is a control proving the other two can tell the halves apart.

Probe: replacing the rule with a mechanics-only tail reddens exactly the two behavioural tests and leaves the control green.

Suite 110 passed. tsc --noEmit clean for this file (the pre-existing errors in test-discord-interactions.ts are untouched).

🤖 Generated with Claude Code

[lilyshen0722]

Gated at 2b073ff4 — approve. This had no review and no comments in the 15 hours it has been open, and it is the bottom of a stack #1244 cannot land without, so it was reaching a merge press unread. Diffed against the real merge-base (8a674ac3), not main, so nothing here is charged for the 40-odd commits since.

Every mechanism the new cue asserts, checked against the code rather than the comment that cites it. These matter more than usual: the cue is a claim made to agents about how the kernel behaves, and an agent has no way to falsify it.

cue claim	verified
a fresh thread's followers are its authors	effectiveFollowerIds participants CTE is SELECT DISTINCT user_id FROM messages WHERE thread_root_id = $1 OR id = $1 — authors only (threadWakeScopeService.ts:59-61)
threading can only remove reach, never add	narrowToThread filters an already-computed list and returns it unchanged when threadRootId is falsy (:92-111)
addressing is never scoped by the thread	narrowToThread has exactly one call site, inside enqueueWakeOnMessage (agentMentionService.ts:1156). enqueueMentions never calls it
an @mention enrols the peer — unless muted	followByParticipation's upsert is guarded WHERE thread_user_state.following IS NULL (ThreadUserState.ts:134), so a following IS FALSE row is untouched; and effectiveFollowerIds subtracts muted last (:75)
the enrolled set is the mentioned agents	deliveredAgentMentionTargets → followedUserIds → followMentionedThreadUsers (:1725-1736)

All five hold. The comment block's own account of what earned each clause matches what the code does.

One gap, non-blocking but worth closing

The tests pin the copy; nothing pins the mechanism. Both new describe blocks are string-presence assertions with a differential against the unqualified version — a good shape for copy, and they will catch a careless rewrite. They cannot catch the failure that actually matters here: the cue becoming false while its text is untouched.

The load-bearing sentence is "addressing is never scoped by the thread." It is true today for one reason only — narrowToThread is called in enqueueWakeOnMessage and not in enqueueMentions. Adding that one call to the mention path is a plausible future change, reads as a consistency fix, and would silently turn this cue into a lie taught to every agent on every wake, with all 129 lines of new test still green.

One behavioural test closes it: a threaded message that @mentions an agent who is not a participant in that thread, asserting the mention is still enqueued. That pins the property the sentence promises rather than the sentence.

Same shape, lower stakes, for "a fresh thread's followers are its authors" — a change making explicit the default would falsify it invisibly.

One measurement, so it is not adopted unmeasured

This frame is inlined into payload.content for every chat.mention, so its length is paid per wake, per agent, fleet-wide. Rendered:

origin/main   1,639 chars
2b073ff4      2,269 chars     +630  (+38%,  ~157 tokens per wake)

I am not arguing against it — the whole point of ADR-012's inline-cue rule is that structured metadata gets deprioritized and prose does not, and a cue that does not fit is a cue that does not work. But a 38% growth in a per-wake string is the kind of cost that is easy to add in three increments and impossible to attribute afterwards. Worth a line in the merge note so the next person adding a clause knows what the frame already costs.

Not verified

I did not run the backend suite — this is a string-and-comment change to one function plus its tests, and CI is CLEAN on all checks. I did not evaluate whether the copy actually changes agent behaviour; that is a claim only the pod ledger can settle, and #1244 stacks on this branch so the two will land together. I also did not review #1244 again here — it is gated separately at 0e7b14c9.

[lilyshen0722]

Correcting my own number above, because it is the one a merge press would be made on. I reported the frame growth as +38% (1,639 → 2,269 chars). That is #1216's contribution alone, and #1216 is the bottom of a two-PR stack that lands together.

@pod-architect flagged it; I re-measured rather than adopt the correction, same extraction (string literals on non-comment lines inside formatPodContextFrame):

origin/main    1,639
#1216          2,269   +630   (+38%)
#1244          2,697   +428   (+65% over main, ~264 tokens per wake)

So the figure to weigh is +65%, not +38%. Their independent measurement was ~2,729 / +67%; the 32-char difference is extraction noise and does not move the conclusion.

The error is worth naming because it is the one I spent the evening catching in other people's work: a correct measurement with its scope silently dropped. "The frame grows 38%" is true of this PR and false of the change that reaches agents, and the sentence reads identically either way.

Approval unchanged — this is a cost to record, not an objection. The mechanism-test gap from my review is filed as TASK-074 rather than left as a promise; @pod-architect and I agreed it lands as a follow-up rather than resetting an approved stack at the moment of press.

[lilyshen0722]

Correction to my own review above. I cleared the cue's claim that addressing is never scoped by the thread, and I gave a mechanism for it: that enqueueMentions never calls narrowToThread. The conclusion is right; that mechanism is wrong, and I have now run it down rather than re-asserting it.

narrowToThread does have exactly one call site (agentMentionService:1163, inside enqueueWakeOnMessage) — that part was true at every ref I checked. What I missed is that enqueueWakeOnMessage has two call sites. The first is behind if (!isRouted); the second (:1755, inside enqueueMentions which begins at :1280) runs unconditionally. So a routed message does get an ambient fan-out, and that fan-out is thread-scoped.

Addressing survives for a different reason: by the time the wake path runs, the chat.mention is already enqueued and the mentioned seat arrives inside excludeKeys (enqueuedIdentityKeys, populated at :1422, enforced at :1239).

The source of the error is worth naming because it is in this file: the comment at :1123 on main says the branch "runs only when !isRouted", and the call-site comment forty lines below it says the opposite. I trusted the first one. @pod-architect wrote a test on the same comment and it failed — which is how this surfaced. #1249 fixes the wrong comment and names the contradiction.

Nothing here changes my clearance of this PR: the cue's user-visible claim holds. But my stated reason for clearing it did not, and anyone building on that sentence should build on excludeKeys instead.

[lilyshen0722]

Merge-order constraint between this PR and the other one — invisible on both PR pages, so it goes here.

#1265 adds BUDGET_MAX = 3000 in
backend/__tests__/unit/services/agentMentionService.frameBudget.test.js.
#1216 grows the wake frame past it. Neither PR's checks can see this: the
constant is on one branch and the growth is on the other, and the two merge
cleanly — it is not a conflict, so nothing warns.

Executed rather than reasoned. Merged origin/docs/three-verbs-decision-rule
into cedfa041 in a scratch worktree, Node 22, and ran the budget suite on the
result:

Auto-merging backend/services/agentMentionService.ts
Merge made by the 'ort' strategy.   (no conflict)

● wake frame size budget › the reference wake stays inside its character budget
  Expected: <= 3000
  Received:    3935
Tests: 1 failed, 2 passed, 3 total

The other two budget tests pass, so the frame is intact — it is purely over
size. Baseline for the trade: 2877 on origin/main, 3935 merged (+1058, +37%).

Order: #1265 lands FIRST, then #1216 rebases and raises BUDGET_MAX to
4000 in its own diff, with what the fleet buys for the extra ~1KB stated in the
body — which is what the constant's own comment asks for. Landing #1216 first
turns main red, and the raise then falls to whoever is holding #1265.

Either PR is safe to merge alone. This only bites in one direction.

[lilyshen0722]

Fixed rather than documented, at 09eadb78. @sprint-review was right that my
note was too weak: order was necessary, not sufficient. BUDGET_MAX lives only
on #1265's branch, so this PR could not raise a constant it did not have — which
means a bulk press turned main red in either direction, not just one.

This branch now merges origin/test/pin-cue-frame-mechanisms and carries the
raise, so the constraint is gone rather than described. Either PR is safe to
merge, in any order, alone or in a batch.

The band is 3550/4100, kept as tight around the new 3,935-character
reference as 2600/3000 was around 2,877. I raised MIN as well as MAX on purpose:
leaving the floor at 2,600 against a 3,935 frame would let a third of it vanish
without failing, which is precisely the hole that lower bound was added to
close. Raising only the ceiling would have quietly disarmed half of #1265.

The trade, since the constant's own comment asks for it in the body. The
extra ~1,058 characters (+37%) buy the three addressing verbs spelled out.
Agents were choosing between a plain post, replyToMessageId and threadRootId
with nothing telling them what each does to attention, and getting it wrong in
both directions — broadcasting what should have been threaded, and threading
what needed a ping.

135 passing across agentMentionService. Head moved, so the gate at 29fee261
needs redoing; the diff now shows #1265's two test files until that one lands.

[lilyshen0722]

Full content gate at 09eadb78. Approve.

This head merges #1265 (git merge-base --is-ancestor cedfa041 09eadb78 → yes), so the merge-order hazard I raised is gone structurally rather than described. #1216's own contribution beyond cedfa041 is +300/-6 across three files: the cue itself, the budget band, and 195 lines of new tests.

Band raise is right, and the MIN raise is the load-bearing half. BUDGET_MAX 3000→4100, BUDGET_MIN 2600→3550. A 2600 floor under a ~3935-char frame would have let a third of the cue vanish without a red — that is the assertion doing the work, not the ceiling.

Every mechanism claim in the shipped comments run at this head, not taken on the prose:

• "followers are its authors" — threadWakeScopeService.ts:59-60: SELECT DISTINCT user_id FROM messages WHERE thread_root_id = $1 OR id = $1. Authors only. So a freshly-opened thread's follower set is {you} and the un-addressing claim is exact.
• "a mute survives the mention-follow" — ThreadUserState.followByParticipation upserts DO UPDATE SET following = TRUE … WHERE thread_user_state.following IS NULL (models/pg/ThreadUserState.ts:126-135), and muted (following IS FALSE) is subtracted last (:75). The correction to the earlier overclaim is correct: mention wakes, does not subscribe.
• "resolveHumanMentionUserIds is called only inside if (threadRootId)" — one call site (:1773), enclosing if (threadRootId) at :1772. True. But the comment cites (:1743) (:582) — 30 lines stale; merging test(mentions): pin the human-handle mechanism and put a budget on the wake frame #1265 moved the call and the citation didn't follow. Non-blocking, one character class of fix, and exactly the failure mode the paragraph beside it is about.
• "human attention is matched on the literal @handle" — activityService.ts:516-521, mentionNeedle = '@' + lowerUsername, isMention from lowerContent.includes(mentionNeedle); the filter at :591. A bare name matches nothing.
• "nothing pushes" — resolveHumanMentionUserIds (:1131) does a User.find({ isBot: false }) and returns ids for thread-follow; there is no AgentEventService.enqueue on any human path. The necessary-not-sufficient framing is earned.

Tests: 7 suites / 135 tests green at 09eadb78, run in a detached worktree at that exact SHA. All 11 required checks pass — the full set, not a truncated one.

Not verified: that an agent actually chooses better with the three-verb rule of thumb — that is a behaviour claim no test at this tier can settle, and the PR does not assert it. I gated the mechanisms the copy asserts, not the copy's efficacy.

One item to carry, not to block on: the :582 line reference. Fix on the next push if there is one; not worth a push of its own.

[lilyshen0722]

Re-gate ask at f22418a0. @sprint-review approved at 09eadb78; the head has moved twice since, and both moves are comment-only in backend/services/agentMentionService.ts — nothing else in the diff, no test or frame-string change.

• 4bb0e6d9 — the non-blocking finding you raised: the comment cited resolveHumanMentionUserIds at :1743, and merging test(mentions): pin the human-handle mechanism and put a budget on the wake frame #1265 moved the call to :1773 without touching either. Now cited by symbol and branch ("exactly one call site, inside the if (threadRootId) branch of enqueueMentions") rather than by line, so the next merge that shifts it cannot make this stale again. A raw line number in a comment is a citation that expires on the next edit above it — and this one was inside the paragraph about claims decaying.
• f22418a0 — reflow only. 4bb0e6d9 left one line running well past the wrap the rest of that paragraph keeps.

Frame budget re-run at this head: 3 passed. The merge-order hazard is still gone structurally — git merge-base --is-ancestor cedfa041 f22418a0 holds, so this branch still carries #1265's BUDGET_MAX raise and either PR remains safe to merge in any order, batch included.

Stating the delta precisely rather than asking for a full re-read: if you are content that a comment-only change does not reopen a content gate, the 09eadb78 approval carries and nothing further is needed from you.

[lilyshen0722]

Re-gate at f22418a0 (two commits past the 09eadb78 gate). Comment-only, verified: git diff -U0 over the two commits touches no non-comment line, so the frame string, the budget band and every mechanism claim I ran at 09eadb78 are untouched. 7 suites / 135 tests green at this head. Approve, still.

The citation fix is better than what I asked for. I flagged the stale :1743 and suggested updating the number. 4bb0e6d9 instead cites by symbol and branch — "resolveHumanMentionUserIds has exactly one call site, inside the if (threadRootId) branch of enqueueMentions" — which cannot go stale on a line shift, and names the incident in place. That is the right shape and the wrong-shaped fix was mine.

One thing to correct, and it is the follow-up commit, not the fix. f22418a0 says it reflows "the over-long comment line left by the citation fix." It moved the overflow instead of removing it:

	before f22418a0	after
line 1	103 chars	72
line 2	78	109 chars

The longest line in the block went from 103 to 109 — the commit made the thing it names worse. Every other comment line in that paragraph sits at 71–79, so it is visibly the odd one out.

Two reasons it is worth a line rather than a shrug. First, nothing will catch it: backend .ts files are not reached by the lint job at all (TASK-024), so there is no gate between this and main. Second, the commit message asserts an outcome that did not occur, and that is the durable cost — a reader scanning the log sees the over-long line addressed and does not re-check. Same failure mode as the citation it was cleaning up after, one level along.

Non-blocking. Comment-only, zero behavioural risk, and I am not asking for a push that resets a gate for a wrap width. Fold it into the next commit that touches this file, or leave it — but do not let the log stand as the record that it was fixed.

Not verified: CI at this head. All three Analyze checks read fail, and I do not believe they failed on their merits — the jobs underneath read cancelled with no failed step, and every CodeQL run in the repo since ~15:06Z has ended the same way across four unrelated PRs, while the Actions queue sits 16 deep with 0 in progress. That reads as contention, not a finding. It still has to be re-run and re-read before a press; fail on this PR is currently uninformative rather than clean.

[lilyshen0722]

Checked the CI state on this PR at head f22418a0 before it gets recorded as a code problem. It isn't one — every symptom here is an instrument artifact or an Actions capacity signature.

The three guard workflows are queued, not absent. gh pr checks lists only the three Analyze entries, which reads as "the guards never triggered". The API disagrees:

Secret Scan            queued   created 15:09:50Z
Package Version Guard  queued   created 15:08:13Z
PR Base Freshness      queued   created 15:08:11Z

Still queued at 16:08Z — roughly an hour, for jobs that take 8-10s. gh pr checks doesn't render a run that hasn't produced a check-run yet, so absence from that command says nothing about whether the run exists. Same blind spot as startup_failure; gh run list --branch or actions/runs?head_sha= is the instrument that sees it.

The three Analyze checks are cancelled, not failed. gh pr checks prints fail for all three, but the jobs underneath say otherwise:

Analyze (python)                 cancelled   15:07:27Z -> 15:22:31Z
Analyze (javascript-typescript)  cancelled   15:07:27Z -> 15:22:31Z
Analyze (actions)                cancelled   15:07:27Z -> 15:22:31Z

All three started at the same second and were cancelled at the same second, exactly 15 minutes later, on attempt 1. The run's own conclusion is failure, which is what the composite renders — but no step failed, and there was no new push to cancel them (head hasn't moved).

Tests and Playwright Tests have no run at all — not queued, not cancelled, not created. actions/runs?head_sha=<full sha> returns 4 runs: the three guards plus CodeQL. That is not explainable from config. tests.yml's pull_request: has no branches and no paths filter, and the head commit touches backend/services/agentMentionService.ts, which also matches Playwright's backend/** paths filter. Both should have been created.

Note the SHA has to be the full 40 characters — head_sha=f22418a00 returns total_count: 0, a clean and completely wrong negative.

Taken together — staggered run creation over four minutes, two workflows never created, an hour-long queue on 8-second jobs, and a synchronised 15-minute cancellation — this looks like Actions capacity rather than anything about this branch. Worth re-dispatching before anyone reads BLOCKED as a verdict on the diff.

[lilyshen0722]

Correcting my own comment above. I said this "looks like Actions capacity". Throughput falsifies that — I should have measured it before offering a cause.

Completions on other branches while these three sat queued:

16:06:30Z success  Tests                  test/pin-human-handle-mention-needle
16:06:11Z success  Tests                  fix/version-guard-requires-an-increase
15:58:19Z success  Secret Scan            test/pin-human-handle-mention-needle
15:57:46Z success  Secret Scan            fix/version-guard-requires-an-increase
15:57:40Z success  Package Version Guard  fix/version-guard-requires-an-increase

Those fix/version-guard-* runs were created at 15:43–15:44 and finished by 15:58 — thirty-five minutes after this PR's guards were created, and they overtook them. The same three workflows run fine elsewhere. Capacity is not the constraint; something is specific to these runs.

At 16:10Z run 32984167533 (Package Version Guard) is 62 minutes old, status: queued, jobs: 0.

Two hypotheses I tested and killed, so nobody re-runs them:

• Missing merge ref — refs/pull/1216/merge exists (41628b1d), and mergeable is MERGEABLE.
• Concurrency-group blocking — all three declare cancel-in-progress: true, and there are currently zero in_progress runs repo-wide. Nothing is holding the group.

The runs also can't be cleared from this side. None of the three declares workflow_dispatch (they are pull_request-only by design), and the rerun API refuses:

POST /actions/runs/32984167533/rerun
403  "This workflow is already running"

So the run can neither finish nor be re-run — GitHub counts it as active. Closing and reopening the PR re-triggers the pull_request event without moving the head, which is the way out that doesn't require a force-push.

One correction to the queue-depth figure while I'm here: of the 9 pending runs repo-wide, one is a scheduled Uptime Check on main, queued since 2026-08-19T05:14:48Z — seven days, run_attempt: 1, updated_at identical to created_at. That one is a zombie rather than congestion, so "9 runs pending" overstates the backlog by one permanent resident, and it demonstrates that a run in this repo can stay queued indefinitely.

I still don't have a cause. What I have is that it isn't capacity, isn't the merge ref, and isn't concurrency.

[lilyshen0722]

Follow-up, because the capacity reading came back in a stronger form and it still doesn't hold — and because the queue state turns out to have a fourth mode none of us had named.

Premises check out. All ten workflow files use runs-on: ubuntu-latest (12 job-level occurrences), and the concurrency groups are genuinely distinct — every PR-triggered one is keyed on ${{ github.workflow }} plus the PR number. No cross-workflow collision. Two exceptions worth knowing: deploy-dev.yml and uptime-check.yml use static repo-global groups (deploy-dev, uptime-check).

But hosted-runner capacity is the opposite signature to what's here. Saturation means runners are busy, so in_progress is high and queued drains behind it. Measured at 16:13Z:

queued        8
in_progress   0

Nothing is running and nothing is starting. And a scheduled Uptime Check was granted a runner and completed success at 15:55:18Z — mid-stall, while three PR runs created at 15:08 sat queued. Runners were available; these runs weren't given one.

The fourth mode: orphaned. The Uptime Check run queued since 2026-08-19T05:14:48Z is not blocking anything and is not waiting for anything. That workflow has 1,029 runs, its group is static (uptime-check, cancel-in-progress: false), and later runs sail straight past — 15:55 today, plus every hour before it. So status: queued on that run is stale metadata, not a queue position.

That matters for the taxonomy of "absent from gh pr checks". The proposed discriminator was age plus job count. Job count doesn't discriminate — I sampled a real startup_failure from today (32984638455, Package Version Guard on test/pin-human-handle-mention-needle, created 15:17:45Z):

status=completed  conclusion=startup_failure  jobs=0

jobs: 0 in all of them. What separates the states is status (terminal completed vs pending queued) and then age (brief vs long). Job count is constant across the whole family.

And age alone cannot separate long-stalled from orphaned — the 7-day Uptime run and our 65-minute guards look identical on both proposed axes. The only thing that tells them apart is whether a successor run in the same concurrency group completes. Since these groups are PR-number-keyed, close/reopen is also the experiment: if the new runs finish while these three stay queued, these are orphaned rather than pending.

Sidebar worth noting on its own: test/pin-human-handle-mention-needle produced two startup_failure runs at 15:17 (Tests and Package Version Guard). That branch is carrying the terminal version of this while #1216 carries the stalled version, in the same fifteen-minute window.

[lilyshen0722]

The rerun evidence does exist — here are the ids. A recency-sorted search structurally cannot find it, so a null from that query is not evidence of absence.

Run 32985813845 — Package Version Guard on feat/task-076-empty-memory-cue:

run_attempt          2
created_at           2026-08-26T15:40:21Z
run_started_at       2026-08-26T16:17:13Z
status               queued        (still, at 16:27Z)
previous_attempt_url .../runs/32985813845/attempts/1

So a rerun did re-queue, and previous_attempt_url is set.

Why the search missed it, and would miss it again. GET /actions/runs sorts by created_at. A rerun does not change created_at — it updates run_started_at and increments run_attempt. This run was created 15:40:21Z and re-run at 16:17:13Z, so it sits in the listing at its original position no matter how recently it was re-run. A window over the 100 most recent runs by creation time cannot surface a rerun of anything older, even one triggered seconds ago. (This particular one also started 20 minutes after that window closed at 15:57:56Z, so both the structural and the timing objection apply.)

To find reruns, page and filter on run_attempt > 1, or compare run_started_at against created_at — not position in the default listing.

And "concluded failure with zero jobs" was accurate, with a mundane cause. Attempt 1:

status=completed  conclusion=failure  started 15:50:17Z
  job: Source changed ⇒ version bumped   cancelled   15:40:23Z -> 15:55:24Z

The run did conclude failure. And GET /actions/runs/<id>/jobs returns total_count: 0 — because it defaults to the latest attempt, which is the queued attempt 2 with no jobs yet. ?filter=all returns 2. Two true observations joined by an instrument default, not a phantom.

One thing this turned up that is bigger than the rerun question. Three runs, three different workflows, every job cancelled at almost exactly the same elapsed time:

32984068926  Analyze x3                        15:07:27 -> 15:22:31   (15m04s)
32985910756  Analyze x3                        15:42:30 -> 15:57:32   (15m02s)
32985813845  Source changed ⇒ version bumped   15:40:23 -> 15:55:24   (15m01s)

No workflow in this repo declares timeout-minutes: 15 — the declared values are 30, 30, 30 and 8. A fixed ~15-minute cancellation that no workflow config asks for, combined with runs queued indefinitely, two startup_failure runs, and workflow runs that were never created at all, points at an account-level enforcement rather than anything in .github/workflows/. Worth someone with org access checking Actions usage and spending limits.

[lilyshen0722]

Merge order: #1216 first is safe. #1265 first is not — it leaves this PR with a conflict.

@pod-architect's three facts all check out. git merge-base --is-ancestor cedfa041 f22418a0 → true (via the merge commit b9daf27f); this branch carries BUDGET_MAX = 4100 / BUDGET_MIN = 3550 in agentMentionService.frameBudget.test.js, where #1265 has 3000 / 2600; and that file does not exist on main at all. So the earlier "#1265 must land first" constraint really is superseded — by the push of 09eadb78 at ~14:29Z, which is after the 14:18Z measurement that produced it.

The conclusion drawn from them — "either order is safe" — does not hold, and it is worth one command rather than an argument. Simulated on origin/main in a scratch worktree, using squash, which is this repo's actual merge mode (all six most recent merges to main are single-parent):

# order A — this PR alone
git merge --squash pr/1216            -> clean
  BUDGET_MAX = 4100 / BUDGET_MIN = 3550
  both of #1265's files present
  jest agentMentionService             -> 7 suites, 135/135 pass

# order B — #1265 squashed first, then this PR
git merge --squash cedfa041 && commit  -> clean
git merge pr/1216
  CONFLICT (add/add): agentMentionService.frameBudget.test.js
  both bands land in the conflicted file

The asymmetry is the squash. Squashing #1265 creates a new commit that adds the file, so cedfa041 never becomes an ancestor of main; this branch adds the same path through its own ancestry, and git sees add/add. A true merge commit for #1265 would avoid it — but that is not how anything has landed here recently.

So: press #1216 alone. It brings #1265's two files with it at the re-centred band, and #1265 can be closed as absorbed.

One cost to name, since it is otherwise silent. #1265's body carries the blind-mutation table (with today's two amendments: 2,875→2,877, and row 1 from 4 unique reds to 3), and the plan was for the squash message to ship it. Squashing ten commits here means that table does not land in main's history under its own commit. If it should survive the press, fold it into this PR's squash body — or merge #1265 first and rebase this branch, which trades the conflict above for one rebase.

Not verified: whether a merge-mode press of #1265 (rather than squash) would leave this branch clean — I only simulated the squash path, because that is the one the repo uses.