# AUTH-001: Fixed-scope account authorization

## Status

Accepted; superseded in part by AUTH-002 and AUTH-004

## Date

2026-09-01

## Supersession Note

AUTH-002 supersedes this ADR's organization-wide ERP FIFO and archive-only removal clauses. AUTH-004 additionally supersedes administrator task creation, all-route possession, task-wide reads, dashboard access, task transitions, and force-delete authority, plus the manual-task-only leadership-dashboard scope. The remaining fixed-scope account, employee route-grant, owner-isolation, AgentBus assignment, browser-worker, and ERP-identity decisions remain active. Current execution-queue and employee deletion behavior must be read from AUTH-002; current administrator and dashboard boundaries must be read from AUTH-004.

## Context

The platform already required login but treated the fixed deployment scope as a shared administrator workspace. It needed administrator-maintained accounts, per-user task isolation, a team-lead oversight role, creator/original-input audit, explicit task-type eligibility, and a deterministic employee-to-AgentBus-to-ERP execution binding without introducing tenant or organization administration.

## Decision

- Keep one internal `organization_id` deployment scope and do not expose organization selection or tenant administration.
- Use three roles: `admin`, `team_lead`, and `user`.
- Superseded by AUTH-004 for task access: administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus channels, parser routing, and employee grants, but hold no business routes and do not enter the task data plane.
- Password entry points require a non-empty value but impose no application-level minimum or maximum length. The platform does not force a password change on first login or after an administrator reset; voluntary self-service change, administrator reset, and session revocation remain supported. The historical `must_change_password` column is compatibility-only and is cleared on password writes.
- Team leads and ordinary users use normal business APIs only for tasks assigned to themselves, whether created manually or through AgentBus. 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.
- Superseded in scope by AUTH-004: give team leads a dedicated read-only platform-operations dashboard over every durably assigned manual and AgentBus task, using immutable assignment as the employee dimension. Administrators do not access this dashboard.
- 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.
- Keep leadership summary cards display-only. Status changes are explicit filter-form actions, default to all results, and retain the business-facing merge of internal attention states into “进行中”.
- Superseded by AUTH-002 for removal behavior: preserve creator and input-turn attribution with encrypted input at rest. The original decision exposed archive/restore only and did not expose irreversible purge.
- Bind each enabled AgentBus channel to exactly one active `user` or `team_lead` account with a configured, case-insensitively unique expected ERP account. Administrator accounts remain unbound from employee channels.
- Execute inbound AgentBus work under the bound employee identity and that account's route allowlist. Persist one immutable task assignee for both manual and AgentBus work; confirmation, browser claim/result, reconciliation, and resume require that employee assignee. Administrators cannot invoke those transitions.
- Allow only one fresh browser execution worker per account. Heartbeats must match the account's expected ERP identity; a second fresh worker or mismatched ERP session fails closed, and automatic failover begins only after the prior worker is stale.
- Superseded by AUTH-002 for queue scope: the original decision preserved organization-wide ERP FIFO serialization. Employee worker binding chose who could execute but did not authorize parallel ERP writes.

## Rationale

This model fits a single-organization deployment while enforcing least privilege, owner isolation, business-facing oversight, and auditable denial without weakening the existing ERP confirmation and write-safety gates.

## Consequences

- Migrations 015–018 must be applied before the updated control plane starts.
- Existing accounts originally migrated as administrators; under AUTH-004, administrator identities are management-only and newly created team leads/users require explicit task grants.
- Existing historical `must_change_password=true` values do not restrict login, reads, or mutations; no destructive migration is required to retire the forced-change flow.
- Permission revocation can block an existing task at confirmation or browser claim; administrators cannot attempt either transition.
- Existing unbound AgentBus channels and historical unassigned AgentBus tasks remain non-executable until an administrator completes an explicit employee binding; no assignee is inferred from whichever browser is online.
- Extension `0.5.164` is the first release carrying the expected-ERP identity probe required by this worker contract.
- Cross-user operational visibility is intentionally separated from normal task mutation and technical debugging surfaces.
- Dashboard acceptance is based on leadership questions, explicit filters, and business-readable drill-through, not on reproducing task history or technical audit records.

## Supersedes

- The implicit administrator-only, organization-shared account behavior of the earlier control-plane baseline.

## Revision

- 2026-09-07: AUTH-004 removed administrators from the task data plane and expanded the team-lead dashboard from manual-origin work to all durably assigned manual and AgentBus tasks.

## Related

- `control-plane/migrations/015_account_roles_and_task_audit.sql`
- `control-plane/migrations/016_team_lead_operations_dashboard.sql`
- `control-plane/migrations/017_user_business_route_authorizations.sql`
- `control-plane/migrations/018_agentbus_account_workers.sql`
- `.project-docs/30-worklog/tasks/20260901-account-system-impl-d4e7a2.md`
- `.project-docs/30-worklog/tasks/20260901-leadership-dashboard-c4b9e1.md`
- `.project-docs/30-worklog/tasks/20260902-integrate-all-push-c93a7f21.md`
- `.project-docs/10-decisions/AUTH-004-admin-management-plane-and-leader-oversight.md`