docs: integrate automatic leader summary routing

.project-docs/20-architecture/data-flow.md

@@ -16,7 +16,7 @@
 | Internal attachment download | Credential-free HTTPS URL | Bounded in-memory workbook bytes | Internal/private DNS answers are allowed; the selected address is pinned, every redirect is revalidated, and URL/host/IP/bytes are omitted from logs. |
 | Operational diagnostics | Service, request, task, parser, AgentBus, attachment, database, and cleanup stages | Structured stdout/stderr and bounded Docker logs | Correlation identifiers, codes, outcomes, and durations only; no secrets or business payloads. |
 | Platform operations oversight | Manual task creator, encrypted instruction history, and readable outcome | Team-lead/administrator leadership projection | Display-only summaries plus explicit filters drive an aggregate-first task/person/input/output/time/type/completion view; list reads are bounded to one read-only connection and hydrate full details only for the current page. |
-| Team-lead task summary | Future stable manual/AgentBus task outcome for another non-admin employee | Separate encrypted durable outbox → leader-owned AgentBus channel → verified WeChat conversation | Administrator-configured and default-off; employee replies are sent first, summary frames use stable IDs and explicit routing with no `reply_to`, and delivery failure never changes task state. |
+| Team-lead task summary | Future stable manual/AgentBus task outcome for another non-admin employee | Role/channel reconciler → current-owner encrypted route → separate durable outbox → leader-owned AgentBus channel → WeChat | Automatic for active team leads with a usable route; employee replies are sent first, summary frames use stable IDs and explicit routing with no `reply_to`, and delivery failure never changes task state. |
 | Browser worker selection | Immutable task assignee | One fresh account-bound browser connection | The heartbeat must match the account's expected ERP identity; a second fresh worker or identity mismatch is non-executable, with failover only after staleness. |
 | Account-scoped ERP queue | Confirmed task assignee | Assigned account's browser worker | Organization-plus-account advisory locking preserves FIFO and at most one active execution for that account; another account's active, queued, stale, or uncertain work is outside this queue. |
 | Executable event and result routing | Immutable task assignee | Matching authenticated platform page and plugin | SSE history/live events, claims, plugin results, and browser cleanup commands never use administrator-wide visibility and fail closed when the authenticated account is not the assignee. |

.project-docs/20-architecture/system-overview.md

@@ -2,7 +2,7 @@
 
 ## Current Architecture
 
-Authenticated manual or account-bound AgentBus input is routed through task-scoped AI/Shadow/Auto/Program orchestration into one validated operation contract. The control plane owns account, channel owner, immutable task assignee, account-scoped execution queue, browser worker, session, task-type authorization, confirmation, audit, reversible archive, explicit force-delete behavior, and default-off team-lead task-summary subscriptions. The Chrome extension verifies the expected ERP account, resolves the unique ERP object, enforces page and write gates, performs native actions, and returns action-specific evidence.
+Authenticated manual or account-bound AgentBus input is routed through task-scoped AI/Shadow/Auto/Program orchestration into one validated operation contract. The control plane owns account, channel owner, immutable task assignee, account-scoped execution queue, browser worker, session, task-type authorization, confirmation, audit, reversible archive, explicit force-delete behavior, and role-driven automatic team-lead task-summary projection. The Chrome extension verifies the expected ERP account, resolves the unique ERP object, enforces page and write gates, performs native actions, and returns action-specific evidence.
 
 ## Main Components
 
@@ -24,7 +24,7 @@ Authenticated manual or account-bound AgentBus input is routed through task-scop
 - The product is one fixed internal organization scope with three roles. Administrators manage accounts, channels, and all 18 manual routes; team leads and users are owner-scoped for normal tasks and require explicit per-route grants. Team leads additionally receive a dedicated read-only, manual-task-only platform-operations dashboard. Administrator-wide visibility does not permit executing another account's assigned ERP work.
 - Account passwords are accepted when non-empty without an application-level length rule. First-login forced password changes are disabled; voluntary changes and administrator resets still revoke the relevant sessions, while the historical `must_change_password` column remains compatibility-only storage.
 - The leadership dashboard is an aggregate-first projection across task, person, original input, final output, time, task type, and completion state. Summary cards are display-only; filtering is explicit and defaults to all results. List reads use one bounded read-only database transaction, SQL prefiltering, selective historical-message hydration, and full detail projection only for the current 20-row page. Its drill-through stays business-facing; technical payloads, internal identifiers, machine-shaped historical input, and technical failure text remain in separate authorized audit/engineering surfaces.
-- Team-lead task summaries are a separate administrator-configured read projection, not an extension of dashboard, task, or ERP authority. Each default-off subscription uses the leader's own enabled AgentBus channel and a verified encrypted target, covers only future stable outcomes for other non-admin employees from explicitly selected manual/AgentBus sources, and never copies raw instructions, attachments, customer/traveller data, URLs, or technical errors.
+- Team-lead task summaries are a separate role-driven read projection, not an extension of dashboard, task, or ERP authority. An active leader with an enabled owned AgentBus channel is automatically subscribed to future stable manual and AgentBus outcomes for other non-admin employees. Routing comes from the current owner's latest valid inbound route or channel external-user reference, remains encrypted, fails closed when unavailable or stale, and never copies raw instructions, attachments, customer/traveller data, URLs, or technical errors.
 - Authorization is enforced in server and service paths, not by navigation visibility. A denied or unresolved non-admin business route stops before parsing, plugin dispatch, and ERP execution; creator authorization is rechecked at confirmation and browser claim.
 - Each enabled AgentBus channel owns one active non-admin employee account. Inbound work uses that account and route allowlist, persists the same account as immutable task assignee, and is returned only to that account's executable feed. A team-lead channel may additionally carry its leader's lower-priority proactive summary outbox; those rows use explicit destination/conversation routing and never become executable task traffic.
 - Each employee account has one expected ERP identity and at most one fresh browser execution worker. Mismatched ERP identity, concurrent fresh workers, unbound channels, or unassigned tasks fail closed. Browser claims, active-execution checks, and confirmed FIFO are serialized per immutable task assignee, so one account cannot block or occupy another account's queue.