AUTH-001: Fixed-scope account authorization

Status

Accepted

Date

2026-09-01

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, and explicit task-type eligibility 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.
Administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus/system tasks, and all manual tasks. They always hold all 18 registered manual business routes.
Team leads and ordinary users use normal business APIs only for their own manual tasks. 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.
Give team leads a dedicated read-only platform-operations dashboard over all manual account tasks. It is an aggregate-first leadership view across task, person, original input, final output, time, task type, and completion state; every aggregate may drill into the same bounded business-facing task projection.
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.
Preserve creator and input-turn attribution with encrypted input at rest. Routine removal is archive/restore; irreversible purge is not exposed.
Keep AgentBus authorization as a separate administrator-controlled channel boundary.

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–017 must be applied before the updated control plane starts.
Existing accounts migrate as administrators; newly created team leads and users require explicit task grants.
Permission revocation can block an existing task at confirmation or browser claim even when an administrator attempts the transition.
Cross-user operational visibility is intentionally separated from normal task mutation and technical debugging surfaces.
Dashboard acceptance is based on leadership questions 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.

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
.project-docs/30-worklog/tasks/20260901-account-system-impl-d4e7a2.md
.project-docs/30-worklog/tasks/20260901-leadership-dashboard-c4b9e1.md

3.4 KiB Raw Blame History Unescape Escape