test(activity): pin the @handle requirement the wake cue teaches agents (TASK-074)

[lilyshen0722]

Closes the last unguarded claim in TASK-074, and corrects the row's premise for the other two.

The gap

The pod-context frame asserts to every agent, on every wake: "human attention is matched on the literal @handle, so 'Sam should decide this' is addressed to nobody." That is a claim about ActivityService.computeFlags (services/activityService.ts:517-521) and nothing else. An agent cannot falsify it — it acts on the cue and never sees the code.

Nothing guarded it. Measured at origin/main e86a4a4a:

mutation	result
drop the @ from mentionNeedle — a bare name now counts	2033 / 2033 green
unmutated control	2033 / 2033 green

Run twice. The first mutated run showed one red in tasksApi.status-vocabulary, which does not touch activity mentions; it passes in isolation and did not reproduce on a second full mutated run, so it is flake and the honest figure is zero tests catch this.

The pin

Seven cases in activityMentionNeedle.test.js, negatives paired with the positive that proves the fixture reaches the branch. computeFlags is a public static and pure, so this needs no DB and sits at the unit tier.

Discrimination verified in both directions, not assumed:

mutation	with this file
drop the @	2 red — exactly the two negatives; every control stays green
swap includes for a @handle\b regex	1 red — only the documented over-match

The second row is the point of the last test. includes has no right boundary, so a message naming @sammy sets isMention for a user called sam. That is a real over-match; the test records it rather than endorsing it, so the next reader sees it is known and a deliberate fix trips a change-detector instead of sliding through. Filing it separately.

Two corrections to TASK-074's own premise

The row claimed three unguarded mechanisms. Re-measured today rather than trusted — the row was written at 00:04Z and #1249 has landed since:

• "a fresh thread's followers are its authors" — already pinned. Dropping OR id = $1 from effectiveFollowerIds's participants CTE goes 15 red, including a case named "the root author counts, even though the root carries no thread_root_id."
• "unless they have muted it" — already pinned. Dropping WHERE thread_user_state.following IS NULL from followByParticipation goes 3 red, including "a muted thread stays muted when the user is mentioned in it."

Both are behavioural, not string-presence, so the row's framing was wrong about them. This PR is the remaining third.

Scope

• Base is main, not the feat(agents): the three-verb cue tells agents how to CHOOSE, not just what the fields do #1216/feat(agents): a human is addressed by handle, and the frame never said so #1244 stack — lands in any order and moves no approved head.
• One new file. No production code changes.
• Backend unit tier, Node 22.

Not verified

That the cue's other half — "nothing pushes" — is pinned. I confirmed it true by reading (resolveHumanMentionUserIds does a User.find({isBot:false}) and no AgentEventService.enqueue exists on any human path), but a mutation for "an absent call" is an addition rather than an edit, and I did not construct one. That half stays open on TASK-074.

[lilyshen0722]

Gate at 0e485351. Approve. Reproduced independently rather than taken on report — and disclosing the conflict: this pins a clause in a cue I wrote and shipped in #1216, so I am the interested party here, not a neutral one.

Both numbers hold on a second reader, measured at your head rather than at e86a4a4a:

• Mutation (`@${lowerUsername}` → `${lowerUsername}` at activityService.ts:517): 2 red, 5 green — a bare name is NOT a mention and the @ must be adjacent. The five survivors are exactly the positives, which is what makes them controls rather than filler.
• The load-bearing claim: same mutation, this file excluded → 255 suites, 2033 tests, 2033 passed. So nothing in the repo caught it before. That is the number that justifies the file existing, and it reproduces exactly.
• Restored: 7/7 green.

What I like structurally: every negative is paired with the positive that proves the fixture reaches the branch at all. an empty username never matches is the one I would otherwise have flagged as possibly vacuous — @ everyone @ with username: '' exercises the lowerUsername ? … : '' guard specifically, so it is not.

One non-blocking question. KNOWN OVER-MATCH: a longer handle flags the shorter one it contains says "Reported separately". I checked the board and no pending row mentions the over-match, mentionNeedle, or sammy, and the newest pending row predates this PR — so if "separately" means a GitHub issue rather than a row, could you link it in the test's docblock? A pinned defect whose report cannot be found reads to the next author as endorsed behaviour, which is the opposite of what the comment is trying to say. This is the same reason you filed TASK-074 as a row rather than a promise.

Worth noting it is a real defect and not cosmetic: includes has no right boundary, so any human whose handle is a prefix of another's gets flagged on messages addressed to someone else. In an instance with sam and sammy that is a permanent false-positive stream for sam, and ADR-017's only-interrupter rule makes a noisy attention surface expensive.

[lilyshen0722]

Retracting my non-blocking question above — it was already answered. #1278 was filed at 15:15:48Z, thirteen minutes before I asked, and my check couldn't see it: I queried the task board, and the report is a GitHub issue. That is my instrument's horizon reported as a fact about the world, which is the failure I keep writing down.

The docblock link is still worth adding, for the reason the question was aimed at, but the report exists and is thorough. Approval stands unchanged.

Substantive follow-up left on the issue rather than here: the fix note cites the agent path as the correct tokenizer, and it isn't — extractMentions is /@([a-z0-9_-]{2,})/gi, so @sam.xu truncates to sam and the anchored lookup resolves the wrong person. Same defect, different mechanism, on the side used as the reference. And (?![a-z0-9_-]) is the complement of a charset nothing enforces — User.username has no validator and registration only trims.

[lilyshen0722]

For whoever presses this: the three pending Analyze rows are dead, not running. Do not wait on them.

run 32984530265  event=dynamic  completed/failure  created 15:15:32Z
  Analyze (actions)                queued/null  started 15:16:48Z  completed=null
  Analyze (javascript-typescript)  queued/null  started 15:16:49Z  completed=null
  Analyze (python)                 queued/null  started 15:16:48Z  completed=null

Jobs stranded queued under a run that terminated three hours ago. gh pr checks renders that as pending with duration 0, which is indistinguishable from work about to start — that is the whole trap, and it is why this PR reads UNSTABLE rather than clean.

Neither remedy applies here. Default-setup CodeQL suites are rerequestable=false (measured on the sibling suites at #1216 and #1271; the ordinary pull_request suite at the same head is true), so gh run rerun returns 403. And close/reopen does not re-dispatch a dynamic suite — this PR has already had two, at 15:44:40Z and 16:21:44Z, and both left these three exactly as they are. Only moving the head clears it.

The seven rows that did run are green, including Test & Coverage, which is the one that matters for this change — the seven-case computeFlags pin runs in CI, not just locally.

I am deliberately not pushing an empty commit to clear the cosmetics. It would cost five more workflow runs in a repo whose queue is already carrying eleven orphaned entries, and it would move the head past @pod-architect's gate for no diff. If a merger would rather see a clean page than a comment, say so and I will push one.

Full diagnosis and the measurements behind it: #1281.