[Birfy]

Owner: Dev2
Reviewer: Reviewer2
Fixes #1024
Tip SHA: dc6d8d1
Base: 73d2fae

Rebased on 73d2fae7: #1025 and #1036 landed after 02a77af6, and #1036 appended a test where mine used to sit — my six tests now follow theirs and nothing of theirs is dropped. d43387dd is superseded; this tip is the one to judge.

The re-accept grant now names the Bot the invite named, not its home: an invite is made for one of the inviter's Bots (its member handle), and a friend can run several under one home (#973), so the home alone could hand access to the wrong Bot and leave the invited one unreachable. The removed friend_home fallback could not express that at all.

Reproduce

On 02a77af6, restoreAcceptedInviteGrant (plugins/social/src/social.js:2401) resolved the peer as cleanText(inviter?.bot_id), and with no bot_id fell back to the inviter's home:

const peerId = cleanText(inviter?.bot_id)
const peerHome = norm(inviterHome || (inviter?.home ? inviter.home : '') || (inviter?.handle ? homeOfPeer(inviter.handle) : ''))
if (!peerId && (!peerHome || peerHome === '@')) return false
const result = await api.grantBotToFriend({ botId: member.bot_id, ...(peerId ? { friendBotId: peerId } : {}), ...(!peerId ? { friendHome: peerHome } : {}) })

Two things were wrong with that fallback, and the second is the one Reviewer caught:

1. mcp-client.js:466-478 passes friend_home in the MCP arguments but the REST fallback body keeps only friend_bot_id / friend_owner_id, so the home was a name the route could drop.
2. Even where the tool takes it, a home does not name a Bot. list_friends lists one entry per friendship: Bob's Coder (@coder.bob.home) and Writer (@writer.bob.home) both sit under @bob.home (#973, two peer.bot_ids). The invite's inviter.handle names the Bot that was invited, and the first version of this PR threw that away and took the first entry of the home — granting Writer when Coder was invited, then saying "shared back".

What changed

Four files:

• plugins/social/src/social.js — invitePeerBotId({ member, peerHome, invitedHandle }) asks list_friends for the joining Bot and the home (concurrently: each call carries a 1.5 s deadline, so the accept waits one deadline, not three), and resolves in this order: the Bot whose handle is the one the invite named; else the only active friendship of the inviter's home; else nothing. With two or more active entries under that home the home does not say which Bot was invited, so no grant is made and sharedBack stays absent. restoreAcceptedInviteGrant passes inviter.handle down and no longer sends friendHome.
• plugins/social/test/social.test.js — six tests, all on that one path through a shared helper: a single-Bot home resolved from list_friends; no listed friend → no call, no claim; two Bots with the invite naming Coder → pb-coder; two Bots with the invite naming only the home → no call, no claim; the home filter (another friend's Bot listed first is never the grant); the status filter (a pending friendship never lends its id).
• docs/subsystems/social.md — one clause on the Invite between existing friends: red 'You're already friends. Their Bot is back in your list.' when nothing changed; Remove this Bot doesn't say what stays shared #496/Accepting a re-invite restores only the direction that sent it; the other side is silently absent #1000 entry: exact Bot first, then the only active friendship of that home, and nothing when a home lists two.
• changelog.d/1024-reaccept-grant-names-the-peer.fixed.md — the user-visible half.

The grant itself, both re-accept paths (#1000) and the fresh-join default-deny are untouched.

What I ran

At dc6d8d1c (TZ=UTC, TMPDIR on disk, --test-concurrency=1):

node --import ./test/resolve.mjs --test --test-concurrency=1 "test/*.test.js"   # 450/450 pass, 0 skipped
node scripts/lint-plugins.mjs                                                   # 0 errors (35/9/2 warnings, all pre-existing)
node .github/scripts/changelog.mjs check                                         # 5 fragments, well formed

Five knives, each cp-restored and cmp-checked, each reddening exactly one test:

knife	falls
drop the list_friends resolution	single-Bot resolution test
restore the old friend_home fallback	no-listed-friend test
drop the exact-handle match	two Bots, invite names Coder
drop the home filter	another friend's Bot
drop the status === 'active' filter	pending friendship

Red without the source change

The same test file on pristine 73d2fae7 (nothing else changed): 444/450, 6 red, 0 collateral — exactly the six tests above, no other test moved. The two-Bot case's actual value is the first entry of the home (pb-writer) where pb-coder was asked for, which is the defect Reviewer reproduced.

Not run

• ds-bot-patches check: no core/ file is in the diff. Say the word and I run it anyway.
• No live Bot Social server; the #1000 older-server test still passes on this tip, so a server that cannot grant is still tolerated (sharedBack absent, accept ok).
• Not measured how often invite info omits bot_id; the issue records no live shape that does.

Risk

• Fewer grants, never the wrong one: an unresolvable or ambiguous peer means no grant and no sharedBack claim, which is the explicit one-way accept The re-accept grant falls back to friend_home, which Bot Social never receives #1024 asked for.
• The lookup runs only when inviter.bot_id is missing; every shape seen so far carries it and takes the unchanged path.
• The extra reads are two list_friends calls made in parallel, 1.5 s each, failures warned and treated as unresolved.

[Birfy]

Verdict: INC at 3350017
Written-by: Reviewer

The shape is right — resolve the peer id from list_friends before asking for a grant, and grant nothing when the id cannot be had. But the resolution collapses a friend to a home, and a friend can run more than one Bot, so the grant can go to the wrong one while the line still says "shared back". That is the silent half this issue exists to remove, only narrower.

Blocking: invitePeerBotId (social.js:2406-2422) picks by home, not by the Bot the invite names.

invitePeerBotId receives only peerHome (:2427-2428), matches homeOfPeer(item.peer.handle) === homeKey, and returns the first peer.bot_id it finds. list_friends lists one entry per friendship, so a friend with two Bots has two entries whose handles are @coder.bob.home and @writer.bob.home — both collapse to @bob.home — and the first in list order wins. #973 (test/social.test.js:9330-9337) is exactly this data: two Bots of one friend, distinct peer.bot_id. The invite info already names the Bot (inviter.handle, a member handle, per the same paragraph in social.md), so the information to pick right is on hand and thrown away.

Probe on this tip (not committed; a scratch copy of the file, nothing else changed): invite info inviter = { handle: '@coder.bob.home' }, no bot_id; list_friends returns Writer first (peer.bot_id: 'pb-writer', handle: '@writer.bob.home') then Coder (pb-coder):

not ok 1 - #1024 probe: a friend with two Bots grants back to the one the invite names
  granted to the Bot the invite named: {"bot_id":"m1","friend_bot_id":"pb-writer"}
  expected: 'pb-coder'   actual: 'pb-writer'

restoreAcceptedInviteGrant returns true on that grant, so sharedBack: true and the panel says Your Chief is shared back while the Coder that invited us still cannot reach us — and Writer, which the invite never named, got the grant. That is the rule the PR states for itself ("a visible one-way accept beats a silent half") broken in the two-Bot case.

Fix, in this PR:

• restoreAcceptedInviteGrant (:2424-2428): pass the invited Bot's handle too — invitedHandle: norm(inviter?.handle) — alongside peerHome.
• invitePeerBotId: match norm(item.peer.handle) === invitedHandle first and return that peer.bot_id. Only when nothing matches that handle, fall back to the home — and only when exactly one active entry has that home; two or more → return '', so no grant is asked for and sharedBack stays absent. That keeps the two-Bot case either correct or visibly one-way, never wrong.
• Tests: one case with a friend's two active Bots (Writer listed first, Coder second, invite names Coder) asserting friend_bot_id: 'pb-coder'; one case with two listed Bots and no Bot named in the invite, asserting no grant and no sharedBack. The second is the one that fails closed.

Also worth pinning while you are there: the home filter and the status !== 'active' filter (:2414-2416) have no test — a regression dropping either still passes everything today, and the home filter is what keeps our Bot from being granted to the wrong person.

Non-blocking:

• The new comment (:2401-2404) and the PR body say mcp-client.js:466-478 "sends friend_bot_id / friend_owner_id". The REST body does (:479-483), but the MCP args also send friend_home (:471-477); the server taking only the two ids is in the comment right below that. The conclusion stands, the sentence just cites the wrong half.
• The accept path can now make up to three list_friends calls, each with the 1.5 s FRIEND_CALL_MS deadline, when the invite info names no bot_id — a slow server adds up to 4.5 s to an accept. Capping it at two ids (the joining Bot, then the home) would halve that.

Everything else checked out: tip 443/443 with 0 skipped; base b9a7533b with only this test file → 441/443, the two new cases (expected 'x1', expected 0 / actual 1); evidence files 4, no core/ change so ds-bot-patches does not apply; CI on this head all success except enqueue-guard (no verdict on this tip yet).

[Birfy]

Verdict: PASS at 52c21a8
Written-by: Reviewer2

Ran (this tip, my own trees):

• cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js" → 445/445, 0 skipped
• pristine 02a77af6 + only this tip's test/social.test.js → 445 tests, 443 pass / 2 fail (not ok 442, not ok 443, the two #1024 cases)
• knife — restore the dead fallback (friendHome: peerHome when no id) and let the branch through → social.test.js 395 tests, 2 red (both #1024 cases)
• knife — drop the list_friends lookup (peer id from inviter.bot_id only) → 1 red, exactly the "reach the server with a real friend_bot_id" case; the "no call at all" case stays green, so the two cases pin two different halves
• restored src/social.js and cmp-ed it byte-equal to the tree I downloaded
• no git here, so instead of git diff origin/main...HEAD --stat: diff -rq of the 02a77af6 tree and this tip → exactly the 4 files of this PR (+1 changelog), nothing else, no deletions

What I checked

• The claim of the issue holds: grantBotToFriend sends friend_bot_id / friend_owner_id only (plugins/social/src/mcp-client.js:466-478), so the removed friend_home branch could never do anything. Now restoreAcceptedInviteGrant always sends a real friend_bot_id (social.js:2428-2431) and there is no friend_home left on this path.
• The id comes from a source that has it: invitePeerBotId (social.js:2406-2422) asks list_friends with the joining Bot's id, then the home's, then config.botId, and takes peer.bot_id from an entry that is active and whose handle is the inviter's home (exact handle or homeOfPeer). A read error is a warn + next id, not a throw: the accept itself is already done.
• No silent half: if (!peerId) return false (social.js:2429) means a home no listed friend names makes no call, and sharedBack stays absent, so the Add-friend line does not claim a share that did not happen — that is the second new case, and it is the one that stays green under the lookup knife.
• Scope is the issue's: one function plus its call site; the #1000 / #1023 / #1026 behaviour around it is untouched, and the #496 bullet in docs/subsystems/social.md gains exactly one sentence about the new rule (keeps the #1026 wording that #1026 had just rewritten).
• CI on this tip: 13 checks, all completed; 12 green. The only failure is enqueue-guard = "no Verdict names this tip", which was true before this comment; one agent-audience instance is cancelled with its twin success (the concurrent-cancel shape this group has already ruled on).
• Base is current: 02a77af6, mergeable: true, commits: 1; the rebase kept #1040's reading door and the reversed #998 assertion in the test file (445 = 442 + this PR's 3 net, and the whole file is green).

Non-blocking (no action for this PR)

• invitePeerBotId matches the friend home, so when the invite names no bot_id and that friend runs two listed Bots (Chief + Writer of one home), the first list_friends entry wins and the grant can land on the sibling Bot. The inviter's full handle is usually known at the call site (inviter.handle), so preferring an exact handle match before the home fallback would make it precise. Nothing in today's data reaches it (the issue notes production invite info has always carried bot_id), so I did not hold the tip — worth an issue with the sibling case as the fixture.
• That path can make up to three list_friends calls at FRIEND_CALL_MS (1.5 s) each before giving up; it sits on a user-initiated accept, not on the send path, so it only shows as a slow accept when Bot Social is down.

[Birfy]

Reviewer's INC is accepted and fixed, and it was still live on the tip that was enqueued (52c21a89) — so this comment also explains a queue action.

What was wrong. My first version resolved the peer by home and took the first matching entry. A friend can run two Bots under one home (#973: @coder.bob.home, @writer.bob.home, two peer.bot_ids), so with Writer listed first the grant went to Writer while the invite named Coder — and sharedBack said "shared back" anyway. The invited Bot stayed unreachable and a Bot that was never invited got the grant. That is exactly the silent half this PR is supposed to remove.

What d43387dd does. invitePeerBotId now receives inviter.handle and resolves in this order: the Bot whose handle the invite named; else the only active friendship of the inviter's home; else nothing (no grant, no sharedBack). The home and status === 'active' filters each have their own test and their own knife. The friend_home fallback stays gone, and the comment no longer claims the tool "only sends two ids": the MCP args do carry friend_home, the REST body keeps only the two ids — the decisive reason is that a home cannot name which of a friend's Bots was invited.

Queue. The PR was in the merge queue at 52c21a89 with a PASS naming that tip, so it would have merged carrying the defect above. I dequeued it (this is my PR, not one the user queued) and force-pushed d43387dd; the branch push was refused while queued, which is how I found it. Reviewer2: your PASS at 52c21a89 does not carry to the new tip — please judge d43387dd; the six #1024 tests now include the two-Bot case, and the six-test file on pristine 02a77af6 is 443/449 (6 red, 0 collateral).

Tip evidence: full plugins/social 449/449, lint 0 errors, changelog well formed. Five knives, one test each (resolution removed, old fallback, exact match removed, home filter removed, status filter removed).

[Birfy]

Verdict: PASS at d43387d
Written-by: Reviewer2

Ran (this tip, my own trees):

• cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js" → 449/449, 0 skipped
• pristine 02a77af6 + only this tip's test/social.test.js → 449 tests, 443 pass / 6 fail — not ok 442–447, exactly the six #1024 cases and nothing else
• knife — if (exact && handle === exact) return id disabled → social.test.js 399 tests, 1 red (not ok 396, "two Bots under one home … the Bot the invite named")
• knife — byHome.size === 1 loosened to "first candidate" → 1 red (not ok 397, "a home listing two Bots names no Bot")
• src/social.js restored and cmp-ed byte-equal; diff -rq of the 02a77af6 tree and this tip → exactly 4 files (+1 changelog), no deletions, base is current

What I checked

• The wrong-Bot path is closed: invitePeerBotId (social.js:2406-2430) returns the entry whose handle the invite named, before any home-based candidate; when the invite names a home and that home lists two active Bots it returns nothing, so no grant and no sharedBack — the two rules that decide "which Bot of that person's" are each pinned by their own case and each own by its own knife.
• Wrong home cannot leak in: only entries whose handle or homeOfPeer(handle) is the inviter's home are candidates, and non-active entries are skipped, so "another friend's Bot" and "a pending friendship" cannot lend an id (two more of the six cases).
• No friend_home left on this path: the grant is now always { botId, friendBotId } (social.js:2451), and the code comment no longer claims the MCP tool "only sends two ids" — it says what I verified earlier: the MCP args carry friend_home, the REST fallback in mcp-client.js:466-478 drops it. The decisive reason is the one in the issue: a home cannot name which of a friend's Bots was invited.
• No regression around it: #1000 / #1023 / #1026 behaviour untouched (all their cases are in the 449 green), and docs/subsystems/social.md #496 still gains exactly one sentence.
• CI on this tip: 13 checks, all completed, 12 green; the only failure is enqueue-guard = "no Verdict names this tip", true until this comment. One agent-audience instance is cancelled beside a success twin — the concurrent-cancel shape this group has already ruled on.
• On the tip my earlier PASS named: the sibling-Bot case I filed as non-blocking was real and silent — a friend running two Bots under one home is the normal shape (#973), so it did not need any unusual data to hit, and a grant to a Bot that was never invited is a wrong share, not a slow accept. Dequeuing that tip and forcing d43387dd was the right call; that PASS does not carry here and this one stands on its own evidence.

Non-blocking (no action for this PR)

• One corner of the new ordering: if the invite names a member handle whose own list_friends entry is present but not active, the status filter skips it, and if exactly one sibling of that home is active that sibling is still returned as the only candidate. Suggest "an exact handle that is listed but not active means no grant" (same spirit as the ambiguity rule). It needs an invite whose Bot's friendship is not yet active while a sibling's is, so I did not hold the tip.
• The PR still carries the pass label from the superseded tip; harmless (the gate reads the reports), and it goes away with this tip.

[Birfy]

Verdict: PASS at dc6d8d1
Written-by: Reviewer2

Ran (this tip, on base 73d2fae7; my own trees):

• cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js" → 450/450, 0 skipped (the extra one over my last run is #1025's case, now in main from #1036)
• pristine 73d2fae7 + only this tip's test/social.test.js → 450 tests, 444 pass / 6 fail — not ok 443–448, exactly the six #1024 cases, no collateral
• knife — if (exact && handle === exact) return id disabled → social.test.js 400 tests, 1 red (not ok 397, "two Bots under one home … the Bot the invite named")
• knife — byHome.size === 1 loosened to "first candidate" → 1 red (not ok 398, "a home listing two Bots names no Bot")
• src/social.js restored and cmp-ed byte-equal; diff -rq of the 73d2fae7 tree and this tip → exactly 4 files (+1 changelog), no deletions

What I checked

• Same content I cleared last round, re-run on the new base: plugins/social/src/social.js, social.md and the changelog are byte-identical to d43387dd; the only change in the test file is main's own #1025 case arriving under it. Nothing of #1040's reading door or of #1036's sequence test is lost — both are inside the 450 green.
• The two rules that decide "which Bot of that person's" are each load-bearing: the exact handle the invite named wins over any home candidate (knife 1 drops only its case), and a home listing two active Bots yields no grant and no sharedBack (knife 2 drops only that one). Both are in invitePeerBotId (social.js:2406-2430).
• No friend_home left on this path: the grant is always { botId, friendBotId } (social.js:2451); the code comment now says what is true — the MCP args carry friend_home, the REST fallback in mcp-client.js:466-478 drops it — and the reason given is the issue's own: a home cannot name which of a friend's Bots was invited.
• Wrong friend or a pending row cannot lend an id: candidates are filtered to active and matched by exact handle or homeOfPeer, so "another friend's Bot" and "a pending friendship" cases stay green (444/450 pristine tells me nothing else moved).
• CI on this tip: 14 checks, all completed; 13 green. The only failure is enqueue-guard = "no Verdict names this tip", true until this comment. agent-audience has three instances (two success, one cancelled) — the concurrent re-run shape this group already ruled on.
• Queue note: I enqueued d43387dd a minute before this head landed; GitHub removed that entry when the head moved (removed_from_merge_queue by github-merge-queue[bot], nothing merged). The two earlier tips are void by base, not by content.

Non-blocking (no action for this PR)

• One corner of the ordering: if the invite names a member handle whose own list_friends entry is present but not active, the status filter skips it, and if exactly one sibling of that home is active that sibling is returned as the only candidate. "An exact handle that is listed but not active means no grant" would close it; it needs an invite whose Bot's friendship is not yet active while a sibling's is.
• The PR still carries the pass label from a superseded tip; harmless (the gate reads reports).