IM identities and messaging: provider coordination #48

v1.3 release reconciliation — 2026-10-11

The Human confirmed full remaining IM Project #10 delivery in v1.3, not Lark-only. Lark is the first qualified slice; Slack/Discord/QQ/WeChat follow through supported, identity-checked platform paths. The v1.3 milestone is the release target authority. Closed historical issues retain their historical milestones and evidence.

Remaining lanes: #1107 installation/binding/setup/proactive reach; #1019 approvals, questions, saved rules, management destinations, feedback and native waits/recovery; #1020 inline Channel media; #1149 QQ; #1372 ordinary pairing/roles/groups/person exceptions and #1404 delegated pairing review / explicit one-time-code alternative, with new first card tracer #1414; #822 packaged installation qualification. Browser final-product qualification is also a release gate, not a new IM content authority.

Ownership is unchanged: #1031 / PR #1104, #1022 / PR #1077, #1115 / PR #1283, #1154 / PR #1204, #1156 / PR #1172 and #1118 / PR #1119 retain existing tasks. QQ media #1157–#1159 are merged into the #1156 feature branch, not default-branch delivery; they now retain that native integration blocker. No label, Project status or elapsed time transfers a claim.

The Human-approved group tracer #1406 and design #1392 are now closed after PR #1407 merged at 0c56a8b; this does not deliver cross-platform ordinary roles or #1404. New bounded Slack ordinary-chat tracer: #1415; separate existing native management tracer: #1046. #1161 is an unclaimed Slack feedback frontier after fulfilled #1040. These are candidates, not implementation claims.

Native topology repairs attach previously unparented #1107/#1149/#1070/#1118 here and #1123 under #1107. Existing valid parents and all active claim scopes are preserved; parentage is not execution blocking. #1042 now also waits for the current-product Discord binding qualification #1123. #1220 remains a real upstream continuation gate and is not cleared by changing a milestone.

No automatic merge, publication, deployment, receiver takeover or platform permission expansion is authorized. Each production-shaped tracer ends at native evidence and Human QA before breadth.

Current execution index — reconciled 2026-10-08 (Asia/Tokyo)

Project: IM Identities & Messaging. Original baseline closeout keeps v1.1; remaining v1.2 extensions retain their own issue milestones.

• Shared-source baseline: Bridge tracer: Lark mention into a shared local Channel and bound-Bot reply #634–Bridge tracer: external-only Lark report and reply into the Bot Inbox #639 are closed. Spec: Channel- and Inbox-targeted external Bridges #629 / Spec: external identities and Channel connectors — current ownership and closeout #693 now distinguish delivered baseline, closeout and superseded requirements.
• Current app-binding contract: Spec: bind a Bot to an app in one step; DMs and mentions arrive without per-conversation authorization #1107 (ADR-0142), including several apps per platform with one owning Bot per app. This supersedes the historical one-account-per-platform limit and saved-target-first assumptions where the qualified contract applies.
• Configuration placement: Spec: Profile shows shareable identity and activity; Bot and Group configuration moves into the Channel sidebar #1083; DM sidebar move External identities and External connectors move to the PersonaBot DM sidebar; standing limits join Memory files #1085 is closed, Group work Group sidebar: Wake policy and External connectors entries; Group Profile shows identity and activity only #1086 remains open.
• Conversation ingest: Spec: external conversations stream into a Channel (接入外部会话) #1144 / External conversations 1: a bound Lark app's group streams into a Channel #1145 and source names External messages show real group and sender names (Lark, Slack, Discord) #1151.
• Questions, approvals, feedback and non-blocking waits: Hub: IM questions, approvals, feedback and non-blocking waits — Lark → Discord → Slack #1019, whose remaining delivery now targets v1.2.
• Media: Spec: inline Bridge media in Channel history — reuse verified IM media #1020; QQ: Spec: QQ group chat through dsh-im with own Bot identities and media understanding #1149; WeChat residuals: Personal WeChat: align supported IM capabilities with Lark and Slack #902 / WeChat tracer: real typing indication with bounded lifecycle #911 / WeChat tracer: global behavior defaults and Profile inheritance #912.
• Public install/onboarding closeout: Spec: single-install qualified IM Provider and resumable Lark onboarding #822; publication recovery residuals: fix: npm prerelease propagation and dist-tag closeout #877.

The rest of this hub preserves historical decisions and execution records. Older paused/active goal statements and baseline descriptions do not replace the latest issue-specific claims or current accepted specifications. This organization update does not claim feature completion or authorize merge/deployment.

Feature scope

Project: IM Identities & Messaging. Milestone: v1.1. Historical cross-feature parents #20/#30 are retired.

Confirmed identity model: one PersonaBot may bind multiple IM platforms; initially one account per platform per Bot, and one platform Bot account bound to one local PersonaBot. dsh-im supplies provider transport and lifecycle; explicit PersonaBot binding belongs to BotHarness. Binding selection/UI and revocation must be part of the Human-testable path.

Shared Channel and Inbox Bridge specification — confirmed 2026-10-01

Published specification: #629 — Channel- and Inbox-targeted external Bridges. Human confirmed the testing boundary: reuse the existing Messaging command/query seam; the first real Lark Channel tracer proves shared visibility with two member Bots, existing Inbox/Wake processing and a bound responder replying under its own identity. Focused overlap/restart/revocation regressions and PR screenshots/recording remain required.

The specification adds the confirmed scenario decisions: multiple sources and explicit multiple local targets; one attention unit per Bot for the same source despite overlapping receiving paths; natural multi-Bot coordination without a mandatory dispatcher or claim lock; explicit authorized Inbox-to-Channel sharing; existing bounded harvest for offline backlog; and departure/unbind closing future intake and not-yet-started applicable effects while preserving history and already-started outcomes. External replies require the responder's own bound, authorized identity; a Bot without one cannot send externally.

First-version withdrawal scope is deliberately simple: no edit/recall subscriptions, synchronized local withdrawal or proactive recall alerts for this Bridge feature. Retain the already accepted local message. A separately supported explicit source read may report not-found/retracted; permission or transport failures are not evidence of withdrawal. This does not redefine existing Source Revision paths under ADR-0037; later recall integration must reconcile that ADR explicitly.

#629 is the product specification, not evidence of completed implementation or a replacement coordination hub. #12 and #612/#613/#614 keep their existing scope and dependencies; derive any new Channel implementation ticket as a separate runnable tracer. Publication does not resume the paused goal or authorize merging #624.

Confirmed Channel-targeted and Inbox-targeted Bridges — 2026-10-01

These are general external-information paths, not a customer-service/shared-work-queue model. Livestream comments, external chat messages, notifications and webhook-like sources may use the same Messaging entry boundary. No provider is declared implemented by this specification.

Explicit local target

• A Human configures a Bridge's authorized external source and an explicit target: an existing local Channel, or one PersonaBot's Bot Inbox. The Bridge does not fabricate a Human DM or auto-create a Group merely to retain an external conversation.
• Channel-targeted ingress becomes a canonical Source Event with Channel placement, visible under that Channel's membership. Members may read it without all being woken. Each PersonaBot may participate in many Channels and retains its own per-Channel subscription/admission and existing Wake Policy.
• Inbox-targeted ingress creates the canonical Source Event and eligible admission for the selected PersonaBot without requiring any local Channel placement. Its origin, receiving identity and reply context remain readable in the Bot Inbox and bounded source queries. App Channel/DM history visibility is independent from canonical persistence and Bot access.
• Direct-mention-only remains the default for a newly bound IM work group. An explicitly configured livestream Channel can collect every eligible viewer message; its member Bots may use count/time digest harvest, immediate, mentions or silent behavior as supported by the existing attention system.

Atomic messages, grouping and presentation

• Each viewer comment intended for independent search, author filtering, location or response retains stable source identity, sender, provider timestamp and content. Never represent the customer/viewer as the local Human or treat the Bridge as the author. Unknown fields remain unknown.
• Bridge-specific format normalization and optional batch/group presentation are configurable. Grouping several viewer messages for display does not discard their canonical identities, authors, timestamps or individual content. A digest of attention is not a replacement transcript.
• Common rendering initially shows sender/time/content plus external-source context. Specialized message parts or presentation may be added by the relevant provider capability later, without creating another content authority.
• Existing subscription/admission decides which Bot receives an Inbox Admission. Existing Wake Policy decides when admitted attention is harvested into the Orchestrator: N messages / T interval, immediate or passive behavior. Do not move admission until the digest threshold, add another provider queue authority, or equate SDK receipt with Observation/handling. This preserves the user's requirement to reuse the existing mechanism.

Receiving identity, outbound-only history and replies

• An Inbox source exposes safe provider/platform, external conversation and optional Thread references, external sender, and the authenticated receiving Bot account/principal bound to this PersonaBot. Names are presentation; opaque references and verified account identity remain authority. No credential or SDK object reaches model/Client context.
• Each PersonaBot can discover which authorized platform identities it owns through bounded Host read models. dsh-im continues to own SDK connections, credentials and account authentication; BotHarness owns the explicit PersonaBot Binding, Source Event, admission, policy and Outbox. Reading a Channel does not silently confer use of another PersonaBot's platform identity.
• Example: a Bot posts a morning report only to Lark. Local DM/Group placement is optional; canonical sent content, author/source correspondence and outcome remain available for that Bot to inspect. Its own post/provider echo does not create fresh self-attention merely to make the content discoverable.
• A Human reply on Lark may target that Bot's Inbox directly, with the original report/reply context and exact receiving identity; no mirror of the conversation in local Human DM history is required. The Bot's reply returns to the authorized original external conversation/Thread through a trusted Reply Route.
• Local Channel discussion and external reply/reaction are explicit distinct operations. Membership, capability and applicable authorization are checked at execution; internal discussion is not automatically broadcast externally. A read-only webhook or livestream source must not claim reply/reaction support it lacks.
• Retain the one-platform-account-to-one-PersonaBot identity boundary for the current tracer. Shared team identity or cross-Bot use of one account requires a separately agreed authorization design, not implicit access through Channel membership.

Collaboration scope and delivery gates

• Shared Channel visibility, ordinary replies, @mentions and existing Bot coordination are the first collaboration surface. An external message need not represent a task. No mandatory Case/ticket, designated dispatcher, claim lock or takeover workflow has been approved; the earlier customer-service options are not requirements.
• IM tracer: work-group @Bot → PersonaBot Inbox → same-topic reply #12 remains the narrow real Lark group/Thread @mention → bound PersonaBot Inbox/Orchestrator → same-source reply tracer. Channel-targeted multi-member visibility needs its own runnable follow-up, rather than widening IM tracer: work-group @Bot → PersonaBot Inbox → same-topic reply #12 or treating IM tracer: mention-only reception with bounded group and Thread context reads #612/IM tracer: configure external group admission and digest or immediate wake #613/IM tracer: Bot-selected Thread following with Human override #614 as already proving it. Livestream transport and morning-report scheduling are examples of the target model, not newly added acceptance breadth.
• Preserve per-issue E2E screenshots/recording and Human QA pauses. This specification update does not resume the paused goal, merge feat(dev): pin qualified IM provider for repeatable isolated QA #624 or implement these target paths.

References: CONTEXT.md; ADR-0036/0037/0038/0039; ADR-0074/0075/0077; #46, #12, #117, #612, #613, #614.

Existing work and first tracer

Native children:

• Research：Feishu/Lark Messaging provider contract（events / capabilities / identity） #78: minimum current Feishu/Lark official behavior and sandbox evidence.
• IM tracer: dsh-im outbound adapter and explicit Bot binding #117: outbound-first dsh-im adapter, Binding/Grant/Outbox and lifecycle path.
• IM tracer: work-group @Bot → PersonaBot Inbox → same-topic reply #12: real Feishu/Lark work-group @mention → bound PersonaBot Inbox/Orchestrator → trusted same-group/topic reply.

#46 supplies only the provider-neutral contracts these slices exercise. Current local Bot Inbox/Wake foundations have delivered evidence under #362; remaining causal/recovery breadth is #47 and is not an automatic prerequisite for every provider experiment.

Deliver the smallest real vertical slice, including explicit binding and Human operation. Obtain feedback before creating a second-provider tracer; do not prebuild a Slack/Discord branch tree.

Confirmed external Group / Thread policy — 2026-10-01

Target design confirmed after #607 Human QA. This is not evidence that external ordinary-message admission, history tools, or Thread following are implemented. #607 remains the @mention / same-Thread provider qualification; #12 remains the first integrated PersonaBot tracer. The implementation goal stays paused at Human QA.

Keep collection, admission, wake, and response separate

• Identify policy by PersonaBot + authenticated Provider Account Fingerprint + Chat identity; a Thread override additionally uses the verified Thread identity belonging to that Chat. Display names or unscoped external IDs are insufficient.
• Human authorizes the provider account and exact external groups / readable scope. Platform permissions and Bot membership bound the available capabilities. Bot-owned policy may narrow or choose participation within that scope; it cannot authorize another group, credential, or operation.
• For each authorized group, Inbox admission scope supports direct mentions only (new-binding default), all eligible messages, or disabled/unbound. Ordinary messages outside the chosen admission scope do not create this PersonaBot's Inbox Admission. Disabling/revoking the binding also closes direct-mention admission; an attention preference alone does not silence direct mentions.
• Independently choose the existing Wake Policy for admitted ordinary messages: immediate, digest, mentions, or silent. Full admission starts with digest unless explicitly overridden. Direct mentions retain the existing immediate/safe-step behavior. Reuse ADR-0074/0075/0077 semantics: its existing mentions and silent preferences still admit ordinary messages, so neither means "do not collect/admit ordinary messages."
• SDK receipt, canonical Source Event storage, Inbox Admission, Observation, successful handling, external reply receipt, and Lark's displayed read status are distinct facts. Admission/wake never forces a reply. The Bot decides whether it should participate or answer after seeing the relevant content.
• The default response behavior is to answer direct @mentions. Enabling ordinary-message Inbox admission, a digest harvest, or an immediate wake does not by itself enable unsolicited ordinary-message replies. Human can configure participation behavior; within that authorized policy the Bot chooses whether to engage. Explicit Thread following is a Bot decision to participate only in that Thread, not permission to answer elsewhere. Existing trusted Reply Route / Service Grant checks still apply.
• If a permitted ordinary event is received and retained as Channel history without admission, it stays one canonical Source Event. Do not keep an alternate transport transcript or create hidden admissions. Mention-only admission must not silently become a full provider-history mirror.

Bot-owned Thread participation

• Thread support is optional Provider Capability, not a prerequisite for group messaging. Adapt Slack, Discord and Feishu/Lark according to each provider's verified conversation hierarchy, identity, permissions and lifecycle; do not assume identical Thread semantics. QQ / WeChat adapters without a verified sub-conversation capability expose group policy and history reads only, with no artificial Thread created from quotes, replies or Bot activity. Their group Inbox/digest/immediate behavior remains usable without Thread support. No provider is declared implemented by this design.
• Within an authorized group, expose Host commands for the Bot to explicitly follow/unfollow an authenticated Thread and inspect/change its attention preference; Human can inspect and override the same policy.
• Posting one reply does not automatically follow a Thread. A Thread not explicitly followed inherits group admission/wake preferences. A followed Thread admits its eligible non-mention replies even when the group's default admits only direct mentions; it inherits the group's ordinary-message Wake Policy unless given an explicit override. Its initial ordinary-message policy is digest when no effective value exists.
• Thread overrides win over group defaults for eligible ordinary messages; direct mentions still take the direct-address path. Removing a follow override returns to group defaults, so unfollowing does not suppress messages from a group configured for full admission. A Thread override can never bypass account/group authorization or a Human restriction on following.
• Follow/unfollow is a versioned durable Messaging Policy owned by the Host, not process-local provider subscription state. Record actor and exact effective policy revision on future admissions, and recover it across restart. Changing policy does not rewrite existing admissions or silently backfill old messages.
• Preserve Chat / Thread / root / parent facts from authenticated provider evidence. Do not infer a Thread from a reply detail panel, Bot participation, or message text. A stale/mismatched group or Thread fails closed; it never retargets to the main group.
• Following a Thread without new @mentions requires actual delivery capability for its ordinary replies. If platform scopes cannot supply those events, expose that limitation rather than claiming following works. The single provider SDK connection remains owned by its Plugin/Fiber; no second listener or standalone Session is introduced.
• Client configuration and model-facing tools expose only the configured account's supported capabilities: group-only providers omit Thread controls; supported-but-missing-permission capabilities show the required setup. Provider quirks stop at the Bridge and Service Provider; Orchestrator wake handling stays source-based and does not gain per-platform runners.

Explicit history and context reads

• Even with direct-mention-only Inbox admission, expose bounded reads of the authorized group's history, the selected message's surrounding context, and the exact Thread's history when the configured account has the corresponding Provider Capability and Human-authorized read scope.
• Reads resolve authenticated account/Chat/Thread references through the Host, with pagination, result/text budgets, cancellation, stable message identities and explicit incomplete/unavailable results. "No matching message" is different from missing permission, an unsupported query, or a truncated window.
• Native provider search, local search over retained Source Events, history listing, and surrounding-context reads are distinct capabilities with explicit coverage. Local search is not search over all provider history. Do not promise provider-wide search from a history-list capability or switch to a Human's credentials when Bot identity cannot perform an operation.
• History fetched explicitly is reconciled through Messaging into canonical Source Events using account-scoped message identities; live delivery and later reads cannot produce duplicate content, admissions, attention or replies. Only content actually returned to the Bot becomes Observation. An explicit read does not automatically subscribe, admit the whole fetched history, create a new wake, or mark the provider message read. Existing admissions actually read retain the established turn handling semantics.
• Lark's official history API supports Chat and Thread containers. For ordinary groups, Chat listing returns Thread roots, and Thread replies require a Thread listing; Thread listing currently cannot use a time window. Group history also requires the stated group-message permissions and membership. Therefore "messages near X" must be implemented as a bounded query/assembly with honest coverage, not a guaranteed native around-message endpoint. Native search under the exact Bot identity still requires qualification before enabling it.

Runnable sequence after Human QA

1. Human QA for feat(dev): pin qualified IM provider for repeatable isolated QA #624's fixed-source optional provider adoption; merge only with the Human's instruction. Then finish IM tracer: work-group @Bot → PersonaBot Inbox → same-topic reply #12's authorized binding and real group/existing Thread @mention → canonical Inbox/existing Orchestrator → trusted same-source reply.
2. IM tracer: mention-only reception with bounded group and Thread context reads #612: mention-only reception with explicit bounded nearby/Thread reads under the actual Bot identity.
3. IM tracer: configure external group admission and digest or immediate wake #613: configure one group's ordinary-message admission and existing count/time digest or immediate wake; validate independently from message format and presentation.
4. IM tracer: Bot-selected Thread following with Human override #614, natively blocked by IM tracer: configure external group admission and digest or immediate wake #613: explicitly follow/unfollow one verified Thread, including unmentioned replies, restart, Human override and missing-capability behavior.

A separate runnable Channel-targeted Bridge tracer is needed to prove shared visibility with multiple member Bots; the existing three follow-ups do not prove it. Scope its concrete provider/test path before creating it or changing native dependencies. Do not substitute a speculative shared-work-item system for Channel collaboration.

Each implementation issue gets focused coverage, real end-to-end screenshots/recording in its PR, and a pause for Human QA before the next issue. No automatic merge, goal resumption or implementation is authorized by this spec update.

References: ADR-0036/0037/0038, ADR-0074/0075/0077, #12, #78, #117, #607, #624; Lark receive permissions, Lark history listing. Provider identity/permission facts must be reverified for the concrete artifact and app before implementation.

Authority boundaries

• Provider Plugin/Fiber owns SDK listener, authenticated provider identity, connection lifecycle, Capability declaration and cleanup.
• Messaging owns canonical Source Events, Channel placement, Inbox Admission, trusted Reply Route, Service Grant and Outbox facts.
• Bot Inbox/Wake Policy owns when admitted content enters an Orchestrator turn.
• dsh-im must not independently create/wake a competing Session mapping for a claimed account; loss of the exclusive consumer fails closed.
• Credentials and provider SDK objects remain Host-side; Browser Consumers use Typert/API Gateway.

Acceptance and ordering

• Research：Feishu/Lark Messaging provider contract（events / capabilities / identity） #78/IM tracer: dsh-im outbound adapter and explicit Bot binding #117/IM tracer: work-group @Bot → PersonaBot Inbox → same-topic reply #12 have their narrow automated and real-provider evidence.
• Human can bind the selected provider identity, operate the real work-group mention/reply loop and revoke it.
• Existing canonical Inbox/Session/Reply authorities are preserved across restart/replay and consumer loss.
• After the first accepted path, Human selects the next provider/slice; reliability breadth follows concrete need.

References: CONTEXT, living architecture, ADR-0026/0036–0039/0041, current dsh-im integration research. Refresh upstream mechanics before implementing.

Confirmed identity and Bridge management UI

#693 refines #629 with separate PersonaBot external identity and Channel Bridge tables, row Switches, distinct delete/unbind actions and provider-specific Modals. One identity per platform is reusable across the Bot's Channels; every Channel can have multiple source configurations, with explicit DM placement separate from Inbox-only routing. Existing #635 and #637 acceptance links this management UI. Project 10 / v1.1; publication does not resume the paused goal or claim implementation completion.