50 lines
3.4 KiB
Markdown
50 lines
3.4 KiB
Markdown
# 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.
|
||
|
||
## 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`
|
||
- `.project-docs/30-worklog/tasks/20260901-account-system-impl-d4e7a2.md`
|
||
- `.project-docs/30-worklog/tasks/20260901-leadership-dashboard-c4b9e1.md`
|