Revert "merge: integrate extension auto-update"

This reverts commit 322475860a, reversing
changes made to f52d9d7413.

.project-docs/10-decisions/EXT-001-central-service-host-extension-updates.md

@@ -2,19 +2,25 @@
 
 ## Status
 
-Accepted
+Reverted
 
 ## Date
 
 2026-09-03
 
+## Reversal
+
+On 2026-09-03 the user explicitly directed that this iteration be backed up and removed from the main branch. The exact integrated state at commit `b2e33e2e5d29138891eabc93969cf24907492dfe` is preserved on remote branch `codex/backup-extension-update-20260903-b2e33e2`; active `main` restores the pre-iteration extension `0.5.165` and migration 018 baseline through a normal revert of merge `3224758`.
+
+This ADR is retained only as historical design context and no longer governs the active architecture. The reverted 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.
 
-## Decision
+## 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.
@@ -25,7 +31,7 @@ The user selected an architecture that keeps release and update logic in the exi
 - 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
+## 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.

.project-docs/10-decisions/decision-index.md

@@ -12,14 +12,14 @@
 | 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
+## Superseded And Reverted Decisions
 
-| ID | Decision | Superseded By | Date |
+| ID | Decision | Resolution | 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 |
+| EXT-001 | Central-service private-OSS and ECS Cloud Assistant orchestration for shared unpacked-extension updates. | Reverted by explicit user decision; exact implementation preserved on `codex/backup-extension-update-20260903-b2e33e2`. | 2026-09-03 |
 
 ## Decision Criteria