docs: reconcile account-scoped execution decisions

This commit is contained in:
inman committed 2026-09-03 09:56:19 +08:00
1 parent d09b3032c0
commit b7bb1d6b52
11 files changed
+101 -24

No files matched your search

@@ -2,12 +2,16 @@
## Status
Accepted
Accepted; superseded in part by AUTH-002
## Date
2026-09-01
## Supersession Note
AUTH-002 supersedes only this ADR's organization-wide ERP FIFO and archive-only removal clauses. The remaining fixed-scope account, role, route-grant, owner-isolation, dashboard, AgentBus assignment, browser-worker, and ERP-identity decisions remain active. Current execution-queue and deletion behavior must be read from AUTH-002.
## 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.
@@ -23,11 +27,11 @@ The platform already required login but treated the fixed deployment scope as a
- 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.
- 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 “进行中”.
- Preserve creator and input-turn attribution with encrypted input at rest. Routine removal is archive/restore; irreversible purge is not exposed.
- 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 the assignee even when the caller is an administrator.
- 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.
- Preserve organization-wide ERP FIFO serialization. Employee worker binding chooses who may execute; it does not authorize parallel ERP writes.
- 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
@@ -0,0 +1,55 @@
# AUTH-002: Account-scoped ERP execution and explicit force delete
## Status
Accepted
## Date
2026-09-03
## 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.
- Keep administrator-wide task visibility as a read model only. Executable SSE history/live events, browser claims, plugin-result ingestion, and browser cleanup commands are accepted or delivered only for the authenticated account matching the task's immutable assignee, including when the signed-in role is administrator.
- 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 retaining organization and owner authorization.
- 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.
- Administrators may inspect and force-delete authorized organization tasks, but their browser never receives or submits another employee's executable task events, plugin results, or cleanup command.
- 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 an authorized administrator-plus-two-employees staging matrix, including cross-account concurrency, same-account FIFO, administrator event isolation, and 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.
## Related
- `.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-integrate-account-routing-9f2c7a61.md`
- `control-plane/src/task-service.ts`
- `control-plane/src/server.ts`
- `LianSyn-platform/app.js`
+3 -1
View File
@@ -10,13 +10,15 @@
| RELEASE-001 | Current artifacts, filenames, versions, and SHA-256 values are defined only by `dist/release-manifest.json`. | Active | 2026-08-28 | Release and delivery | [Release manifest](../../dist/release-manifest.json) |
| SAFETY-001 | Real ERP access/write, task mutation, extension reload, service restart, deployment, and external delivery require explicit task-scoped authorization. | Active | 2026-08-28 | Operations and maintenance | [Governance](../../AGENTS.md) |
| NETWORK-001 | In the trusted internal deployment, AgentBus roster attachment URLs may resolve to internal/private addresses; HTTPS, credential rejection, DNS pinning, redirect validation, bounds, and digest checks remain. | Active | 2026-08-31 | AgentBus attachment ingress | [Reply contract](../../agent设计规范/agentbus-reply-contract.md) |
| AUTH-001 | The fixed deployment scope uses administrator-managed `admin`, `team_lead`, and `user` accounts, owner-isolated normal tasks, display-only leadership metrics with explicit filtering, explicit non-admin route grants, and assignee-bound AgentBus/browser/ERP execution. | Active | 2026-09-01 | Authentication, authorization, audit, AgentBus workers, and operations oversight | [ADR](AUTH-001-fixed-scope-account-authorization.md) |
| AUTH-001 | The fixed deployment scope uses administrator-managed `admin`, `team_lead`, and `user` accounts, owner-isolated normal tasks, display-only leadership metrics with explicit filtering, explicit non-admin route grants, and assignee-bound AgentBus/browser/ERP execution. | Active except clauses superseded by AUTH-002 | 2026-09-01 | Authentication, authorization, audit, AgentBus workers, and operations oversight | [ADR](AUTH-001-fixed-scope-account-authorization.md) |
| AUTH-002 | ERP execution is serialized per immutable assigned account, administrator visibility is never execution routing, and explicit force delete physically removes authorized tasks regardless of lifecycle state. | Active | 2026-09-03 | ERP claim queues, executable events/results, and task removal | [ADR](AUTH-002-account-scoped-execution-and-force-delete.md) |
## Superseded Decisions
| ID | Decision | Superseded By | Date |
|---|---|---|---|
| DOC-LEGACY-001 | Root `task_plan.md`, `findings.md`, and `progress.md` were the active project-memory system. | DOC-001 | 2026-08-28 |
| AUTH-001 (partial) | Organization-wide ERP FIFO and archive-only operator removal. | AUTH-002 | 2026-09-03 |
## Decision Criteria