feat: bind AgentBus work to account workers
This commit is contained in:
inman committed
1 parent
d034f649c4
commit
6f9fd0f0bd
31 files changed
+1119
-257
No files matched your search
@@ -0,0 +1,65 @@
|
||||
# Task: Bind AgentBus channels to account workers
|
||||
|
||||
## Identity
|
||||
|
||||
- Task ID: 20260902-agentbus-account-routing-b62f19e4
|
||||
- Mode: Feature
|
||||
- Branch: codex/20260902-agentbus-account-routing-b62f19e4-agentbus-account-routing-b62f19e4
|
||||
- Worktree: /Users/inmanx/Documents/lwltAPI-agentbus-account-routing-b62f19e4
|
||||
- Base commit: d034f649c4e7c5d0856f22053b92d2e5a63be5eb
|
||||
- Owner: codex
|
||||
- Status: Ready for integration
|
||||
|
||||
## Scope
|
||||
|
||||
- Add a one-to-one AgentBus channel owner on platform employee accounts and stamp every new task with an immutable execution assignee.
|
||||
- Route inbound AgentBus messages through the bound employee's identity and existing business-route allowlist.
|
||||
- Keep administrators able to manage and inspect channels/tasks while preventing them from claiming another account's ERP work.
|
||||
- Make one fresh browser connection the only execution worker for each account and fail closed when the expected ERP account is missing or does not match.
|
||||
- Extend account/channel administration UI, browser heartbeat, extension ERP-session inspection, migrations, contracts, tests, and the versioned extension release.
|
||||
|
||||
## Intent And Constraints
|
||||
|
||||
- User-authorized routing model: each employee platform account binds one AgentBus channel and one expected ERP account; administrator accounts remain unbound from employee channels.
|
||||
- Preserve organization-wide ERP FIFO serialization; this task does not authorize parallel ERP writes.
|
||||
- Existing unbound AgentBus channels and historical unassigned AgentBus tasks must not execute automatically.
|
||||
- Browser worker failover is automatic only after the previous worker heartbeat becomes stale; concurrent cloud PCs must not race or alternate ownership.
|
||||
- No production database migration, deployment, service restart, or real ERP write is authorized in this task.
|
||||
- Preserve unrelated dashboard-filter work in the main worktree; integration must reconcile the known overlap in `control-plane/src/task-service.ts` and `LianSyn-platform/app.js`.
|
||||
|
||||
## Outcome
|
||||
|
||||
- Added migration `018_agentbus_account_workers`: non-admin accounts can carry a case-insensitively unique expected ERP account; each AgentBus channel has one scoped employee owner; every new task stores its execution assignee; existing manual tasks are backfilled while historical AgentBus tasks remain deliberately unassigned; one connected browser worker is allowed per account.
|
||||
- AgentBus channel creation/update now requires an active `user` or `team_lead` with an ERP account. One account cannot own multiple channels, one AgentBus key cannot fan out across channels, enabled unbound legacy channels stay stopped, and listener intake rechecks that its runtime owner still matches the database owner.
|
||||
- AgentBus intake executes under the bound employee identity and business-route allowlist. The assignee is stamped when the task is created and is not re-inferred from whichever cloud PC happens to be online.
|
||||
- Ordinary employees and team leads can read and execute their own assigned manual and AgentBus work. Administrators retain organization-wide inspection and management visibility, but confirmation, browser claim, result submission, reconciliation, and resume require the exact task assignee.
|
||||
- Browser heartbeats verify the expected ERP account, register only a matching session as execution-ready, reject a second fresh worker for the same account, and permit failover only after the earlier heartbeat is stale for 90 seconds. A mismatched cloud PC is recorded as `identity_mismatch` and cannot displace a valid worker.
|
||||
- Updated the account/channel administration UI, employee-only executable task feeds, assignment audit display, bridge heartbeat, and extension ERP-session probe. Released extension `0.5.164`; its probe receives the expected account and returns only the match boolean rather than page account text.
|
||||
- Archived the superseded `0.5.163` ZIP and manifest snapshot under `archive/releases/2026-09-02/`; the current versioned artifact is `dist/ltjt-order-assistant-0.5.164.zip` with SHA-256 `5a59b616aa7ea2cfcc02b2c3242bfc0b424dcd6ddd28fff7ed9bcfb5b367191a`.
|
||||
|
||||
## Verification
|
||||
|
||||
- TypeScript no-emit check: passed.
|
||||
- TypeScript build to ignored `.build/`: passed.
|
||||
- Full control-plane regression: passed 158/158.
|
||||
- Full legacy/platform/extension/tools regression: passed 264/264.
|
||||
- Repository hygiene and release/source/hash checks: passed 10/10.
|
||||
- Focused account/AgentBus routing regression: passed 29/29.
|
||||
- JavaScript syntax checks for the platform app and modified extension bridge/background files: passed.
|
||||
- `git diff --check`: passed.
|
||||
- No live PostgreSQL migration, deployed-service smoke test, live multi-cloud-PC staging exercise, extension reload, ERP read, or ERP write was performed.
|
||||
|
||||
## Follow-ups
|
||||
|
||||
- Integration must reconcile the known overlap with task `20260902-kanban-filter-7e3a91c4` in `control-plane/src/task-service.ts` and `LianSyn-platform/app.js`; retain both the kanban filtering behavior and assignee-only executable feeds.
|
||||
- Production rollout requires separate authorization: back up PostgreSQL, apply migration 018, deploy/restart the control plane and platform, load extension 0.5.164 on each employee cloud PC, configure each employee ERP account and route allowlist, then bind one independent AgentBus channel/key to each employee.
|
||||
- Before production assurance, perform a staging matrix with at least two employee accounts/cloud PCs/ERP logins, an administrator browser left open, a deliberately mismatched ERP login, a same-account two-device conflict, 90-second stale-worker failover, and both manual and automatic AgentBus tasks.
|
||||
|
||||
## Promotion Candidates
|
||||
|
||||
- Target canonical documents: `.project-docs/20-architecture/system-overview.md`, `.project-docs/20-architecture/data-flow.md`, `.project-docs/40-domain/business-rules.md`, and the relevant authentication/authorization ADR during a later Integration Gate.
|
||||
- Proposal: make the supported routing chain explicit as `AgentBus channel -> employee platform account -> immutable task assignee -> one fresh browser worker -> matching ERP account`; administrators manage and inspect but do not execute another assignee's work.
|
||||
- Evidence: migration 018, channel owner/key gates, task-assignee access and execution checks, heartbeat worker/ERP checks, employee-only polling, updated extension probe, release 0.5.164, and the verification results above.
|
||||
- Future impact: account onboarding, AgentBus key management, task APIs/SSE, automatic dispatch, cloud-PC failover, ERP identity handling, administrator workflows, deployment ordering, and staging acceptance.
|
||||
- Semantic conflicts: this supersedes the prior behavior in which AgentBus tasks had no employee owner and administrators could claim globally visible work; organization-wide ERP FIFO serialization remains unchanged. Integration also has a code overlap with the kanban-filter task that is mechanical unless either task changed the meaning of active/status filters.
|
||||
- Human confirmation required: yes for canonical promotion, conflict resolution if integration reveals a behavioral difference, production migration/deploy/restart, extension rollout, and live staging or ERP access.
|
||||
Reference in new issue
Block a user