huangruiteng · Oct 10, 2026 · Oct 10, 2026 · Oct 10, 2026
@@ -341,14 +341,23 @@ It uses the authoritative catalog command and does not require publishing this
 provider to npm. [The beta.6 GitHub package](https://github.com/loopx-project/loopx/releases/tag/dsh-loopx-plugin-v0.1.1-beta.6)
 is published from merged commit `5eee730c2`; downloaded bytes match the built
 artifact. Its [personal illustrated upgrade guide](https://my.feishu.cn/docx/Q8pOdO1jco0y10xBDCkce87Xngc)
-was read back with three real DSH screenshots. The live catalog still selects
-beta.5 as of 2026-10-07; [catalog PR #6633](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/6633)
-remains open. [Hub PR #98](https://github.com/dshplugin/dsh-plugin-hub/pull/98)
-is merged and shipped in [Hub 1.5.0](https://github.com/dshplugin/dsh-plugin-hub/releases/tag/v1.5.0).
+was read back with three real DSH screenshots.
+[Catalog PR #6633](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/6633)
+merged on 2026-10-08; its deployed awesome directory selects beta.6.
+However, on 2026-10-10 the [DSH Hub website](https://dsh-plugin.org/plugins/loopx-project/loopx)
+and both `api.dsh-plugin.org/plugins.en.json` and `plugins.zh.json` still
+select beta.5 in the LoopX row's `ic` and `igc` commands. Current Hub releases
+consume those separate feeds, not the awesome directory. This is an unresolved
+consumer metadata gap, tracked in [Hub #146](https://github.com/dshplugin/dsh-plugin-hub/issues/146);
+neither the directory merge nor a Hub upgrade establishes its adoption.
+[Hub PR #98](https://github.com/dshplugin/dsh-plugin-hub/pull/98)
+shipped in [Hub 1.5.0](https://github.com/dshplugin/dsh-plugin-hub/releases/tag/v1.5.0).
 The npm-published 1.5.0 backend and Client helpers passed beta.6 install,
 installed identity, pinned update and removal through native DSH 0.2 HTTP routes
-with the proposed catalog URL. This qualifies published Hub bytes, not adoption
-of beta.6 by the live catalog.
+with the proposed catalog URL. A fresh isolated macOS DSH 0.2.0-rc.2 profile
+also installed the published beta.6 URL with pnpm 11.25.0 and Hub 1.6.4;
+both package versions, all four LoopX rows and real web-host loading were read
+back. These direct-install results do not qualify the stale Hub feed's route.
 
 New [#5786](https://github.com/loopx-project/loopx/issues/5786) and
 [#5796](https://github.com/loopx-project/loopx/issues/5796) report
@@ -359,10 +368,13 @@ pnpm 12.6.0; `--force` and `--fix-lockfile` also fail. Preserving the old
 lockfile and resolving again restores the checksum and installation with
 integrity checks enabled. The reports do not establish how their lockfiles
 lost the checksum. [Hub #102](https://github.com/dshplugin/dsh-plugin-hub/pull/102)
-proposes accurate policy diagnostics, English/Chinese recovery copy and
-backend-recorded command reporting. Its packed candidate passed the real
-macOS DSH failure dialog and persisted notification readback; it remains an
-upstream proposal, not a released repair for the reported Windows profiles.
+merged on 2026-10-07; current published Hub 1.6.4 includes the policy diagnostics,
+English/Chinese recovery copy and backend-recorded command reporting. Its
+earlier packed candidate passed the real macOS failure dialog and persisted
+notification readback. Shipping that guidance does not repair existing
+lockfiles or establish the origin of the reported Windows failures.
+[LoopX #6053](https://github.com/loopx-project/loopx/issues/6053) still attempts
+beta.5 with Hub 1.6.3; its wrapper alone cannot identify the inner pnpm error.
 
 The published package passed native CLI URL installation, beta.5-on-compatible-0.1.5
 to beta.6-on-0.2 upgrade/removal, and offline plugin-tarball installation/removal.
@@ -377,9 +389,17 @@ model turn. This does not qualify Windows desktop market installation,
 initialization, control, upgrade/removal or model-driven continuation. Network
 recovery still depends on external connectivity; an offline plugin archive
 requires compatible host/CLI dependencies or their caches. Native browser hot
-uninstall disconnected the Web service while the dependency remained; it is a
-failed journey, not covered by the passing CLI removal. Close DSH before CLI
-removal and restart it afterwards. [Issue #5671](https://github.com/loopx-project/loopx/issues/5671)
+uninstall failed again on 2026-10-10 with published beta.6 and Hub 1.6.4: the
+dependency was removed, but withdrawing `loopxBootstrap` stopped the shared Web
+rows and disconnected the browser. A follow-up source candidate removes those
+shared dependencies while retaining the native Loader readiness wait and
+LoopX-owned Host/Driver gating. Its packed real 0.2.0-rc.2 and 0.1.5-rc.2 smokes
+passed delayed initialization before readiness, live-disable with a surviving
+Web host and retired LoopX route, and cold boot with the package disabled. Real
+macOS Hub 1.6.4 browser uninstall completed, removed the dependency and preserved
+the host through page refresh. This candidate is not a new published release;
+for published beta.6, close DSH before CLI removal and restart it afterwards.
+[Issue #5671](https://github.com/loopx-project/loopx/issues/5671)
 also reports a missing Windows desktop-host CLI module before plugin loading;
 that host packaging failure needs its own Windows/upstream readback. The L1 observer still
 consumes only

@@ -269,10 +269,47 @@ npm 分发通道要求包与 GitHub release artifact 完全一致，`latest` 指
 包名安装与卸载，CI 覆盖 Linux 和 Windows。
 [Hub PR #93](https://github.com/dshplugin/dsh-plugin-hub/pull/93) 报告的直接 release 安装已由
 上游独立实现并发布到 [Hub v1.4.14](https://github.com/dshplugin/dsh-plugin-hub/releases/tag/v1.4.14)，
-按现有权威目录命令安装，不要求本 provider 先发布 npm。在线目录仍选择 beta.5；beta.6
-发布与目录采用仍未完成。发布版 Hub 的安装已通过，但其 Client 的已安装状态仍不能
-识别 release URL，因此市场升级、卸载交互尚未闭环。
-公开分发、市场目录采用，以及浏览器挂载后的 Start/Pause 仍各自需要发布证据。L1 observer 仍只消费 `session/created`、
+按现有权威目录命令安装，不要求本 provider 先发布 npm。
+[beta.6 GitHub 包](https://github.com/loopx-project/loopx/releases/tag/dsh-loopx-plugin-v0.1.1-beta.6)
+已从合并提交 `5eee730c2` 发布，下载字节与构建产物一致；个人图文升级指南已回读文本
+及三张真实 DSH 截图。[目录 PR #6633](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin/pull/6633)
+于 2026-10-08 合并，已部署的 awesome 目录选择 beta.6。
+但 2026-10-10 回读 [DSH Hub 网站](https://dsh-plugin.org/plugins/loopx-project/loopx)
+及 `api.dsh-plugin.org/plugins.en.json`、`plugins.zh.json`，LoopX 行的 `ic` 和
+`igc` 仍选择 beta.5。当前 Hub 消费这两个独立 feed，并不读取 awesome 目录；
+[Hub #146](https://github.com/dshplugin/dsh-plugin-hub/issues/146) 跟踪这一真实消费入口的
+元数据缺口，目录合并或升级 Hub 均不能证明它已采用 beta.6。
+
+[Hub #98](https://github.com/dshplugin/dsh-plugin-hub/pull/98) 已由 Hub 1.5.0 发布。
+发布版 backend 与 Client helper 已通过原生 DSH 0.2 HTTP 路由验证 beta.6 安装、
+已安装身份、固定版本更新与卸载，但使用的是手动提供的目录 URL。
+新的隔离 macOS DSH 0.2.0-rc.2 profile 使用 pnpm 11.25.0 和 Hub 1.6.4，成功直接
+安装已发布 beta.6 URL，并回读两个包版本、四个 LoopX 行及真实 Web 宿主加载。
+直接安装不等于过期 Hub feed 的安装路径已通过。
+
+[Hub #102](https://github.com/dshplugin/dsh-plugin-hub/pull/102) 于 2026-10-07 合并；
+当前发布的 Hub 1.6.4 包含缺校验和的准确诊断、英中文恢复提示和实际执行命令回报。
+早期 packed candidate 已通过真实 macOS 失败弹窗及通知持久化回读。合成缺校验和
+lockfile 在 pnpm 12.6.0 下重现拒绝，`--force` 和 `--fix-lockfile` 也失败；保留旧文件
+并重新解析依赖后，在校验启用的前提下恢复安装。这不解释报告中的 Windows lockfile
+为何丢失校验和，也不自动修复既有 profile。
+[LoopX #6053](https://github.com/loopx-project/loopx/issues/6053) 使用 Hub 1.6.3 仍尝试
+beta.5，只有外层错误，尚不能归因到具体 pnpm 步骤。
+
+已发布包的原生 URL、旧兼容宿主到 0.2 的升级和离线 tgz 安装／卸载均有独立通过证据；
+干净 Linux 容器使用发布的 LoopX 1.2.4 wheel 验证私有 bootstrap、技能、认证和
+GoalBar 回读。真实 macOS 浏览器中的合成 Goal 与预配置唯一绑定已通过 Start/Pause
+并回读 `active`／`stopped`；未激活 Session 未增加模型 turn。这不验收模型驱动续跑、
+Windows 桌面完整旅程或网络故障恢复。2026-10-10 使用已发布 beta.6 与 Hub 1.6.4
+再次热卸载：依赖已删除，但撤销 `loopxBootstrap` 使共享 Web 行退出、浏览器断连。
+后续源码候选删除共享行的这一依赖，保留原生 Loader 启动等待和 LoopX Host／Driver
+内部等待。packed 真实 0.2.0-rc.2 与 0.1.5-rc.2 均通过延迟初始化后公布 URL、热停用后
+宿主仍在线且 LoopX 路由退场、整个插件禁用后冷启动。真实 macOS Hub 1.6.4 浏览器
+卸载完成、删除依赖，刷新后宿主仍在线。候选尚未发布；已发布 beta.6 仍应先关闭 DSH，
+用原生 CLI 卸载后重启。
+[#5671](https://github.com/loopx-project/loopx/issues/5671) 的 Windows desktop-host CLI
+模块缺失属于插件加载前的宿主打包边界，仍待 Windows／上游回读。
+L1 observer 仍只消费 `session/created`、
 `session/event`、`session/disposed`；兼容性修复不关闭另行预算的 C0/C1 或开销验收。
 
 ## 数据流与权限

@@ -57,11 +57,12 @@ and spends no model calls. For an explicit repair, the settled native
 not participate in installation or reload decisions.
 
 The init row publishes a typed `loopxBootstrap` service only after that
-success or safe failure settles. The plugin patch adds the service to the
-existing Web server and Web runtime injection lists, turning DSH's printed URL
-into the host-visible readiness boundary. The failure value contains only the
-safe stage and cause kind; it releases DSH startup without granting LoopX
-readiness or hiding the repair command.
+success or safe failure settles. Only LoopX's Host and Driver depend on this
+service. DSH's native Loader wait puts initialization before the printed URL;
+the shared Web server and runtime must remain independent of this optional
+package so disabling or uninstalling it cannot stop DSH. The failure value
+contains only the safe stage and cause kind; it settles initialization without
+granting LoopX readiness or hiding the repair command.
 
 The command accepts no free-form input. Invalid input returns the usage error
 before any followup or CLI probe. An exact invocation performs this bounded

@@ -77,9 +77,10 @@ cd packages/dsh-loopx-plugin
 
 Start DSH on loopback (port `0` asks the OS for a free port) and open the
 printed URL. The plugin finishes its idempotent LoopX CLI and skill bootstrap
-before DSH publishes the Web URL. Its typed `loopxBootstrap` service gates the
-Web server and runtime rows until startup has either succeeded or failed
-safely:
+before DSH publishes the Web URL through its native Loader readiness boundary.
+The source candidate gates only LoopX's Host and Driver on `loopxBootstrap`,
+so disabling or uninstalling it keeps the shared Web server and runtime alive.
+The published beta.6 limitation is described under automatic initialization:
 
 ```bash
 dsh --profile web --port 0
@@ -122,7 +123,10 @@ pnpm smoke:docker
 The runtime smoke creates an isolated temporary DSH profile. Its real web
 process proves profile composition, automatic initialization before readiness,
 immediate skill-catalog visibility, boot-manifest discovery, bundle serving,
-Client materialization, and the loopback Connection fence. Separately, a
+Client materialization, and the loopback Connection fence. A
+live-disable probe withdraws the bootstrap provider and all package rows while
+checking that DSH stays available and LoopX's route retires; a fresh process
+also boots with the whole package disabled. Separately, a
 packed supported-DSH Context, Connection, and WebServer with a live Host Session fixture
 cover same-turn binding discovery, lease-time source reconciliation,
 status-only updates, pending-watch cancellation, successful actions, and
@@ -144,16 +148,19 @@ never opens a browser or configures a model provider.
 
 ## Maintainer release and marketplace handoff
 
-A DSH plugin release needs an immutable prebuilt GitHub asset, a qualified
-marketplace install channel, and an update pull request against the upstream
+A DSH plugin release needs an immutable prebuilt GitHub asset and a qualified
+install channel in each marketplace named in its closeout. The
 [`awesome-dsh-plugin`](https://github.com/awesome-dsh-plugin/awesome-dsh-plugin)
-marketplace. Marketplace maintainers retain merge authority; publishing a
-LoopX release does not grant authority over that catalog. Released DSH Hub
-[v1.4.14](https://github.com/dshplugin/dsh-plugin-hub/releases/tag/v1.4.14) supports
-pinned GitHub release packages, so this route does not require publishing the
-LoopX plugin on npm. Its installed-state matcher still needs
-[Hub PR #98](https://github.com/dshplugin/dsh-plugin-hub/pull/98) to be merged
-and released. Qualification must read the online catalog back, select the
+directory and [DSH Plugin Hub](https://github.com/dshplugin/dsh-plugin-hub)
+have distinct published catalogs. Current Hub releases read
+`https://api.dsh-plugin.org/plugins.en.json` and `plugins.zh.json`; updating
+the awesome directory does not update those consumers. Marketplace maintainers
+retain authority over their own catalogs.
+
+Pinned GitHub release installation does not require publishing LoopX on npm.
+Release-URL installed-state matching shipped in
+[Hub 1.5.0](https://github.com/dshplugin/dsh-plugin-hub/releases/tag/v1.5.0).
+Qualification must read the actual marketplace's catalog back, select the
 pinned package, install it, recognize the installed row, update it and remove
 it successfully. The optional npm channel retains its separate account and
 trusted-publisher requirements.
@@ -200,15 +207,19 @@ For every DSH plugin release:
    The workflow requires a merged tag, consumes its GitHub asset without
    rebuilding, and verifies npm bytes and discovery. It neither creates a
    GitHub release nor replaces npm account ownership or the release guide gate.
-5. In a clean fork branch of `awesome-dsh-plugin`, update only
+5. For the awesome directory, in a clean fork branch of `awesome-dsh-plugin`, update only
    `data/plugins/loopx-project__loopx--packages-dsh-loopx-plugin.yml` to the new
    immutable asset URL. Confirm the URL resolves, then run
    `node scripts/generate-readme.mjs --check` and `git diff --check`.
-6. Open an upstream marketplace pull request and link it from the release
-   closeout. Do not describe the release as marketplace-published until that
-   pull request is merged by the upstream maintainers and the installed
-   marketplace resolves the released package. A catalog listing alone does
-   not prove that its installer consumes the pinned release command.
+6. Open the upstream directory pull request and link it from the release
+   closeout. Separately verify the installed Hub's catalog source at the
+   released Hub revision. Read both language feeds and the website's install
+   command; for the LoopX row, check the `ic` and `igc` targets against the
+   immutable release URL. Route stale Hub metadata to its existing
+   [data-correction issue channel](https://github.com/dshplugin/dsh-plugin-hub/issues).
+   Keep that marketplace's adoption open until its actual consumer resolves
+   and installs the released package. A merged directory PR, another catalog's
+   listing, or an upgraded Hub cannot establish that postcondition.
 
 ## Shadow observer (default off)
 
@@ -290,12 +301,18 @@ does not change LoopX core state by itself.
 
 When DSH loads the plugin, the init row runs the same typed initialization
 routine and publishes the `loopxBootstrap` readiness service only after it
-settles. The plugin's profile patch makes DSH's Web server and runtime depend
-on that service, so the printed URL is a real bootstrap boundary. A safe
-failure is logged without raw subprocess output or local paths, releases the
-Web rows instead of stopping DSH, and leaves `/loopx-init` registered for an
-explicit retry. Automatic startup does not create Agent followups or model
-calls.
+settles. DSH's native Loader wait keeps the printed URL behind initialization;
+the service is a dependency only of LoopX's Host and Driver. A safe failure is
+logged without raw subprocess output or local paths and leaves `/loopx-init`
+registered for an explicit retry. Disabling the package leaves LoopX's
+rows unavailable while DSH remains usable. Removing the package's
+rows releases its routes without stopping the shared Web server or runtime.
+Automatic startup does not create Agent followups or model calls.
+
+The host-isolation repair in this source is pending a new plugin release.
+Published beta.6 still adds the shared Web dependency and can disconnect DSH
+during hot uninstall, including with Hub 1.6.4. For that published package,
+close DSH, remove it with the native plugin CLI, then restart DSH.
 
 The repair command has no arguments. Extra input returns a usage error before any
 model work or CLI probe. A valid invocation queues a bounded start followup on

@@ -15,13 +15,6 @@
     - id: loopx-shadow-observer
       name: dsh-loopx-plugin/observer
 
-# The browser must not advertise readiness while first-run skill bootstrap is
-# still in flight. A safe bootstrap failure also publishes the service, so DSH
-# remains usable and /loopx-init can repair it.
-- id: webserver
-  name: '@deepseek-ai/dsh-host-webserver'
-  inject: [webStartup, loopxBootstrap]
-
-- id: web-runtime
-  name: '@deepseek-ai/dsh-web-app'
-  inject: [webStartup, loopxBootstrap]
+# DSH waits for the Loader tree before announcing its Web URL. Bootstrap gates
+# only LoopX's Host and Driver; shared Web rows must survive disabling or
+# uninstalling this optional package.