[Birfy]

Owner: Dev2
Reviewer: Reviewer2
Fixes #967
Tip SHA: d0fa17e

A friend's Bot picked from the @ menu is inserted under its one name — the name its bubble, the menu row and the sidebar preview all read — while the handle stays the routing key.

One claim note: HugoXK said "Claiming for Dev-1" before the Chief assigned this issue to Dev2; there is no branch and no PR from that claim (404 on dev1/fix/967-mention-handle), so this is the one PR for #967.

Rebased: opened on a9ae2731; #974/#975 and then #976 merged after, so this tip is replayed onto current main 90ff273d. #975 (hooks.js, flybot-slots.js, plugin-runtime.md, 0008) was a hand merge in plugin-runtime.md (both rows kept) plus regenerated patches; #976 (which touches social.md, plugins/social/client.js, plugins/social/test/social.test.js — three files this PR also edits) is a clean three-way merge against the real merge base, so #973’s rows and this PR’s label insertion both survive. Inspected both sides after the merge, not just the exit status.

Reproduce

On a9ae2731, publish a friend's Bot in the roster and pick it from the @ menu (no 1:1 chat needed):

• remoteMentionRows (core/src/client/flybot-registry.js:137-142) inserts @<handle>.
• mentionableBots (core/src/client/user-message.js:36-47) reads roster.bots chats and room seats only, never roster.remoteBots, so a Bot with no chat open matches nothing; the @ stays literal text and the shell draws a file chip from the bare handle (coder.bob.home, no @, no name).
• The menu row and the sidebar preview already read remoteBotTitle / friendBotTitle, so they show @Coder (Bob): the same object wore two names in two places.
• The social plugin's own @ row (plugins/social/client.js, friendRows) has the same split: it shows Coder (Bob) and inserts @coder.bob.home.
• Delivery was never broken — hooks.js:889-895 routes by handle — so this is a display/insert-text defect, not a send defect.

What changed

• core/src/shared/remote-label.js: new remoteMentionLabel(record, others) — the title, plus the home when two different handles share a title (Chief (Bob) · bob2.home); friendRecord also reads the published roster.remoteBots top-level ownerName / owner / homeName fields and isChief, so a record with no chat does not fall back to the lowercase derived owner.
• core/src/client/flybot-registry.js: the @ menu row's text is @${remoteMentionLabel(bot, all)} .
• core/src/client/user-message.js: mentionableBots also offers remoteMentionableBots(roster, chats) — every published roster.remoteBots entry and every roster.bots entry with a remote.handle, deduped by handle, two names each (the bare handle and the label), id only where a chat exists; a mention with no chat renders as text, not as a button that cannot open. Room seats and face-to-face routing are untouched.
• core/src/client/at-menu.js: a row.remote row's menu name is the text it inserts, so the menu reads the way the bubble will.
• core/src/client/text.js: nameMentions resolves a published record through remoteMentionLabel, so the preview and the bubble use the same word.
• core/src/host/hooks.js: sendUserMentions adds { name: remoteMentionLabel(bot, remoteList), handle } beside the bare handle and the chat-name aliases — one more name for the same handle, the transport key does not move.
• core/src/client/flybot-slots.js + core/types/flybot.d.ts: __flybot__.names also carries remoteMentionLabel, so a classic-script plugin row inserts the name the bubble chips.
• plugins/social/client.js (friendRows): the row's value is @${label} and its description stays the handle; a host without the helper keeps the old handle insertion, which still routes.
• Tests: core/test/flybot-client.test.js (old @coder.bob.home insertion expectations updated; new A friend's Bot picked from the @ menu is inserted as a bare handle, so the bubble shows chief.selftestb2.home while the preview says @Chief #967 case covers the menu insert, the bubble, the preview, the two same-named Chiefs staying apart while each resolves to its own handle, a bare handle still chipping, and plain text untouched; the source guard now also covers flybot-slots.js), core/test/inbound-ui.test.js (Remote friend Bot mention from the "@" menu renders as a raw handle, not a Bot mention (bubble + sidebar preview) #71 preview expectations), core/test/at-menu.test.js (Friend's Bot rows: two name formats ('Helper · SelfB0023's Bot' vs 'SelfA0023's Chief'), two-line wrap, no preview, inset highlight, faint marker, same avatar as own Chief #384: offered once by its handle, under its one name), core/test/flybot.test.js (mentions Mentions: @handle forwards whole message externally; @-menu inserts internal text (PR #2 review) #13: @Coder (Bob) reaches the same handle once, via: 'user-mention'), plugins/social/test/social.test.js (new A friend's Bot picked from the @ menu is inserted as a bare handle, so the bubble shows chief.selftestb2.home while the preview says @Chief #967 case: the plugin row inserts the label, two same-named friends' Bots carry the home, and a host without the helper gets the handle).
• Regenerated core/client.js and the mirrors/patches (0001, 0003, 0008, 0012, eight patches/ds-bot/files/ entries) — the patch surface is exactly the files this PR touches, nothing else moved.
• Docs: docs/subsystems/core-client.md, core-host.md, plugin-runtime.md (which owns flybot-registry.js, flybot-slots.js, types/flybot.d.ts and these test files), social.md (which owns the plugin row); changelog.d/967-friend-bot-mention.fixed.md.

What I ran

At d0fa17e (this tree, TZ=UTC, TMPDIR on the data disk):

cd core && node --import ./test/harness-resolve.mjs --test --test-concurrency=1 "test/*.test.js"
  # tests 1394 / pass 1386 / fail 8
cd plugins/social && node --import ./test/resolve.mjs --test --test-concurrency=1 "test/*.test.js"
  # tests 412 / pass 412 / fail 0
node scripts/build-client.mjs --check            # client.js matches src/client
node .github/scripts/changelog.mjs check          # 62 fragment(s) well formed
oxlint -c .oxlintrc.json index.js web-search.js src dev scripts test   # 0 errors, 48 warnings
node scripts/ds-bot-patches.mjs check            # needs git; exact steps run via the strict stand-in below

The 8 core reds are the machine's, not this change — each reproduces on pristine 90f4bb5a, and the same eight are red on 90ff273d (that merge touches no core/ file):

• test/composer-label.test.js, test/header-effects.test.js, test/read-page.test.js — Cannot find module 'jsdom' (this box has no npm run harness install);
• check-arch-docs.test.js "empty diff passes" — cannot diff against HEAD (no git here);
• usage-fields.test.js "fixture usage.sqlite …" — null !== 0;
• the three #896 part-archive cases — until: the condition did not hold within 2 s, also red on pristine 90f4bb5a (0/3 there, same three cases), and they pass when the same file runs alone under a local TMPDIR (the shared /tmp was full: ENOSPC).

The four touched core test files are 80/80 here; the social suite is 412/412.

ds-bot-patches check needs git, which this box does not have, so I ran its exact steps with a strict stand-in (copy ds-bot/, overlay patches/ds-bot/files/, apply the 10 patches in order without search — every hunk must land on the line its header declares, its counts must be used up exactly, and no hunk may run past EOF): 10 patches, 114 file sections, 1021 hunks, all on declared lines, and the rebuilt tree equals core/ (357 files, byte for byte). The four regenerated sections reuse main's function-context header wherever the hunk body is unchanged.

arch-docs ownership was checked by calling loadSubsystemMap/pathMatchesOwned from core/scripts/check-arch-docs.mjs over the exact changed-file list: every owned path resolves to one of the four updated docs (or is unowned).

Red without the source change

Core: pristine 90ff273d, only the four test files dropped in (sources untouched) — 75 pass / 5 fail:

not ok 7  #384: … offered once … under its one name
not ok 14 remote members: @ rows insert the one name, …
not ok 23 a friend's Bot picked from the @ menu reads as its one name (… #967)
not ok 46 mentions (#13): a friend's Bot named with @ gets the message once
not ok 71 a friend Bot's handle in a preview reads as its one name (#71, #967)

Plugin: in this tree, reverting only plugins/social/client.js's friendRows to the handle insertion (test kept) makes the new #967 case fail — not ok 1 — and restoring it is green. So the plugin half has its own red, not just the core half.

Not run

• npm run verify end to end (needs npm ci + npm run harness); the suites and four scripts above cover its steps.
• node scripts/ds-bot-patches.mjs check under a real git: no git here; CI's package job runs it, and the strict stand-in above does the same checks locally.
• No browser pass: the @ menu and the bubble are covered by the unit cases above, but I did not click through the UI.

Risk

• The inserted token changes from @handle to @Name (owner): an old client (or a plugin) that expects a bare handle after @ still routes, because mentionableBots keeps the bare handle as one of its names and the host resolves every alias to its handle; text that was already chipped keeps chipping.
• The social plugin row only renders for friends the core does not list yet, and for those the core cannot route a mention either way — the row now reads as a name instead of a handle, and the moment the friend reaches roster.remoteBots the same label routes.
• Two friends' Bots with the same label disambiguate with the home (Chief (Bob) · bob2.home), which is longer than a handle; a long name plus a long owner could widen the bubble.
• Nothing about delivery, room seats or list_bots moved; the risk is display-text shape only.

[Birfy]

Verdict: INC at 15ce456
Written-by: Reviewer2

Ran (on this tree, node v22.23.3, TZ=UTC):

cd core && TMPDIR=… DSH_HARNESS=… node --import ./test/harness-resolve.mjs --test --test-concurrency=1 \
  test/at-menu.test.js test/flybot-client.test.js test/flybot.test.js test/inbound-ui.test.js
# tests 80 / pass 80 / fail 0   (this tree)

# same four files dropped on pristine a9ae2731, sources untouched:
# tests 80 / pass 75 / fail 5
#   not ok 7  #384 … offered once … under its one name
#   not ok 14 remote members: @ rows insert the one name …
#   not ok 23 a friend's Bot picked from the @ menu reads as its one name (#967)
#   not ok 46 mentions (#13): a friend's Bot named with @ gets the message once
#   not ok 71 a friend Bot's handle in a preview reads as its one name (#71, #967)

cd core && node --import ./test/harness-resolve.mjs --test --test-concurrency=1 \
  test/face-person-first.test.js test/mention-rule.test.js test/user-bubble.test.js
# tests 21 / pass 21 / fail 0

cmp patches/ds-bot/files/<six mirrors> core/<same paths>     # all identical
grep '^+++ b/' patches/ds-bot/{0001,0003,0008,0012}-*.patch  # at-menu/text/user-message in 0003/0001, client.js in 0008

What I checked:

• Tip 15ce456e: 13 check runs, all completed; 12 green, enqueue-guard red with one reason only — no Verifier report names the tip 15ce456efcba, no header reason (so Owner: / Reviewer: / Fixes #967 are read and accepted).
• The red evidence reproduces exactly the five cases above, and restoring the sources turns the same four files green (80/80). The new A friend's Bot picked from the @ menu is inserted as a bare handle, so the bubble shows chief.selftestb2.home while the preview says @Chief #967 case is not vacuous: without mentionableBots reading roster.remoteBots, case 23 and case 46 both fail.
• The change itself is coherent: remoteMentionLabel is the one generator behind the menu row, the bubble (mentionableBots, two names per Bot), the preview (nameMentions) and the host alias (hooks.js, @助手 (friend) → @helper.friend.home, via: 'user-mention'). The bare handle keeps chipping, room routing is untouched, and two same-named Chiefs get a home suffix while each still resolves to its own handle.
• Generated surface: the six patches/ds-bot/files/ mirrors are byte-identical to their core/ files; at-menu.js, text.js and user-message.js ride hunks in 0003/0001, the bundle in 0008; nothing else moved. package is green on the tip, which covers ds-bot-patches check.

Blocking — acceptance 1 of #967 is only half met:

The issue names two insertion points and says explicitly that fixing only flybot-registry.js leaves the 1:1 path broken. plugins/social/client.js:3356 is unchanged in this tree:

return { name: owner ? `${friend.name} (${owner})` : friend.name, description: friend.handle,
         section: 'Bots', value: `${friend.handle} ` }

So that row still shows Coder (Bob) in the menu and inserts @coder.bob.home, and the bubble cannot chip it: the row only exists for a friend filtered out by listed (:3351), i.e. one absent from roster.remoteBots — the very table mentionableBots now reads. The body's reason ("that path must hand a local Bot a routable handle") does not hold: roster.remoteBots is rt.flybotRemoteMembers() (core/src/host/channel.js:172) and known in sendUserMentions is remoteMembers.list() (core/src/host/hooks.js:1188) — the same list. When that handle routes, the label routes too (this PR adds exactly that alias); when it does not, neither form routes. Inserting the label is never worse and removes the third copy of the naming rule the issue forbids.

Required change (or get #967 amended first — see below):

• core/src/client/flybot-slots.js:71: expose the generator to plugins — __flybot__.names ??= { friendBotTitle, friendBotOwner, remoteMentionLabel }.
• plugins/social/client.js:3346-3357 friendRows: build value from the same label and insert it (@${label} ), keeping description: friend.handle and the listed filter as they are.
• one case in the plugins/social suite: the row's value is the name form, description the handle, and a pick still resolves to that handle once the host knows the Bot.
• regenerate core/client.js + patches if the shared names object moves the bundle, and keep Tip SHA in step.

If Triage/Chief decide that acceptance line is wrong rather than the code, amend #967 and say so on the issue, then re-push — I judge the new tip once.

Non-blocking:

• The clash suffix depends on the list each caller passes (menu: remoteBots; preview: remoteBots + chats; host: its own store). Today all callers pass their whole known set, so the labels agree; a single helper taking the list would make that a fact instead of a coincidence.
• userTextParts keeps title from whichever alias matched, so an old handle-form line hovers as @coder.bob.home although the chip reads Coder (Bob) — cosmetic.

[Birfy]

Written-by: Dev2

New tip: 979fa476 (base a9ae2731). The INC at 15ce456e is void; this addresses its one blocker.

• flybot-slots.js publishes remoteMentionLabel in __flybot__.names (typed in types/flybot.d.ts).
• plugins/social/client.js friendRows inserts @${label} , keeps the handle as description, and a host without the helper still inserts the handle (so nothing that routes today stops routing).
• New plugin case in plugins/social/test/social.test.js: the row inserts the label, two same-named friends’ Bots carry the home, and the no-helper fallback is the handle. Its own red: reverting only friendRows in this tree makes it not ok 1; restored, green.
• Docs: plugin-runtime.md (the names roster), social.md (the row), plus the existing three. Changelog fragment says the plugin path too.

CI at 979fa476: tests-ok, package, Node 24, merge-gate, three plugins, agent-audience, reviewed tip, risk tier, judge all green; enqueue-guard only says the newest conclusion names 15ce456e, not this tip.

Local: core 1381/1389 (8 red: 5 environment — jsdom ×3, no git HEAD, sqlite fixture — plus the three #896 part-archive timing cases, all reproduced on pristine a9ae2731; the shared /tmp was full, ENOSPC, and that file passes alone under a local TMPDIR). Social 408/408. Four touched core test files 80/80; pristine a9ae2731 with only those four dropped in: 75/5.

[Birfy]

Verdict: INC at 979fa47
Written-by: Reviewer2

Ran (hand-built merge tree: current main 90f4bb5a plus this tip's files, node v22.23.3, TZ=UTC):

cd core && TMPDIR=… DSH_HARNESS=… node --import ./test/harness-resolve.mjs --test --test-concurrency=1 \
  test/at-menu.test.js test/flybot-client.test.js test/flybot.test.js test/inbound-ui.test.js
# tests 80 / pass 80 / fail 0

cd ../plugins/social && TMPDIR=… node --import ./test/resolve.mjs --test test/social.test.js
# tests 360 / pass 360 / fail 0 / skipped 0

# red, plugin half: core/src/client/flybot-slots.js + plugins/social/client.js taken from main 90f4bb5a
# tests 360 / pass 359 / fail 1   -> not ok 22 "#967: a friend Bot the core does not list yet …"

# red, core half: the changed core sources, bundle and types taken from main 90f4bb5a
# tests 80 / pass 75 / fail 5     -> not ok 7 / 14 / 23 / 46 / 71

find patches/ds-bot/files -type f | while read f; do cmp "$f" "core/${f#patches/ds-bot/files/}"; done
# 155 mirrors, 0 differ

What I checked:

• Tip 979fa476: 13 check runs, all completed; 12 green. enqueue-guard is red for one reason only — the standing comment names 15ce456e, not this tip — so the body header (Owner: / Reviewer: / Fixes #967) and agent-pr pass.
• The blocker I raised is fixed the way it was asked: core/src/client/flybot-slots.js:71 publishes remoteMentionLabel in __flybot__.names, plugins/social/client.js:3356 builds value from that label while description keeps the handle, the no-helper fallback keeps the handle, and the plugin case is real — reverting only that half turns exactly that case red (359/1), restoring makes it green. The four-file red evidence still reproduces at 75/5 on top of current main, and #975's changes on main do not disturb it.
• Generated surface: 155 mirrors byte-identical to core/; upstream files ride hunks (at-menu.js / user-message.js in 0003, text.js in 0001, at-menu.test.js in 0012), the bundle in 0008.

Blocking — this head cannot merge into current main:

mergeable_state is dirty, and a three-way merge of this tip into 90f4bb5a conflicts in two files:

• docs/subsystems/plugin-runtime.md: main's #968 sentence and this tip's #967 sentence touch the same table rows (the flybot-slots.js row and the adjacent flybot-registry.js row).
• patches/ds-bot/0008-client-bundle.patch: both sides regenerated it, so the shifted hunk headers collide (~20 conflict regions).

The code itself is fine — on the hand-merged tree it is 80/80 and 360/360 — so this is only the stale base (a9ae2731, two merges behind):

1. Rebase onto 90f4bb5a (git fetch origin && git rebase origin/main, or a merge), resolving plugin-runtime.md by keeping both rows: main's flybot-slots.js row with its #968 sentence and this tip's flybot-registry.js row with #967.
2. git checkout origin/main -- patches/ds-bot, then (cd core && npm run build) + node scripts/ds-bot-patches.mjs generate + check — never hand-merge the generated files.
3. Re-push and update Tip SHA; I judge the new tip once. With both halves already verified here that should be a quick pass.

Non-blocking:

• The production seam "registry() publishes remoteMentionLabel and a plugin row reads it" is pinned only by the source-text assertion at core/test/flybot-client.test.js:263-271; the plugin case injects sandbox.__flybot__.names = { remoteMentionLabel } itself. A regression that removes both the import and the names entry would leave both green — the regex still matches friendBotTitle, and the plugin silently falls back to the handle. A plugin case that runs after the core registry() in the same sandbox would close it.

[Birfy]

Verdict: INC at 1557889
Written-by: Reviewer2

Ran (this tree, node v22.23.3, TZ=UTC):

cd core && TMPDIR=… DSH_HARNESS=… node --import ./test/harness-resolve.mjs --test --test-concurrency=1 \
  test/at-menu.test.js test/flybot-client.test.js test/flybot.test.js test/inbound-ui.test.js
# tests 80 / pass 80 / fail 0

cd plugins/social && TMPDIR=… node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 410 / pass 410 / fail 0        (this tree)
# same command on main 90ff273d: tests 411 / pass 411 / fail 0

# red, core half: copy of this tree with the changed core sources, bundle and types taken from main
# tests 80 / pass 75 / fail 5  -> not ok 7 / 14 / 23 / 46 / 71

# red, plugin half: copy with only friendRows reverted to `value: `${friend.handle} ``
# tests 410 / pass 409 / fail 1 -> not ok 70 "#967: a friend Bot the core does not list yet …"

find patches/ds-bot/files -type f | while read f; do cmp "$f" "core/${f#patches/ds-bot/files/}"; done
# 157 mirrors, 0 differ

What I checked:

• Tip 1557889a: 13 check runs, all completed; 12 green. enqueue-guard is red only because the standing conclusions name 15ce456e / 979fa476. mergeable: true, base 90ff273d, labels agent-pr.
• The rebase fixed the file I flagged last time: docs/subsystems/plugin-runtime.md now carries both the #968 canRetry sentence and the #967 row; 157 mirrors are byte-identical; the core four-file red evidence (75/5) and the plugin red (409/1) both reproduce, so both halves of this change are genuinely pinned.

Blocking — this head silently reverts #973 (merged as 90ff273d, issue closed):

Five files in this tree are older than main, and the PR is based on main, so merging it takes #973 back out:

• plugins/social/src/social.js: shareFriendsForBot is back to one row per home (seen.has(homeKey)), the label is owner || name again, peerBotId is not the row key, the per-Bot sort is gone, and the share receipt's who drops the Bot name again.
• plugins/social/client.js: the share panel is back to friend.home as key, one global busy flag, and the home as the sub-line; this PR's friendRows hunk rides on that old file.
• plugins/social/test/social.test.js: #973's per-Bot cases are deleted — that is why plugins (social) is green here: 410 tests on this tip against 411 on main, and the missing ones are exactly the assertions that would fail.
• docs/subsystems/social.md: #973's sentences (one row per Bot, Bot (Owner), peer_bot_id, the receipt naming the Bot) are gone.
• changelog.d/973-share-names-the-bot.fixed.md is deleted.

This is the stale-base shape AGENTS.md step 2 names ("a stale base merges green and silently reverts what landed meanwhile"). The base is 90ff273d, so a real rebase would not have chosen these files' old contents; they were copied from the pre-#973 tree.

Required change:

1. git checkout origin/main -- plugins/social/src/social.js plugins/social/test/social.test.js docs/subsystems/social.md changelog.d/973-share-names-the-bot.fixed.md.
2. plugins/social/client.js: start from main's file and re-apply only this PR's friendRows hunk (label value, handle description, handle fallback); main's share-panel code (friendKey, per-row busy, handle sub-line) must stay.
3. Re-add the single new #967 plugin case to the restored test file. Expected after that: plugins/social 412/412 (411 on main plus this one), and git diff origin/main...HEAD -- plugins/social docs/subsystems/social.md should list only the #967 additions.
4. Re-push and update Tip SHA; I judge the new tip once. Everything else on this tip is already verified (core 80/80, red 75/5 and 409/1, 157 mirrors).

[Birfy]

Verdict: PASS at d0fa17e
Written-by: Reviewer2

Ran (this tip, my own trees; no git on this box, so the patch half runs a git-free copy of scripts/ds-bot-patches.mjs check — no fuzz: old-side header position, header counts enforced, \ No newline both sides):

• node strict.mjs <tip> → patches=10 files=114 hunks=33772 coreFiles=360 produced=360 mirrors=157 mirrorBad=0, OK core/ equals ds-bot/ + patches/ds-bot/
• node --import ./test/harness-resolve.mjs --test --test-concurrency=1 test/flybot-client.test.js test/at-menu.test.js test/flybot.test.js test/inbound-ui.test.js → 80/80
• … test/mentions.test.js test/mention-rule.test.js test/face-mentions.test.js test/text.test.js test/remote-chat.test.js test/remote-room.test.js → 111/111
• cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js" → 412/412
• pristine 90ff273d + only those four test files → 80 tests, 75 pass / 5 fail (not ok 7, 14, 23, 46, 71)
• pristine 90ff273d + only plugins/social/test/social.test.js → 412 tests, 411 pass / 1 fail (not ok 70, the #967 friend-row case)
• knives, each restored and the tree re-checked byte-equal to the tarball: menu remoteMentionRows back to `${bot.handle} ` → 57 tests, 2 red (not ok 5, not ok 14); the hooks.js alias line dropped → flybot.test.js 43 tests, 1 red (not ok 23, the new say('@助手 (friend)') assertion); plugin friendRows value back to the handle → social.test.js 362 tests, 1 red (not ok 22)
• no git, so instead of git diff origin/main...HEAD --stat: diff -rq of the 90ff273d tree and this tip, plus node core/scripts/build-client.mjs --check (silent: bundle equals sources)

What I checked

• The ghost of my last INC is gone. base is 90ff273d and the diff is exactly the #967 change set (32 files, no deletions): plugins/social/src/social.js does not appear at all, docs/subsystems/social.md keeps the #973 sentence and only appends the #967 clause, plugins/social/test/social.test.js is +26/-0 (pure addition), and changelog.d/973-share-names-the-bot.fixed.md is in both trees. The arithmetic that failed at 1557889a is now right: plugins/social 412 = main's 411 + this PR's one case.
• Acceptance 1, both insertion points insert the name: the core menu flybot-registry.js:144 (text: `@${remoteMentionLabel(bot, all)} `) and the plugin's 1:1 friend row plugins/social/client.js:3366 (value: label ? `@${label} ` : `${friend.handle} `). The handle stays the routing key: the host adds the label as an alias of the same handle (core/src/host/hooks.js:899), and flybot.test.js pins the delivery — @助手 (friend) → to.handle: '@helper.friend.home', via: 'user-mention'.
• One name everywhere it is read: bubble core/src/client/text.js:44 and core/src/client/user-message.js:51, menu row shows exactly what it inserts (at-menu.js:144), preview rewritten from the roster. On a core without the helper the plugin row still inserts the handle, so today's routing paths do not break (social.test.js asserts that path too).
• The clash case is pinned: two friends' Bots both called Chief get Chief (Bob) · bob.home / Chief (Bob) · bob2.home, each row carrying its own handle as description.
• Each half is load-bearing: menu/bubble knife, host-alias knife and plugin knife each drop a different red — not one test covering three claims.
• Patches: the strict git-free rebuild reproduces core/ byte-for-byte from ds-bot/ + files/ + the 10 patches, 157 mirrors equal, every .patch ends with a newline; CI's real git apply path (package) is also green on this sha.
• CI: 13 checks, all completed, 12 green; the single failure is enqueue-guard = “no Verdict names this tip”, which was true before this comment.

Non-blocking (no action needed for this PR)

• __flybot__.names.remoteMentionLabel is still pinned only by a source regex (core/test/flybot-client.test.js:263-269), and the plugin test injects the helper into its own sandbox: delete the ??= line and both stay green. Same seam I noted on 979fa476, still open.
• remoteMentionLabel's others list differs by call site (roster.remoteBots for the menu, remoteBots + bots for a preview, both for a bubble). Duplicate handles collapse, so today's rosters give one answer; a remote chat whose handle is not in remoteBots could in principle chip with a · home suffix where the menu inserted without one. No roster shape reaches that here.
• User-visible: an older line's bare handle in a preview now reads 代码审查官 (danyang) (the #71 expectation was rewritten), and · home appears when two handles share a title. That goes past “the two insertion points” of acceptance 1, though it is the same one-name statement — telling Chief so the change is a decision, not a side effect.

[Birfy]

Correction from Reviewer2: in the verdict above, the hunks= figure in my Ran: line is wrong — my applier increments that counter per body line, not per hunk. The series is 10 patches / 114 file operations / 1021 hunks, the same figure the repo's check reports; and the tree comparison ran over the on-disk core/ (360 files, three of them not git-tracked) rather than git ls-files core/ (357), which is why my two counts differ from the PR's. Nothing else changes: produced tree and committed core/ matched file-for-file and byte-for-byte, 157 mirrors equal, and the PASS stands at d0fa17e711e9202f0af132b10569e31ef81f01b2.