Lark tracer: delegated pairing review from group and private-DM cards #1414

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.

Parent: #1404; delivery Hub #1372, Project #10. Follow the Human-confirmed contract in #1404. This is an implementation slice, not a takeover of #1019/#1031/#1033/#1034 or other Provider work.

Observable behavior

A person with explicit pairing-review authority receives a new restricted-chat applicant's review card in the authorized source group or their trusted Lark DM, chooses an existing Role within their current delegable authority, and clicks Approve pairing. The applicant is paired, receives a notice to ask again, and only their new valid question starts model execution.

Scope

• Add explicit review-pairing and separate delegation Allow/Deny through current Role/group/person resolution and real settings. Existing records default to no new authority; direct authenticated Web Human input stays unchanged.
• Deliver bounded durable request cards automatically to all current eligible reviewers with qualified private routes within the same Bot/current App Binding, plus one shared source-group card for group-origin applications. The group-only path needs no DM. No generic native management-route replacement.
• Card shows applicant/conversation/expiry, explicit eligible Role selection, Approve pairing and Reject. A Role's management and onward-delegation grants must fit the reviewer's current delegation ceiling. Use the existing qualified Provider/exclusive Consumer with distinct pairing callbacks.
• Canonical transaction rechecks actor/route/scope/revisions/current authority. First Web/IM winner commits; synchronize every delivered card to final state and remove controls, including across restart.
• Applicant approval notice requires re-asking. Pending intake, controls and rejected requests create no model work/request Admission/wake/Task or stored old executable instructions.

Acceptance

• Host → canonical persistence → authenticated settings → qualified Lark Provider → reviewer card → actual pairing → ask-again → fresh model reply → revoke is one runnable production-shaped slice.
• Public tests exercise ordinary/management Role limits, independent use/delegation, explicit Deny, multiple reviewers/Web races, stale/copied/wrong-actor callbacks, lost review/delegation, Role edits, rebind, duplicate/restart and missing/unknown DM delivery.
• Independent Reject and delayed unauthorized card are verified with real rendering and canonical decision evidence; no native execution approval behavior is repurposed.
• First real isolated Lark workflow receives explicit Human feedback before adding the alternative code redemption or other Provider variants. Coordinate a new exclusive receiver window before start and stop the receiver afterward.
• ADR/living architecture and bilingual ledgers describe actual new authority; complete-flow before/after light/dark/narrow UI evidence and exact-head explainer accompany the PR.

One-time codes remain in parent #1404 for the next feedback-gated slice. This ticket deliberately delivers the Human's primary click-to-authorize flow first; tests passing alone do not complete it.