Files
LWLT-AIBOT/.project-docs/10-decisions/AUTH-003-leader-task-summary-notifications.md

5.6 KiB

AUTH-003: Team-lead task-summary notifications

Status

Superseded in transport and activation by AUTH-005; retained for projection/privacy history

Date

2026-09-07

Context

Team leads could inspect manual employee work through the read-only operations dashboard, but they had no bounded proactive notification path. Reusing employee AgentBus replies or fabricating inbound correlation would mix oversight with task ownership and execution routing. The fixed deployment also has no team-membership model from which a narrower supervisor scope can be derived.

Decision

  • Treat leader-summary delivery as an automatic consequence of an active team_lead identity with that leader's enabled, account-bound AgentBus channel. The scope is the fixed organization and both manual and AgentBus task sources are always included; there is no separate administrator subscription switch or source selector.
  • Project only results created after the current subscription revision starts. Include stable completed, failed, cancelled, and uncertain outcomes for tasks assigned to other non-administrator employees; never backfill history or copy transient progress.
  • Keep the summary projection read-only. It does not alter assigned_user_id, route grants, confirmation, queue position, executable SSE, browser claim, plugin result handling, reconciliation, or ERP authority, and delivery failure never changes task state.
  • Use a dedicated revisioned durable outbox rather than agentbus_deliveries. Encrypt recipient address, conversation ID, and payload at rest; expose only bounded fingerprints and counts to administration and diagnostics.
  • Derive the proactive route from AgentBus state. Prefer the latest accepted inbound from and conversation_id whose task is assigned to the current channel owner; otherwise use the channel's external_user_ref and the normal agentbus:<sender> conversation fallback. If neither exists, remain waiting until the leader's first valid inbound message. Channel rebind clears the previous external-user reference, and a route, role, ownership, account-validity, or channel change creates a new revision and cancels obsolete unsent rows instead of sending them to a stale target.
  • Keep messages deterministic and business-safe: employee username, registered business label, public task ID, submission time, generic outcome wording, and allowlisted group/order identifiers only. Do not copy original instructions, attachments, customer or traveller details, URLs, technical payloads, or technical errors.
  • Send employee replies before the smaller leader-summary batch. Proactive frames use event task.summary, stable ID leader-summary-<delivery-id>, explicit to and conversation_id, and no reply_to; inbound task.summary is reserved so an echo cannot create work.
  • Treat WebSocket delivery as at-least-once. Downstream routing should deduplicate the stable frame ID, and deleting platform data cannot retract a message already accepted by AgentBus or WeChat.

Rationale

A separate projection preserves the existing employee reply and ERP execution invariants while giving leaders timely, privacy-bounded awareness. Role-driven activation matches the meaning of the team_lead identity; current-owner route correlation, encryption, revisioned deduplication, future-only projection, and fail-closed invalidation limit accidental disclosure without requiring administrators to duplicate AgentBus routing state.

Consequences

  • Migration 020_leader_task_summary_notifications is required before the updated control plane starts.
  • The /channels administrator page observes automatic status only; it is not an arbitrary message composer and exposes neither a subscription mutation endpoint nor a live test-send endpoint.
  • The migration's enabled DEFAULT false remains an internal fail-closed storage default. Only the runtime role/channel/route reconciler activates a row, so migration 020 does not need to change.
  • Repository verification proves projection, privacy, retry, priority, echo rejection, and database behavior, but production assurance still requires an authorized rollout plus a controlled AgentBus/WeChat canary of automatic route resolution.
  • A later real team-membership model may narrow scope, but role labels alone must not be used to invent reporting relationships.

Supersedes

  • None. This extends the read-only leadership model without superseding AUTH-001 or AUTH-002.

Revision

  • 2026-09-07: Replaced the initial administrator-configured/default-off workflow with role-driven automatic activation at explicit user direction. The fixed organization scope, privacy allowlist, future-only projection, independent encrypted outbox, and no-ERP-authority boundaries remain unchanged.
  • 2026-09-09: AUTH-005 replaced the AgentBus/channel/route transport with one organization-level external Webhook and terminal one-attempt delivery semantics. The future-only scope, privacy allowlist, independent projection, and no-task/ERP-authority boundaries continue under AUTH-005.
  • .project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md
  • .project-docs/10-decisions/AUTH-002-account-scoped-execution-and-force-delete.md
  • .project-docs/10-decisions/AUTH-005-leader-summary-external-webhook.md
  • .project-docs/30-worklog/tasks/20260907-implement-leader-agentbus-copy-b7e31a94.md
  • .project-docs/30-worklog/tasks/20260907-auto-leader-summary-routing-5e8c1a73.md
  • control-plane/migrations/020_leader_task_summary_notifications.sql
  • control-plane/src/leader-notification-service.ts
  • control-plane/src/agentbus.ts
  • agent设计规范/agentbus-reply-contract.md