docs: integrate account authorization model

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

@@ -2,7 +2,7 @@
 
 ## Current Architecture
 
-Manual or AgentBus input is routed through task-scoped AI/Shadow/Auto/Program orchestration into one validated operation contract. The control plane owns task/session/confirmation/audit state, and the Chrome extension resolves the unique ERP object, enforces page and write gates, performs native actions, and returns action-specific evidence.
+Authenticated manual or AgentBus input is routed through task-scoped AI/Shadow/Auto/Program orchestration into one validated operation contract. The control plane owns account, task, session, task-type authorization, confirmation, audit, and archive state, and the Chrome extension resolves the unique ERP object, enforces page and write gates, performs native actions, and returns action-specific evidence.
 
 ## Main Components
 
@@ -20,7 +20,10 @@ Manual or AgentBus input is routed through task-scoped AI/Shadow/Auto/Program or
 ## Important Boundaries
 
 - AI/Program parsing and ERP resolution/execution share the final operation contract but do not share authority.
-- Platform envelope fields such as task ID, session, parser decision, confirmation, transport, and audit never enter the business operation.
+- Platform envelope fields such as task ID, account identity, authorization revision, session, parser decision, confirmation, transport, and audit never enter the business operation.
+- The product is one fixed internal organization scope with three roles. Administrators manage accounts 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 operations dashboard.
+- 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.
+- Creator and manual input-turn attribution remain durable while business input stays encrypted at rest. Routine removal is reversible archive/restore; physical purge is not an operator capability.
 - Unknown, ambiguous, unverified, or post-write-uncertain states fail closed; automatic retries must not create duplicate writes.
 - PostgreSQL is the sole required durable database/state middleware, and the production artifact provider is OSS. Redis, message queues, MongoDB, and search services are not runtime dependencies.
 - Migrations must complete before the application starts. The current ACK topology starts with one application replica because AgentBus listeners and SSE emission are process-local; horizontal scale requires explicit coordination first.
@@ -36,7 +39,8 @@ Manual or AgentBus input is routed through task-scoped AI/Shadow/Auto/Program or
 - RELEASE-001
 - SAFETY-001
 - NETWORK-001
+- AUTH-001
 
 ## Last Updated
 
-2026-08-31
+2026-09-01