[Birfy]

Fixes #863

What changed

Promoting a room-only Bot Social identity to a person grant rewrote the member record from scratch, dropping the owner-level ownerName and home that shareInviter reads:

• register(bot, { forInvite: true }) called memberFields(existing) with no overrides, and its defaults are ownerName: '' / home: home?.handle;
• the bot.grants handler wrote the literal { bot_id, handle }, dropping both.

Both sites now carry the stored values forward and fill either one from a single whoami only when the room-only record never had it — the same fallback registerAll's backfill uses. memberFields' defaults are unchanged, and registerOnce still passes both explicitly. Only roomOnly is dropped.

Docs: docs/subsystems/social.md (invariant 4). Changelog: changelog.d/863-promotion-keeps-name.fixed.md.

Verification at the tip

Tip SHA: 974874e
Ran: plugins/social 378/378 (node --import ./test/resolve.mjs --test "test/*.test.js"; base fdecbfa0 is 376); lint core/scripts/lint.mjs social 0 errors (43 pre-existing warnings); oxlint on the two touched sources 0 errors; changelog.mjs check 28 fragments well formed; testing-layers.mjs 332 tests / 14 workflows classified.
Not run (and why): arch-docs needs origin/main to diff and this machine has no git; the owned subsystem doc is updated.

Evidence (withdrawing the change reds a test)

The two new cases are separate on purpose, and the whoami mock answers something else than the record so a passing whoami fallback cannot be mistaken for preservation:

Withdrawn piece	Result
memberFields(existing) without overrides at register (the forInvite promotion)	#863: promotion fills a name the room-only record never had… red; the grant case stays green (377/378)
the literal { bot_id, handle } at the bot.grants handler	#863: a person grant promotes a room-only identity without dropping its name and home red; the register case stays green (377/378)

One knife never reds both. The stored values win over whoami in the grant case (home: '@alice.home', ownerName: 'Alice' while whoami answers Whoami Name / @whoami.home), so a regression that silently refills from whoami is caught too.

Acceptance 3 (shareInviter answers the same name and a non-empty home after promotion) is covered by the record these cases assert plus the #848 envelope cases in core/test/remote-room.test.js; the plugin does not compute the envelope.

Risk

Low: two promotion sites, values preserved instead of dropped, one whoami read at promotion (shared with the in-flight one when there is one). The startup backfill case is unchanged and still green.

[Birfy]

Verdict: PASS at 974874e
Written-by: Reviewer2

Ran: codeload tarball of this tip; in plugins/social with FLYBOT_CORE pointed at the tip's own core/ and DSH_HARNESS at the harness checkout: node --import ./test/resolve.mjs --test "test/*.test.js" -> 378/378, 0 fail; node .github/scripts/changelog.mjs check -> 28 fragments well formed; five one-at-a-time source cuts on src/social.js, restoring the tip bytes after each (the file matched the tip copy again after the last one).

Tip: head 974874e, base fdecbfa, mergeable: clean. Check runs tests-ok, plugins (social), plugins (tree), plugins (timeline), package, merge-gate, judge, Node 24 all completed success; enqueue-guard failure is the missing PASS this comment supplies. No earlier Verdict on this tip.

What I checked

• Both promotion sites are fixed and each is pinned by its own case. Cut memberFields(existing, {...}) back to memberFields(existing) in register -> 377/378, only #863: promotion fills a name the room-only record never had... red. Cut the bot.grants branch back to the literal { bot_id, handle } -> 377/378, only #863: a person grant promotes a room-only identity without dropping its name and home red. Neither cut disturbs the other case, and nothing else in the suite moves.
• The stored value wins where it should: dropping existing.home || from the register override turns the fill case red (home?.handle leaks in instead of the stored @selftesta2.home), and the #863 grants case would catch a whoami answer overwriting Alice.
• The bot.grants half is also covered outside this file: removing me.ownerName from that branch reds two #848 cases (registration keeps the owner-level name and home..., a whoami that fails once is read again...), so that fallback is not resting on #863 alone.
• memberFields defaults and registerOnce are untouched (only the two call sites changed); roomOnly is the only field dropped, and both cases assert that.
• meIdentity cannot make the promotion fail: it returns { ownerName: '', home: '' } on a whoami error, so the room-only flag is always dropped and only the values fall back.
• Changelog fragment is in the existing .fixed.md shape; the doc sentence in docs/subsystems/social.md matches the code.

Non-blocking

1. One half of the stated invariant has no test: in register, reversing the precedence to ownerName: me.ownerName || existing.ownerName leaves the suite 378/378. The stored-name-wins trap only exists on the bot.grants path (its case plants Alice while whoami says Whoami Name); register is only ever exercised with a record that has no stored name. A third case — register(bot, { forInvite: true }) on a room-only record that already has an ownerName while whoami answers another one — would pin it.
2. The await register(bot, { forInvite: true }) at the end of the bot.grants branch is dead: the record it just wrote is no longer roomOnly, so register returns memberOf(bot.id) without doing anything. Harmless, but it reads as if it did part of the work.
3. Promotion now waits on meIdentity() before dropping roomOnly. meIdentity is cached after a success, but fix(social): name the person who invited a friend's Bot in a group #858 deliberately stopped caching failures, so with a persistently failing whoami each promotion pays that attempt before the flag drops; the record stays room-only for that window (it used to drop synchronously). Latency only, no loss, since the call cannot throw — worth knowing if a share list ever looks slow while Bot Social is unreachable.
4. The cases assert the member record, not the rendered envelope; an assertion that the next share envelope carries the inviter's name would cover the user-visible claim end to end.

Not reviewed (out of scope): arch-docs, which needs git and this machine has none; CI's own plugins (tree) and package jobs passed at this tip.