Repository navigation
RFC: merged Bot output digest and acceptance (reduce human orchestration load) #401
Description
Owner: Dev2
Child of #349 (Agent inbox board). Related: #353, #396, #149, #51, #57.
Pain point
With several Bots or sessions running in parallel, the human becomes the orchestrator: remembering which sessions exist, what each is doing, and reviewing every output one by one. Agents save typing but add coordination and review work; the only idle time is while Bots are working.
Proposal: merged output and acceptance
- Digest per task or per day: outputs from all Bots/sessions merged into one "needs your decision" list, each item with summary, evidence (diff, file, test result), and the Bot/harness/model that produced it (RFC: harness × provider (Magpie-inspired gateway, routing groups, profiles) #366).
- Accept / reject / send back in one place; a rejection becomes a follow-up task for the same Bot with the reviewer's note.
- Session map: a live view of active sessions, who owns them, what they are waiting on (extends [Feature RFC] Agent inbox board: one place for tasks, approvals and failures (personal first, team second) #349).
- Staged review: a reviewer Bot (read-only, see Safety: graders and evidence read-only for the Bot under test #398) pre-checks outputs and flags only the uncertain ones, so humans review exceptions first.
- Personal first: your Bots only. Team later: owner/assigner sees their delegated items (Team mode via groups: task layer step 1 - responsible-owner authority, FLYBOT-TASK envelope, workBotId #149).
Acceptance
- Three Bots finishing tasks in parallel produce one digest with accept / send-back actions.
- Every item links to evidence and to the decision log (Safety: decision log for rejected options (tried but not used) #396).
- A digest can be delivered on a schedule or on demand (Proactive reminders 1/3: event reminders (approval waiting, failed, finished) in app and desktop #353).
Open questions
- Digest cadence: per event, hourly, or daily?
- Who reviews in team mode: assigner or owner?
- How much can the reviewer Bot auto-approve (low-risk only)?
- Do we show a token/cost summary per item?
Process: implementation via OpenCode + Codex review.
Activity
hsliuustc0106 commentedon Oct 19, 2026
Related multi-Bot GitHub coordination: #408 (PR budget, task lock, decision card).
Birfy commentedon Oct 19, 2026
Owner decision (2026-10-19): This may proceed as a design direction. Phase work still needs triage /
agent-readyand a spec before anyone codes it.Birfy commentedon Oct 19, 2026
Constraint (from #349 owner decision, 2026-10-19): accept / reject / send back only via explicit UI controls reusing the Bot Social approval flow; a typed chat reply never counts as approval.
Birfy commentedon Oct 19, 2026
Triage on main
7b9e90b, 2026-10-19 ~12:10 Asia/Shanghai: needs-info, not agent-ready. Direction approved (owner, 2026-10-19), with the constraint that accept/reject/send back only happens through explicit UI buttons. Blocking: no phase has a spec yet. Split the first phase into an issue with expected behaviour and scope.Birfy commentedon Oct 19, 2026
Triage 2026-10-19 18:03 Asia/Shanghai (main 245be0b). Direction is approved; the blocker is a phase-1 spec. Proposal for the owner to confirm:
Phase 1 (personal, your own Bots only): inside the Agent inbox (#349), a Done list: one card per finished task with a one-line summary, an evidence link (PR/diff, file, or test result) and the Bot/model that produced it, plus Accept and Send back buttons (reusing the Bot Social approval flow; a typed reply never counts). Send back opens a note box; the note goes to the same Bot as a follow-up task. On demand only (open the inbox).
Not in phase 1: scheduled digests, reviewer-Bot pre-checks or auto-approve, cost/token summary, team view, session map.
Question: (a) phase 1 as above, built as part of #349 once #349's own phase 1 is confirmed, (b) a standalone digest page before #349, or (c) park until #349 ships? Recommendation: (a). It depends on #349, so #349 needs its go-ahead first.
Timeline: token spend per Bot, from the activity feed (ThinkFlowLab#537)
Turn the timeline window into a run report a person can paste
Birfy commentedon Oct 25, 2026
Written-by: Triage
needs-human. The direction was approved on 2026-10-19 and a phase-1 spec was proposed the same day; what is missing is the owner's yes/no on that spec, which no Bot can supply.Phase 1 as proposed: a Done list inside the Agent inbox (
#349) — one card per finished task with a one-line summary, the evidence (diff/files/test line) and which Bot/model produced it; accept / send back acts from the card.Two things to answer, then this is
agent-readyin the same round: (a) is that the phase 1 you want, (b) does acceptance live in the card only, or does it also write back to the issue/PR.Birfy commentedon Oct 25, 2026
Owner decision (2026-10-25)
Yes, proceed with phase 1 as scoped on 10-19: a merged Bot output digest with an explicit Done list, and acceptance written back to the issue/PR rather than only into chat. The Done list is the acceptance record.
Birfy commentedon Oct 25, 2026
Written-by: Triage
Decided (owner, 2026-10-25): yes to phase 1 as proposed, and acceptance writes back — the Done list is the acceptance surface, and a decision there also lands on the issue/PR the task came from.
Phase 1, now fixed: inside the Agent inbox (
#349), one card per finished task — a one-line summary, the evidence (diff/files/test line), and which Bot/model produced it; accept / send back acts from the card; the verdict is recorded where the task came from.Not phase 1: multi-user, cross-home merging, digest mail, anything that redefines what "done" means for a Bot.
Birfy commentedon Oct 25, 2026
Written-by: Dev2
Claiming phase 1. Branch
dev2/feat/401-accept-result, from currentmain75ca7ab9; PR follows in this round.Scope, per the owner decision on 2026-10-25 and Triage's reading of it: the Done list is the acceptance surface — one card per finished task with the summary, the evidence links and the producing Bot/model, Accept and Send back acting on the card, and the decision recorded on the task record. The other half the owner named (the verdict landing on the issue/PR the task came from) is not in this PR: the host has no pointer from a task to an issue/PR and no GitHub write path, so I opened #1154 for it and this PR names it in
Related.Birfy commentedon Oct 25, 2026
Written-by: Dev2
#401phase 1 done — 四项在 main412681c7上核过：#401closed/completed；#1155已合（merge0972daa7，10:41Z），squash 提交正文里Fixes #401在。changelog.d/401-accept-or-send-back-a-result.added.md在 main——一句话、用户可见（“A finished task can now be accepted or sent back right in the inbox… Accept / Send back”）。docs/subsystems/core-host.md（端点、result.links、task-send-back）、docs/subsystems/core-client.md（Done 行 + Done is the acceptance surface 不变量）、docs/subsystems/team.md（channel allow-list），三处 contents 都是 200。#1155的agent-pr与#401的agent-working（pass是 controller 的，没动）。phase 1 两半都在 main（Done 列表即验收，逐条对过）：
0972daa7：inbox.js有status === 'result'的 Accept / Send back（What should change→Send it back）、Sent back: …、card.task?.result?.links证据链接、产出 Bot 的 model；tasks.js有task-send-back（note 必填 1..500、要求result-ready、回到working并写followUp）与readLinks；authz.js/channel.js的 allow-list 都含它；index.js暴露acceptTaskResult/sendBackTask；五条新文案都有中文（i18n.test的“每条客户端文案都有中文”仍成立）。1581a5d6（#1154/#1165）：target、writeBack、recordTaskPostResult都在 main。Accept a result or send it back from the Inbox Done list (ThinkFlowLa…