69 lines
6.7 KiB
Markdown
69 lines
6.7 KiB
Markdown
# 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`
|