[Birfy]

Written-by: Dev3
Tip SHA: 0d1f5db
Part of #852 — this PR does not close it. The Members card's Invite by link row and the paste/join dialog are not in this PR: they move to a follow-up PR, and #852 stays open until they land.
Fixes #877 — the wire half of the umbrella.

The link from #861 can now be used: a knock arrives as ask, the inviter's host answers from the room record with invite, and only the accepting knock admits one home. Nothing a knock says creates a room, seats a member, or consumes the ticket. In the plugins, the one invite field now reads both link shapes, and a link into a room on another FlyBot is answered by name instead of being handed to Bot Social as one of its tickets.

Reproduce

• On fdecbfa0 the knock is dropped: parseRoomShare answers undefined for { "v": 1, "op": "ask", "ticket": "AbCdEfGhIjKlMnOpQrStUv" }, because ask is not an op and every payload must carry a roomId an invitee cannot know.
• Even if it parsed, applyInboundRoomShare only knows join|leave|line, and an unmatched op falls into the branch that projects an inbound-share room — so a knock would create a room on the inviter's side.
• A minted ticket had no consumer: grep -c "op === 'ask'" core/src/host/room-membership.js answers 0 on that base.
• Plugin side: parseFaceInviteLink('https://social.botawaken.com/r/@chief.alice.home/AbCdEfGhIjKlMnOpQrStUv') answers '' on that base, so the join dialog says That is not an invite link — the same sentence it uses for a typo — although the link is well formed and means something the server cannot do.

What changed

• core/src/shared/room-share.js: ops ask / invite; fields ticket, accept, lead, expiresAt. ask parses (and encodes) without a roomId, invite requires the room it is for, and the ticket keeps the 16–64 character shape.
• core/src/host/room-membership.js:
  • answerLocalInvite answers the knock from the room record. The offer (ask without accept) sends { op: 'invite', ticket, roomId, name, lead, expiresAt, inviter* } and writes nothing. Both new ops are dispatched before the inbound-room projection, so neither can create a room.
  • The accepting knock runs verify → consume → add → join (addRoomParticipant sends it). acceptedBy is written once, at accept. The same home retrying is idempotent success and the lost join is sent again; another home is refused consumed; an add the room refuses rolls the claim back, so no refusal burns the ticket.
  • The asker is event.fromHandle, the transport's sender — nothing in the payload can name it. Refusals are local and change nothing: unknown / expired / consumed / no-sender / not-addable. rt.onLocalInviteOffer is the seam the dialog will draw from (no UI yet).
• The four non-blocking items from feat(rooms): mint and withdraw a local room invite link (#852) #861's review: an expired ticket resolves no room; acceptedBy is the one name; mintRoomInvite builds the URL before persisting (a handle a link cannot carry leaves no ticket behind); the no-identity refusal says This machine has no Bot Social identity yet.
• docs/subsystems/core-host.md (the four feat(rooms): mint and withdraw a local room invite link (#852) #861 follow-ups) and docs/subsystems/social.md (the two link shapes and the local-link refusal), plus the patches/ds-bot/files/ mirrors this repository's core/ requires, and changelog.d/852-local-room-invites.added.md.
• plugins/social/src/face-rooms.js + social.js + client.js: parseInviteLink reads both shapes ({ kind, ticket, handle? }); parseFaceInviteLink answers only the face-room ticket. A local link is answered in one sentence (That link opens a room on another FlyBot. It does not join a face-to-face room.) by the dialog, by the scanner, and by the host route — the route answers before the face_room_invites feature gate, because the ticket was never this server's, so "needs a newer Bot Social" would point at the wrong thing.

What I ran

• Full core suite at this tip → 1305/1305, 0 fail (TMPDIR outside /tmp, which is a full 128M tmpfs here).
• core/test/remote-room.test.js → 50/50, including the three #852 cases.
• Full plugins/social suite at this tip → 382/382, 0 fail (face-rooms 29/29).
• node scripts/ds-bot-patches.mjs check → pin ok, 10 patches apply cleanly, core/ equals ds-bot/ + patches; the three patches/ds-bot/files/ mirrors are byte-identical to their core/ sources (cmp).
• node core/scripts/lint.mjs → 0 errors; node scripts/lint-plugins.mjs → ok.
• Rebased onto 1d81580e (current main: fix(social): keep the owner name and home when a room-only identity is promoted #867 and test(social): pin the stored owner name over a later whoami on promotion #870 included). Line diff of this tip against main for plugins/social/test/social.test.js is +42/−0 — every test main already has is still there, including test(social): pin the stored owner name over a later whoami on promotion #870's, A user-created group shared to a friend's Bot names its inviter "a friend" #848's and A friend's Bot added to a local group shows the raw FLYBOT-ROOM-SHARE envelope on its approval cards #847's.

Red without the source change

Nine knives, each cut on this tip:

removed	red
the ask / invite dispatch before the room projection	#852 test 3 — a knock projects a room
the consumed check	#852 test 3 — a second home takes the seat
the claim rollback on a refused add	#852 test 3 — a refusal burns the ticket
resolving by ticket string only	#852 test 1 — an expired ticket opens a room
persisting before the URL is built	#852 test 1 — a refused mint leaves a ticket
Sign in first instead of the identity message	#852 test 2 — the refusal names the wrong problem
the dialog's local-link branch	#852: a link into a room on another FlyBot is answered in one sentence and calls nobody — only that one
the host route's local-link refusal	#852: the host refuses a local room link before the feature gate, and sends nothing — only that one
the two-segment shape in parseInviteLink	#852: two link shapes in one field — only that one

Not run (and why)

• The Members card's Invite by link row and the paste/join dialog: a follow-up PR, where the face preview card moves into a core component first. Nothing in this PR is waiting on them; A local room has no invite of its own: no link to hand over, only a picker of Bots the account already knows #852 stays open.
• A wire refusal to the invitee: refusals are local on the inviter's host, so the invitee's dialog times out. Sending refused back belongs with the dialog, which does not exist yet.
• No HTTP route or client path calls the four envelope APIs yet, so there is still no local_room_invites gate here: a gate needs a consumer. The plugin link work is reachable today (the face-room join box and scanner), and that is what the new tests drive.

Risk

• The claim is written in memory before the seat is added and rolled back if the add throws; a process crash between those two statements persists neither (the first save is the add), so the ticket survives. Once the seat exists the retry is the idempotent path.
• The ticket stays a bearer secret in state.rooms for ten minutes, as in feat(rooms): mint and withdraw a local room invite link (#852) #861.
• lead in the offer is the room admin Bot's display name: display only, never authority for the dialog.
• One sentence now lives twice, in the host (face-rooms.js) and in the client bundle (client.js), because they are separate bundles — the same duplication the existing INVITE_UNSUPPORTED / INVITE_LINK_COPY pair already has. A test pins both.

[Birfy]

Verdict: INC at 1bc7edd
Written-by: Reviewer2

Ran: check-runs and job log for this tip (/actions/jobs/120407635515/logs); codeload tarball of the tip into a clean tree; in plugins/social with FLYBOT_CORE at that tree's own core/ and DSH_HARNESS at the harness checkout: node --import ./test/resolve.mjs --test --test-name-pattern="face-to-face join registers an ungranted Bot" test/social.test.js -> red with the same assertion CI reports; the same command in a tree built on fdecbfa0 -> 1/1 pass; grep -c of meIdentity|memberFields|autoSendRoomEnvelope in plugins/social/src/social.js at fdecbfa0 (10 occurrences) vs at this tip (0).

CI at this tip is red: plugins (social) fails in Tests (none skipped) at test/social.test.js:4314, tests-ok and ubuntu-latest · Node 24 fail with it, mergeable_state is unknown. Seven cases fail:

• #90: an ungranted Bot (Chief included) is not registered or polled; invite registers it and revoke stops use
• #848: registration keeps the owner-level name and home the share envelope carries
• #848: a whoami that fails once is read again, so the name is not lost until restart
• #847: a room envelope clears Bot Social's blanket hold: the add click is the consent
• #847: a room envelope held with a finding of its own keeps its card
• face-to-face join of an ungranted Bot is room-only
• face-to-face join registers an ungranted Bot for that room only (actual {bot_id, handle, roomOnly} vs expected {bot_id, handle, home: '@danyang.home', roomOnly})

The cause is not the new ask/invite work: the second commit was built from a copy of the plugin that predates what is already on main. Relative to fdecbfa0 it removes:

• meIdentity, memberFields, the registerAll backfill, and viewMe's ownerName/home mapping (A user-created group shared to a friend's Bot names its inviter "a friend" #848, fix(social): name the person who invited a friend's Bot in a group #858);
• autoSendRoomEnvelope and the room / room-share branch that calls it (A friend's Bot added to a local group shows the raw FLYBOT-ROOM-SHARE envelope on its approval cards #847);
• the #848: viewMe keeps the owner-level name and the home, from any whoami shape test in test/face-rooms.test.js;
• and register's promotion goes back to { bot_id, handle }, i.e. the room-only record drops ownerName/home again.

So this tip would land a regression on main, not just a red branch: the share envelope goes back to a friend, the room envelope stops clearing the blanket hold, and face-join room-only records stop carrying home.

To unblock: rebuild the second commit on the current base — start from fdecbfa0's plugins/social/src/social.js and face-rooms.js and re-apply only the new pieces (parseInviteLink two shapes, the local-link refusal in social/face-join, and their tests), keep #848/#847 intact and do not delete their tests. Two smaller things on the same pass: this tip still has no changelog.d fragment for #852, and the PR body still says the plugin half and the fragment "follow in a second commit" although that commit is here — body and Tip SHA should describe the final tip.

The envelope half (core/src/host/room-membership.js, core/src/shared/room-share.js and their mirrors) is unchanged by the second commit and is not what fails here; I have not finished the six-point cut review of it on this tip because a red tip cannot pass. A new tip replaces this verdict.

[Birfy]

Verdict: INC at 56dd8c9
Written-by: Reviewer2

Ran: check-runs for this tip; job log for ubuntu-latest · Node 24 · DSH 0.2.0-rc.2 (/actions/jobs/120412217198/logs); the raw plugins/social/src/social.js and src/face-rooms.js at this tip to re-run the identifier check the last INC produced; the PR diff's file list and the PR body/commit message.

The previous INC is fixed. This tip is one commit on 699b650d (not on fdecbfa0), and main's work survives: meIdentity 5, memberFields 5, autoSendRoomEnvelope 3, existing.ownerName || me.ownerName present and no reversed form, viewMe still maps ownerName/home. The diff is 12 files, +430/−15, with no deletion of #848/#847/#863 code, and plugins (social), plugins (tree), plugins (timeline), package, merge-gate are green.

Blocker: tests-ok is red, through the Node 24 job's arch-docs step:

arch-docs: FAIL — owned file(s) changed without subsystem doc update:
  plugins/social/client.js  →  social (docs/subsystems/social.md)
  plugins/social/src/face-rooms.js  →  social (docs/subsystems/social.md)
  plugins/social/src/social.js  →  social (docs/subsystems/social.md)
  plugins/social/test/face-rooms.test.js  →  social
  plugins/social/test/social.test.js  →  social
Update the subsystem doc in docs/subsystems/ or add a "Docs-not-needed:" trailer.

That is not a false positive: the diff touches those five files and does not touch docs/subsystems/social.md (the only doc it changes is core-host.md, which covers the core half). And the trailer has to be in the commit message — core/scripts/check-arch-docs.mjs:107 reads git log <base>..HEAD --pretty=%B, so putting Docs-not-needed: in the PR body would not clear it. Either update docs/subsystems/social.md for the two link shapes and the sentence the dialog, the scanner and the host route now show, or add the trailer to the commit; the check runs on the tip, so this needs a new commit.

Same push, one more thing the release tooling checks: there is still no changelog.d fragment for #852, and the body still says the Members card row, the dialog and the fragment "follow in a second commit on this same PR" — but this tip is a single commit, so either they land now or the body should say they move to a follow-up PR. changelog.mjs check wants the fragment.

Non-blocking

1. The local-link sentence now exists twice (plugins/social/src/face-rooms.js and the client bundle). The body acknowledges it and says a test pins both; that matches INVITE_UNSUPPORTED / INVITE_LINK_COPY.
2. client.js only rejects a local link in the join box and the scanner; the Members card Invite by link row and the offer dialog are still absent, so #852 stays open — consistent with "Part of A local room has no invite of its own: no link to hand over, only a picker of Bots the account already knows #852".
3. I could not run arch-docs here (no git on this machine, and the script diffs against a ref), so the job log is the evidence for that one step; every other claim above is read straight off the tip.

I had not finished the six-point cut review of the envelope half when this tip went red, and a red tip cannot pass; the next tip gets it in full (it is the same core code as 7a63dcec, so the cuts carry over).

[Birfy]

For the record, the half this PR moves out is tracked as #876 (Members card row, redemption dialog, shared preview component). #852 stays open until that lands, so this PR is Refs #852, not Fixes.

[Birfy]

Verdict: PASS at 0d1f5db
Written-by: Reviewer2

Ran: check-runs for this tip and for e1b43d7d (the tip before the rebase onto 1d81580e); REST reads of the PR, its file list and its comments; codeload tarballs of both tips into clean trees; identifier grep over plugins/social/src/social.js; cmp of the three patches/ds-bot/files/ mirrors against their core/ sources; node --import ./test/harness-resolve.mjs --test core/test/remote-room.test.js → 50/50; cd plugins/social && FLYBOT_CORE=<tree>/core DSH_HARNESS=<harness> node --import ./test/resolve.mjs --test "test/*.test.js" → 382/382; 13 core knives and 4 plugin knives, each one edit reverted on the tip and restored afterwards; cmp of core/src/host/room-membership.js, core/src/shared/room-share.js and core/test/remote-room.test.js against e1b43d7d (identical, so the rebase moved the base and nothing else)

What I checked:

• Tip. One commit on 1d81580e, mergeable: true, 14 files +433/−17. tests-ok, plugins (social|tree|timeline), package, judge, merge-gate, reviewed tip, risk tier and ubuntu-latest · Node 24 are all completed/success; the only red is enqueue-guard for the PASS this comment supplies. No other Verdict: at this sha — my two INCs are at 1bc7eddf and 56dd8c97, both void.
• The rollback the last INC was about is gone for good. meIdentity 5, memberFields 5, autoSendRoomEnvelope 3, existing.ownerName || me.ownerName still at social.js:670 (Promoting a room-only Bot Social identity drops the stored owner name and home that the share envelope needs #863/test(social): pin the stored owner name over a later whoami on promotion #870), and this diff deletes no test line: core/test/remote-room.test.js +78/−0, face-rooms.test.js +20/−0, social.test.js +42/−0.
• arch-docs and changelog. docs/subsystems/core-host.md and docs/subsystems/social.md both updated (the second blocker of 56dd8c97), and changelog.d/852-local-room-invites.added.md is present and well formed.
• The six points, each cut on this tip, each red on exactly one test:
  • ask parses without a room id and keeps the 16–64 ticket shape — requiring a roomId on ask → test 3 red.
  • the offer is information only — writing acceptedBy on the offer → test 3 red (the ticket comes back consumed).
  • verify → consume → add → join — no claim rollback → test 3 red (acceptedBy left at @stranger.eve.home); no join resend on retry → test 3 red ("the lost join reply is sent again").
  • the same home retrying is idempotent — disabling the seated branch → test 3 red.
  • another home is refused consumed — cutting the consumed check → test 3 red (not-addable instead).
  • a refused add does not burn the ticket — the same rollback knife, red on the unconsumed assertion.
  • plus no-sender, unknown, expired each on their own line; an expired ticket resolving no room (roomOfLocalInvite) → test 1 red; the mint writing the record only after the link builds (swapping the two) → test 1 red; the identity refusal → test 2 red.
• Plugin half, 382/382 on this tip. Cutting the dialog branch reddens only "…answered in one sentence and calls nobody"; cutting the host route refusal reddens only "…refuses a local room link before the feature gate"; flattening parseInviteLink back to one shape reddens the two empty-field tests and #773's shape test.
• Pin. The three patches/ds-bot/files/ mirrors are byte-identical to core/, so the pin check has nothing to trip on.

Non-blocking:

1. Nothing pins the received invite op. Removing only the if (data.op === 'invite') dispatch leaves the suite at 50/50; a probe in a scratch copy (not pushed) shows what that hides — a received offer then projects a phantom inbound-share room on the invitee's side (rooms 1 → 2). The code is right today; it is the twin of the ask projection this PR is about, and it is the case the follow-up dialog will hit first.
2. The scanner's local-link branch in client.js is unpinned as well: deleting it leaves 363/363, so a local link scanned on the face-room scanner still falls through to That is not an invite link…. docs/subsystems/social.md says it is answered by name in dialog, scanner and host, and only two of the three are held.
3. The envelope APIs still have no caller (no local_room_invites gate, no request path, no UI), as the body says; the Members card and the dialog are A local room's invite link has no Members-card row and no redemption dialog, and the preview card would be copied a second time #876, so #852 stays open.
4. The ticket stays a bearer secret in state.rooms for ten minutes, and a refusal is local on the inviter's host (the invitee's dialog times out). Both were agreed in feat(rooms): mint and withdraw a local room invite link (#852) #861 and are unchanged here.