Hub: IM questions, approvals, feedback and non-blocking waits — Lark → Discord → Slack #1019

Source waiting notices — confirmed refinement, 2026-10-25 (Asia/Tokyo)

The Human approved prioritizing #1049's safe source-conversation waiting notice and refining the existing issues rather than duplicating the specification.

• First notification milestone: one real QQ group Source Event → one committed, still-pending tool approval → one fixed safe notice in the proven source conversation. The existing Web approval owner retains the decision and exact operation.
• Confirmed product choices: default on within an already authorized conversation, with a per-conversation off switch; first slice sends only the waiting notice, with normal replies unchanged and no extra approval-settlement notification.
• Audience separation: source conversation X receives only a minimal waiting explanation. Management destination Y retains detailed requests and authorized decisions. X need not equal Y; Binding an IM app does not configure Y or make its members Approvers.
• Reuse: deepen the existing source-bound private-input notice / Messaging Outbox path, with independent notification identity and current authority checks. Do not copy private-input notice-failure cancellation behavior into approvals.
• Honest limits: no guessed first/latest source, broadcast to all groups, private operation detail, private management link, answered marker, implicit proactive QQ post or replay of an unknown send. Notification failure cannot settle the pending approval.
• Sequencing: notification-only is an intermediate milestone, not proof of non-blocking execution. Source notice tracer: one safe waiting notice only for a proven origin #1049 retains native Lark tracer: native Human questions answered from the paired DM #1031/Wait tracer: Orchestrator formal requests do not stop other Inbox work #1038 dependencies for its full original goal; Wait tracer: Orchestrator formal requests do not stop other Inbox work #1038/Blocked: qualify native exact-operation continuation for one Orchestrator root #1220 retain same-Orchestrator tool-approval continuation. Do not delete those edges or close the full issue on notice-only evidence.
• Shared management work: Alert tracer: Bot work failures reuse the configured management route #1041 is closed/merged; Management destinations tracer: independent multi-target work-failure notifications #1492 has an existing active task for multi-target management failure notifications. Preserve that ownership. QQ native approval, additional groups/providers and cross-source availability notices remain separately qualified scope.

The detailed current source-notice acceptance lives in #1049. The dated delivery snapshots below remain historical; this refinement is a specification update, not implementation, receiver authorization, merge or deployment.

Notification destination direction — Human feedback, 2026-10-13

The Human requested a shared RBAC-style wide two-column notification modal and future multi-destination delivery across different IM platforms. #1041 / PR #1468 is revising the current qualified single-Lark-DM UI. New native child #1492 owns the bounded multi-target failure-notification tracer: first two authorized Lark management DMs, one canonical failure, independent per-destination authorization/receipt/retry/unknown outcome. It is natively blocked by #1041.

The target is a shared management destination collection with explicit event subscriptions, not a Lark-only product setting or a separate failure-only registry. Group/provider qualification and formal decision authority remain separate: #1034, #1042–#1043, #1046–#1047 and #1050–#1051 keep their native dependencies and owners. Ordinary chat pairing does not automatically qualify management notifications/controls. No unimplemented platform choices or multi-target sends are claimed by #1041's UI revision.

v1.3 release reconciliation — 2026-10-11

Remaining formal interaction/feedback/wait work now targets v1.3. Lark is the first slice, not the release's only platform. Retain #1042–#1051 and #1161's exact native dependency graph; #1031/#1104 and other active owners are unchanged. QQ/WeChat must have explicit capability-qualified equivalents or separately approved gap resolution, never assumed native button parity or silent omission.

Ordinary Role/group/person permission parity is owned by #1372 (Slack first ordinary-chat tracer #1415); existing #1042/#1046 remain native management pairing/control slices, not a second ordinary permission model. #1404 now has a Human-confirmed reviewed delegation contract: first Lark private-DM pairing card tracer #1414, then the explicit one-time-code forwarding alternative after first-flow feedback. Preserve the existing design task and do not confuse these actions with native execution approvals. Missing cross-platform children are tracked as remaining scope; create bounded implementation slices only when their contract and next acceptance path are ready.

#1042 retains #1029 and now also waits for #1123's current-product Discord app binding/contract qualification. #1036 → #1037 → #1038 and #1039/#1049 keep the unresolved #1220 continuation gates; no destructive edge removal or status-only unblocking. Saved-rule #1033 is unclaimed but its actual Lark execution/receiver window must be coordinated with #1031; #1161 and #1046 are independent currently unclaimed Slack candidates.

Historical v1.2 rows below describe previous sequencing, not the new release target. No implementation claim, receiver authorization or upstream upgrade is made by this reconciliation.

Delivery map — reconciled 2026-10-09 (Asia/Tokyo)

Feature Project: IM Identities & Messaging · Milestone: v1.2 · Parent coordination: #48.

This is the specification and delivery hub, not one implementation task. Its 23 native sub-issues remain the units of implementation and acceptance. Two baseline slices are closed; the other 21 remain open. Project status does not substitute for platform qualification, Human QA, merge or publication.

Confirmed management workflow

A community conversation X can trigger a formal question or tool approval. The committed request is delivered to the Bot's explicitly configured management conversation Y; X and Y need not be the same conversation. Ordinary clarification stays in its source conversation under normal intake policy.

• Where to deliver: choose a named private/group/supported-channel destination through the Bot's existing external conversation/connector management. Do not hardcode the source group as the administrative destination or require copying platform IDs.
• Who may decide: paired external actors need the explicit capability for this Bot and action. Receiving a card, being a group member or owning the source message grants no decision authority. The first valid accepted Web/IM decision wins; unauthorized clicks cannot become a Bot answer.
• Where to configure: follow Spec: Profile shows shareable identity and activity; Bot and Group configuration moves into the Channel sidebar #1083 / ADR-0138. The Bot DM Channel sidebar owns Approvals, Approvers and Approval destinations; External identities owns the Bot's sender accounts. Profile remains shareable identity and read-only activity.
• Failure alerts: Alert tracer: Bot work failures reuse the configured management route #1041 reuses the configured management route and delivery lifecycle. An alert is a notification, not an approval grant or a new decision authority.
• While waiting: Prototype: verify a supported native wait and continuation seam #1036–Recovery tracer: expired and restarted formal work requires a fresh Web request #1039 separately establish exact native waiting, continuation and recovery. A delivered card does not prove that unrelated Inbox work can continue.

Delivery lanes

Statuses below are a dated coordination snapshot; native dependencies and the latest issue claim/outcome remain authoritative. Closed prerequisites are retained as history.

Execution and ownership

1. Finish the existing Lark tracer: native Human questions answered from the paired DM #1031 candidate's real Lark QA with its current owner; do not create a duplicate implementation session. A prior QA window is not continuing authorization to take the shared receiver.
2. Lark feedback tracer: received and answered reactions from canonical facts #1040 is complete for the original source-bound Lark receipt/answer tracer: implementation feat(messaging): source-bound Lark receipt and answer feedback #1207 / Provider docs: coss ui landing + /docs /dev 分区 + 中英双语 + 预渲染图表 #16 and evidence docs: record guarded Lark feedback qualification #1236 are merged. Permission, real DM/group reactions, silence/failure, exact source/Admission/accepted Outbox correspondence, reconnect and same-Profile live Host restart are supported by focused tests and bounded Human QA. The later Human-supplied R3 original completes group rendering evidence. Broader residual qualification is explicitly separate: Lark QA follow-up: correlate one in-window blocked DM with checked receiver rejection #1250 covers exact blocked-marker arrival/rejection, Web diagnosis: reproduce session-maybe adapter failure and preserve first-error evidence #1251 covers the earlier Web failure’s unverified trigger, and IM identities and messaging: provider coordination #48 retains Provider qualification/pin-promotion coordination and unexercised runbook cases. Lark feedback tracer: received and answered reactions from canonical facts #1040 closure resolves that native dependency for Discord feedback tracer: source reactions, typing and generic shared activity #1045/Slack feedback tracer: received and answered reactions from canonical facts #1161 without claiming those siblings implemented. Task codex/local/01a11bd6-6350-7013-b7ae-79b7405f2fa6; all receiver windows remain closed, production Lark/Discord replies were Human-confirmed, and the Provider pin is unchanged. Completion does not publish or deploy the candidate. Receipt means durable Admission; answered means the corresponding answer was accepted for sending, not read, understood or model-turn completion.
3. The independent Prototype: verify a supported native wait and continuation seam #1036 experiment merged as PR docs: qualify native Human waits and gate continuation (#1036) #1223 after Human authorization. The same task codex/local/01a11c24-31cb-7fa3-86d8-98e13f81a0b4 continued the bounded native frontier under its #1220 claim: draft PR fix: preserve RC2 timed question cards through late replies #1227 proves the native RC2 timed-question two-settlement path with real same-Session model replies, while retaining the incompatible application card as a gap. Production stays RC1; native approval/capacity and same-group privacy are unqualified. Blocked: qualify native exact-operation continuation for one Orchestrator root #1220 blocks Prototype: verify a supported native wait and continuation seam #1036, then Wait tracer: pending Assignment approvals free running capacity #1037/Wait tracer: Orchestrator formal requests do not stop other Inbox work #1038 remain blocked; avoid duplicate implementation claims. This uses an isolated fixture, not the shared IM receiver, and does not authorize downstream production implementation or an upstream post.
4. Lark tracer: management conversation destinations with per-actor question and approval checks #1034 follows Lark tracer: native Human questions answered from the paired DM #1031. Alert tracer: Bot work failures reuse the configured management route #1041 can start from the delivered baseline, but must coordinate edits to the same route/management surface. Additional provider expansion follows Lark → Discord → Slack and each slice's native prerequisites and Human QA gates.

Historical source/package descriptions in Further Notes are publication snapshots, not current capability or delivery assertions. Preserve existing claims and Provider evidence; an implementation merge is distinct from a qualified package release and deployment.

Problem Statement

Community members cannot reliably tell whether a PersonaBot received their message, is actively preparing a reply, or actually sent an answer. A successful model turn is not proof of an external reply, and private work on another platform must not leak through public activity indicators.

When a PersonaBot asks a formal question or requests approval, the Human currently has to open the Web management surface. Simply forwarding the prompt to IM does not establish who may answer or approve, and it does not release a synchronously waiting Orchestrator. One unattended request can therefore prevent the same PersonaBot from processing unrelated Bot Inbox attention.

The Human wants one PersonaBot across Lark, Discord and eventually Slack, with useful receipt/activity feedback, configurable automatic notifications, and trustworthy questions and approvals completed in IM. Setup must not require manually entering platform user or conversation IDs or transmitting a long-lived API token. Public community chat must not confer management authority.

This is a target specification under the existing IM coordination hub #48. It complements the Channel/Inbox Bridge specification #629 and identity/Bridge management specification #693; it does not replace them. It is not evidence of implementation or deployment.

Solution

Provide a shared Host-owned question and approval contract, rendered through each platform's verified native interactions, with Web remaining an alternative management and recovery surface.

• Show 👀 after durable Inbox Admission, qualified Discord typing while preparing a reply in that conversation, generic shared Discord Working activity, and ✅ only after the platform accepts a corresponding answer for sending.
• Configure the notification destination by visible names in the PersonaBot DM Channel sidebar. A Human selects an authorized Bridge and private/group/channel target; the Host automatically delivers committed requests and reports honest delivery status.
• Let a prospective approver initiate /pair in the Bot's IM DM. Authenticated Web management reviews the genuine platform account and explicitly grants current-Bot capabilities. Pairing codes identify pending requests; they are not API credentials or bearer grants of authority.
• Let qualified actors answer questions, reject an operation, allow it once, and, with the required capability and additional confirmation, save an exact Tool Approval Rule or an explicitly broader supported rule.
• Pause only the related work. Other Bot Inbox messages must continue to reach actual model handling and replies. Waiting capacity is bounded separately from running capacity; approval must reacquire execution capacity and revalidate authority.
• Deliver Lark first, then Discord, then Slack. Capture real, sanitized screenshots during development and retain them for bilingual tutorials as well as reviewer evidence.

The first complete IM approval slice is Lark DM: pairing request → Web review → named destination selection → native tool-approval card → Allow once / Reject → canonical decision and execution result. Questions, saved-rule controls and additional renderers follow as runnable slices. A notification-only milestone is useful preparation, not completion of IM approval. Non-blocking native waits are a separate mandatory acceptance path, not something a successful card proves.

User Stories

1. As a community member, I want a receipt reaction after my message enters the Bot Inbox durably, so that I know the Bot received it.
2. As a community member, I want the receipt marker to mean received rather than read or understood, so that I can interpret it accurately.
3. As a Discord member, I want typing feedback in the conversation where the Bot is actually preparing a response, so that I can see relevant activity.
4. As a Discord member, I want typing to stop when that work completes, fails, stops or waits for a Human, so that an unattended approval does not appear to be continuous typing.
5. As a Discord member, I want a generic Working indicator when the same PersonaBot works on either platform, so that I can see its shared activity.
6. As a private Lark user, I want public activity to omit my message, identity and conversation, so that private work remains private.
7. As a community member, I want ✅ only when a corresponding answer is accepted for sending, so that a silent turn is not mistaken for a reply.
8. As a community member, I want silence, delegation and waiting to remain distinct from an externally sent answer, so that status stays truthful.
9. As a community member, I want ordinary clarification to continue in the original conversation, so that I do not need management access to explain an installation problem.
10. As a Discord member, I want to answer a clarification by replying to it and mentioning the Bot, so that the answer retains its correspondence and normal mention policy.
11. As a Lark DM user, I want to answer an ordinary clarification directly, with disambiguation when several questions are open, so that conversation remains simple.
12. As a Human managing the Bot, I want one PersonaBot across Lark and Discord, so that I can ask about authorized Discord activity from Lark without maintaining a second Bot.
13. As a Human, I want to select an authorized notification Bridge and target by name, so that I do not have to copy platform IDs.
14. As a Human, I want a private conversation, group or supported channel to be selectable as a destination, so that the interaction fits my workflow.
15. As a Human, I want receiving notifications to be separate from answering or approving, so that delivery group membership does not create permissions.
16. As a Human, I want a test notification and visible delivery status, so that I can confirm the selected route.
17. As a Human, I want the Host to notify after a request commits without depending on the model's prompt, so that reminders are deterministic.
18. As a Human, I want every distinct request to be notified immediately and individually, so that separate pending decisions are not hidden in a batch.
19. As a Human, I want duplicate deliveries of the same request suppressed, so that callback replay does not spam me.
20. As a Human, I want bounded retries only when non-delivery is known, so that transient failures can recover without blind retransmission.
21. As a Human, I want an uncertain send outcome exposed for inspection, so that the system does not claim success or send duplicate alerts.
22. As a Human, I want Bot work-failure notifications to use an explicitly configured destination, so that operational alerts are predictable.
23. As a Human, I want public source notices to omit commands, paths, credentials and private management links, so that community members do not receive private administrative details.
24. As a Human, I want a reliable originating-source association before a waiting notice is posted, so that an unrelated conversation is not treated as the requester.
25. As a prospective approver, I want to initiate pairing in the Bot DM, so that the platform supplies my genuine account identity.
26. As a Web manager, I want to review the applicant's platform, account, name and available avatar, so that I can distinguish real applicants without typing IDs.
27. As a Web manager, I want to choose question, approval and rule-saving capabilities explicitly for the current Bot, so that pairing grants only intended authority.
28. As a Web manager, I want the first administrator to require authenticated Web approval, so that the first stranger to apply cannot claim the Bot.
29. As a prospective approver, I want pairing to avoid long-lived API credentials, so that I do not expose Host access in a chat.
30. As a community member, I want ordinary authorized @bot chat to work without administrator pairing, so that community participation remains separate from management.
31. As a Human using two platforms, I want Discord and Lark accounts verified separately and explicitly associated, so that matching names cannot impersonate me.
32. As a Human using two platforms, I want to revoke one identity independently, so that loss of one account need not revoke the other separately authorized account.
33. As a Web manager, I want revocation to invalidate future decisions and old controls immediately, so that a stale card cannot preserve withdrawn authority.
34. As a Web manager, I want revocation to disable rules created under that authorization, so that the revoked identity's authority does not continue through automation.
35. As a Web manager, I want re-pairing to require fresh review without restoring old rules automatically, so that revoked permissions do not silently return.
36. As an authorized question responder, I want to answer a formal question in the configured IM, so that I can resolve it without opening Web.
37. As an authorized question responder, I want choices and free-text answers to use native controls or an explicitly correlated reply, so that the answer cannot be guessed from unrelated messages.
38. As an approver, I want Allow once and Reject in the IM request, so that I can make a bounded decision in place.
39. As an approver, I want the request to show the relevant operation and scope safely, so that I understand what my decision permits.
40. As an approver, I want allow-once to cover only the exact pending operation and arguments, so that it cannot authorize later commands.
41. As an authorized rule saver, I want an exact-call rule with a second confirmation, so that repeated matching calls can proceed deliberately.
42. As an authorized rule saver, I want broader supported rules to be visibly distinct and separately confirmed, so that broad authority is never an accidental consequence of a normal answer.
43. As an approver, I want Web and IM to share one authoritative decision, so that competing clicks cannot execute twice.
44. As an approver, I want the request message updated after resolution or expiry, so that stale actions do not appear usable.
45. As an approver, I want action acknowledgement, decision acceptance and operation completion shown as different facts, so that a responsive button is not mistaken for successful execution.
46. As a Human, I want wrong-actor, wrong-account, wrong-conversation and unsupported decisions refused, so that visible controls do not bypass authorization.
47. As a Human, I want an unanswered request to expire after the configured default of 24 hours, so that forgotten pending operations do not remain executable indefinitely.
48. As a Human, I want restart to retain work records but invalidate old live controls, so that recovery never automatically replays stale approval.
49. As a Web manager, I want to re-request interrupted work explicitly with fresh checks, so that recovery remains understandable and authorized.
50. As a community member, I want a second message answered while another task waits for a Human, so that unattended management does not stop the Bot.
51. As a Human, I want waiting requests bounded separately from executing Assignments, so that waiting does not consume all running capacity.
52. As a Human, I want resumed work to reacquire capacity and revalidate permissions, so that concurrent approvals cannot exceed execution limits or withdrawn scope.
53. As a question responder, I want the original pending question preserved until its owning service accepts my answer, so that uncertain delivery cannot lose the question.
54. As a Human, I want unrelated Inbox processing to survive restart, denied requests and notification failures, so that recovery is local to the affected work.
55. As a Lark user, I want the first complete slice to work in my private Bot conversation, so that the initial setup and approval path is easy to operate.
56. As a Discord approver, I want the same decision contract through Discord-native controls, so that switching platforms does not change permission semantics.
57. As a Slack approver, I want the same decision contract through verified Slack interactions, so that the feature extends without creating a separate approval system.
58. As a Human reviewer, I want a runnable slice and real evidence before the next expansion, so that I can evaluate behavior early.
59. As a tutorial reader, I want real screenshots of pairing, review, configuration, pending approval, decision and result, so that I can follow the setup visually.
60. As a tutorial reader, I want expired, revoked, failed and uncertain states documented, so that I know how to recover.
61. As a Human, I want screenshots and tutorials free of secrets and private messages, so that retained material can be published safely.
62. As a tutorial reader, I want English and Chinese source guides reflecting the verified UI, so that documentation matches the supported product rather than a mockup.

Implementation Decisions

• Platform and slice order. Lark precedes Discord, which precedes Slack. The first complete Lark path supports a paired DM approver, a visible-name destination, a committed native tool approval, Allow once / Reject and the canonical execution outcome. Follow-on slices add native questions, explicit saved rules and group/provider variants. Every expansion must remain independently operable; backend preparation or disconnected UI is not a completed slice.
• Existing product authorities. Reuse Messaging's Source Event, Inbox Admission, Service Grant, Provider Account Fingerprint, Binding and Outbox boundaries. Reuse the owning native-question and tool-approval brokers and existing Human Inbox projections. Cards, notifications and route settings must not become a second request, decision, transcript or execution authority. Preserve the distinction between the PersonaBot's external identity, a Bridge and an external Human's authorization.
• Application-defined authorization. Add durable pending pairing and external-approver authorization through the owning application persistence module. Its identity includes the verified platform, Provider Account Fingerprint and external sender, and its grant names one PersonaBot and explicitly selected capabilities. Store authorization revision, status and decision provenance needed for expiry and revocation. An external approver must not inherit the local Human's full authority merely by being attributed in the UI. Cross-platform association is explicit presentation and management of separately verified grants, not automatic capability propagation.
• Pairing flow. The checked Provider authenticates the envelope and determines the real DM sender before the Host creates the pairing request. Authenticated Web management reviews that request and grants capabilities. Code possession alone does not grant permission. The first applicant is never automatically promoted. Do not reuse browser login credentials, DSH API bearers or deployment credentials. Pairing does not imply other-Bot authority, approver-management rights, VPS access, native API access or group chat access.
• Pairing control intake. Unknown DM applicants need a bounded account-scoped control path after trusted Provider normalization and before ordinary Source Event/Inbox/model/Memory admission. This must use the existing checked consumer dispatch, not a second competing consumer or a model interpreting /pair. Pairing controls and credentials do not enter public Memory or developer logs. Define cryptographic challenge generation, single-use resolution, explicit expiry, sender/account bounds and attempt throttling. Exact pairing TTL and cap values are engineering choices, not Human-confirmed OpenClaw defaults; pairing expiry is distinct from operation expiry.
• Web configuration seam. Extend the existing authenticated Host Service / Typert / API Gateway boundary and the Bot DM Channel sidebar management surfaces (Spec: Profile shows shareable identity and activity; Bot and Group configuration moves into the Channel sidebar #1083 / ADR-0138). Select Bridge/account and external target using visible names backed by genuine opaque references. Display paired actors, scoped capabilities, status and revoke controls. Web login remains necessary for pairing review and the accepted restart recovery action; Tailscale reachability alone does not establish application authority. Respect existing native UI tokens, primitives, keyboard and focus behavior.
• Routes and actors are separate. A target may be a private conversation, group or supported channel. Visibility of a card, group membership, a matching display name or ownership of its message is not approval authority. Formal questions and approvals require their explicitly authorized actor/capability; ordinary source-conversation clarification retains the ordinary conversation policy. The model cannot change approval destinations or authorize a recipient. One shared initial destination is sufficient; no workflow-builder framework is required.
• Checked Provider interaction capability. Extend the existing Messaging Provider Service Definition with the minimum explicit operations/events needed for actionable send, accepted message receipt, update/expiry and qualified callback or reply handling. The normalized action carries verified actor/account, actual conversation/message, typed request/action reference, declared capability and lifecycle context. No raw SDK object, credentials or caller-asserted identity substitutes for verified provenance. Existing standalone chat handlers must not be enabled as a parallel conversation system.
• Native presentation. Use Lark interactive cards, Discord buttons/selects/modals and Slack Block Kit controls where verified. Use structured choices for choices and explicit input submission for free text. Qualified text replies are allowed only with reliable correspondence and deterministic handling of an offered decision; an LLM must not infer authorization from prose. Discord ordinary clarification keeps reply plus @bot; Lark DM disambiguates multiple questions. Exact provider message/reply references, rather than visible quote text, establish correspondence.
• Interaction lifecycle. Acknowledge native actions promptly within platform deadlines, then validate and settle outside serialized message intake. Do not wait for a later Human click under the transport queue. Acknowledgement is not durable decision acceptance or execution. Update the original request after accepted decision, cancellation or expiry; stale controls are refused even if the platform still displays them. An uncertain acknowledgement requires canonical state readback rather than repeated operation execution.
• Canonical decision gate. Check current external authorization and revision, PersonaBot ownership, account fingerprint, configured conversation, outgoing receipt/request association, live request, exact offered action, pending status and expiry before calling the existing question/approval authority. Web and IM race for the same first accepted answer. Audit the true external actor and source of the decision without granting broader local-Human privileges. Do not settle the pending question before its owning native service accepts; failed or ambiguous acceptance remains visible for repair. Approval acceptance and successful tool execution are separate outcomes.
• Default approval and rules. Default to one-time permission for the exact pending call and complete input. Rule saving requires its explicit capability and a second confirmation. An exact Tool Approval Rule matches the native tool name and complete input within the same PersonaBot role and Workspace Grant scope. The existing all-opaque rule is broader within that scope and has a separate, visible confirmation. Neither rule can broaden a Workspace Grant, provider Service Grant or other existing authority. Ordinary question answers are not approval rules. Every matched automatic call still receives its own native decision/audit fact.
• Revocation. Revoking one external authorization immediately prevents its new decisions and invalidates its outstanding controls, and disables automatic rules created under that grant. Bind rule provenance to the authorization that created it. Other valid actors can still handle the pending canonical request; separately approved sibling-platform identities remain independent. Already-started effects are not automatically reversed. Approved but not-started effects revalidate authority before execution. Re-pairing does not silently reactivate rules. Route disable, unbind and account replacement also close affected not-started effects using existing lifecycle boundaries.
• Automatic notifications. Deliver only after the canonical request commits, using an exact request reference and supported checked outbound route. Aggregate attention counts and normal Bot output callbacks are not substitutes for an exact pending-request notification. Use existing authorized outbound/Outbox behavior with stable deduplication for a frozen request, target and content. A different lifecycle notification has a distinct intent. Send every distinct request individually and promptly; do not combine separate requests, while honoring platform limits and bounded waiting capacity.
• Notification outcomes. Expose pending, accepted delivery, known failure and Unknown Outcome/needs-inspection through Web. Retry known non-delivery only with a finite policy. Ambiguous provider results stop automatic retry pending reconciliation or Human repair. Request expiry/approval remains authoritative regardless of alert delivery. Receiving a card or notification never approves the operation. Include no login token or approval bearer in links.
• Disclosure and causation. Detailed management requests go only to explicitly authorized management destinations with suitable visibility. A public source gets at most one minimal waiting notice, omitting operation details, paths, credentials and private management links, only after trustworthy request-to-source causation exists. This originating-source extension is deferred beyond the first Lark slice; a batch's first or latest source is not proof of causation. Generic activity never includes private chat content or participants.
• Receipt and completion feedback. Receipt reactions follow durable Inbox Admission, not mere SDK receipt and not Observation. Corresponding ✅ requires a known accepted outbound answer associated with that source. A silent turn, delegation, waiting notice or generic lifecycle completion is insufficient; provider acceptance does not imply the recipient read the answer. Track source-specific reply/activity correspondence under parallel work and reconnect, with bounded best-effort feedback that cannot decide or block work.
• Typing and presence. Discord typing belongs only to actual reply preparation for that qualified conversation. Stop that work's typing on wait, stop, failure or completion, retaining other active work's indicators. Shared Working follows canonical Bot activity across platforms, with only generic presentation. Respect platform update limits and clean up lifecycle ownership after disconnect/disposal. Emoji write capabilities and any required external app permissions are verified separately.
• Non-blocking wait contract. Waiting formal work cannot hold the only Orchestrator processing path or consume running Assignment capacity. Add bounded waiting capacity separate from running capacity and reacquire a running permit after an accepted decision, before current authorization and operation validation. New work continues through the existing Bot Inbox/Wake/Delivery Policy; do not create a second agent mailbox or scheduler. Distinguish native tool approval, native user question and an Assignment Ask; the latter already follows the addressed request/report lifecycle in ADR-0059.
• Native mechanism is a feasibility gate. The inspected DSH RC1 native question/approval brokers await live decisions; a waiting independent Assignment can leave the Orchestrator available while still consuming concurrency. No verified native pause/detach/resume API has been established for preserving a synchronous pending call while that same Orchestrator runs another turn. Prototype or verify the supported native seam, or obtain upstream support, before claiming this requirement implemented. Cancellation is not suspension. A fresh operation after expiry/restart cannot inherit approval for an old call. OpenClaw's async exec behavior is a reference, not proof of DSH capability. Reconcile changes with ADR-0045, ADR-0059, ADR-0071 and the living architecture once the mechanism is validated.
• Expiry and restart. Default formal operation wait is 24 hours, bounded by actual live-owner validity; loss or cancellation of the native owner invalidates it earlier. Expiry is never permission. Persist recoverable work and request/audit references; do not persist a fabricated live continuation. After restart old cards are unusable, unrelated Inbox handling recovers, and authenticated Web management explicitly requests fresh validation. Do not automatically execute, replay or reuse historical approval.
• Alerts and scope. PersonaBot work-failure alerts belong to the explicit per-Bot route. Host/VPS-down alerts require an independently running monitor and a separate server-level configuration/authorization boundary; the stopped Host cannot notify. This feature does not silently borrow another Bot's credentials or convert existing monitoring into a universal Bot route. Integrating independent monitoring into the same UI is a follow-on concern, not the first Lark acceptance path.
• Durability and diagnostics. Canonical requests/decisions remain with their existing owning services and native SessionEvents. New routing, external authorization, rule provenance and necessary notification correlation are durable application facts; transient UI/transport activity stays lifecycle-owned. Derived Web/Human Inbox views read these facts. Record bounded structured lifecycle diagnostics—request reference, phase, refusal and outcome—without secrets or full private payloads.
• Evidence and tutorials. Capture real UI states during each slice, not reconstructed mockups. Retain pairing entry, Web review, named destination, pending card, allow/reject, actual execution result, expiry/revocation and recovery, with a step index and source/version provenance. Use demo data where possible and omit secrets, actual challenge codes, credential-bearing links and unrelated private messages. Match before/after viewport, locale, data and theme; verify Web light/dark. Publish maintained English and Chinese source guides with those real images through the existing docs generation workflow. PR evidence must render for reviewers and distinguish local tests, native acceptance, external delivery, Human QA, merge and deployment.

Testing Decisions

• Highest product seam, already confirmed. Test through the existing checked Messaging Provider boundary and authenticated PersonaBot management command/query surface, into the existing owning question/approval service and observable provider receipt/result. The Human confirmed this production-shaped chain during the interview; no new interview or repeated approval is needed to publish it. New interaction/authorization capabilities extend that boundary rather than introducing competing content or approval APIs. Behavioral public-seam tests precede internal helpers; do not assert private field layouts or mirror implementation code.
• Prior art. Reuse existing tests for checked inbound and original-source replies, canonical Outbox/Unknown Outcome, native Human Inbox questions and tool approvals, Tool Approval Rules, Assignment wait/collaboration, accepted-answer retry, account replacement and restart. Reuse the isolated pinned-DSH development and existing real IM qualification/evidence approach. Fixtures can test hostile envelope/control shapes, but are never reported as real platform messaging or model execution.
• First Lark path. Through the real packaged Provider, create a DM pairing request, review it in authenticated Web, grant current-Bot approval capability, select the named DM route and cause a real model/native tool approval. Allow once from the Lark card; prove the canonical native decision and actual authorized tool result. Separately deny and prove the operation does not start. Retain real screenshots and reproduce the path through the user-facing controls.
• Pairing and scope. Verify genuine sender/account identity, pending expiry, single-use resolution, repeated requests, bounded attempts/capacity, Web-only review, no first-applicant promotion, no ordinary model/Memory admission of control secrets, and no implicit cross-Bot/API/approver-management capability. Two equal display names are different accounts; independently verify and revoke two platform identities.
• Adversarial decisions. Refuse wrong actor, account, Bot, conversation, message/request reference, decision kind, authorization revision, revoked capability, expired or cancelled owner, duplicated click and changed operation arguments. No refusal creates a rule, resolves another request or executes a tool. Shared-group visibility alone cannot approve.
• Competing surfaces. Race Web and IM, duplicate callbacks and two authorized approvers against one request. Exactly one canonical accepted decision wins; stale surfaces show that result. Test failed pre-acceptance writes and uncertain post-acceptance outcomes without losing the original ask or executing twice.
• Saved-rule behavior. Test capability gating, explicit second confirmation, exact native tool/input/role/Workspace Grant match, separately confirmed all-opaque scope, mismatches, revocation and no implicit broadening. Revoking the creator authorization disables its rules; re-pairing does not restore them. A question answer cannot create a rule.
• Notification behavior. A request not yet committed cannot send a management prompt. A duplicate committed request emits one frozen notification; different requests produce separate immediate notices, without batching. Test target change, unbind, account replacement, platform limits, known-unsent bounded retry, uncertain outcome, result inspection and request expiry. Notification failure cannot authorize, discard the request or stop another Inbox item.
• Wait acceptance through a real model. On one PersonaBot bound to Lark and Discord, leave an Assignment native tool approval pending and prove a new admitted message receives an actual model reply. Repeat with an Orchestrator-owned native question; the first result is not proof of the second. Keep formal requests unanswered to prove processing, rather than only admissions or API health. Follow-up Slack receives its own provider qualification.
• Capacity and continuation. Fill bounded waiting capacity and demonstrate unrelated permitted work still acquires running capacity. Approve several waits and prove the running limit is respected. Revalidate revoked/changed authority before start. Verify exact native pending-owner/session/call correspondence and show that cancellation, a historical request or a restarted Session cannot act as a suspended continuation.
• Expiry, stop and restart. Exercise the 24-hour expiry deterministically, owner cancellation, shutdown with pending work, cold restart, stale action rejection and explicit fresh Web re-request. Preserve historical attribution and work references; prove no automatically replayed effect and that unrelated Inbox processing resumes. Inspect provider results and canonical state after ambiguous transport recovery.
• Feedback. Verify 👀 follows durable Admission, and ✅ follows a corresponding platform-accepted answer. No ✅ for silence, delegation, a waiting notice, failed delivery or an ambiguous outcome. Parallel sources and multiple Bot jobs must not exchange reactions. Feedback API failures do not decide or block the request.
• Typing and shared activity. Validate actual Discord typing, shared generic Working for Lark/Discord activity, update limits, overlapping work, waiting transitions, reconnect, stop and disposal. Public indicators expose no private content or actor/target names. Lark reaction tests require the verified write capability and appropriate app setup.
• Provider-native interactions. Lark, Discord and Slack each require actual send/action/update qualification and deadline-compliant acknowledgement; one platform's callback fixture is not proof for another. Verify input/choice submission, receipt correlation, private refusal where supported and old-card disabling. Do not hold the provider intake queue while awaiting a later click.
• UI and tutorials. Verify named pickers, permissions, route testing, empty/pending/success/refusal/revoked states, accessible labels, keyboard/focus, light/dark and relevant widths in the real Web shell. Capture matched baseline/changed screens and meaningful interaction states, verify published images render, and retain captions/version/step index for English and Chinese tutorials. Sanitize before publication; never call a mockup a verified screenshot.
• Slice completion. The first Lark path is not complete until pairing, review, card, decision and actual result are operable with the negative-path checks. The complete feature additionally requires native non-blocking acceptance, feedback and separately qualified Discord/Slack paths. Provide a PR and runnable review path per slice, obtain Human QA before broadening, and keep merge/deployment as separate explicit actions.

Out of Scope

• Creating a second PersonaBot for administration, or changing the chosen model/provider, reasoning defaults, server purchase, repository visibility or existing deployment credentials.
• Treating a first pairing applicant, community member, card recipient, emoji reaction or model-inferred “yes” as an administrator.
• Sharing native Web/API bearer tokens through IM, automatic cross-platform identity matching, profile-wide implicit permissions, external approver delegation or full staff RBAC for every DSH subsystem.
• Broadening ordinary-message subscriptions, admitting every public message, changing Discord's normal mention-only response policy, Slack DM/private-channel qualification by assumption, or changing authorized history visibility merely to add approval controls.
• Borrowing another Bot's sender identity or Service Grant, reopening the Provider's standalone conversation bridge, or introducing a second content store, Inbox, decision authority or tool executor.
• Synchronized edit/recall, moderation bots, new chat providers beyond the agreed sequence, universal QR authentication, an arbitrary workflow builder or generalized notification batching.
• Automatically undoing already-started effects on revocation, automatically resuming approvals after restart, or converting cancellation into an unverified native suspension.
• Immediate public source notices without trustworthy causation; that extension follows the first committed-request/owner-DM path.
• Automatic creation of wide approval rules, semantic “similar command” matching, or skipping provider/Workspace/native authorization because an IM action was accepted.
• Full server-monitor management, monitoring credential migration or automatic expansion of existing VPS alert routes in the first Lark slice.
• Claiming the feature shipped, modifying live services, widening app scopes, claiming implementation work, creating a speculative provider ticket tree, merging or deploying merely because this specification is published.

Further Notes

• The Human confirmed the design through Q1–Q24 on 2026-10-06 (Asia/Tokyo), including Lark → Discord → Slack and ongoing screenshot capture for tutorials. The earlier Web-only formal-decision proposal and Web-issued bearer-redemption default were explicitly superseded. Default allow-once remains; explicit rule-saving capabilities were retained. Every independent request is notified individually; distinct requests are not batched.
• This specification has no hidden request for another interview. Engineering must verify its concrete DSH/Provider mechanism and document feasibility results; those checks do not reopen settled product choices.
• Source inspection covered Core worktree 3aba2699187785629d37dd813012c85f9efba3af, local main reference 72a1642f0175e60fd43f0d1bd80a0e9dd0883c90, Provider worktree ff86996ccc74a0effae328c29fa7242546521ba7 and Provider main aaaae50dc66df0c6c202293e40123b195a9c8d35. Refresh current source and running package versions before implementation. Inspected native brokers still await live decisions and lack an external paired-actor authorization mapping. Generic Bot output excludes requests without normal message origin; committed-request delivery needs an exact post-commit hook. Checked Lark external mode does not yet expose actionable card decisions; Discord requires qualified native interactions, and checked Slack Socket Mode handles event callbacks but not the needed interactive action path.
• Existing Slack public-channel work under IM identities and messaging: provider coordination #48 has completed qualification for its own stated scope; this specification adds questions/approvals and does not claim those native controls are already supported. Private/DM and other additional capabilities require their own real proof. No capability or permission expansion follows from an old success screenshot.
• Relevant existing decisions: ADR-0006 (credentials), ADR-0028 (native UI), ADR-0035–0045 (composition, Messaging/authority and independent Assignments), ADR-0059 (Assignment collaboration) and ADR-0071 (Human Inbox projection). Delivery remains a sequence of runnable tracer bullets, not a horizontal framework build. Record accepted architecture changes and integrate the living architecture during the owning implementation changes.
• Primary precedents: OpenClaw pairing, OpenClaw approval delivery and authorizers, OpenClaw plugin permissions, Discord native interactions, Lark Channel SDK, and Slack Block Kit. These establish platform patterns and comparative designs, not a universal industry standard or a DSH async continuation API. OpenClaw's explicit first-owner bootstrap exceptions are not adopted here.
• Coordination: IM identities and messaging: provider coordination #48; related specifications Spec: Channel- and Inbox-targeted external Bridges #629 and Spec: external identities and Channel connectors — current ownership and closeout #693. Milestone v1.2. This hub indexes the confirmed specification; select bounded work from the child issues' readiness and native dependencies. It does not create a claim or resume another task's paused work.

Feedback qualification follow-up

• Lark QA follow-up: correlate one in-window blocked DM with checked receiver rejection #1250 tracks the exact blocked-DM delivery/rejection proof independently of completed Lark feedback tracer: received and answered reactions from canonical facts #1040.
• Web diagnosis: reproduce session-maybe adapter failure and preserve first-error evidence #1251 tracks the observed native Web assembly failure; no IM/Companion causal attribution is established.
• IM identities and messaging: provider coordination #48 retains broader Provider qualification and pin-promotion coordination. These follow-ups do not reopen the completed source tracer or create new production-window authorization.