Co-seat shared-group Bot outbound still waits for owner Approve #1175

Activity

1. Birfy

   self-assigned this

   on Oct 25, 2026
2. Birfy

   added

   bugSomething isn't workingSomething isn't working

   on Oct 25, 2026
3. Birfy commented on Oct 25, 2026

   

   Birfy

   on Oct 25, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   Re-triaged on main 97065bac: needs-info, because the report describes two very different situations with the same words, and the code distinguishes them:

   • Auto-send is off for that room — then a held line is by design. social.js:176-183 names face_room_auto_send_off as a real per-room switch, :4497 only auto-sends a face line when autoSendFaceLine succeeds, and :4510-4515 refuses unless held.autoSendHold === true. A pair that has never set it reads “Waiting for approval” forever, and the owner's Approve is the feature working.
   • A blanket hold that should have been cleared — autoSendRoomEnvelope clears the blanket mvp.all_outbound_requires_approval hold for a room line (:1825, :1867, :2000), and :181-182 says explicitly that neither outbound path clears face_room_auto_send_off. If the pair is a co-seat in one open room and the room's own Auto-send is on, a card here is a bug — in the clearing path, not in the seat.

   What I need on this issue to decide between them, all of it from the same attempt:

   1. the hold's holdReason and reasons (the face_room_auto_send_off switch versus a blanket reason);
   2. whether the room's own Auto-send switch reads on for the holding Bot, and for the other seat;
   3. which room (roomId) and whether both Bots are current members of that same open room — co-seat versus 1:1 is the axis Send a shared-room leave while the seat is still reachable #1174/Co-seat shared-group Bot outbound still waits for owner Approve #1175 turn on;
   4. whether the same pair, outside any room, also waits — if yes this is the 1:1 path (#948 territory), not the room path.

   With those four answered this becomes either “working as designed, set the room's Auto-send” (and closes) or an agent-ready bug with a named file. Labels: area:social added, because this is Bot Social outbound, not a UI defect.
4. Birfy

   added

   area:socialFriends, invites, grants, Bot SocialFriends, invites, grants, Bot Social

   needs-infoWaiting for the reporter or a maintainer decisionWaiting for the reporter or a maintainer decision

   on Oct 25, 2026
5. Birfy commented on Oct 28, 2026

   

   Birfy

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   State unchanged — parked on the label it already carries, because criterion 2 (scope / expected behavior) still does not hold. #1174 closing does not settle it: #1174 closed as pass on 2026-10-25 (1debb12d) and covers sending a room leave while the seat is reachable — membership, not this outbound hold. The report still describes two situations the code tells apart, with the same words:

   • Auto-send off for that room — the hold is the feature working: face_room_auto_send_off is a real per-room switch, a room line is only auto-sent when autoSendFaceLine succeeds, and delivery refuses unless held.autoSendHold === true.
   • A blanket hold that should have cleared — autoSendRoomEnvelope clears the blanket mvp.all_outbound_requires_approval hold for a room line, and states outright that it does not clear face_room_auto_send_off. With the room's own Auto-send on, a card here is a bug in the clearing path, not in the seat.

   What is missing, all of it from one attempt:

   1. the hold's holdReason and reasons;
   2. the room's Auto-send switch as each seat reads it;
   3. the roomId, and whether both Bots are current members of that same open room (co-seat vs 1:1 is the axis);
   4. whether the same pair outside any room also waits — if yes this is the 1:1 path (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), not the room path.

   Who can give it: whoever ran the E2E (SelfTest on the two-home bench, :3090/:3091) with the same shared-group setup, pasting those four readings here. If the answer is "by design" and the owner wants that default changed, it is an owner call, not a Dev task. With the four answers plus a roomId this becomes either a close ("working as designed, set the room's Auto-send") or an agent-ready bug with a named file.
6. Birfy commented on Oct 29, 2026

   

   Birfy

   on Oct 29, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   卡在判据 1（设计冲突未闭）→ 只留 H（需要 owner 一句话）。昨天要的四项读数（holdReason、两边 Auto-send 开关、roomId/共席、1:1 是否也等）只能分清「按设计在等批」还是「clearing 路径有 bug」；但它们都依赖一个没定的前提，先问 owner 更省事。

   缺什么：两个 Bot 同处一个 open 的 shared group 时，A 的 Bot 发一句给 B 的 Bot，应该——

   1. 直接发出（co-seat 即 auto-send，逐对 Sharing/Approve 不参与），还是
   2. 仍按 per-room / per-pair 开关（房内 Auto-send 关着就等 owner 批）？

   issue 里引的 owner 原话「拉了群就应该都能发消息」只定了「能发」，没定「不经批准」。

   谁能给：owner（经 Chief 转达）——这是 sharing/安全面，Bot 不自己拍。答 1 → 变成 clearing 路径的 bug，带文件转 agent-ready；答 2 → 回到那四项读数，按设计说明或按 clearing bug 处理。
7. Birfy

   added

   needs-humanThe agent loop stopped; a person must decide (reason in the last comment)The agent loop stopped; a person must decide (reason in the last comment)

   and removed

   needs-infoWaiting for the reporter or a maintainer decisionWaiting for the reporter or a maintainer decision

   on Oct 29, 2026