docs: reconcile AgentBus and dashboard integration
This commit is contained in:
1 parent
cc09506a06
commit
9eeb071099
10 files changed
+115
-22
No files matched your search
@@ -10,20 +10,24 @@ Accepted
|
||||
|
||||
## 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.
|
||||
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`.
|
||||
- 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.
|
||||
- Administrators manage account lifecycle, passwords, sessions, global settings/audit, AgentBus channels, and all manual/AgentBus task visibility. They always hold all 18 registered manual business routes, but their inspection authority does not grant ERP execution authority over work assigned to another account.
|
||||
- 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 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.
|
||||
- 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.
|
||||
- Keep AgentBus authorization as a separate administrator-controlled channel boundary.
|
||||
- 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.
|
||||
|
||||
## Rationale
|
||||
|
||||
@@ -31,12 +35,14 @@ This model fits a single-organization deployment while enforcing least privilege
|
||||
|
||||
## Consequences
|
||||
|
||||
- Migrations 015–017 must be applied before the updated control plane starts.
|
||||
- Migrations 015–018 must be applied before the updated control plane starts.
|
||||
- Existing accounts migrate as administrators; newly created team leads and 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 even when an administrator attempts the 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 and business-readable drill-through, not on reproducing task history or technical audit records.
|
||||
- Dashboard acceptance is based on leadership questions, explicit filters, and business-readable drill-through, not on reproducing task history or technical audit records.
|
||||
|
||||
## Supersedes
|
||||
|
||||
@@ -47,5 +53,7 @@ This model fits a single-organization deployment while enforcing least privilege
|
||||
- `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`
|
||||
@@ -10,7 +10,7 @@
|
||||
| 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, an aggregate-first read-only leadership dashboard, explicit non-admin task-route allowlists, and no first-login forced-password-change workflow. | Active | 2026-09-01 | Authentication, authorization, audit, 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 | 2026-09-01 | Authentication, authorization, audit, AgentBus workers, and operations oversight | [ADR](AUTH-001-fixed-scope-account-authorization.md) |
|
||||
|
||||
## Superseded Decisions
|
||||
|
||||
|
||||
Reference in new issue
Block a user