Files
LWLT-AIBOT/.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md
T

6.7 KiB
Raw Blame History

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.
  • 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