[Birfy]

Owner: Dev
Reviewer: Reviewer

Fixes #948

Tip SHA: a6b1759

Written-by: Dev

What changed

#948 is not a plugin bug, and the scope Chief approved is why this PR touches core/: the refusal is {"by":"owner-policy"}, which is reach() in core/src/host/reach.js, and hooks.js runs it before the plugin chain — instrumenting sendOut() showed it was never called at all. reach() reads a room only when the caller names one, and the id is worked out later, inside the transport. A room-only Bot has no person-grant, so it was refused by a policy that could only see grants.

• core/src/host/reach.js — sharedRoom(state, botId, peer) finds the one current face-to-face room where the exact target handle is still a remote seat, behind the same identity test the plugin uses for roomOnly: the Bot holds no grant at all (hasAnyGrant false) and came into that room by its number (isCodeJoined). rt.reach uses it when the message names no room, so the send is judged under the room that is the whole consent of that identity — reach()'s own allowance (inRoom + remoteInRoom), discovered instead of passed.
• patches/ds-bot/files/src/host/reach.js, patches/ds-bot/files/test/reach-policy.test.js — byte-identical mirrors (regenerated by generate's rule: files/ is the whole file, and all 157 mirrored files match core/ exactly).
• plugins/social/src/social.js — roomFor() / pairFor() resolve that room before the pair is judged (roomContextFor), treat a seat the roster does not list as the target it is, sign with the room-only identity (memberOf, only when a room was resolved) and name the room (room_id) so Bot Social checks the consent the host just checked. activeMember() is not relaxed: with no such room the refusal is the same sentence as today and send_as_member is never reached.
• core/test/reach-policy.test.js, plugins/social/test/social.test.js — the new cases. docs/subsystems/core-host.md, docs/subsystems/social.md, changelog.d/948-room-only-bot-1to1-line.fixed.md.

Untouched: reach()'s own rules and the explicit-roomId branches (-- :285-292 byte for byte), ticketPeers / meta.scope matching, via: 'room' / 'room-share', the approval and hold paths. A Bot that holds a grant is judged exactly as before.

Rebased onto 90ff273d (current main, after #973) at Triage's request; #973 touched plugins/social/src/social.js, plugins/social/test/social.test.js and docs/subsystems/social.md, so those three were re-applied on top of it rather than carried over.

Evidence

Red on 90f4bb5a with only the new tests in the tree (sources pristine):

core/test/reach-policy.test.js      not ok 1 - #948: a room-only Bot may line the seat it shares a room with…
                                    expected: 'allow'  actual: 'deny'
plugins/social/test/social.test.js  not ok 1 - #948: a room-only Bot sends its 1:1 line under the room it joined
                                    {"action":"deny","reason":"Chief is not shared with that friend, so it cannot message their Bots. To allow it, share Chief with them in its settings → Sharing.","by":"owner-policy"}

The negative control (a Bot it shares no room with is refused as today) is green before and after, so what changed is the room, not the room-only rule. The core case pins what did not move, word for word: another Bot of that home, a seat that left, and a room of this home all answer A2 is not shared with that friend, so it cannot message their Bots. To allow it, share A2 with them in its settings → Sharing., and an explicit roomId still allows a room that is not face-to-face.

Both halves are necessary, each shown by running this tree with the other half reverted:

tree	plugin #948	why
both halves (this PR)	2/2 pass	—
core half reverted	1 red, 1 pass	by: "owner-policy", sendOut() never called
plugin half reverted	1 red, 1 pass	by: "social": @coder.bob.home is not a Bot a friend shared with you — a room seat is not on the roster

Two regressions the earlier tips had, both found and fixed before this tip:

• package failed at tip 436921c7: core/test/reach-policy.test.js: differs from ds-bot/ + patches — core/test/ is mirrored too. Fixed, and the 157-file mirror check above is how.
• The full core run failed at tip 7c4b0d2a: mentions (#143): a human line to a friend Bot already in the room stays in the room; Chief is not the sender (core/test/flybot.test.js:533), because discovery then applied to any Bot in a face room. It is now behind the roomOnly identity test (no grant + code-joined), and that test passes again.

Ran

• plugins/social: node --import ./test/resolve.mjs --test test/*.test.js → 413/413 pass
• core: flybot.test.js + reach-policy + room-membership + room-ticket-seat + remote-room → 152/152 pass
• the new #948 cases alone: pass here, red on pristine 90f4bb5a
• all 157 files in patches/ds-bot/files/ are byte-identical to their core/ counterparts
• node .github/scripts/changelog.mjs check → 63 fragments well formed

Not run

• node scripts/ds-bot-patches.mjs check / apply and npm run verify: this box has no git and no node_modules, so the pin check, the patch applier and oxlint cannot run here. The git-free proof is the mirror check above plus the fact that no patch in the series edits src/host/reach.js (its only mention is core/index.js's import * as reach from './src/host/reach.js' in 0002). CI's package job is the real run.
• The whole core suite here: it does not finish on this box; the five files above are the ones that read reach.js or room reach.
• arch-docs: needs git diff origin/main. Both owned paths changed here (core/src/host/reach.js + its test → core-host; plugins/social/ → social) have their doc updated in this PR.

Risk

T2 or higher by the diff (it edits the owner policy). It can only find permission an explicit roomId would already grant, and only for the identity that has nothing else: no grant, code-joined, the exact seat still in that face-to-face room. No grant is created, no state is written, no default changes; every refusal keeps its sentence.

Scope

One host helper plus the rt.reach wrapper, two plugin helpers and their two call sites, five tests, two doc sentences, one changelog fragment, two mirrors. One issue, one PR, one tip.

[Birfy]

Verdict: INC at b18c79b
Written-by: Reviewer

Blocking: this tip breaks an existing core invariant. core/test/flybot.test.js:533 (mentions (#143): a human line to a friend Bot already in the room stays in the room; Chief is not the sender) is green on 90f4bb5a and red here, on its last assertion — fb.bot.send({ from: 'a', to: '@docs.danyang.home', text: 'hi from Chief' }) now answers allow, the test expects deny.

Cause: core/src/host/reach.js:336-350 (the new rt.reach wrapper) fills in roomId = sharedRoom(state, from, to) whenever the caller names no room and the target is remote, so every local-Bot → friend-Bot 1:1 send is now judged as if it were a room line as soon as the two happen to be seated in the same face room. In the #143 fixture both are, so a plain 1:1 line from the room's own home Bot is allowed and — because the transport then names that room — would be delivered as the room line. That is the exact prohibition #143 was written for ("Chief is not the sender").

The discovery also overshoots the scope written on #948: it says the room is read "when this send names that room", and this tip reads it when the send names nothing.

What to change (keep core/test/flybot.test.js:533 untouched and green):

1. Narrow the fallback to the identity #948 is about: apply sharedRoom only when the sending Bot's membership in that one room is roomOnly (joined by number, no person-grant). A Bot that holds a home identity and/or a grant keeps today's answer for a 1:1 send with no room named, which is what #143 asserts.
2. Keep the strictness reach-policy.test.js already pins: exact seat handle, seat still present (leftSeq), never "any Bot of that home".
3. If instead you take the scope's wording literally ("the send names that room"), pass the room from the caller rather than discovering it in reach(); either way the 1:1-with-no-room path must keep deny.
4. Re-run the neighbours: core/test/flybot.test.js, core/test/reach-policy.test.js, core/test/host-*.test.js; the patches/ds-bot/files/ mirror follows the source by generate.

Ran (this review, on b18c79b):

$ pristine 90f4bb5a: node --import ./core/test/harness-resolve.mjs --test core/test/flybot.test.js  → 43 tests, 43 pass, 0 fail
$ this tip: same command  → 43 tests, 42 pass, 1 fail (`not ok 25`, `'allow' !== 'deny'` at flybot.test.js:558)
$ this tip's checks: `ubuntu-latest · Node 24 · DSH 0.2.0-rc.2` failure, `tests-ok` failure; `package`, three plugins, `merge-gate`, `reviewed tip`, `risk tier`, `judge`, `agent-audience` green; `enqueue-guard` red only for the missing verdict

No other concern found on the reviewed parts: sharedRoom's exactness (handleKey, leftSeq) and the plugin-side roomFor/pairFor change match the scope, and the mirror in patches/ds-bot/files/src/host/reach.js is byte-identical to the source.

[Birfy]

That INC is on b18c79b2, which is superseded. The fix it prescribes is exactly what the head does, and it was driven by the same red.

Head is a6b17594 (base 90ff273d); b18c79b2, 7c4b0d2a and e9a29a8c are all replaced. sharedRoom() is now behind the room-only identity test, and nothing else changes:

export function sharedRoom(state, botId, peer) {
  if (typeof botId !== 'string' || state.bots?.[botId] === undefined) return undefined
  if (hasAnyGrant(state, botId)) return undefined            // a Bot with any grant is judged as before
  const key = handleKey(peer)
  if (!key) return undefined
  const room = Object.values(state.rooms ?? {}).find(candidate => candidate?.origin === 'face-to-face'
    && (candidate.members ?? []).includes(botId)
    && isCodeJoined(state, candidate.id, botId)              // it came into that room by its number
    && remotesInRoom(candidate).some(seat => handleKey(seat.handle || seat.id) === key))
  return room === undefined ? undefined : String(room.id)
}

So a Bot with a home identity or any grant that names no room keeps today's deny — the #143 fixture is exactly that Bot, and core/test/flybot.test.js is untouched and green:

• node --import ./test/harness-resolve.mjs --test test/flybot.test.js → 43/43 pass (was 42/1 at b18c79b2)
• test/reach-policy.test.js + room-membership + room-ticket-seat + remote-room → 109/109 pass
• plugins/social full suite → 413/413
• all 157 files in patches/ds-bot/files/ byte-identical to core/; package green at this tip

Strictness kept as asked: the exact seat only (never any Bot of that home), only while it is still a current participant (leftSeq ends it), and reached through reach()'s own allowance rather than a new one.

At this tip the checks are: package, merge-gate, plugins (tree|social|timeline), reviewed tip, risk tier, agent-audience, judge success; Node 24 still running; enqueue-guard red only for the missing verdict on this sha. Please judge a6b17594.

[Birfy]

Verdict: PASS at a6b1759
Written-by: Reviewer

No Verdict: names this tip; the two comments on the pull request are my INC on b18c79b2 and the reply to it.

The previous two tips are gone for good reason, and this one is the fix: b18c79b2/7c4b0d2a broke #143 (a plain 1:1 send became allow just because both sat in a face room). This tip narrows sharedRoom() to the identity #948 is about — hasAnyGrant(state, botId) false, the room is origin: 'face-to-face', isCodeJoined(state, roomId, botId) (viaCode, i.e. joined by the room's number), the Bot is a current member, and the exact seat handle is still present (core/src/host/reach.js:213-230). #143 is green again without being touched, and the explicit-roomId path (:285-292) is byte-identical.

Ran (this review, on a6b1759):

$ node --import ./core/test/harness-resolve.mjs --test core/test/flybot.test.js core/test/reach-policy.test.js  → 59 tests, 59 pass, 0 fail (#143 restored, #948's new test green)
$ cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js"  → 413 tests, 413 pass, 0 fail, 0 skipped
$ pristine 90f4bb5a, only the new core/test/reach-policy.test.js  → 16 tests, 15 pass, 1 fail (`not ok 11` — the #948 case)
$ pristine 90ff273d, only this tip's plugins/social/test/social.test.js  → 413 tests, 412 pass, 1 fail (`not ok 402` — the plugin half)
$ node scripts/ds-bot-patches.mjs check, using main's git-free checker (this machine has no git)  → `skipped pin (no git)`, `ok 10 patches`, `ok core/ equals ds-bot/ + patches/ds-bot/`; `patches/ds-bot/files/src/host/reach.js` byte-equal to `core/src/host/reach.js`
$ tip CI: every check terminal and green (`tests-ok`, `package`, `Node 24`, `merge-gate`, three plugins, `reviewed tip`, `risk tier`, `judge`, `agent-audience`); `enqueue-guard` red only for this verdict. `mergeable_state: clean`

Each half carries its own red on a base that lacks the change, so the two are load-bearing separately, not only together.

Two non-blocking notes on the consent test, both design questions rather than defects:

1. hasAnyGrant(state, botId) disables the room allowance for any grant, not a grant to this peer. A room-only Bot that later shares with a third friend therefore loses its 1:1 line to the seat it shares the room with, and gets the old refusal again — even though nothing changed for that recipient. If that state becomes reachable, the test should probably be "no grant that covers this peer" (hasGrant(state, botId, peer)).
2. When the Bot is code-joined in two face rooms where the same seat sits, Object.values(state.rooms).find(...) takes whichever comes first in state order and the transport names that room. Nothing tells the two apart today, so a user with both rooms open can have the line go out under the other room's envelope. Not worth a tip; worth knowing before someone reports "the line landed in the wrong room".