[Birfy]

Owner: Dev3
Reviewer: Reviewer
Written-by: Dev3

Fixes #995

Tip SHA: eb3cf48

Reproduce

main da17eb5f, real browser (SelfTest): A shared Chief with B's two Bots, so Share with a friend showed two rows (#973) while People with access showed one (SelfTest B2 (@selftestb2.home) + Auto-send + Revoke). One click on that Revoke left list_bot_grants with 0 person grants: both Bots lost access. accessRows keyed rows by the person's home and pushed every grant into grantIds; social/revoke-grant deletes that batch. That was #383's shape, right when a person could hold only one Bot-level grant.

What changed

• plugins/social/src/social.js, accessRows: a grant that names a Bot (view.member differs from the person's home) is its own row, keyed bot:<handle>, with grantIds holding that grant alone, so its Revoke takes one Bot. A grant that names no Bot keeps the per-person row, and People with access lists each person once; a talk-through grant on an already-shared Bot is not a share #387's unsure talk-through grant keeps its own row untouched.
• The row is labelled Bot (Owner) like the share list (One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973). The host's grants.set keeps only id/grantee/name/relationshipId/roomId (core/src/host/reach.js:355), so the Bot's own name cannot ride on the grant: normalizeGrant keeps botName/ownerName from the grantee Bot Social sends, and the grant sync stashes them per handle for the panel. With no name from the server the label degrades to Owner (@bot.home), never to two identical person rows.
• plugins/social/client.js: the row shows the Bot's handle instead of the same shared home twice, and Auto-send stays one switch per person (on the first of their rows), because it is one pair setting.
• docs/subsystems/social.md (access rows, auto-send) and changelog.d/995-access-one-row-per-bot.fixed.md. No core/ and no patches/ds-bot/ change.

What I ran

• cd plugins/social && node --import ./test/resolve.mjs --test test/*.test.js → 433/433, 0 fail, 0 skipped on this base (430 + 3 new; four People with access lists the same friend twice when my already-shared Bot joins that friend's invite (talk-through grant shown as a share) #383/People with access hides live shares once two friends have joined each other's invite: owner can't see or Revoke them (side effect of #383 fix) #495/object-shape tests updated to the per-Bot shape).
• node scripts/ds-bot-patches.mjs check → 10 patches apply in order, core/ equals ds-bot/ + patches.

Red without the source change

• Pristine d24c47c8 + this test file, --test-name-pattern='#995' → 4 fail / 0 pass (the #383 + #995 batch row, the two-Bot row, the single-Bot/person-level row, the panel). The updated #495 reply_only, object-shaped grantee and Manage access loader tests also fail there (3 red).
• Knives, each restored and cmp'd: key rows by person again → 3 red; normalizeGrant without botName → 3 red; Auto-send drawn on every row → panel test red; no Bot handle on the row → panel test red.

Not run

• npm run lint / oxlint: no node_modules in this sandbox (ERR_MODULE_NOT_FOUND), so the linter was not run locally; CI runs it.
• No smoke test: plugins/social only, no core/ or index.js change.

Risk

UI/social only, no core/, no DS-bot patch, no new endpoint. A friend who holds a person-level grant and a per-Bot grant now shows two rows instead of one merged row — the person-level grant names no Bot, so it cannot be folded into one, the same rule #981 uses for the share list.

[Birfy]

Verdict: PASS at eb3cf48
Written-by: Reviewer

tip 上除 enqueue-guard 外全绿（tests-ok、Node 24、plugins (social) 都 success），证据我自己重跑了一遍。

Ran on the tip tree（pristine 那组是把三个源文件换回 base d24c47c8 的版本，测试文件留 tip）:

$ cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js"
1..433 / # tests 433 / # pass 433 / # fail 0 / # skipped 0
$ node --import ./test/resolve.mjs --test --test-name-pattern='#995' "test/*.test.js"   # sources = d24c47c8
not ok 5 - #383 + #995: People with access is one row per Bot; a row keeps the batch Revoke for its own grants
not ok 6 - #995: People with access is one row per Bot, and Revoke takes only that row
not ok 7 - #995: a single-Bot friend is still one row and one Revoke, and a person-level grant keeps its row
not ok 8 - #995: the access panel draws one Revoke per Bot, one Auto-send per person, and the Bot handle
# tests 9 / # pass 5 / # fail 4
$ node scripts/ds-bot-patches.mjs check
skipped pin (no git): the tree hash cannot be computed here
ok   10 patches apply cleanly in order
ok   core/ equals ds-bot/ + patches/ds-bot/

三把刀各自还原后 cmp 过：accessRows 的 perBot 改回 false → 6 红（两条新 #995、#383 + #995 的批量行、#495 reply_only、object-shaped grantee、access loader）；syncOutgoingGrants 里 botNames.set 关掉 → 3 红（两条新 #995 + object-shaped grantee）；client 的 showAuto 去掉按人去重 → 1 红（panel 那条，断言 Auto-send 一人一个）。

代码我看过的点都对：grantPersonView 的 home 恒由同一 handle 推出（personHomeOf），所以 perBot = member !== home 不会把 person 级 grant 误判成 Bot 行；grantIds 仍然只有一个 id，social/revoke-grant 按行撤；unsure 的 grant:<id> 优先于 bot:<member>，#387 那条 talk-through 还是自己一行；server 不给名字时落到 Owner (@bot.home)，两行仍靠 handle 分得开。

两条不影响结论的（下次碰这文件再改，不为它重开 tip）：

1. client.js 的 autoKey = grant.person || grant.home 用的是显示名：同一对（同 home）如果一行是 person 级 grant、另一行是 Bot 级 grant，两边的 person 可能是不同字符串（Bot 行那个 view.person 来自 server 给的 Bot 名），就会画出两个 Auto-send 开关——状态一样、写的是同一个 social/auto-send {botId, home}，只是重复。直接把键改成 grant.home（showAuto 本来就要求 grant.home）。
2. botNames 只增不清：撤销后再分享、server 又不给名字时，标签会沿用旧名。量级很小��只影响显示。

我随后入队。