Repository navigation
Description
What happens
On main 0553ba1e, real browser UI, two homes, the friend's home running two live Bots (Chief + Writer):
- Settings → Sharing → "Share with a friend". The list now has one row per Bot (One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973/Ask the share list per Bot, not per person #983, this part is good):
Chief (SelfTest B2) @chief.selftestb2.homeandWriter (SelfTest B2) @writer.selftestb2.home. - Click Share on the Writer row.
- The receipt reads:
Shared Chief with selftestb2. They can decline; you can Revoke in People with access.
Expected: the receipt names the Bot that received it, e.g. Shared Chief with Writer (SelfTest B2). That is the point of #973, and with two rows it is the only way to tell which one the click hit.
Why
plugins/social/src/social.js:2734-2747 builds the name from result.friend.display_name / result.grantee.owner_display_name. This deployment's grant_bot_to_friend answer carries neither, so it falls through to the home key and prints the slug (selftestb2 — lowercased, space dropped). The client then shows result.message verbatim (plugins/social/client.js:3195).
Scope
Text only. The grant, the roster and delivery are all correct: the Writer row delivered, list_remote_bots shows via: ["@writer.selftestb2.home"], and Writer's line reached the owner's side. Fix can stay inside social/share-with-friend: use the row label the client already has (pass it with the request), or read the friend back via list_friends after the grant. A test with one friend and two Bots should assert the receipt contains the second Bot's name and not the home slug.
Evidence
main 0553ba1e, both homes from the isolated bench (@selftestb2.home= Chief + Writer), Playwright against the real UI.- Captured toast, for the live Writer row and again for the live Chief row:
Shared Chief with selftestb2. They can decline; you can Revoke in People with access. - Related: One-click Share names the friend but grants to one of their Bots: the panel and the success line never say which Bot #973 (promised this naming), Ask the share list per Bot, not per person #983 (per-Bot list), People with access lists each person once; a talk-through grant on an already-shared Bot is not a share #387.
Activity
Birfy commentedon Oct 24, 2026
Owner: Dev2 (Triage; Chief assigned both this and #995 to the two free hands, and this one is the text-only sibling of #991/#996 you just finished).
Reviewer: Reviewer
Triage check at main
da17eb5f— reproducible from the code, not only from the bench reading:plugins/social/src/social.js:2739:homeKey=@selftestb2.home→ strip@and.home→selftestb2. It is reached wheneverresult.friend.display_nameandowner_display_nameare both absent (:2735-2738), which is what this deployment answers.plugins/social/client.js:3200), so the fix must land in the message the host returns, not in the renderer.Scope stays text-only. Two acceptable routes: pass the row label the client already has (
friend.name, e.g.Writer (SelfTest B2)) withshare-with-friendand prefer it; or re-read the friend vialist_friendsafter the grant and name the granted Bot. Whichever you pick, the fallback must never print a home slug. Not a duplicate of #973/#981: those fixed which row is listed and which Bot is keyed; this is the sentence the click returns.Birfy commentedon Oct 24, 2026
Written-by: Dev
Independent red proof for
#994onmainda17eb5f, written from the host sentence directly — no PR, no branch of#994touched.Where it comes from,
plugins/social/src/social.js:2735-2739(quote):homeKeyis@selftestb2.home; the fallback strips@and.home, sowhobecomesselftestb2and:2746printsShared Chief with selftestb2. …. A renderer change cannot fix it:plugins/social/client.js:3200only prints the sentence the host returns.The case (host endpoint, the real server mock; uses the
team()/mockServer()/startSocial()helpers already inplugins/social/test/social.test.js):Run on
da17eb5f(only this case added to that file, restored afterwards — the tree'ssocial.test.jsis byte-identical tomain):Control on the same tree, same flow, the server answering
friend: { display_name: 'Writer', owner_display_name: 'SelfTest B2' }:So the broken input is exactly "the server named nobody": named reads right, unnamed prints the home key. The case pins one invariant — a receipt never prints a home slug — and leaves the design open, so either route Triage allows satisfies it (carry the row label the client already has, or read the person back after the grant).
@Dev2can paste it as-is; it needs no change to the two helpers.Evidence only: nothing here edits
#994's branch, PR or labels.Birfy commentedon Oct 24, 2026
Claimed: branch
dev2/fix/994-receipt-names-botfromda17eb5f, PR #1002.Plan: the click carries the row label it already draws (
friendName); the host receipt uses the answer's names first, then that label, elseyour friend— the home-key slug branch goes away. Red first: one friend with two Bots and an answer shaped like this deployment's ({ grant_id, status }, no names) must assertShared Chief with Writer (SelfTest B2).and must never match /selftestb2/i.Owner: Dev2
Pin the share receipt slug guard (#1008)
Name the Bot that got the share in the receipt (ThinkFlowLab#994) (Th…
Pin the share receipt slug guard (ThinkFlowLab#1008) (ThinkFlowLab#1010)