Repository navigation
Wait tracer: Orchestrator formal requests do not stop other Inbox work #1038
Description
Parent
What to build
The same PersonaBot handles unrelated Bot Inbox attention while its Orchestrator-originated native question or tool approval waits, and later resolves only that original qualified operation.
Acceptance criteria
-
Group privacy availability: leave an original Orchestrator permission request pending for a protected private-content read/action/disclosure under existing authority. Before any decision, the original requester and another eligible group member each send ordinary permitted messages in the same Group Channel; obtain real model replies while the original request stays pending. Do not read/disclose protected content, expose private approval details, or inherit permission from ordinary dialogue. Preserve existing admission, visibility and reply policies; this is not permission to reply to every group message.
-
Repeat same-group conversation availability with an unanswered native formal question. Ordinary follow-up chat must not implicitly answer that question, approve another request or replace the original call.
-
Human rejection settles only the original operation as refused; the same PersonaBot remains conversational. Accepted approval resumes only the exact original operation after current actor/owner/scope/destination validation. Group membership does not authorize approval or public disclosure; a formal question answer does not grant permission.
-
Reuse the verified continuation/wait lifecycle rather than a second Orchestrator or executor; at most one active dispatch root remains the product invariant.
-
Leave an Orchestrator native question unanswered and obtain a real model reply to another source; repeat for an Orchestrator-owned native tool approval.
-
Preserve exact original request/operation ownership and answer acceptance; unrelated messages, historic decisions or another Session cannot inherit approval.
-
Expose waiting versus working through existing Web/attention surfaces; approve/answer reacquires applicable capacity and revalidates scope.
-
Refusal, source concurrency and callback races cannot clear a request before acceptance or execute it twice.
-
Update the accepted architecture/ADRs for the now-verified mechanism; independent Assignment success alone is not completion.
-
Test through checked Provider and authenticated management/owning service boundaries; keep existing canonical persistence and no parallel content/decision authority.
-
Retain real sanitized screenshots/step evidence and maintain the affected English/Chinese tutorial section; UI changes include matched baseline/changed light/dark evidence and no private secrets.
-
Provide the exact-version runnable review path and focused behavioral coverage; pause for Human QA before expansion, without automatic merge/deployment.
Activity
docs: clarify conversation availability during permission waits
docs: qualify native Human waits and gate continuation (#1223)
DoodleBears commentedon Oct 9, 2026
Native approval continuation follow-up
PR #1239 is merged for independent Assignment approval-capacity release/reacquisition. It does not qualify this issue's same-Orchestrator or same-group privacy behavior.
With Human authorization, the actual-model/browser/native evidence and this issue's Group privacy acceptance requirements were published to existing upstream Discussion #8916. The request retains exact original operation ownership, current actor/Grant/destination checks, refusal without silencing ordinary dialogue and no replay. Published content was read back and verified.
#1220 remains the native-capability tracker. No maintainer-supported approval continuation mechanism has yet been established, and these acceptance criteria remain uncompleted. No production upgrade or deployment occurred.
Task:
codex/local/01a11c24-31cb-7fa3-86d8-98e13f81a0b4; publication follow-up completed.DoodleBears commentedon Oct 13, 2026
Progress from claude-code task 9f51f103 (owner chose to continue this route, 2026-10-13): on main with DSH 0.2.0-rc.2 and a Profile patched to
tool-ask-usermode: timed, a real model run showed a DM question card staying answerable while the same Bot replied to an unrelated message, then settling on the late answer. A card held in a Group (after #1540) refused its late answer; #1545 fixes that and was verified with one real Group run. Not done: default enablement (timed mode is native preset configuration the product does not set), Group privacy acceptance from this issue, cold recovery, and tool approvals (#1220, deferred by the owner until upstream supports it).Generate the PersonaBot preset into the packaged product patch too
Name and describe the PersonaBot agent preset
Add the Agent presets screenshot for the product preset
Run PersonaBots on a product preset with timed questions (#1549)
DoodleBears commentedon Oct 13, 2026
Default timed questions for PersonaBots landed in #1549 (ADR-0187) on top of #1545. Remaining here: the Group privacy acceptance criteria, cold recovery of a pending question, and tool approvals (blocked on #1220).
DoodleBears commentedon Oct 13, 2026
Agent work claim
claude-code/cloud/session_01M1zEG3Sn1X9aUeUNxPixKU(not a DSH Session)claude/project-thread-9etbz0Generated by Claude Code
Keep a timed question card answerable across a Host restart (#1599)
DoodleBears commentedon Oct 13, 2026
Agent work outcome
claude-code/cloud/session_01M1zEG3Sn1X9aUeUNxPixKUGenerated by Claude Code