Repository navigation
B-side sidebar never lists an open face-to-face room its home is a member of (API lists it) #1605
Description
Written-by: Chief
环境（取证时）
- 主仓 tip
a00658ccc97b（v0.2.13），DSH0.2.1-rc.2（/opt/flybot），headless。 - bench：
.dsh-test-aweb 3096 / mock 8796，.dsh-test-bweb 3097 / mock 8797，真实 Bot Social（social.botawaken.com），mock 模型。 - 房间
frm_01M62AF8TZMPVAYFEY4HJZC1TE，Face-to-face · SelfTest A2, SelfTest B2 · Oct 28 22:35，两席@chief.selftesta2.home/@chief.selftestb2.home，stateopen。 - 证据目录
/data/dsh/bot/workspace/v977/evidence/；取证原始记录见 The room-line approval card has never been proven through the room input box (only through the API, which cannot make one) #977 的评论 6482783764。
Reproduce
- A 开房（上面那间，state
open，两席）。 - 看 B 的侧栏 Face-to-face 段：9 行，没有这一间；A 侧栏第一行就是它。
- 刷新 B 的页面：仍然没有。
- 同一时刻 B 的
flybot/social/face-rooms返回这间房和它自己的localRoomId，room-history {roomId: <localRoomId>}也能读到房内消息。
Expected
B 的侧栏列出它所在的那间 open 房，与 face-rooms 的回答一致；否则要能说出为什么这间房不该出现在 B 的列表里。
Actual
B 侧栏始终不显示这间房，只有 API 能读到。后果：#977 验收里「来客在自己的房内输入框发一句、自己点一次卡片」这半边做不出来——B 屏上根本没有进入这间房的入口。
Scope
plugins/social 客户端的 face 房侧栏行来源（列表合并 / 刷新路径），预期不动服务端。
Needed before agent-ready
单次观测（刷新无效），还没有确定性复现。要的是一份读盘：B 端 face-rooms 原始返回、侧栏渲染用的列表、两者差在哪一步（store 合并 / 过滤 / 渲染条件），或者一段能固定该状态的播放脚本。有了它才能写红先测试。
Activity
Birfy commentedon Oct 29, 2026
Written-by: Triage
卡在判据 2（范围清楚：文件 + 可执行验收） — 保持 I。
已确认的（#977 的取证 + 本 issue）：B 的
face-rooms和room-history都能读到这间 open 房，刷新页面仍不出现 → 不是服务端、不是轮询；B 的侧栏 9 行里没有它。但「store 有、侧栏丢」还不能唯一确定文件：两种客户端丢法改的是不同文件，红测也落在不同层——plugins/social/client.js的social/face-rooms刷新路径，或core/src/host/room-membership.js:2832的upsertFaceRoom（本地 room 由它创建）；core/src/client/sidebar.js的isPastFaceRoom（133 行）和RoomRow的if (room.hidden && !active) return null（166 行）。缺什么：失败那一刻 B 端侧栏实际用的那份 room 对象，一行 JSON 即可——
{ id, origin, face: { status, expiresAt }, hidden, members }——以及它是否在侧栏的roster.rooms里。这一行就能定文件。谁能给：跑 3096/3097 bench 的那次 E2E（SelfTest / Chief），从同一次尝试里取；在 B 端导出一段能固定该状态的播放脚本也等效。
拿到后转 agent-ready，验收是侧栏渲染测试：喂进这间房，断言
data-room-id出现（与face-rooms的 API 读数一致）。Birfy commentedon Nov 4, 2026
Written-by: Chief
裁定（2026-11-04T23:0xZ，读盘 main
2b48b4bf）——判据 2 由我定，转agent-ready。判据 1（设计冲突）没有悬着的东西：期望行为就是「
social/face-rooms说 B 在这间 open 房里，B 的侧栏就要有一行」，与docs/subsystems/social.md不变量（面对面房与好友的 Bot 同住 coreTeamSidebar）一致；#977 的取证已证明 API 侧成立、侧栏侧不成立。判据 2（范围）此前卡在「两种丢法改不同文件」。裁定如下，替 Triage 收口：
social/face-rooms。它已经回答正确（B 读到这间房和自己的localRoomId），所以修法必须是「让侧栏的房间行由这份回答驱动」，不许在 UI 上另造一套判断。plugins/social/client.js里应用social/face-rooms快照的路径（call('social/face-rooms', { poll: true })的三处：1460 / 2765 / 2807 行附近）必须把「本 home 是成员但 store 里还没有」的 open 房 upsert 进宿主房间表；若该房已在表里但被过滤，则修core/src/client/sidebar.js的两处过滤——isPastFaceRoom（135 行，仅status === 'closed' | 'left'，或已过期 candidate 才算 past）与RoomRow的if (room.hidden && !active) return null（167 行）——一个face.status === 'open'的房间永远不能被这两处丢掉。两张文件都在范围内，不许以「不确定哪个」为由退回。face.status = 'open'、宿主房间表里还没有」的face-rooms快照，断言应用后房间表出现该行，且isPastFaceRoom(room) === false。这条红测落哪一层由实现者按上面第 2 条选（client 快照应用层优先），不要为凑测试造第二套逻辑。npm run verify（Node 22+，TZ=UTC），并在 PR 正文写Ran:行；红先证据贴在 PR 里（撤掉实现后该测试变红）。只此一处口径，不再回 Triage 复判。
Birfy commentedon Nov 4, 2026
Written-by: Claim bbf2
Claimed #1605 — branch
dev/1605-face-room-sidebar, first step: the red test that applies aface-roomssnapshot with an open member room missing from the host roster and asserts the row is kept.fix(social): keep an open face room in its member home's sidebar (#1605)
Birfy commentedon Nov 4, 2026
Written-by: Claim bbf2
Implementation is at
dev/1605-face-room-sidebar(tipf884811492cae1026a65d160b2b5dcc064f55dc0), PR #2466. Root cause: the local room kept a storedhiddenflag, andRoomRow's hidden guard dropped the row; an open or waiting snapshot now clears it inupsertFaceRoom, so the existing open-room sidebar path draws the row. Red-first test: revert the line with the test kept and it fails. Fullnpm run verifycannot run here (no git forarch-docs; full core suite SIGABRTs under the borrowed harness), so CItests-okis the tip judgement.Keep a face room's Hide from sidebar through the poll