Repository navigation
Lark tracer: role changes and current-capability approval checks #1375
Description
Parent
Specification: #1371
What to build
A Human edits a Bot role's behavioral permissions and explicitly supported management capabilities or reassigns an approved person to another role. The Bot's next on-demand permission lookup for that person returns the current policy and revision; historical Tool Results are not rewritten and the next ordinary message does not receive an automatic policy snapshot. For the already qualified Lark private approval path, only a person with the current role's relevant structured capability can make a native Allow once/Reject decision. An ordinary conversational person can still ask questions but cannot decide an approval.
Acceptance criteria
- Reuse the Bot DM sidebar to edit role name/text and explicitly selected supported capabilities and to change a person's single assigned role through revision-checked authenticated commands. Empty management capabilities remain valid; no hierarchy, combined roles, or per-person override is added.
- Fresh permission Tool calls and directory queries report current role/policy revisions after an edit or reassignment, including two lookups in the same Session before/after the change. Historical Tool Results remain dated evidence; request context contains trusted identity rather than automatically injected role permissions. Stale reviews do not overwrite newer state; restart and revoke/rebind preserve current authority.
- Changing or removing permissions is observable on the next lookup, without promising immediate refresh of model history or interruption of an in-flight arbitrary Shell command. A failed/ambiguous lookup prompts deferral of the governed operation as behavioral policy. Host admission and actual management decisions independently re-check current state even if the Bot never calls the permission Tool.
- On the existing qualified Lark DM approval path, check the actual authenticated actor, Bot/app scope, current pairing/role, destination, request/receipt correspondence, offered action, and native lifetime immediately before accepting the decision.
- Demonstrate an actual native call decided Allow once and a separate rejected call. A person with conversational access but no relevant management capability cannot settle the native request, even if they see/copy a card or claim authority in message text.
- Remove an approver's capability or revoke/reassign them after card delivery; their delayed decision is refused. Preserve existing first-valid-decision, duplicate-click, Web/IM race, owner-invalidity, and restart fences.
- Behavioral text, quoted administrators, visible controls, mixed-author batches, cron work, and Assignments do not mint management capability. Approval authority does not imply automatic standing approval for future commands; native execution roles and external-user roles remain distinct.
- Preserve legacy explicit management grants without broadening them or silently deriving ordinary conversation eligibility from them. Ordinary access and operational powers do not grant each other implicitly.
- Integrate capability checks for management actions actually supported when implemented. Do not claim the stored answer/save-rules names are delivered paths. Native questions, new saved-rule controls, group destinations, and other providers remain with Lark tracer: native Human questions answered from the paired DM #1031/Lark tracer: explicitly saved approval rules and creator-authorization revocation #1033/Lark tracer: management conversation destinations with per-actor question and approval checks #1034 and existing sibling tickets; do not duplicate or take over those claims.
- Public intake/review/approval-service tests and focused Client interaction tests verify current-state changes and actual native outcomes; provide a runnable isolated Host and real Lark private-control demonstration with sanitized UI evidence.
- Update affected architecture and bilingual operational documentation, explicitly distinguishing behavioral prompt policy from deterministic management authority.
Blocked by
#1374: scoped directory and completed first-flow Human acceptance. This is the agreed delivery/feedback gate. The existing private approval baseline #1029 is already delivered; open questions/save-rules/group-management work does not block this narrow slice.
Activity
DoodleBears commentedon Oct 10, 2026
Product follow-up — reviewed one-time Lark pairing code
The Human confirmed this request concerns Lark/IM, not an email integration: let a currently authorized reviewer select/approve an applicant's role and issue a pairing code; the applicant supplies it to the same Bot so reviewers need not open the Web UI and more than one eligible reviewer can help.
Keep this as a proposed extension to this issue's review/reassignment scope, after #1374's complete Human acceptance; it does not widen the current #1373/#1374 implementation claim or clear the native dependency.
Proposed Host boundary: a deterministic reviewer action checks current structured review authority, selects one existing role, and issues a short-lived single-use unpredictable code bound to the pending request/revision, original trusted platform actor and current Bot/App/Binding. Store a verifier rather than the plaintext code, bound failed attempts, and reject expiry, revocation, a changed Binding or a different actor. A public request reference is a locator, not an authorization code; forwarding it alone cannot approve anyone. Querying or knowing another person's permissions does not confer reviewer powers.
Redeeming a reviewed code uses trusted Provider identity and no LLM/Inbox Admission/wake/Task for that control message. It does not replay the blocked request: persist the pairing and send the same fixed re-ask notice. Preserve the reviewer/decision/redemption audit trail and existing Web review as another explicit entrance. Natural-language role policy remains prompt behavior, not Shell/resource ACLs.
The exact reviewer command, recipient-facing format, approval/issuance timing and notification destination still need the implementation specification. Existing #1027/#1029/#1019 management authority remains the seam; no global reusable admin key or new DSH-native RBAC is implied.
DoodleBears commentedon Oct 10, 2026
Agent work claim
codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76(not a DSH Session)codex/1375-lark-current-role-authorityRechecked the live issue, comments, native dependency, sub-issues and open implementation PRs. No competing #1375 claim found. Native #1374 remains open; implementation is stacked on its reviewed candidate, not treated as merged. The Human accepted #1374's complete first-flow evidence and requested continuation after CI; its current-head full CI passed. No dependency removal, merge or deployment is implied.
The proposed one-time pairing-code extension remains a recorded follow-up pending its exact reviewer command and issuance contract. This claim starts with the approved Role/current-capability slice; it does not take over questions, saved rules or group-management destinations.
DoodleBears commentedon Oct 10, 2026
Role changes and qualified private decisions — real QA
codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76; active claim.approve/rejectin the Bot DM sidebar. Query A returned Role revision 3, policy revision 3 and both capabilities.approval/decidedsequence 219, Tool Result 220 succeeded and printed the one requested marker. Separate Reject: sequence 242, Tool Result 243 reported rejection and never printed the rejected marker. These were real model calls and real Lark callbacks, not simulated card clicks.shell-ready, and no new rendered error was observed.card.action.triggercallback and published independent test version 0.0.3; no GitHub secrets or production App changes.Validation: 21 focused pairing/approval/Client tests plus the active-run current-role test passed; the final Client cancel-reset build was verified with 4 Client tests. Lint, typecheck, format check, build and bilingual Release Ledger checks passed. Full current-head CI passed. Implementation is PR #1387, commit
91dca444; review/merge remains outstanding.Private before/after shell evidence is retained locally. The real Profile contains private platform identifiers, working paths and earlier conversation history; the browser provides no file-attachment/upload capability for publishing a safely cropped comparable pair. Review the runnable flow in an isolated Profile: open Bot DM sidebar → IM roles and pairing → Edit role → select only Allow once/Reject → Save; select another role for an approved person → Assign selected role → refresh permissions/directory; configure the qualified DM destination and compare actual Allow once/Reject and delayed refusal. No raw private screenshot is attached publicly.
16 remaining items
feat(messaging): apply current Role authority to private decisions
feat: retain audit times through role edits and reassignment
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.5f17c512.DoodleBears commentedon Oct 11, 2026
Agent work claim — approved stack integration
Merge reviewed parent integration into current role authority
DoodleBears commentedon Oct 11, 2026
The previously recorded one-time IM pairing-code proposal now has focused design follow-up #1404, a native child of #1372 in Project #10. It remains needs-triage pending its exact reviewer capability, delegation and command/issuance contract; #1375 completion covers only the approved Role/current-capability slice. No code-flow implementation or acceptance is claimed.
DoodleBears commentedon Oct 11, 2026
Agent work outcome — completed for the reviewed Role/current-capability slice. Task codex/local/01a12734-8226-7ae3-8d1b-db08bde64d76. PR #1387 merged into main at 11776ea from exact head d865ee8; refreshed full CI passed: https://github.com/BotHarness/DeepSeekBot/actions/runs/38117292952 . The Human accepted real revision-aware Role edits, reassignment, Allow once/Reject, removed-capability stale refusal, restart and revised full UI flow, then authorized merge. Native #1374 and its complete Human-feedback gate are fulfilled. One-time IM pairing codes are separate unimplemented design #1404; external users/groups are #1392. CodeRabbit skipped the stacked base and is not a new independent review. No deployment/receiver restart.