Design: reviewer DM pairing cards and one-time Lark/IM codes #1404

Human-confirmed group-only requirement — 2026-10-11

The Human explicitly requires the simple only a group, no private DM scenario to work in the first Lark slice. This supersedes the earlier DM-first/group-later description for #1414.

• An intentional group @ creates the restricted applicant's existing metadata-only pairing request. Deliver a pairing card to that authorized source group; all members can see it, but only a trusted actor with current review-pairing authority may select a Role/approve/reject. Eligible reviewer DMs remain additional delivery when available; a DM route is never a prerequisite for group pairing review.
• A group card's Role choices are current candidates, not an authority grant. Each operator's actual current delegation ceiling and the exact selected Role/request revision are checked at selection and at approval. No group membership, ordinary pairing, copied card or visible button grants review permission.
• The selected Role and its onward delegation must fit the reviewer's delegation ceiling. Bind decisions to the same Bot/current App Binding and original card receipt/conversation. The first canonical Web/IM decision wins; all delivered copies show the final state. Group selection and confirmation must preserve which operator selected which Role rather than approving another person's intervening selection.
• Approval is announced in the source group and asks the applicant to send a new valid question. Pending request/card callbacks do not create model work, Admission, wake or Task, and no earlier instruction is replayed. No private conversation bootstrap is required.
• The group card displays only pairing identity/reference/Role/expiry/result metadata. It must not echo the applicant's blocked instruction or private native tool arguments. Group visibility is accepted by the Human.
• Real group-only acceptance includes one authorized and one unauthorized participant, actual successful pairing/fresh reply and refused unauthorized controls, delayed authority loss and restart.

After Lark is operable and accepted, extend the same pairing/permission semantics through each platform's independently qualified Provider. QQ/Discord group-only support must not assume private DM or native card parity.

Pairing is distinct from formal question/permission requests. Native questions and execution approval can use a qualified private destination; explicitly selected group management destinations are handled under #1019/#1034 and existing platform children. Chat pairing does not implicitly grant Answer/Approve/Reject or publish private requests to the source group.

Origin and delivery scope

Parent: #1372, Project #10. Original proposal: #1375 follow-up. This is Lark/IM pairing, not email. Keep #1019/#1031/#1033/#1034 ownership and gates; native questions, saved rules and management-group destinations are separate work.

Human-confirmed direction — 2026-10-11

• Permit granting an existing Role with management capabilities, subject to the reviewer's explicit current delegable permission ceiling.
• Automatically notify eligible pairing reviewers in their trusted private DM destinations.
• Use an interactive pairing review card as the primary Lark flow: choose a permitted Role, then click Approve pairing or Reject. Approval commits pairing directly; the applicant receives the fixed notice to ask again. The card flow does not require a code round trip.
• Retain reviewer-issued one-time codes as the alternative for forwarding an authorization to the applicant. Code generation is an explicit reviewed action, never automatic approval on request arrival.

These are product directions for new delivery, not claims that the current release supports pairing cards, review delegation or codes. #1406/#1407 only delivered group/person permission resolution and existing native execution approvals; both product #1407 and Provider #20 are now merged.

Concrete authorization contract

1. Add an explicit review-pairing capability. Existing native execution approve / reject, ordinary chat eligibility and possession of a DM destination do not imply it.
2. Represent the ability to use a management capability separately from the ability to delegate it. Role, authorization-group and person exception sources resolve current delegation Allow minus any applicable delegation Deny. Old records default to no delegation; no existing approver becomes a pairing reviewer implicitly.
3. A reviewer may grant an existing Role only if its structured management capabilities and its onward-delegation ceiling are subsets of the reviewer's current delegable capability set. A plain behavior Role with no management/delegation grants requires only review-pairing.
4. Card selection, direct approval and code issuance/redemption recheck trusted actor, current Bot/platform/App Binding, current reviewer authority, selected Role revision and exact pending request revision. A forwarding recipient, changed Role, removed group, personal Deny, revoked reviewer or replaced Binding cannot use a delayed card/code.
5. IM review can only approve/reject the exact pending ordinary-chat applicant and assign one existing Role. It cannot create/edit Roles, alter groups or grant direct Web Human/Super Admin machine authority. The authenticated Web Human retains existing full authority and Web review.

First tracer: Lark group-only and private-DM review cards — #1414 (native child)

1. An unpaired intentional DM/@ creates the existing metadata-only pending request and applicant notice. No model, request Inbox Admission, wake or Task is created.
2. Messaging finds currently authorized review-pairing actors within the same Bot/current App Binding who have a platform-qualified private DM route. It sends a separate private request card to each eligible reviewer with a qualified route. For a group-origin request, it also sends one shared pairing card to the authorized source group; reviewers without DM routes can decide there. Group membership/display names never infer private destinations or decision authority.
3. The card shows applicant identity, originating conversation, expiry and permitted Role choices. The reviewer selects a Role and explicitly clicks Approve pairing, or Reject. There is no hidden default management Role. Bounded choices/pagination must remain usable when many Roles exist.
4. Host checks current authorization at the actual canonical transaction. The first valid Web/IM decision wins; duplicate, stale, forwarded and racing callbacks have no additional effect.
5. Persist the reviewer/decision and notification receipt in the existing Messaging-owned Operational Database. Update all delivered copies to the final state with action controls removed; shared card updates must be visible to recipients, including after restart. A visual update failure cannot undo or repeat an accepted pairing decision.
6. On approval, notify the applicant to ask again; only a fresh subsequent valid message can start model execution. Original blocked input is never retained for later execution. Rejection remains metadata-only.

Use qualified Provider card rendering/callback normalization under its existing exclusive Consumer. Keep pairing-card actions distinct from native execution Allow once/Reject. No second listener or parallel approval authority. Existing automatic-native-approval destination selection remains unchanged; this flow routes its own pairing notices to eligible private reviewers and does not implement #1034 management-group routing.

Delivery is bounded and durable: deduplicate repeated request/card callbacks and per-reviewer notices; revalidate before send, refuse stale routes, record unknown send outcomes without blindly creating duplicate cards, and retain bounded private diagnostic evidence without request content or secrets. When no eligible deliverable reviewer exists, leave the request pending in Web; never auto-approve.

Alternative code flow after the first card feedback

• Reviewer deliberately chooses the existing Role and issues a short-lived one-time code; the code is delivered privately to the issuer for forwarding, rather than broadcasting usable codes to every reviewer before authorization.
• Bind the verifier to the exact applicant/request/revision, reviewer decision, Role revision and Bot/platform/current App Binding. Store a verifier, never plaintext; keep raw codes out of logs, model context and published evidence.
• Applicant redeems through a deterministic private DM or intentional group @ control using the same trusted identity. Wrong actor/scope, expiry, replay, revision changes and lost current reviewer delegation are refused. Success commits ordinary pairing and sends the same ask-again notice.
• Issuance and redemption create zero model work, request Inbox Admission, wake or Task. Define concrete encoding/TTL/attempt/rate/unknown-delivery handling in the next narrow tracer after Human feedback on the card flow; no speculative sibling implementation starts before that gate.

Verification and completion

• First native implementation child delivers settings grant/delegation → real restricted applicant → automatic reviewer DM card → explicit Role choice/approval → persisted pairing → applicant ask-again → fresh model reply → revoke/delayed refusal. Include independent Reject, multiple reviewers/Web races, wrong actor/copied card, changed Role, delegation loss, explicit Deny, rebind and restart.
• Reuse Messaging, Operational Database, the qualified exclusive Provider Consumer and authenticated API Gateway/Client seam. Natural-language Role policy remains behavioral, not an arbitrary Shell/resource ACL.
• Public behavior tests plus real isolated Lark rendering/callback/decision evidence and first-tracer Human feedback are required. Earlier accepted pairing/native approval QA does not qualify this new flow.
• Arrange a fresh exclusive QA App receiver window before connecting. Prior IM tracer: continuous authorization groups and explicit person exceptions #1406 window is released; other active owners and production stay untouched.
• Update ADR/living architecture and bilingual release ledgers with implementation. PR follows task trace, risk, complete workflow before/after screenshots and exact-head reviewer-accessible explanation.

Slack and Discord also have interactive message components at the platform level; their BotHarness Provider qualification remains with their existing tickets. This first tracer qualifies Lark only.