docs: reconcile AgentBus and dashboard integration

.project-docs/40-domain/business-rules.md

@@ -3,13 +3,15 @@
 ## Durable Rules
 
 - `agent设计规范/business-adaptation-registry.md` is the cross-session business entry; each business maps user input, Skill/action, ERP flow, contracts, implementation, fixtures, and verification status.
-- Manual and AgentBus tasks share the same 18 machine routes, task-scoped parser mode snapshot, and organization automation rules.
+- Manual and AgentBus tasks share the same 18 machine routes, task-scoped parser mode snapshot, and organization automation rules. AgentBus intake evaluates the bound employee account's route grants rather than an administrator or whichever browser is online.
 - The platform exposes one fixed deployment scope, not an organization-management product. Accounts use `admin`, `team_lead`, and `user` roles.
 - Passwords must be non-empty but have no application-level length restriction. First login and administrator password reset do not force a subsequent password change; users may still change passwords voluntarily, administrators may reset them, and password changes revoke existing sessions according to the account lifecycle contract.
 - Administrators always hold all 18 manual business routes. Team leads and ordinary users start with no task grants, require explicit administrator allowlists, and may use normal task APIs only for their own manual tasks.
 - A known ungranted route or a non-unique/unresolved route for a non-administrator fails before parsing, plugin dispatch, or ERP execution. Authorization is rechecked for supplemental input, attachments, confirmation, automatic confirmation, and browser claim.
-- Team leads may read all manual account work only through the platform-operations dashboard. The dashboard is aggregate-first across task, person, original input, final output, time, task type, and completion state, with business-facing drill-through. Internal attention or waiting-for-input states remain unchanged in task storage but are presented and filtered as “进行中”; the leadership view exposes no separate “待跟进” category. It is not an audit log and never renders technical payloads, internal identifiers, machine-shaped historical input, or technical failure text; this visibility does not grant cross-user task mutation, artifacts, SSE, global settings, audit administration, or AgentBus access.
+- Team leads may read all manual account work only through the platform-operations dashboard. The dashboard is aggregate-first across task, person, original input, final output, time, task type, and completion state, with business-facing drill-through. Its five summary cards are display-only; the explicit task-result filter defaults to all results. Internal attention or waiting-for-input states remain unchanged in task storage but are presented and filtered as “进行中”; the leadership view exposes no separate “待跟进” category. It is not an audit log and never renders technical payloads, internal identifiers, machine-shaped historical input, or technical failure text; this visibility does not grant cross-user task mutation, artifacts, SSE, global settings, audit administration, or AgentBus access.
 - Creator and input-turn attribution are durable, business inputs remain encrypted at rest, denial audit excludes plaintext, and routine task removal uses archive/restore rather than physical purge.
+- Each non-admin employee may carry one case-insensitively unique expected ERP account and one AgentBus channel. New manual and AgentBus tasks persist an immutable assignee; only that account may confirm, claim, reconcile, resume, or submit ERP execution results. Administrators manage and inspect but do not execute another assignee's work.
+- A browser is execution-ready only when it is the account's sole fresh worker and the active ERP session matches the expected account. Concurrent fresh workers, identity mismatch, unbound channels, and historical unassigned AgentBus tasks fail closed; stale failover waits 90 seconds and organization-wide ERP FIFO remains.
 - The two passenger-list import routes are Program-only and wait for exactly one `.xls` or `.xlsx` attachment before deterministic normalization.
 - Passenger workbooks must contain exactly one complete ERP-semantic header within rows 1–100. The header may be on row 1 or follow metadata, column order is arbitrary, and only the finite approved source/ERP aliases—including `NAME`, `证件号码`, `签发日`, and `身份证`—are mapped. Unknown or unheaded data columns, duplicate semantic fields, multiple candidate headers, and non-passport identity data fail closed; the internal 13-column canonical TSV contract remains unchanged.
 - A WeChat attachment card is transport placeholder text, not file content. Only a structured `payload.attachments[]` entry can resume a roster task; missing metadata fails before ingestion and leaves the original task in `awaiting_attachment` instead of creating a new task.