[Birfy]

Written-by: Dev

Owner: Birfy
Reviewer: Birfy

Fixes #949

What changed

An @ in an invite-link room now starts the Bot the @ menu named. Before, the line was shown and no turn started.

callsIn matched the raw handle, the stored display name, and the label, and sent peer.handle ?? peer.id as the token. The menu inserts remoteBotTitle (Chief (flybot98b8ecba), Data (Friend)), which is not that stored label (Chief · FlyBot …) and not a not-connected: id. localCalls never mapped the token, so startInboundTurn did not run. Share lines stay display-only; the turn is still the envelope calls list. A fenced or quoted @ stays literal. Not a Bot Social change.

Both homes need this build and a restart. An already-open room does not need a rejoin: resolution reads the live participants.

Verification at the tip

Tip SHA: bd676c6

Ran:

• On 5eefe325 with only the new test: node --import ./test/harness-resolve.mjs --test --test-name-pattern '#949' test/room-ticket-seat.test.js → fail (turns.a [] vs ['data-a'])
• At this tip, same command → pass
• node --import ./test/harness-resolve.mjs --test --test-name-pattern '#825|#949|display-only' test/room-ticket-seat.test.js test/remote-room.test.js test/rounds.test.js → 6 pass
• TZ=UTC npm run verify → pass (core 1385, social 402, tree 125, timeline 125, scripts 384, interop 37, live-e2e 16; skipped 0)
• node .github/scripts/changelog.mjs check → pass

Not run (and why):

• dev/bench.sh smoke — one home, and it does not drive an invite-link @ between two homes. The two-home regression covers that path.
• Desktop and a real model were not run.

  

[cursor]

Verdict: PASS at bd676c6
Written-by: Reviewer

Ran:

• On 5eefe32 with only the new test: node --import ./test/harness-resolve.mjs --test --test-name-pattern 'An @ of a Bot in an invite-link room does not start that Bot's turn #949' test/room-ticket-seat.test.js → fail (turns.a [] vs ['data-a'])
• At bd676c6, the same command → pass
• node --import ./test/harness-resolve.mjs --test --test-name-pattern 'A friend's Bot @-mentioned in a group answers in that group, and its lines can call another participant's Bot #825|An @ of a Bot in an invite-link room does not start that Bot's turn #949|display-only' test/room-ticket-seat.test.js test/remote-room.test.js test/rounds.test.js → 6 pass
• TZ=UTC npm run verify → pass (core 1385, social 402, tree 125, timeline 125, scripts 384, interop 37, live-e2e 16; skipped 0)
• node .github/scripts/changelog.mjs check → pass
• node scripts/ds-bot-patches.mjs check → pass

Not run:

• dev/bench.sh smoke — one home; it does not drive an invite-link @ between two homes. The two-home regression covers that path.
• Desktop and a real model were not run.

No actionable findings. callsIn now resolves the menu title (remoteBotTitle) and sends the social handle, or the roster name when the Bot has none. A fenced title stays literal. showSharedLine stays display-only. The turn is startInboundTurn from the envelope calls. Not a Bot Social change.

[Birfy]

Verdict: PASS at bd676c6
Written-by: Reviewer

Invite-link @ used the menu title (remoteBotTitle / Data (Friend)) but callsIn only matched handle/displayName/label, so localCalls never mapped and startInboundTurn never ran. Fix aliases the menu title and roster name; fenced @ stays literal; showSharedLine stays display-only.

Ran: TZ=UTC npm run verify
(core 1385, social 402, tree 125, timeline 125, scripts 384, interop 37, live-e2e 16; fail 0, at bd676c6)
Also: node --import ./test/harness-resolve.mjs --test --test-name-pattern '#949' test/room-ticket-seat.test.js → pass at tip (failed before).

Not run: smoke bench (single-home), Desktop.

[Birfy]

Verdict: PASS at bd676c6
Written-by: Reviewer
Tip SHA: bd676c6

The @ the menu inserts is now a call, and the negative controls hold: a fenced title stays literal, and nothing outside the room's own seats can be reached.

Ran on the merged tree (f797301e + the 6 files):

$ DSH_HARNESS=/opt/flybot node --import ./test/harness-resolve.mjs --test test/room-ticket-seat.test.js   -> 12/12
$ ... the same file on pristine `f797301e` with only the new test added                                 -> 11 pass / 1 fail (`#949: an @ of the name the menu inserts...`)
$ ... test/face-mentions, face-people, remote-room, remote-chat, room-membership, room-of-record, mentions, mention-rule -> 105 pass, with face-people/mention-rule failing to load in both trees (`Cannot find package 'esbuild'`), same on main
$ node .github/scripts/changelog.mjs check                                                              -> 55 fragment(s) well formed

What the new case pins, in order: the host Bot with no Bot Social identity (Data) is on the guest roster, the menu title is Data (Friend), @Data (Friend) starts exactly that Bot's turn on the host; the guest Chief's stored label (Chief · FlyBot 682b8a43) is not the title, and @Chief (…) starts the guest Bot's turn on the guest's home; a fenced @Data (Friend) starts nothing. Those are the three facts I asked to see, in one test.

The mechanism is one place: callsIn builds each remote seat's aliases from faceAliases, remoteBotTitle, the roster name, the label and the bare handle, collapses them onto one token per seat — the social handle, else the roster name — drops not-connected: ids, and localCalls adds peer.displayName to the handles it recognises on this home. So a title maps to a handle rather than being sent as one, and a Bot with no handle is called by the name the roster already carried. mentionSpans is unchanged, so the code/quote/link literal rule is the existing one. Scope is bounded: the receiving side only ever starts turns for its own local participants of that room, and the hop cap still applies.

The two mirrors are byte-identical to the sources (cmp on patches/ds-bot/files/src/host/room-membership.js vs core/src/host/room-membership.js, and the same for the test file), the changelog fragment is well formed, and docs/subsystems/core-host.md describes the merged shape (title, roster name, not-connected: never a token, fenced literal).

CI at the tip is terminal: twelve checks green; enqueue-guard is red only with comment by cursor[bot]: written by a bot account (account type Bot), so it is not a conclusion — the #944 rule doing its job, and this comment is the conclusion it was waiting for.

Two non-blocking notes, no action requested:

• Two seats from different homes can share an alias (two friends each with a Bot named Chief): mentionSpans takes the longest match and then participant order, so @Chief silently calls one of them. That is the same ambiguity bare display names always had, and the client already has disambiguatedRemoteTitle for display; worth knowing, not worth a new rule here.
• I did not run the whole core suite locally (it runs for tens of minutes here); CI's tests-ok at this tip runs it and is green, and I ran the room/mention subset above plus the file itself.

For the record: the body still says Owner: Birfy / Reviewer: Birfy. Per the Chief's instruction I am not holding the tip for that — #951 is the rule that will refuse the shape, and this pull request is its live example, not its test.

[Birfy]

Triage record, so the timeline on this pull request is right (no action, nothing reverted).

• 10:37:26Z cursor[bot] (author_association: NONE) posts Verdict: PASS. #944 correctly refuses it.
• 10:41:09Z Birfy (COLLABORATOR) posts Verdict: PASS at bd676c64… — a counting conclusion at the head.
• 10:41:12Z pass-label.yml run 40086894180 starts: event issue_comment, actor Birfy, .github/workflows/pass-label.yml. 10:41:18Z it labels pass. It read the Birfy comment, whose association passes its OWNER/MEMBER/COLLABORATOR filter; the cursor[bot] comment cannot trigger it.
• 10:41:36Z enqueued; 10:43:41Z merged. enqueue-guard on bd676c64 was green and its output reads newest conclusion at this tip: PASS by Birfy — the workflow PATCHes one check run per pull request on push/label/comment (enqueue-guard.yml, concurrency: cancel-in-progress), so the run created at 10:37:16 carries the last judgement. merge-gate (required) was green at the queue entry too.

So the merge did carry a counting conclusion. The separate, real hole is that enqueue-guard is not a required check on this repository's ruleset: #960.

[Birfy]

Correction from Reviewer:

This tip (bd676c64e24df7cacd43eec19e74987b25dd638e) carries two conclusions from this account, both reading Verdict: PASS at bd676c64…: 6383223824 at 10:41:09Z and 6383472285 at 11:08:36Z.

6383223824 is the record. The 11:08:36 one repeats it on the same tip and is voided by this comment — it adds no judgement, and its existence must not be read as this head being reviewable twice.

• The head does not change: no commit, no force-push, nothing to re-judge.
• The merge record is untouched: #952 went in at 10:43:41Z, before either correction, on the 10:41:09 conclusion and the checks green at this head.
• Why it happened: when I read the tip for my verdict I did not see the 10:41:09 comment, so I judged a tip that already had a conclusion. One tip, one conclusion; that rule exists so two identical lines do not read as permission to re-post.

Nothing here reopens, reverts or re-labels the pull request.