EXT-001: Central-service orchestration for Windows extension updates

Status

Reverted

Date

2026-09-03

Reversal

On 2026-09-03 the user explicitly directed that this iteration be backed up and its server-side automatic-update architecture removed from the main branch, then clarified that the Chrome plugin itself must remain at 0.5.167 at that rollback point. The exact full-stack state at commit b2e33e2e5d29138891eabc93969cf24907492dfe is preserved on remote branch codex/backup-extension-update-20260903-b2e33e2. Active main later advanced the manually distributed plugin to 0.5.170 and the control plane to migration 023 without restoring private-OSS/ECS update orchestration.

This ADR is retained only as historical server-architecture context and no longer governs the active control plane. Plugin-side idle proof and guarded reload handlers remain as dormant capabilities in 0.5.170 with no current server/platform trigger. The reverted server code was never deployed, migration 019 was not applied, no OSS extension release was published, and no Cloud Assistant or Chrome reload action was performed by these repository tasks.

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.

Former 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.

Historical 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.

.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

5.5 KiB Raw Blame History