docs: integrate leadership dashboard definition

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

@@ -7,7 +7,7 @@
 - The platform exposes one fixed deployment scope, not an organization-management product. Accounts use `admin`, `team_lead`, and `user` roles.
 - 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 operations dashboard's who/instruction/result projection; this does not grant cross-user task mutation, artifacts, SSE, technical payloads, 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. 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.
 - The two passenger-list import routes are Program-only and wait for exactly one `.xls` or `.xlsx` attachment before deterministic normalization.
 - 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.