test: the read-only suite never mounts FaceRoomOverview, and liveRoom() has no origin — the assertion would be green from birth #2229

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: b3005a0494b34f838a96d4ac9cc6f5ba
Branch: dev/1-overview-readonly-test-gap
Base: 9863992
At: 2026-11-02T23:33:48Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead
Credit: gap found while triaging P-443; lines re-read by Lead on live main.
Kind: test gap (an assertion that cannot fail)
Source: live main 986399246ff8c26bd418978785ce1199dbd239ca, read 2026-11-03T00:0xZ.

Dedupe (searched before opening)

Open issues for FaceRoomOverview: only #2228 (the defect this gap is about). false green: none about this file. social-readonly in the body: #2228, #2219 (closed, the read-only shell work) and #1748 (open, unrelated: remote-bots menu waits for a per-Bot grant). No issue covers the test gap.

The gap

plugins/social/test/social-readonly.test.js:117 (#2219: a read-only window draws no Bot Social write control) mounts two things: the FriendsBots section (:121-124) and FaceRoomCard (:128-129). It never mounts FaceRoomOverview, which is the component that draws the room view's own head row — the one #2228 is about.

The fixture makes that worse. liveRoom() (:113-115) is

{ roomId: 'r1', faceRoomId: 'frm1', status: 'open', members: [...], face: { roomId: 'frm1' } }

and FaceRoomOverview starts with if (room?.origin !== 'face-to-face') return null (plugins/social/client.js:2789). Handing today's liveRoom() to the overview renders nothing, so a "no write control" assertion written against it would be green from birth — exactly the failure mode the suite already warns about elsewhere.

FaceRoomCard does not read origin (it reads readOnlyReason(roster) at client.js:1980), so adding origin: 'face-to-face' to the shared fixture cannot change the existing card assertions.

Expected (red first on unfixed main, before #2228 merges)

• liveRoom() carries origin: 'face-to-face' so the overview actually renders.
• A new test mounts FaceRoomOverview with a read-only roster ({ bots: [], byId: {}, readOnly: LOCK }, the file's own readOnlyRoster() at :91) and asserts zero write tags: today it must fail listing 5 (face-leave, face-auto-send, face-auto-bot, face-invite, face-invite-mint) and 2 buttons (Leave, Create link). The failure output goes into the PR body as the red-first evidence.
• The same mount with a writable roster still draws those 5 tags and 2 buttons — the positive control that proves the assertion is not vacuous.
• A guard that cannot go green by emptiness: the read-only tree must still contain the status chip (assert the tree is non-empty and carries the room's status text), so a future null return fails the test instead of passing it.
• Existing tests in the file keep passing unchanged; flybotTags (:72 helper, currently used at :126/:130) stays the way tags are collected.

Sequence

This test is red until #2228 lands, so the PR stays a draft and merges only after #2228. That ordering is the point: capture the failure on the unfixed main now, so the fix cannot be born together with a green assertion.

Scope

plugins/social/test/social-readonly.test.js only. No production file changes; if the new test needs a helper, keep it in that file. changelog.d/ entry not needed for a tests-only change unless the repository requires one for test-only PRs (check changelog.d/README.md); docs/subsystems/ needs no change.

Tier: tests-only → T1 by the path table, so the PR stays a draft until FlyBot Test posts its independent advisory PASS (and, above, until #2228 merges).