[Birfy]

Fixes #496

What

• social/join-invite: on Bot Social's 409 relationship_exists it now answers a result instead of throwing: { alreadyHave: true, status: 'active', bot, botName, ownerName, restored: [{ handle, name, owner }] }. Bot Social's 409 names no Bot, so the plugin reads the public invite info (GET /v1/invites/{code}, new inviteInfo in mcp-client.js, sent without a token) to name the invite's Bot and owner. restored lists only Bots that were locally hidden or declined before and are listed again after the (still Bot/peer-home scoped) unhide.
• Add friend panel: neutral (not red) You already have Chief (SelfA1233). (Bot first, owner in parentheses, Friend's Bot rows: two name formats ('Helper · SelfB0023's Bot' vs 'SelfA0023's Chief'), two-line wrap, no preview, inset highlight, faint marker, same avatar as own Chief #384); Chief (SelfA1233) is back in your list. only when something really came back. Fallback when the Bot can't be named (or an older host still throws): neutral You already have this friend's Bot., never "… failed:".
• Remove this Bot confirm is one line: Remove Chief (SelfB1233) from your list? Your own Bots stay shared. SelfB1233 can share it again.
• Out of scope (owner decision, option a): one-click Share with a friend (Share a Bot with an existing friend without an invite link #500).

Why: re-accepting an invite for a Bot you already have changed nothing and failed nothing, but showed red You're already friends. Their Bot is back in your list.; the Remove confirm did not say your own shares stay.

Test

• New: #496 join with a production-shaped 409 (MCP isError, code + message only) names Coder (Bob) from the invite info, restored: [], and the invite-info GET carries no authorization header; panel shows info/ok tones and the three texts; an older host's thrown relationship_exists shows the neutral sentence with no "failed:".
• Updated: #139 (hidden Bot re-accepted → alreadyHave + restored names it; unrelated hidden Eve stays hidden), #197, #230/#139 Remove confirm copy.
• ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify: pass (core lint + arch-docs, plugin lint + pack-import, build-client check, ds-bot patches check, core/social/tree/timeline suites, scripts, interop, live-e2e unit tests; 0 failures).
• Not run: live two-home browser test on Mac/self-test instances; smoke bench.

Docs: docs/subsystems/social.md updated; changelog fragment changelog.d/496-already-have-invite.fixed.md.

Risk tier: T2 (estimate; the controller sets the label) — user-facing social copy plus one new unauthenticated read of a public Bot Social route.

[Birfy]

Self-review: PASS
Tip SHA: 2286477
Ran:

• ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify at the tip (base a7adfe0): pass, 0 failures. This covers core lint + arch-docs, plugin lint + pack-import (social/tree/timeline), the build-client check, the ds-bot patches check, the core/social/tree/timeline suites, .github scripts, interop, and the live-e2e unit tests.
• npm test in plugins/social: 298/298 pass, including the new 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 tests: a production-shaped 409 names the Bot from the invite info, no token is sent, the info/ok/neutral-fallback tones work, and an older host's thrown error shows no "failed:".
• node .github/scripts/changelog.mjs check: 18 fragments well formed.
• CI at the tip: tests-ok, test, plugins (social/tree/timeline) and package are green. Risk tier T3 (report only, paths mcp-client.js and social.js).
• Diff re-read against the owner design rules. English UI copy per the owner decision (option a). There is no new grant or publish path. Approvals are unchanged. The only new network call is an unauthenticated GET of a public Bot Social route, so the connector token still goes only to /mcp and the allowed REST routes. Peer-supplied names go through cleanText. Unhide scope is unchanged. Share with a friend (Share a Bot with an existing friend without an invite link #500) is not included.
  Not run:
• A live two-home browser run on the self-test or Mac instances (the user's instances must not be restarted), and the smoke bench.
• A live check of the reply-only hunch. It was checked by reading Bot Social master code only (see 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 comment).

[Birfy]

Self-review: PASS
Tip SHA: 5836d29
Ran:

• Merged origin/main (303c0d6, includes Fit chat approvals and the Agent inbox to a phone-width screen #481/Keep live shares in People with access using Bot Social's reply_only #501/Show a friend's first line and its approval card live: read friends' inboxes fast while a window is on screen #505) into fix/496-already-friends-copy; resolved docs/subsystems/social.md keeping 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 reply_only People-with-access wording from main with 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 already-have / Remove confirm copy (2026-10-20 15:00 Asia/Shanghai).
• ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify: passed (core lint + arch-docs OK, plugin lint OK, build-client --check OK, ds-bot-patches check OK; core/social/tree/timeline/scripts/interop/live-e2e all green).
• node .github/scripts/changelog.mjs check: fragments well formed.
  Not run:
• Live Mac instances or the production Bot Social server (not touched).
• Browser smoke on two live homes.