[Birfy]

A Bot that works on something handed out in a group (a member there sends it the work with message_bot) runs it in a hidden turn of its own chat. Its ask_user card therefore landed in the Bot's private chat, and an answer there never went back to the group. Now the card sits in that group's composer dock, named for the Bot that asks. The answer reaches the Bot as a hidden request from the member that handed the work over, so the Bot's reply goes back to the group the same way the work does. The group shows a quiet notice of the answer, and the Bot's private chat gets no card and no visible turn.

Fixes #550

• tools.js: ask_user in a turn that answers a group member's request (senderRoomId, not audience: 'user', not a friend's) writes state.questions[<room>] (header, botId, replyTo, the turn's origin, allowCustom). Only one card per group: while one is open, a second Bot is told to ask in its reply. rt.answerGroupQuestion delivers the answer and posts the notice.
• channel.js answer-question: routes a room card to it. delivery.js: a header for it (answeredIn). turns.js: a typed group line no longer clears the group's card.
• authz.js: only the asking Bot's owner or the room's owner sees or answers such a card. A non-owner's answer carries origin: other.
• roster.js: deleting the room or the Bot drops the card. Face-to-face rooms use the same path on the local home.
• Docs: core-host.md. Changelog fragment 550-group-questions.fixed.md.

Not changed: ask_user inside a group Session is still refused (the Bot asks in its reply, which already shows in the group). Secret cards stay private. reply_to: "user" hand-offs are still answered in the Bot's own chat by design.

Verification (tip 6dfe7ba)

• The second commit, 6dfe7ba, runs the answerer's display name through cleanName before it goes into the group notice.
• Red at base: 11f80dd with only test/group-work.test.js and test/authz.test.js copied in gives 4 fail / 27 pass. The 4 new Questions from work handed out in a group show in the Bot's private chat instead of the group #550 tests fail and the own-chat guard test passes. At the tip they all pass.
• ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify passes: core 1121/1121, social 313, tree 83, timeline 93, scripts 93, interop 37, live-e2e 16; arch-docs OK; patches check ok. oxlint warnings are 53 at both base and tip.
• On the first verify run (at 368b4fb), tasks.test.js "an untagged hold stamps the latest working task…" failed once under full-suite load. It passed 3 of 3 alone and the rerun was fully green. That test uses millisecond timestamps, and this PR does not touch that code.
• DSH smoke (dev/bench.sh + dev/smoke.mjs, DSH 0.2.0-rc.2, mock model) passes all 42 steps at 6dfe7ba.

Not run: Desktop app, a real model, a live two-home face-to-face run, and a browser check of the group dock rendering. The client is unchanged: QuestionDock already reads questions[sessionId] for the open conversation and shows header.

File overlap with open PRs: #544 touches authz.js, channel.js, topics.json, core-host.md and the 0001/0005 patches; #547 touches 0001-core-fixes.patch, topics.json and core-host.md. The source hunks are in different places. topics.json adds test/group-work.test.js to topic 0001.

[Birfy]

Verifier report (review-pr), PR #551

Verdict: PASS at 6dfe7ba6c759fe52085afebcf93be405047a087a. This was a self-review by the owner's reviewer agent (Birfy, selfReview). The rules were loaded from origin/main 11f80dd: AGENTS.md, code-standards, LESSONS, review-pr.

Tip SHA: 6dfe7ba6c759fe52085afebcf93be405047a087a
Ran:
  - ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify (node 24) → pass (core 1121/1121, social 313, tree 83, timeline 93, scripts 93, interop 37, live-e2e 16; arch-docs OK; ds-bot-patches check ok)
  - red at base: worktree at 11f80dd + only test/group-work.test.js and test/authz.test.js from the tip → fail (4 #550 tests fail, 27 pass); same files at tip → pass (31/31)
  - oxlint warning count base vs tip → 53 vs 53 (no new warnings)
  - DSH smoke: dev/bench.sh + dev/smoke.mjs (DSH 0.2.0-rc.2, mock model, ports 3196/8896) → pass (42/42 steps), bench stopped
  - GitHub CI run 39431402526 at this head → pass (tests-ok, test, plugins tree/social/timeline, package)
  - node .github/scripts/risk-gate.mjs --pr 551 → T3 (authz.js, channel.js, delivery.js paths)
Not run:
  - Desktop app and real-model runs — no model key; mock model only
  - live two-home face-to-face run — unit test covers the local-home path only
  - browser check of the group composer dock showing the card — client unchanged; QuestionDock already renders questions[sessionId] with header
Verdict: PASS

Findings: nothing that needs fixing.

• Non-blocking: the asking Bot's sidebar row no longer alerts, and the group row does not read questions[room.id]. Filed as Show a group's open question card in the sidebar and Agent inbox #552.
• Non-blocking: the answer's relay is recorded in state.exchanges as sender → asking Bot (its text starts with [Answer to question card]). This is only cosmetic in the exchange log.

Security, fences and display names: no fence code changed. The model-visible text that is new is the request header ([The user answered your question card in the group "<room name>" …]). It uses the room name in the same way existing [Group chat "<room name>" …] headers do. The body is the Bot's own question plus the owner's answer, with session chips stripped by deliver and unshareableReference checked in channel.js. The answerer's display name goes through cleanName and appears only in a client-rendered group notice (an event post, not logged to room.log). Authz allows only the asking Bot's owner or the room's owner to see, answer or dismiss a room card (test added). A non-owner's answer carries origin: other, failing closed.

This is not merge authority. T3 also needs the maintainer's approval through GitHub.

[Birfy]

Verifier report (review-pr), PR #551

Verdict: PASS at 8547f5cd7ed81741bc2b6a0943634ab83bdae88f. Self-review by the owner's reviewer agent (Birfy, selfReview). Rules loaded from origin/main 17af764: AGENTS.md, LESSONS.md, docs/code-standards.md, review-pr.

Why the tip moved: the merge-queue run 39432996183 (group on 17af764) failed one test, warnings are kept, cleaned, written to the log, and read back after a restart (core/test/diagnostics.test.js), with ENOENT on logs/diagnostics.jsonl. Neither #551 nor #544 touches diagnostics. The test read the file after a fixed 50 ms pause while the log is written in the background; slowing mkdir by 80 ms locally reproduces the same ENOENT (30/30 idle runs and 30/30 CPU-loaded runs pass, so it is a disk-timing flake). Changes since the PASS at 6dfe7ba:

• bdf3757 plain merge of origin/main 17af764 (Add Always allow for a Bot or a group to tool approval cards #544), no conflicts; generate produced no further change; topics.json keeps both Add Always allow for a Bot or a group to tool approval cards #544's src/host/approvals.js and Ask a group's question in that group, not in the Bot's own chat #551's test/group-work.test.js in 0001.
• 8547f5c test only: poll for both log lines (up to 5 s) instead of the fixed pause; patch 0007 regenerated. Fails without the change and passes with it under a 80 ms and a 1.5 s slowed mkdir.

Merge review (#551 × #544 in authz.js/channel.js): #544's "always" branch in the approval authz and #551's question gate are separate endpoints; no shared state changed.

Tip SHA: 8547f5cd7ed81741bc2b6a0943634ab83bdae88f
Ran:
  - ARCH_DOCS_BASE=origin/main TZ=UTC npm run verify (Node 24.21.0) → pass (core 1129/0, social 313/0, tree 83/0, timeline 93/0, scripts 93/0, interop 37/0, live-e2e 16/0; arch-docs OK 18 files)
  - node scripts/ds-bot-patches.mjs check → pass
  - arch-docs on a simulated squash of the branch onto origin/main (no trailer) → pass
  - diagnostics test with slowed mkdir (80 ms, 1500 ms) → pass; without the fix → fail (ENOENT)
  - dev/bench.sh + node dev/smoke.mjs (DSH 0.2.0-rc.2, mock model) → pass, 42/42 steps
  - GitHub CI at tip (tests-ok and all jobs) → pass
Not run:
  - Desktop app manual check — not needed for host/test change
  - real-model run — mock model only
Verdict: PASS

No actionable findings. This report is not merge authority.

[Birfy]

Owner re-approved in chat 2026-10-20 21:53 Asia/Shanghai (originally owner-queued).