Slack tracer: explicit open-channel visitor chat under optional Bot pairing #1463

Parent and release target

Parent: #1372. Specification baseline: #1371 / ADR-0165. Project #10 — IM Identities & Messaging. Milestone: v1.3.

Human-confirmed direction, 2026-10-12 (Asia/Tokyo): ordinary users need not configure pairing or management permissions merely to talk to a Bot. Reuse the existing optional Bot-scoped restricted sender policy and exact-conversation visitor exception, not a new bypass or permission store.

One observable behavior

For one PersonaBot and its current Slack App Binding, the Human opts into restricted chat and opens one already permitted public Slack channel to visitors. An unpaired human @mentions that App in the selected channel and receives an own-App reply in the original channel/thread without pairing. An intentional request in another restricted conversation still requires reviewed ordinary pairing. Closing the exception makes the next unpaired mention in that channel request pairing without model work; reopening admits only fresh eligible messages.

This is one narrow vertical slice: the Slack group sender gate, the existing conversation toggle, canonical admission and checked reply are delivered together. #1415 qualified ordinary Slack private-DM pairing only; extending restricted admission to Slack groups is part of this slice and must be explicit, not inferred as already delivered.

Product contract

Three conceptual chat-access modes, reusing existing settings rather than requiring a separate three-option control:

1. Open chat: Bot-level restricted chat is off. Reachable, enabled and otherwise permitted DMs/@mentions need no ordinary user pairing.
2. Paired users only: the Human explicitly enables restricted chat. Eligible unpaired intentional requests require review.
3. Paired users only + selected open conversations: restricted chat stays on, with an explicit visitor exception for the selected external conversation.

An open conversation grants ordinary request initiation, never administrator enrollment, approval, rule saving, delegation, private-input rights or machine Owner authority. Existing independently approved management grants remain subject to their own current checks. Exact scope is PersonaBot + current App Binding/fingerprint + authenticated workspace/conversation ID, not a display name or a local Channel mapping.

Acceptance criteria

• Reuse Messaging's canonical sender policy, pairing/Role resolver, conversation entries, existing Operational Database, exclusive qualified Provider Consumer, authenticated Host/Client seam and checked reply/Outbox. No second receiver, policy database, transport listener or fake UI-only route.
• Qualify the selected Provider's actual public-channel mention, trusted workspace/App/actor/conversation identity and original reply route. Missing identity/capability fails closed; do not infer Slack group eligibility from Slack tracer: ordinary roles and reviewed chat pairing with current-authority intake #1415's DM proof.
• Expose the existing visitor exception on the exact allowed public-channel conversation row, with visible Bot/App/channel scope and revision-checked enable/disable. Missing policy, channel-name matching, directory discovery, membership, platform defaults and a shared local Channel do not create an exception or transfer it to another Bot/App.
• Preserve open-chat defaults and existing conversation/app-binding behavior. Explicitly address previously enabled restricted policies whose UI promised only Slack DMs: do not silently widen their scope to Slack groups. Make the new supported scope clear and require an explicit Human opt-in/migration decision before applying that broader restriction.
• With restricted group chat explicitly enabled and no exception, an unpaired intentional channel mention creates only bounded pending routing/identity metadata, with zero request Source Event/Inbox Admission/model wake. The current approved ordinary pairing qualifies only its own Bot/App/actor; a Role/capability lookup never grants authority.
• Open the selected channel: a fresh unpaired @mention produces canonical Source Event/Admission, trusted visitor provenance and an own-App reply in the original channel/thread. The same actor remains restricted in another eligible channel/DM; include one already paired actor as a regression.
• Close the selected exception: the next unpaired mention returns to reviewed pairing with no model work. Reopen admits fresh requests only, never pending/blocked instruction replay. Restart preserves the explicit policy/exception; Binding pause, unbind/rebind and replacement cannot resurrect or transfer it.
• Durable conversation Block, platform reach, Binding/Bot readiness, existing current explicit Deny semantics, reception rules, mention filters, wake policy, admission bounds and rate limits retain precedence. Visitors cannot use real management controls or acquire a Role, management grant or delegation merely by speaking in the open channel.
• Preserve mention-only default. Ordinary channel chatter does not start pairing spam, independent model work or replies. If separately authorized collection is exercised, unpaired passive observations retain author provenance and do not count toward request-trigger thresholds; no collection/subscription expansion is implied.
• Focused regression covers both access levels, another channel/DM, close/reopen, restart, stale revisions, block, identity replacement, duplicate mention delivery and visitor no-management authority through production seams. Include any applicable shared-source/Bridge path so local placement cannot bypass the sender gate.
• Demonstrate the complete real Slack restricted → open channel → visitor mention/reply → another-conversation refusal → close → fresh refusal → restart sequence, correlated with Source Event/Admission/Outbox facts. Record the exact product/Provider head and qualification limits; provide GitHub-rendered baseline/changed light/dark/narrow UI and native workflow evidence.
• Update bilingual guides/Release Ledger and affected current architecture. Explain that group replies are visible to the group, pairing controls request initiation, and ordinary chat openness is not enforced arbitrary-resource ACL or private-data isolation. Use an isolated task-owned Profile and an explicitly authorized exclusive receiver window; obtain any missing Slack app/event scope approval before expansion.
• Pause after the first tracer PR for Human QA. Do not merge, publish, deploy, change production access, or start broader platform/private-channel parity automatically.

Dependencies and ownership

Delivered native baselines: #1376 (Lark open-group semantics) and #1415 (Slack ordinary DM pairing). Add both as fulfilled native dependencies; do not reopen them or expand their accepted evidence.

Coordinate without taking over #1046 (Slack native management pairing/Allow once/Reject), #1047/#1048/#1051 (questions, rules, management destinations), #1161 (feedback), #1115 (proactive posts), and #822 (packaged Provider/install qualification). Those are not prerequisites for ordinary visitor chat unless implementation finds a concrete shared blocker; record that blocker rather than widening their scope.

Deferred

Private Slack channels, multi-platform blanket qualification, automatic group discovery/opening, generalized resource ACLs, new management controls, and a broad UI redesign. No implementation claim, receiver ownership or runtime permission is granted by creating this issue.