docs: accept central extension update architecture

This commit is contained in:
inman
2026-09-03 16:17:11 +08:00
parent 322475860a
commit efc342c626
10 changed files with 132 additions and 16 deletions

View File

@@ -0,0 +1,43 @@
# EXT-001: Central-service orchestration for Windows extension updates
## Status
Accepted
## Date
2026-09-03
## Context
The production control plane runs on a separate Node server while ERP work runs in multiple Chrome profiles across multiple Alibaba ECS Windows Server hosts. The profiles use an unpacked extension and are not managed through AD, Chrome Enterprise policy, or the Chrome Web Store. Maintaining every profile by logging in to each Windows host does not scale, but a remote web page cannot itself install an extension or write silently to a Windows extension directory.
The user selected an architecture that keeps release and update logic in the existing control plane, stores packages in OSS, and uses Alibaba Cloud Assistant only as the bounded remote-execution boundary. A separately maintained LTJT updater service on each Windows host is not introduced.
## Decision
- The central control plane owns approved extension releases, version comparison, update state, retry policy, host safety, and post-update verification. Private OSS owns immutable, content-addressed package bytes.
- Each non-administrator account may map to one Alibaba ECS region and instance. Accounts on the same instance share one host update row and one idle gate, while every Chrome profile continues to report its actually loaded extension version.
- The updater may start only while every mapped account is safe: no live ERP lease, accepted/running execution, write-started/submitted/uncertain attempt, reconciliation task, or recent browser worker reporting an unsafe extension state. The same organization serialization boundary protects both update start and ERP task claim.
- The control plane sends one bounded `RunPowerShellScript` command through ECS Cloud Assistant. The Windows command downloads through a short-lived organization/release/host-bound control-plane capability, verifies byte count, SHA-256, Manifest identity and target version, stages the package beneath the configured `ProgramData\LTJT` subtree, retains one `.previous` directory, rolls back a failed switch, and refuses downgrade.
- Cloud Assistant completion requires a successful exit code and an explicit completion marker. Ambiguous dispatch reuses the same persisted attempt identity and client token; definite failures may retry at most three total attempts.
- File deployment alone is not success. Each installed profile performs its own idle recheck and `chrome.runtime.reload()`, and a target-version heartbeat is required before that profile can receive new ERP work.
- Extension `0.5.167` is the one-time bootstrap release for the safety and reload protocol. Before enabling automatic updates, every existing profile must manually load the shared `C:\ProgramData\LTJT\chrome-extension\ltjt-order-assistant` directory once.
- Automatic updates remain disabled by default. Production activation requires HTTPS `APP_ORIGIN`, private OSS configuration, a least-privilege ECS RAM identity, verified ECS account mappings, Cloud Assistant connectivity, completed bootstrap, backup, migration `019`, and a canary rollout.
## Consequences
- Routine releases no longer require logging in to every Windows account after bootstrap; one host file deployment can serve multiple profiles, while each profile remains independently version-gated and verified.
- The update path does not depend on Google services or Chrome Web Store review, but it does depend on Alibaba ECS Cloud Assistant and Windows-to-control-plane HTTPS reachability.
- An offline profile does not block deployment. It remains unable to claim new ERP work until it starts, reloads from the shared directory, and reports the required version.
- Disabling the feature is a kill switch for new update work, not permission to bypass an unfinished host update or an active higher-version claim gate.
- This mechanism externally replaces trusted unpacked-extension files; it does not claim Chrome-native installation or enterprise-policy distribution. Removing Cloud Assistant without another host execution boundary would reduce the workflow to a manual download/install procedure.
## Related
- `.project-docs/30-worklog/tasks/20260903-adaptive-wait-auto-update-7b3e9a2c.md`
- `.project-docs/30-worklog/tasks/20260903-service-extension-update-8d42c6f1.md`
- `.project-docs/30-worklog/tasks/20260903-finalize-extension-update-a6c4e192.md`
- `control-plane/src/extension-updates.ts`
- `control-plane/migrations/019_extension_host_updates.sql`
- `chrome-extension/ltjt-order-assistant/background.js`

View File

@@ -12,6 +12,7 @@
| 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 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) |
| EXT-001 | The separate central control plane publishes private OSS extension releases and uses bounded ECS Cloud Assistant commands to update shared unpacked-extension files only while every mapped account is idle; target-version browser heartbeats are required before ERP execution resumes. | Active | 2026-09-03 | Chrome extension release, Windows host update, and ERP claim safety | [ADR](EXT-001-central-service-host-extension-updates.md) |
## Superseded Decisions

View File

@@ -17,6 +17,7 @@
| Operational diagnostics | Service, request, task, parser, AgentBus, attachment, database, and cleanup stages | Structured stdout/stderr and bounded Docker logs | Correlation identifiers, codes, outcomes, and durations only; no secrets or business payloads. |
| Platform operations oversight | Manual task creator, encrypted instruction history, and readable outcome | Team-lead/administrator leadership projection | Display-only summaries plus explicit filters drive an aggregate-first task/person/input/output/time/type/completion view; list reads are bounded to one read-only connection and hydrate full details only for the current page. |
| Browser worker selection | Immutable task assignee | One fresh account-bound browser connection | The heartbeat must match the account's expected ERP identity; a second fresh worker or identity mismatch is non-executable, with failover only after staleness. |
| Extension release and host update | Administrator ZIP → private OSS release → account-mapped ECS Windows host | Shared unpacked-extension directory → profile reload → verified heartbeat | The central service validates and content-addresses each monotonic release, waits for every mapped account to be ERP-idle, sends one bounded Cloud Assistant command, verifies hash/Manifest and rollback-safe deployment, then blocks new claims until each browser reports the target version. |
| Account-scoped ERP queue | Confirmed task assignee | Assigned account's browser worker | Organization-plus-account advisory locking preserves FIFO and at most one active execution for that account; another account's active, queued, stale, or uncertain work is outside this queue. |
| Executable event and result routing | Immutable task assignee | Matching authenticated platform page and plugin | SSE history/live events, claims, plugin results, and browser cleanup commands never use administrator-wide visibility and fail closed when the authenticated account is not the assignee. |
| Task removal | Authorized operator | Archive/restore or permanent force delete | Archive/restore remains reversible and state-gated. Explicit force delete has no lifecycle-state gate, removes task-owned platform records atomically, retains a minimal deletion audit marker, and performs post-commit artifact/plugin cleanup best effort. |
@@ -25,8 +26,8 @@
## State Ownership
- PostgreSQL owns durable control-plane account, role, expected ERP identity, task-route grant, AgentBus channel owner, immutable task assignee, account-scoped queue/lease state, browser worker, session, confirmation, audit, archive, and outcome state. A force-deleted task no longer exists in task state; only its minimal non-content deletion audit marker remains.
- Production attachment bytes use the configured OSS provider; normalized sensitive fields remain encrypted.
- PostgreSQL owns durable control-plane account, role, expected ERP identity, ECS host mapping, approved extension release metadata, host update state, task-route grant, AgentBus channel owner, immutable task assignee, account-scoped queue/lease state, browser worker, session, confirmation, audit, archive, and outcome state. A force-deleted task no longer exists in task state; only its minimal non-content deletion audit marker remains.
- Production attachment bytes and private immutable extension release packages use the configured OSS provider; normalized sensitive fields remain encrypted.
- Chrome extension local state is bounded execution/reconciliation support, not canonical business history.
- `.project-docs/30-worklog/tasks/` owns task-local project memory; canonical project state is an integrated projection.
@@ -35,7 +36,7 @@
- Operator workbench at the control-plane service.
- AgentBus WebSocket channels and attachment delivery.
- Logged-in ERP browser pages under the Chrome extension host permissions.
- PostgreSQL, OSS, deployment gateway, and authenticated artifact download.
- PostgreSQL, OSS, deployment gateway, authenticated artifact download, Alibaba ECS Cloud Assistant APIs, and the host-bound HTTPS extension package route.
## Last Updated

View File

@@ -10,9 +10,9 @@ Authenticated manual or account-bound AgentBus input is routed through task-scop
|---|---|---|
| `agent设计规范/` | Agent Prompt, five parsing Skills, business templates, business registry, and stable fixtures | Editable source for business semantics; not runtime evidence |
| `schemas/` and `mappings/` | Parse-state, execution-state, ERP form, field, and lifecycle contracts | Current contracts only |
| `control-plane/` | Task/session persistence, parser orchestration, confirmation, audit, AgentBus channel ownership, task assignment, browser workers, attachments, receipts, and structured diagnostics | TypeScript source; build output goes to `.build/` |
| `control-plane/` | Task/session persistence, parser orchestration, confirmation, audit, AgentBus channel ownership, task assignment, browser workers, private extension release/host-update orchestration, attachments, receipts, and structured diagnostics | TypeScript source; build output goes to `.build/` |
| `LianSyn-platform/` | Operator workbench and external parser adapter | Source and UI, not local task output |
| `chrome-extension/ltjt-order-assistant/` | Logged-in ERP resolution, preflight, native execution, response handling, and requery | Any code change requires synchronized versioned release updates |
| `chrome-extension/ltjt-order-assistant/` | Logged-in ERP resolution, preflight, native execution, response handling, requery, update-safety proof, and idle runtime reload | Any code change requires synchronized versioned release updates |
| `dist/` | Versioned current deliverables and machine-readable release manifest | Not a compilation directory |
| `.project-docs/` | Task-isolated project memory and integrated canonical context | No runtime dependency |
| `archive/` | Date-scoped immutable history and evidence | Never defines current behavior |
@@ -28,10 +28,12 @@ Authenticated manual or account-bound AgentBus input is routed through task-scop
- Each enabled AgentBus channel owns one active non-admin employee account. Inbound work uses that account and route allowlist, persists the same account as immutable task assignee, and is returned only to that account's executable feed.
- Each employee account has one expected ERP identity and at most one fresh browser execution worker. Mismatched ERP identity, concurrent fresh workers, unbound channels, or unassigned tasks fail closed. Browser claims, active-execution checks, and confirmed FIFO are serialized per immutable task assignee, so one account cannot block or occupy another account's queue.
- Administrator-wide task visibility is a read model, not an executable feed. Task SSE history/live events, browser claims, plugin-result ingestion, and browser cleanup commands are always scoped to the authenticated account matching `assigned_user_id`, including for administrators.
- The separate central service owns approved extension versions and maps multiple employee accounts to shared Alibaba ECS Windows hosts. Private OSS stores immutable packages; one-shot ECS Cloud Assistant PowerShell updates only the configured `ProgramData\LTJT` directory after every mapped account is idle. Update start and ERP claim share an organization serialization boundary, and a browser below the active release cannot receive new ERP work.
- Extension file deployment is not release acceptance. Every Chrome profile reloads only after its own in-memory and durable execution state is safe, then reports the active version through a fresh heartbeat. Existing profiles require one manual `0.5.167` bootstrap from the shared directory before this automatic path is enabled.
- Creator and manual input-turn attribution remain durable while business input stays encrypted at rest. Routine removal is reversible archive/restore. Separately confirmed force delete physically removes an authorized task regardless of lifecycle state, retains only a minimal non-content deletion audit marker, and cannot undo an ERP write that already occurred.
- Unknown, ambiguous, unverified, or post-write-uncertain states fail closed; automatic retries must not create duplicate writes.
- PostgreSQL is the sole required durable database/state middleware, and the production artifact provider is OSS. Redis, message queues, MongoDB, and search services are not runtime dependencies.
- Migrations through `018_agentbus_account_workers` must complete before the updated application starts. The current ACK topology starts with one application replica because AgentBus listeners and SSE emission are process-local; horizontal scale requires explicit coordination first.
- Migrations through `019_extension_host_updates` must complete before the updated application starts. The current ACK topology starts with one application replica because AgentBus listeners, SSE emission, and bounded extension-update polling are process-local; horizontal scale requires explicit coordination first.
- Operational diagnostics are privacy-safe structured JSON on stdout/stderr. Docker owns bounded rotation; repository files and a second mutable log database are not log sinks.
- In the trusted internal deployment, AgentBus roster attachment downloads may resolve to private/reserved addresses. Credential-free HTTPS, DNS resolution/pinning, redirect revalidation, size, timeout, and digest checks remain mandatory, and trusted channels/bridges own the network-input boundary.
- Canonical project memory is updated only under Integration Gate; feature tasks write only their task-scoped records.
@@ -46,6 +48,7 @@ Authenticated manual or account-bound AgentBus input is routed through task-scop
- NETWORK-001
- AUTH-001
- AUTH-002
- EXT-001
## Last Updated

View File

@@ -4,6 +4,8 @@ This file is the integrated default-branch snapshot. Feature tasks record progre
## Integrated Through
- Merge commit `3224758` integrating source commits `500034b` and `f08aac0` from tasks `20260903-adaptive-wait-auto-update-7b3e9a2c` and `20260903-service-extension-update-8d42c6f1` for adaptive ERP entry readiness plus central-service/private-OSS/ECS-Cloud-Assistant extension updates, migration 019, and extension `0.5.167`.
- Integration task `20260903-finalize-extension-update-a6c4e192` for acceptance of EXT-001, canonical update/release reconciliation, full release verification, and normal non-force synchronization to `origin/main`.
- Commit `c4c469f4441d744627af2d34abe693b6783e833c` for the independently advanced remote deployment/extension line.
- Commit `cd45ce17d0fcd25f7fa89ab9f8a391d3e904ecdf` for WeChat attachment correlation and privacy-safe server diagnostics.
- Commit `161f90d09d6ad1368973b1a85d51059059495223` for trusted-intranet attachment compatibility and canonical reconciliation.
@@ -31,7 +33,7 @@ This file is the integrated default-branch snapshot. Feature tasks record progre
## Current Focus
Operate the repository's current `0.5.165` extension baseline and fixed-scope account model safely, bind each enabled AgentBus channel to one employee/ERP identity, provision narrow route grants, use explicit leadership-dashboard filters, and preserve Program/AI plus per-assigned-account ERP execution boundaries. Same-account tasks remain FIFO and single-active; distinct accounts are independent, and administrator visibility never enters another account's executable event/result path. Migration 018, extension reload, guarded product-search retry, and service rollout remain separately authorized runtime work.
Operate the repository's current `0.5.167` extension baseline and fixed-scope account model safely, bind each enabled AgentBus channel to one employee/ERP identity and ECS Windows host, provision narrow route grants, use explicit leadership-dashboard filters, and preserve Program/AI plus per-assigned-account ERP execution boundaries. Same-account tasks remain FIFO and single-active; distinct accounts are independent, and administrator visibility never enters another account's executable event/result path. Migration 019, one-time profile bootstrap, restricted RAM/OSS configuration, extension publication, Cloud Assistant canary, and service rollout remain separately authorized runtime work.
## Recently Completed
@@ -55,25 +57,29 @@ Operate the repository's current `0.5.165` extension baseline and fixed-scope ac
- 2026-09-02: Integrated extension `0.5.165`: scatter-plan creation and independent batch-order creation now try loaded product candidates, then the form's native non-empty `S_chanpinming` search, and finally one bounded empty-query compatibility reload. A user-authorized search-only ERP check returned exactly one target row in both forms without selecting or saving it; zero or multiple local matches continue to fail closed.
- 2026-09-03: Accepted AUTH-002 and integrated account-scoped ERP queues. Each immutable assignee now owns one FIFO/single-active claim partition, different accounts no longer block one another, and executable SSE/results/cleanup commands are owner-only even when an administrator is signed in.
- 2026-09-03: Restored explicit permanent force deletion as a separate operation from reversible archive/restore. It bypasses lifecycle-state gates, physically removes task-owned platform records, retains a minimal deletion audit marker, performs post-commit cleanup best effort, and warns that prior ERP effects are not rolled back.
- 2026-09-03: Added an immediate-first, conditional 100 ms readiness probe for scatter-plan entry. It proceeds without a fixed delay when the current ERP document is ready and fails closed before any write after the bounded timeout.
- 2026-09-03: Integrated extension `0.5.167` and migration 019. The separate central service can publish validated private OSS releases, group multiple accounts by ECS Windows host, wait for all mapped ERP workers to become safe, deploy through one-shot Cloud Assistant PowerShell with hash/staging/rollback/no-downgrade checks, and require profile reload plus target-version heartbeat before reopening ERP claims.
## In Progress
- The standard database currently contains one administrator account and no non-administrator task grants. Multi-account operational smoke testing remains for an administrator-led staging window.
- Migration `018_agentbus_account_workers`, employee ERP identities/channel bindings, extension `0.5.165`, account-scoped queue/routing changes, force-delete behavior, and the merged dashboard/runtime changes have not been applied to or restarted on the standard service in this integration task.
- Migrations `018_agentbus_account_workers` and `019_extension_host_updates`, employee ERP identities/channel/host bindings, extension `0.5.167`, account-scoped queue/routing changes, force-delete behavior, and the merged dashboard/update runtime have not been applied to or restarted on the production service in this integration task.
## Next Recommended Steps
1. In an explicitly authorized staging/rollout window, back up PostgreSQL, apply migration 018, restart the control plane, load extension `0.5.165`, verify its runtime handshake, configure employee ERP identities and channel bindings, and run the multi-cloud-PC/identity/failover plus account-queue matrix before production assurance.
2. Through the administrator UI, create representative team-lead and ordinary accounts, assign narrow task grants, and verify owner isolation, leadership dashboard reads, grant/revoke behavior, and denial prompts without ERP writes.
3. In the same authorized staging window, verify that an administrator receives no employee executable events/results, then force-delete disposable waiting and active employee tasks and confirm database absence plus cleanup only in the owning employee plugin.
4. With explicit authorization, run a live read-only ERP verification of the shared-mother-plan `tid-only` whole-visitor export path.
5. With explicit authorization, perform ERP write verification for independent-order SGL/TWN and adult/child/leader headcount mappings.
1. In an explicitly authorized rollout window, back up PostgreSQL, apply migrations through 019, deploy the central service with automatic extension updates still disabled, manually load bootstrap extension `0.5.167` from the shared ProgramData directory in every profile, and verify each runtime heartbeat.
2. Configure a least-privilege ECS RAM identity, private OSS release prefix, HTTPS `APP_ORIGIN`, and exact account-to-ECS mappings; then enable updates and run one controlled higher-version canary through waiting → running → deployed → reload → verified before widening rollout.
3. Through the administrator UI, create representative team-lead and ordinary accounts, assign narrow task grants, and verify owner isolation, leadership dashboard reads, grant/revoke behavior, and denial prompts without ERP writes.
4. In the same authorized staging window, verify that an administrator receives no employee executable events/results, then force-delete disposable waiting and active employee tasks and confirm database absence plus cleanup only in the owning employee plugin.
5. With explicit authorization, run a live read-only ERP verification of the shared-mother-plan `tid-only` whole-visitor export path.
6. With explicit authorization, perform ERP write verification for independent-order SGL/TWN and adult/child/leader headcount mappings.
## Open Questions / Blockers
- Shared-mother-plan whole-visitor export has historical read evidence and static coverage but lacks a fresh authorized runtime ERP read verification.
- Independent-order SGL/TWN and four headcount categories lack authorized current-version ERP write evidence.
- The standard service was last restarted before commits `3062ed5`, `b5f5847`, `cc09506`, `336ca6e`, `e4fd916`, and `d09b303`; its runtime schema, extension, account UI, queue/routing, force-delete, and dashboard behavior must not be represented as the newly integrated repository state until an authorized rollout.
- The production service has not been verified at merge commit `3224758`; its runtime schema, extension, account UI, queue/routing, force-delete, dashboard, and extension-update behavior must not be represented as the newly integrated repository state until an authorized rollout.
- Extension auto-update cannot be enabled safely until every existing Chrome profile has loaded bootstrap `0.5.167` from the shared ProgramData directory and the restricted ECS/OSS/HTTPS configuration plus one-host canary have been verified.
- AgentBus account-worker routing still lacks a live two-employee/two-cloud-PC staging matrix covering mismatched ERP login, same-account device conflict, 90-second stale failover, same-account FIFO, cross-account independence, administrator executable-feed isolation, and both manual and automatic channel work.
- Lifecycle-independent force deletion has repository regression evidence but lacks an authorized runtime smoke test for waiting/active deletion, database absence, OSS cleanup, and owner-plugin-only cleanup.
- A live internal AgentBus attachment verification remains separately unperformed.
@@ -86,6 +92,7 @@ Operate the repository's current `0.5.165` extension baseline and fixed-scope ac
- Account role changes, session revocation, creator-based task-route revocation, cross-user dashboard projection, and encrypted input audit are security-sensitive boundaries.
- AgentBus channel ownership, immutable task assignment, expected ERP identity, browser-worker freshness/failover, and administrator non-execution are security- and write-safety-sensitive boundaries.
- Account-scoped advisory locking, per-assignee FIFO queries, executable SSE/result routing, and irreversible force deletion are concurrency-, authorization-, and evidence-sensitive boundaries.
- Host-wide idle aggregation, update/claim serialization, short-lived package capabilities, Cloud Assistant idempotency, ProgramData path restriction, rollback, and post-reload version verification are security- and write-availability-sensitive boundaries.
- Release synchronization across extension source, minimum platform version, mapping, ZIP, Skills, DOCX, and `dist/release-manifest.json`.
## Last Updated

View File

@@ -9,3 +9,4 @@ This is integrated history. Feature tasks write only their task-scoped records;
| 2026-08-28 | Shared mother-plan whole-visitor export | Released strict `shared_plan + visitor-list + tid-only` routing and execution boundaries in extension `0.5.157`. | [Release gate](../../agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md) |
| 2026-09-02 | AgentBus account workers | Integrated one-to-one employee channel ownership, immutable task assignment, expected ERP identity, single-fresh-worker enforcement, migration 018, and extension `0.5.164`. | [Integration task](tasks/20260902-integrate-all-push-c93a7f21.md) |
| 2026-09-02 | Leadership dashboard query and filter contract | Integrated bounded single-connection reads, 20-row paging, cancellation/timeout feedback, display-only metrics, and explicit result filtering. | [Integration task](tasks/20260902-integrate-all-push-c93a7f21.md) |
| 2026-09-03 | Adaptive ERP readiness and extension host updates | Integrated immediate-first scatter-plan readiness plus private OSS release publication, multi-account ECS host safety, Cloud Assistant deployment, and heartbeat-verified extension `0.5.167`. | [Integration task](tasks/20260903-finalize-extension-update-a6c4e192.md) |

View File

@@ -0,0 +1,58 @@
# Task: Finalize extension update main push
## Identity
- Task ID: 20260903-finalize-extension-update-a6c4e192
- Mode: Integration
- Branch: codex/20260903-finalize-extension-update-a6c4e192-finalize-extension-update
- Worktree: /Users/inmanx/Documents/lwltAPI-finalize-extension-update-a6c4e192
- Base commit: 322475860afa81ed43cb59164d815d20590d3125
- Owner: codex
- Status: Verified; push pending
## Scope
- Finalize merge commit `3224758`, which combines completed source commits `500034b` and `f08aac0` with the current `origin/main`, including adaptive ERP readiness, extension `0.5.167`, migration 019, central-service OSS publication, ECS Cloud Assistant host deployment, multi-account host locking, tests, release artifacts, and operator documentation.
- Reconcile the accepted central-server/multi-Windows-Server update architecture into canonical project memory, preserving the existing unpacked-extension model and recording the user-selected Cloud Assistant boundary as the successor to the earlier Web Store/managed-CRX assessment.
- Run the complete repository, release, document and build gates, then update `origin/main` by a normal non-force push. Stop at repository synchronization as the user ultimately requested; do not deploy or restart a service.
- Produce a concrete server-colleague handoff covering migration order, environment/RAM/OSS/ECS mapping, one-time profile bootstrap, canary, health checks, rollback, and the boundary between Git synchronization and live production rollout.
## Intent And Constraints
- The user explicitly authorized merging all changes from this extension-update line into remote `main`, then clarified that repository synchronization is the terminal action. “All changes” is scoped to the two-commit feature ancestry and its governed artifacts, not unrelated ready-for-integration worktrees.
- This task starts at merge commit `3224758`, so both source task records are part of the recorded baseline and remain read-only. The local `main` worktree is owned by task `20260902-migrate-restart-confirmed-4f8c2a71`; do not alter, adopt, stash, reset, or run its local service.
- Preserve `AUTH-002` account-scoped execution and assignee-only routing while adding the host-level update gate. Resolve source conflicts semantically; never use wholesale `ours`/`theirs` resolution for canonical documents or safety-sensitive code.
- Accept the user's clarified architecture: one independent central Node service controls many multi-account Windows Server hosts; private OSS stores immutable bytes; Alibaba Cloud Assistant executes one-shot bounded PowerShell; no separately maintained LTJT host updater is introduced.
- The external replacement of a shared unpacked-extension directory plus extension-owned idle reload does not claim Chrome-native self-installation. Every existing Chrome profile still requires a one-time manual `0.5.167` bootstrap from the shared ProgramData path before auto-update is enabled.
- Do not read or print `.env`, credentials, tokens, browser storage, customer data, or database business inputs. Do not force-push, deploy or restart a service, publish a release, enable automatic updates, map production ECS instances, mutate ERP tasks, reload Chrome, or call a real Cloud Assistant command.
## Outcome
- Verified merge commit `3224758`, which preserves source commits `500034b` and `f08aac0` together with the latest `AUTH-002` account-scoped queue, force-delete, dashboard, and executable-routing changes already present on remote `main`.
- Accepted `EXT-001`: the separate central Node control plane owns monotonic extension releases and host state, private OSS stores immutable package bytes, and ECS Cloud Assistant supplies one-shot Windows execution without adding a separately maintained LTJT updater.
- Promoted the host-safety invariant that update start and ERP claim serialize through the same organization boundary. All mapped accounts must be idle before deployment, and every old-version browser remains claim-blocked until it safely reloads and reports the target version.
- Promoted extension `0.5.167` as the one-time shared-ProgramData bootstrap and migration `019_extension_host_updates` as the required schema baseline. Automatic updates remain disabled until every profile is bootstrapped and the restricted RAM/OSS/HTTPS/ECS configuration plus one-host canary are complete.
- Updated the canonical decision index, architecture, data flow, current state, task history, evidence and rollout commitment. Corrected production documentation to require migration 019 and to keep automatic updates disabled during the first `0.5.167` service deployment.
- Kept the user-rejected web-page local-filesystem alternative out of the repository. The final implementation remains the previously completed OSS plus Cloud Assistant design.
- No production deployment, service restart, database migration, OSS publication, ECS command, Chrome reload, ERP operation, live task mutation, or secret access occurred.
## Verification
- Fresh `npm ci --no-audit --no-fund` completed from the merged lockfile in this corrected Integration worktree.
- `node --run check:repo` passed, 10/10.
- `node --run check` passed.
- `node --run test:control-plane` passed, 169/169.
- `node --run test:legacy` passed, 270/270.
- `node --run build` passed.
- `node --check` passed for the extension background and business bridge scripts.
- `unzip -t dist/ltjt-order-assistant-0.5.167.zip` passed; SHA-256 is `6822ec660097a8889da8ea4fa22d4091467aa022067bff3bee2ac5406864b679`.
- `git diff --check` passed.
## Follow-ups
- Server operators must back up PostgreSQL, apply migrations through 019, deploy with updates disabled, bootstrap every profile from the shared `0.5.167` directory, configure least-privilege ECS/OSS/HTTPS values and exact account-to-instance mappings, then enable and canary a higher version before fleet rollout.
- The inherited production-dependency audit findings recorded by source task `20260903-service-extension-update-8d42c6f1` remain a separately scoped security-maintenance item.
## Promotion Candidates
- None. The user-confirmed update topology and rollout invariants were promoted by this Integration task as `EXT-001`.

View File

@@ -20,6 +20,7 @@ Use this index for searchable, traceable evidence records.
| 2026-09-02 | Leadership-dashboard filtering and summary interaction | Repository and focused regression verified; merged runtime not restarted | [Integration record](../30-worklog/tasks/20260902-integrate-all-push-c93a7f21.md) | Single-connection bounded reads, SQL prefiltering, selective hydration, 20-row paging, cancellation/timeout feedback, and display-only metric cards with explicit filters passed combined regression. |
| 2026-09-02 | Native ERP product search for ordering forms | Root cause and live search-only behavior verified; repository/release verified; extension not reloaded | [Integration task](../30-worklog/tasks/20260902-integrate-product-search-3b7f6a20.md) | Both `plan_add.asp` and `orders_adds.asp` returned exactly one target product for the full keyword with radios left unchecked and no save; extension `0.5.165` now uses native non-empty search before its bounded empty-query fallback while retaining deterministic unique matching. |
| 2026-09-03 | Account-scoped ERP queues, assignee-only executable routing, and force delete | Repository and full regression verified; runtime not deployed or mutated | [Integration task](../30-worklog/tasks/20260903-finalize-account-routing-7c4e2a91.md) | Source task `20260902-per-account-queue-hard-delete-a6d9f2c1` replaced global head-of-line blocking with per-assignee FIFO/advisory locks, isolated SSE/plugin-result/browser-command routing from administrator read visibility, and separated reversible archive from lifecycle-independent physical deletion. |
| 2026-09-03 | Adaptive ERP readiness and central extension host updates | Repository, release package, and full regression verified; production migration/bootstrap/publication not performed | [Integration task](../30-worklog/tasks/20260903-finalize-extension-update-a6c4e192.md) | Source commits `500034b` and `f08aac0` added immediate-first bounded ERP entry readiness, extension `0.5.167`, migration 019, private OSS publication, multi-account ECS host safety, bounded Cloud Assistant deployment, rollback/no-downgrade checks, and target-version heartbeat verification. |
## When To Add Evidence

View File

@@ -9,6 +9,7 @@ Track future-facing memory: promised follow-ups, unfinished loops, timed checks,
| 2026-08-28 | Resolve AgentBus OSS attachment rejection caused by private/reserved local DNS answers. | User scheduled integration and confirmed the environment is trusted internal networking | Integration task `20260831-integrate-server-diagnostics-8b42c6d1` | Completed in repository | Deploy/restart and run one live internal attachment verification only under separate authorization. |
| 2026-09-02 | Roll out and stage-test AgentBus account workers, account-scoped queues, and force deletion. | Explicit authorization for database backup/migration, service restart, extension reload, account/channel configuration, staging traffic, and disposable task mutation | Future authorized rollout task | Pending authorization | Apply migration 018 and extension `0.5.165`; verify two employee accounts/cloud PCs, ERP identity mismatch, same-account worker conflict/FIFO, cross-account independence, 90-second failover, administrator executable-feed isolation, manual/AgentBus routing, and waiting/active force-delete cleanup. |
| 2026-09-02 | Verify the integrated native product-search execution path. | Explicit authorization for extension reload and a guarded ERP preflight/retry | Future authorized rollout task | Pending authorization | Load extension `0.5.165`, confirm the runtime handshake, then verify deterministic product selection and normal write gates without automatically retrying the earlier failed task. |
| 2026-09-03 | Bootstrap and canary the central extension-update channel. | Authorized production maintenance window with database backup, migration, service restart, per-profile Chrome access, restricted RAM/OSS configuration, exact ECS mappings, and a disposable higher extension version | Server operator plus future authorized rollout task | Pending rollout | Deploy with updates disabled; apply migration 019; load shared-directory bootstrap `0.5.167` in every profile; verify heartbeats; configure ECS mappings and least privilege; then enable and observe one host through waiting, running, deployed, reload, and verified before fleet rollout. |
## Use

View File

@@ -174,13 +174,13 @@ npm run data:retention
npm run dev
```
`npm run dev``npm start` 会先执行数据库迁移,再启动控制平面;直接运行 `control-plane/src/server.ts` 或构建后的 `server.js` 时,服务也会在启动前检查必需迁移 `018_agentbus_account_workers`,缺失时拒绝监听端口。`db:migrate` 和管理员初始化需要可连接的 PostgreSQL。开发机没有数据库时可以运行 `npm run test:control-plane` 完成无数据库静态/健康烟测。
`npm run dev``npm start` 会先执行数据库迁移,再启动控制平面;直接运行 `control-plane/src/server.ts` 或构建后的 `server.js` 时,服务也会在启动前检查必需迁移 `019_extension_host_updates`,缺失时拒绝监听端口。`db:migrate` 和管理员初始化需要可连接的 PostgreSQL。开发机没有数据库时可以运行 `npm run test:control-plane` 完成无数据库静态/健康烟测。
`/health/ready` 同时检查 PostgreSQL 可用性和必需 schema 版本;迁移未完成时返回 503并标明 `required_migration`,避免任务在数据库结构未升级时进入解析队列。
## 生产部署
1. 复制 `.env.production.example` 为部署机受保护的 `.env.production`,填入 `DEPLOYMENT_REVISION`、PostgreSQL URL、`DATABASE_SCHEMA`、字段加密密钥、外部解析 Key 和 OSS 凭据,并确认 `AGENTBUS_LOG_PAYLOADS=false`。生产数据库可使用现有 PostgreSQL 实例中的新 Schema迁移程序会创建 Schema不会触碰其他 Schema 的测试表。
1. 复制 `.env.production.example` 为部署机受保护的 `.env.production`,填入 `DEPLOYMENT_REVISION`、PostgreSQL URL、`DATABASE_SCHEMA`、字段加密密钥、外部解析 Key 和 OSS 凭据,并确认 `AGENTBUS_LOG_PAYLOADS=false`首次部署 `0.5.167` 时保持 `EXTENSION_AUTO_UPDATE_ENABLED=false`只有完成共享目录引导、HTTPS 可达性、受限 ECS RAM 凭据和账号实例映射后再启用。生产数据库可使用现有 PostgreSQL 实例中的新 Schema迁移程序会创建 Schema不会触碰其他 Schema 的测试表。
2. 在正式数据库上线前执行并验证备份:`infra/backup-postgres.sh`
3. 使用 `docker compose --env-file .env.production up -d --build` 启动Compose 会先执行数据库迁移再启动控制平面。Compose 中的本地 PostgreSQL 仅用于 `--profile local`,生产 `DATABASE_URL` 指向受保护的远程数据库。
4. 首次启动后在容器内通过 `docker compose exec -e ADMIN_USERNAME=admin -e ADMIN_PASSWORD='replace-with-password' control-plane node .build/control-plane/src/admin-cli.js bootstrap` 创建管理员;不要把密码写入镜像或 Git。