AUTH-002: Account-scoped ERP execution and explicit force delete

Status

Accepted; superseded in part by AUTH-004

Date

2026-09-03

Supersession Note

AUTH-004 supersedes this ADR's administrator-wide task read model and administrator force-delete authority. Per-assignee FIFO, assignee-only executable routing, reversible archive/restore, and lifecycle-independent force delete remain active for the owning team_lead or user account.

Context

AUTH-001 bound each task to one employee account and one matching ERP browser worker, but retained organization-wide ERP FIFO and archive-only operator removal. In production, one blocked or stale account could therefore hold every other employee's work behind the same queue. Administrator-wide task visibility also shared paths with executable event delivery, allowing an administrator page and plugin to observe or attempt to process another employee's task. Finally, an active or waiting task could fail the archive gate and then could not be permanently removed, leaving the same blocked state in place.

The user explicitly required independent execution across accounts, FIFO only within the same account, strict separation between administrator inspection and employee execution routing, and an authoritative force-delete operation that is not blocked by task state.

Decision

Use immutable tasks.assigned_user_id as the ERP execution queue and routing partition.
Serialize browser claims with an advisory transaction lock scoped to organization plus assigned account. Active-execution checks, confirmed FIFO selection, and queue positions include only that account's tasks.
Preserve deterministic FIFO and at most one active ERP execution for one assigned account. A different assigned account's active, queued, stale, or uncertain task does not block this account and does not occupy its queue position.
Superseded by AUTH-004 for administrators: task reads and executable SSE, browser claims, plugin results, and cleanup commands are available only to a team_lead or user session matching the immutable assignee. Administrators have no task read model.
Keep archive and restore as the reversible routine workflow, with their existing lifecycle-state guard.
Expose separately confirmed force delete through the single-task and bulk-delete APIs. Force delete intentionally has no parse, handoff, queue, or ERP-execution status gate, while requiring the owning employee account under AUTH-004.
On force delete, remove the task, task-owned records through existing cascades, and task outbox entries atomically. Retain only a minimal non-content task.hard_deleted audit marker, then request OSS artifact cleanup and owner-plugin local cancellation/cache cleanup after commit on a best-effort basis.
Force delete removes platform state only. It cannot roll back an ERP write that already happened, and the operator warning must state this explicitly.

Rationale

The execution account is already the durable link between the platform user, AgentBus channel, expected ERP identity, and browser worker. Using it as the serialization boundary preserves same-account write safety without coupling unrelated employees. Separating inspection feeds from executable feeds prevents broad administrator visibility from becoming accidental execution authority. Keeping archive and force delete as distinct operations provides both recoverability and a deliberate escape from irrecoverably blocked platform state.

Consequences

Two employees with distinct assigned accounts and valid matching workers may execute concurrently; tasks for either employee remain FIFO and single-active within that employee's queue.
An uncertain ERP result blocks only the same assigned account's later claims unless an authorized operator explicitly force-deletes the platform task or resolves it through the existing reconciliation workflow.
Superseded by AUTH-004: administrators may neither inspect nor force-delete business tasks. The owning employee session alone receives executable task events, plugin results, and cleanup commands.
A force-deleted task and its task-owned evidence cannot be restored. The retained audit marker proves the destructive action without retaining task content.
No database migration or Chrome extension source/version change is required. The control-plane and platform UI must be deployed together before relying on the behavior.
Runtime acceptance requires separate management and employee sessions plus two employee workers, including cross-account concurrency, same-account FIFO, administrator task-API denial, and owner-performed waiting/active force deletion.

Supersedes

AUTH-001's organization-wide ERP FIFO clause.
AUTH-001's archive-only removal and unavailable-physical-purge clause.

All other AUTH-001 account, role, route-grant, ownership, dashboard, session, AgentBus, and expected-ERP-identity decisions remain active.

AUTH-004 is the current authority for administrator task isolation and leadership-dashboard scope.

.project-docs/10-decisions/AUTH-001-fixed-scope-account-authorization.md
.project-docs/30-worklog/tasks/20260902-per-account-queue-hard-delete-a6d9f2c1.md
.project-docs/30-worklog/tasks/20260903-finalize-account-routing-7c4e2a91.md
control-plane/src/task-service.ts
control-plane/src/server.ts
LianSyn-platform/app.js
.project-docs/10-decisions/AUTH-004-admin-management-plane-and-leader-oversight.md

5.4 KiB Raw Blame History