A ticket-claimed (room-only) Bot cannot send a 1:1 line into the room it shares: the member check runs before the room lookup #948

What happens

A Bot that joined a face room by redeeming a ticket gets its identity with roomOnly: true, and from then on our own gate refuses every 1:1 line it sends, before the room lookup runs:

• plugins/social/src/social.js:728 — register() stores memberFields(member, { …, roomOnly: forFace }); forFace is the ticket-claimed join.
• :637 — activeMember() returns undefined for a roomOnly member: return member && !member.roomOnly ? member : undefined.
• :1603-1608 — sendOut() asks activeMember(msg.from), gets undefined, and throws "<name> is not shared with that friend, so it cannot message their Bots."
• :1622-1623 — only after that check does the same function call roomContextFor(msg.from, bot.handle) and put room_id on send_as_member.

So the room path at :3211 is unreachable for exactly the identity that needs it. Two independent reproductions on ed60c5a1 (evidence: #866 comment 6383026248):

social/send {from: guestBotId, to: hostHandle}
→ {"action":"deny","by":"owner-policy","reason":"Guestyrgn7 is not shared with that friend, …"}

Same room, same guest Bot, sending a room line (face-send) reaches the platform (pending_approval, messageId fmd_…, approvalId apr_…). Only the 1:1 line that should name the shared room is blocked.

The comment at :628-633 says a room-only identity "is not polled, does not sign friend sends". It does not say it cannot sign a room send — and :3211/:3224 exists to name that room. The two paths are stitched in the wrong order, not deliberately closed.

Expected

Resolve the room first, then judge the pair:

1. If roomContextFor(from, target) names an open room both sides are in, the send goes out as a room-scoped send_as_member with that room_id — signed by the roomOnly identity, because the room is the consent (:1618-1621 says as much for the ordinary case).
2. If it names no room, the refusal stays exactly as today: owner-policy, "not shared with that friend", with the same sentence users see now.
3. roomOnly is not deleted by this fix: the identity is still not polled, still revoked when the Bot is in no face room (releaseRoomOnlyIdentity, :3230), and still cannot sign a friend send with no room behind it.

Where to change

• sendOut() :1598-1623 — compute roomId before the activeMember check at :1604; when it names a room, take the member from memberOf() (room-only allowed) instead of activeMember(), and keep passing room_id at :1623.
• friendshipActive() :1187 uses activeMember() too, so it sees no identity for the guest; check whether the room-scoped path still reaches it (:1614 skips via: 'room', but a 1:1 room-scoped line has no via) and handle it the same way.
• The approval policy at :1444 (covered(…)) and :1460 (friendshipActive) run before sendOut; a room-scoped send must not be denied there either.

Acceptance

1. A ticket-claimed Bot that is in an open face room with the target Bot sends a 1:1 line → the transport carries room_id of that room and the platform answers (a message id or the platform's own hold); our gate no longer refuses at :1605/:1607.
2. The same guest Bot sends the same line with no shared open room → refused, still by: owner-policy, reason unchanged.
3. A room-only Bot that has no person-grant still cannot sign a friend send with no room (roomOnly semantics intact) and is still revoked when it is in no face room.
4. via: 'room' and via: 'room-share' lines are untouched: no room_id is added at :1622 for them, and the room envelope path (:1649) behaves as before.

Notes

• The 1:1 half of Wrap up bot-social #43 on the FlyBot side: a send into a claimed room must name its room #866 points here; Wrap up bot-social #43 on the FlyBot side: a send into a claimed room must name its room #866 keeps only the in-room face-send → approve → deliver half.
• Face-join quota: reproductions used the A home's 5/60-minute window; a fresh window is needed for an end-to-end run.

Scope revised 2026-10-24: the owner-policy half lives in core/

Dev traced the refusal with a point in sendOut(): it is never called. The denial comes from the host, one layer above the plugin:

• core/src/host/reach.js:272-302 reach() — the toRemote branch (:285-292) honours a room only when the caller passes one: hasGrant(state, from, to, roomId) at :286, inRoom && remoteInRoom at :288, a ticket's scope at :290. With roomId undefined it falls to :292, which is the owner-policy sentence users see.
• The room_id is computed after that call (social.js:1622, roomContextFor at :3211), so it cannot be named in time.

That makes this one behaviour across two layers, and the scope now includes the host:

1. core/src/host/reach.js:285-292 — accept the pair when both sides are current members of the same open face room and the send names that room. Narrow to face rooms (the only id the platform can verify); no general relaxation, and the no-room refusal at :292 stays byte-identical.
2. patches/ds-bot/files/src/host/reach.js — regenerate with node scripts/ds-bot-patches.mjs generate; never hand-edit the mirror. #978 lands the git-free strict validator, so from then on a bad hunk is caught locally instead of by CI.
3. The subsystem doc that owns reach.js gets a sentence; if the answer is "no doc", write Docs-not-needed: with the reason in the commit and the PR body.
4. plugins/social/src/social.js as described under "Where to change" above: resolve the room first, sign with the roomOnly member (memberOf(), not a loosened activeMember()), keep room_id.

Why one issue, not two

Either half alone changes nothing observable: without the host change sendOut() still gets denied (and a room id reaching reach is exactly what is missing); without the plugin change no caller ever passes roomId. A split would produce a PR whose acceptance cannot be measured end to end, and those are the ones that come back as "proved by hand". One behaviour, one tip, one verdict.

The four acceptance items above are unchanged. Two additions:

5. A core unit case on reach(): the same pair with the room named → allow; identical call without roomId → deny with the same reason string. This is the half that cannot be seen from the UI.
6. The branch is rebuilt on current main (c20c152e at the time of this note), not on ed60c5a1.

Dev's two existing reds stand as the plugin-side half: the room case red today, the no-room case green today (which is what proves the refusal was not loosened).

Owner decision, 2026-10-24 (recorded verbatim in effect)

Scope includes core/; Docs belong to the subsystem that owns reach.js. One issue, one PR, one verdict. The four acceptance items stand, with the two additions above. The work is exactly these four, in this order:

1. core/src/host/reach.js — before the deny at :292, accept the pair when both sides are current (未离开) members of the same open face room and the send names it. Face rooms only; activeMember() is not loosened anywhere, and the no-room refusal keeps the same string.
2. patches/ds-bot/files/src/host/reach.js — regenerated with node scripts/ds-bot-patches.mjs generate; never hand-edited (#978 brings the local strict check).
3. sendOut() — sign with the roomOnly identity taken from memberOf() (not from a relaxed activeMember()) and put room_id on the send_as_member.
4. The subsystem doc that owns reach.js gets the sentence; if none applies, Docs-not-needed: with the reason in the commit and the PR body.

A split would have produced two green halves and a broken whole: the denial happens in reach(), before the transport, so no plugin-only change can ever turn the room case green.