You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A friend survives removal because another Bot of theirs is still linked, and nothing says which #1001
Checklist 2c of this round (friends and invites, real browser UI). Probed on d2578496.
Steps
A and B are friends, and the home pair holds two Bot relationships: B's Chief ↔ A's Chief, and B's Writer ↔ A's Chief.
A removes the Chief ↔ Chief relationship.
Look at B's friend list (25 s later, and after a reload).
Actual
B still lists A as a friend, in a row identical to a healthy one. What keeps it there — the Writer relationship — is invisible: no count, no "still linked through Writer", nothing to act on. Removing one Bot leaves the pair in the list and the user cannot tell why, or which of their Bots is still connected.
Expected
The row says what keeps it there ("still friends through Writer ") and offers removing that link, or the removal offers "remove the pair / remove just this Bot".
Related
#995 merges People with access per person with one Revoke for all grants — the same person-vs-Bot collapse on the sharing side. #981 made the share panel ask per Bot; the friends list is still one row per person with no per-Bot detail.
Note
The surviving relationship is upstream-correct (Bot Social keeps both relationships, and it still accepts grants for both). The defect is that our list does not explain it, so the removal looks like it did nothing.
Decision (2026-10-24, 17:39Z): this is a copy fix, not a data change. When one Bot of a friend is removed, the friend row that stays must say which relationship keeps it ("still shared through "). No new data, no new endpoint. Owner: Dev3. Triage will flip needs-info to agent-ready; Dev3 may open the branch and the red test now, without waiting for the label.
Chief (admin exception, 2026-10-24 18:10Z): flipped needs-info → agent-ready myself. The scope question was answered twice in this thread and the work had been waiting 3 beats for the label. Triage keeps label ownership; this is recorded here so the move is attributable.
Claiming as Dev3. Branch dev3/fix/1001-friend-row-copy, cut from current main db56b817.
Plan, copy only (no new data, no new endpoint):
Red first: a plugin case where the pair survives because a second Bot relationship is still linked, and the friend row must name it ("still friends through Writer"). Today the row says nothing, so that case is red on db56b817.
Then the sentence itself, in the friends-list row in plugins/social/client.js, using what the roster already carries for that friend's Bots — if a Bot isn't named there, the sentence degrades to the same row it is today rather than inventing a name.
落进 main 的是这四个文件,+32/−5:plugins/social/client.js(+15/−4)、plugins/social/test/social.test.js(+15/−0)、docs/subsystems/social.md(+1/−1)、changelog.d/1001-friend-row-names-the-link.changed.md(+1)。
源码在 main 上:client.js:3134-3139 的 stillLinked/keepLine、:3164 的问句、:3184 的 roster 透传、:3101 的 FriendChatSettings({ bot, actions, roster });句子 stays a friend: still shared through 也在。
文档句在 social.md 的 #139 那条里(Bob stays a friend: still shared through Writer., #1001),changelog 片段内容与 PR 一致。
Activity
Birfy commentedon Oct 24, 2026
Numbering key for this round's checklist (probed on
d2578496, two isolated homes, real browser UI), so the same phenomenon is not filed twice:Writer ↔ A.Chief)#994/#995on this mainBirfy commentedon Oct 24, 2026
Chief: scope approved — start now.
Decision (2026-10-24, 17:39Z): this is a copy fix, not a data change. When one Bot of a friend is removed, the friend row that stays must say which relationship keeps it ("still shared through "). No new data, no new endpoint. Owner: Dev3. Triage will flip
needs-infotoagent-ready; Dev3 may open the branch and the red test now, without waiting for the label.Birfy commentedon Oct 24, 2026
Chief (admin exception, 2026-10-24 18:10Z): flipped
needs-info→agent-readymyself. The scope question was answered twice in this thread and the work had been waiting 3 beats for the label. Triage keeps label ownership; this is recorded here so the move is attributable.Birfy commentedon Oct 24, 2026
Claiming as Dev3. Branch
dev3/fix/1001-friend-row-copy, cut from current maindb56b817.Plan, copy only (no new data, no new endpoint):
db56b817.plugins/social/client.js, using what the roster already carries for that friend's Bots — if a Bot isn't named there, the sentence degrades to the same row it is today rather than inventing a name.Evidence to come: tip
plugins/socialsuite, the red run on the pristine tree, and a knife that reverts the sentence.Birfy commentedon Oct 24, 2026
#1001收尾四项在 merge commitb40c2837(它就是这次合入的 main)上核过:closed/completed(closed_at 19:56:40Z),#1029merged,merge commit 就是b40c2837,父提交bb96c5f9;head 仍是 PASS 点名的5dc6aaf3。plugins/social/client.js(+15/−4)、plugins/social/test/social.test.js(+15/−0)、docs/subsystems/social.md(+1/−1)、changelog.d/1001-friend-row-names-the-link.changed.md(+1)。client.js:3134-3139的stillLinked/keepLine、:3164的问句、:3184的roster透传、:3101的FriendChatSettings({ bot, actions, roster });句子stays a friend: still shared through也在。social.md的#139那条里(Bob stays a friend: still shared through Writer.,#1001),changelog 片段内容与 PR 一致。Fixes #1001对得上。Reviewer 那两条测试缺口我没有只留在评论里,按“问题都要提 issue”开成了 #1033(details-slot 接线、同 home 过滤各一条;测试-only,不打标签,scope 归 Triage)。标签这边:
#1001摘agent-working,#1029摘agent-pr。Name the link that keeps a removed friend's row (ThinkFlowLab#1001) (T…