Repository navigation
Description
Parent
Specification: #1371
What to build
A Human creates an ordinary role in the Bot DM sidebar and enables restricted sender admission for the Bot/app. An unknown user sends a DM or mentions the Bot in an otherwise allowed Lark group. They receive a fixed pairing notice; the Human reviews the verified identity and assigns the role, including an empty management-capability set. Approval sends a fixed notice asking the person to submit a new question. Only the new message reaches the model with trusted sender/source references; the Bot can query that person's current permissions on demand through a read-only Tool and can receive a checked original-conversation reply. Revoking pairing prevents the next request from starting the model.
This is the first usable vertical path, not a backend-only role foundation. This slice includes the minimal single-person permission Tool, while the three model-facing directory queries and complete first-slice acceptance remain with #1374. Start with ordinary roles; assigning/editing structured management powers follows in slice 3 while preserving existing explicit grants.
Acceptance criteria
- Through real sidebar controls and the authenticated Host service, create a named role with natural-language behavior text, enable restricted sender policy explicitly, approve/reject a pending request with one role, and revoke an approved pairing. A role with no management capabilities is valid.
- Use the existing application-defined Messaging owner, canonical Operational Database, qualified exclusive Provider Consumer/fanout, and checked reply/outbox lifecycle. No second listener, authority store, global identity merge, or email integration is introduced.
- Unknown intentional DM/mention or explicit pairing controls are handled deterministically before request Inbox Admission, wake/Task creation, or model work. Ordinary collected group text does not create pairing requests. All applicable ingest, Bridge, followed-thread, and shared-source paths obey the sender gate; none bypass it via default-traffic alternatives.
- Fixed pending and success responses do not include the blocked request body or depend on the LLM. Do not retain that body as deferred executable input, Memory, prompt input, or batch trigger material. Approval never replays or backfills it.
- Duplicate delivery and repeated requests reuse bounded pending state and respect explicit expiry, rate/capacity limits, and stale review revisions. Notification retries are bounded and checked; a failed success notice leaves approval intact and does not launch work.
- Pairing uses the Bot, current Binding/account identity, and provider-authenticated namespaced sender. It works across otherwise allowed conversations in that same verified scope, survives restart, and does not inherit across another Bot/app or a replacement Binding.
- On a fresh approved request, attach compact trusted sender/Bot-app/source/conversation references separately from untrusted content and reply through the checked original route. Do not automatically inject role, permission text, or policy snapshots into each Inbox turn/system prompt. Preserve per-author provenance and never grant batch-wide authority from the last or most privileged author.
- Provide a read-only single-person permission Tool through the existing Messaging owner/service and model-facing Consumer. It resolves a trusted scoped actor reference and returns current pairing status, effective role/behavior text/capabilities where applicable, policy revision, and query time. Wrong-scope/ambiguous/unavailable references produce explicit bounded results/errors; querying someone grants no right to act as them. Visitor/unpaired/revoked results grant no management power.
- Ordinary chat does not force a Tool lookup. Stable behavior guidance asks the Bot to query the actual requester for a new permission-sensitive request, refresh historical results rather than assume they are current, and defer the governed operation if the lookup is unresolved. This remains behavioral policy; deterministic sender admission and Host management checks do not depend on model compliance.
- Public Tool tests verify canonical current-state reads, scope and attribution, revoked/unpaired status, and explicit failures. The real role-governed request demonstrates the model using the permission Tool, without mailbox credentials or enforced arbitrary Shell ACLs. Historical role-injection tests/evidence alone do not satisfy the revised contract.
- Existing Binding/platform restrictions, blocks, reception, collection, mention rules, and Wake Policy remain independent. Restricted requests and unpaired passive messages do not contribute trigger/batch wake counts; any existing explicitly authorized context read remains passive.
- Migration preserves explicit legacy management capabilities and conversation/app defaults without silently making old approvers conversation members, resetting blocks, or turning missing policy into an open-group exception.
- Focused public Messaging-intake tests with a recording Bot Agent Adapter prove zero model starts, zero request admissions, and zero wake/Task contributions for unknown/revoked requests; include cross-scope, restart, stale review, and notification failure behavior. Client interaction tests prove ordinary-role review needs no admin capability.
- Provide an isolated real Host/sidebar and test Lark DM/group demonstration: unknown request → Human review → fixed re-ask notice → fresh real model reply plus an on-demand permission lookup for a role-governed request → revoke → blocked next request. Retain bounded lifecycle evidence and matched UI evidence using repository conventions, with no secrets or production receiver takeover.
- Record the accepted authority boundary in the domain/living architecture and required bilingual release documentation as part of the implementation, using native in-harness UI tokens and primitives.
Confirmed revision — 2026-10-11
The Human approved trusted per-message identity plus on-demand current-permission lookup, replacing mandatory role/permission injection. This is a spec update for the existing active #1373 task, not a new claim or implementation takeover. Preserve earlier pairing/re-ask/revoke QA as evidence for those behaviors; additionally verify the revised model context and permission Tool. #1374 retains the three directory views and the complete first-flow Human gate.
Blocked by
None (can start immediately after publication). Reuses delivered #1027 and #1029; it does not wait on the separate native-question or save-rules roadmap.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
- StatusShow more project fieldsDone
Activity
DoodleBears commentedon Oct 10, 2026
Agent work claim
Claim: codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76 — starting the ordinary-role Lark pairing tracer.
codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76(not a DSH Session)codex/1373-lark-ordinary-pairingLive preflight: no existing comments/claim, assignees, open related PR or native blocker on #1373. #1374 remains gated by this slice; #1375/#1376 retain the #1374 Human acceptance gate. Existing #1031/#1022/#1115/QQ and other task claims are preserved. No questions, save-rules, management destinations, other-provider expansion, email integration, merge or deployment in this scope.
DoodleBears commentedon Oct 10, 2026
Agent progress — real Lark pairing and on-demand permission lookup
codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76; claimcodex/1373-lark-ordinary-pairing; head63a35f37; Draft PR #1377bridge_sender_permissionsreads current authority on demand. Native Session Tool call/result and checked Lark replies verify the permission-sensitive behavior.22780414passed 3954 tests. The superseded permission run was cancelled; the next run failed formatting in the added test array. Formatting is corrected and locally checked. Current-head CI is running. No current-head full pass is claimed yet.Clarify pairing instructions for an already connected receiver
fix(messaging): preserve legacy intake and bound pairing review
26 remaining items
feat: refine pairing tables and persist compact audit times
fix: keep pairing table headers compact
docs: verify baseline and publish complete role editing flow
docs: verify baseline and publish complete role editing flow
DoodleBears commentedon Oct 11, 2026
Agent work outcome — compact UI / audit-time revision handed off
codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76; state: handed-off. Same task/claim, no other owner's work taken over.c1e5dfc9.DoodleBears commentedon Oct 11, 2026
Agent work claim — approved merge integration
Merge main into Lark pairing; preserve ledgers and unique ADR identity
DoodleBears commentedon Oct 11, 2026
Agent work outcome — completed. Task codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76. Human accepted real Lark pairing/re-ask/new-message/revocation and revised UI, then explicitly authorized merge. PR #1377 merged into main at 78a57f1 from exact head 9adbf60; refreshed full CI passed: https://github.com/BotHarness/DeepSeekBot/actions/runs/38117221532 . Integration preserved both bilingual ledgers and renamed the unmerged pairing ADR to 0165. Before/after and full UI flow evidence remain in the PR body. Current CodeRabbit status is rate-limited, not a new independent review. No deployment/receiver restart. Separate users/groups and one-time pairing-code design remains #1392/#1404.