docs: integrate leadership dashboard definition

.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md

@@ -19,7 +19,8 @@ The platform already required login but treated the fixed deployment scope as a
 - Administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus/system tasks, and all manual tasks. They always hold all 18 registered manual business routes.
 - Team leads and ordinary users use normal business APIs only for their own manual tasks. New non-administrator accounts start with no task-type grants and may invoke only routes explicitly granted by an administrator.
 - Re-read route authorization before intake and relevant task state transitions. Known denied routes and unknown/non-unique routes fail closed before parsing, plugin dispatch, or ERP execution.
-- Give team leads a dedicated read-only operations dashboard over all manual account tasks. It exposes who acted, the business instruction, and the readable business result, but not parser/executor payloads or mutation authority.
+- Give team leads a dedicated read-only platform-operations dashboard over all manual account tasks. It is an aggregate-first leadership view across task, person, original input, final output, time, task type, and completion state; every aggregate may drill into the same bounded business-facing task projection.
+- Keep the leadership dashboard separate from audit and engineering diagnostics. It never renders parser/executor payloads, internal identifiers, codes, machine-shaped historical input, or technical failure text; those values are replaced by a concise business explanation without changing the underlying audit evidence.
 - Preserve creator and input-turn attribution with encrypted input at rest. Routine removal is archive/restore; irreversible purge is not exposed.
 - Keep AgentBus authorization as a separate administrator-controlled channel boundary.
 
@@ -33,6 +34,7 @@ This model fits a single-organization deployment while enforcing least privilege
 - Existing accounts migrate as administrators; newly created team leads and users require explicit task grants.
 - Permission revocation can block an existing task at confirmation or browser claim even when an administrator attempts the transition.
 - Cross-user operational visibility is intentionally separated from normal task mutation and technical debugging surfaces.
+- Dashboard acceptance is based on leadership questions and business-readable drill-through, not on reproducing task history or technical audit records.
 
 ## Supersedes
 
@@ -44,3 +46,4 @@ This model fits a single-organization deployment while enforcing least privilege
 - `control-plane/migrations/016_team_lead_operations_dashboard.sql`
 - `control-plane/migrations/017_user_business_route_authorizations.sql`
 - `.project-docs/30-worklog/tasks/20260901-account-system-impl-d4e7a2.md`
+- `.project-docs/30-worklog/tasks/20260901-leadership-dashboard-c4b9e1.md`