dsh-m 0.9.10 → 0.9.12

package/README.en.md

@@ -48,6 +48,15 @@ The default registry includes DSH Skins, ModSearch, the Lark / QQ / Weixin / WeC
 
 The restart chain below applies to **Web only** (Desktop takes effect via the official app lifecycle: after installing, quit and reopen the Desktop app — see the 0.9.0 section). After any mutation, the already-open Market and Installed views refresh the profile state together, keeping badges and cards in sync without closing and reopening the marketplace; a "⚡ Restart" banner appears — under systemd, the DSH launcher's `appExit` hook hands the restart back to a unit configured with `Restart=on-failure` or `Restart=always`, avoiding a `systemctl` helper inside the unit cgroup that is about to stop; if `appExit` is unavailable, the fallback uses a manager-owned transient `systemd-run` service and only then a detached helper. The client confirms the replacement by boot id and dismisses the banner, leaving DSH Web's own background connection recovery in control; it does not force a full-page reload during the auth/route handoff. The restart chain has been live-verified on the current DSH Web `0.2.0-rc.2` (2026-10-01): dsh-m probes the unit's `Restart=` policy, hands the stop back via `appExit`, the `status=75/TEMPFAIL` exit is caught by the Restart policy and auto-started, and after recovery the page reconnects in the background with the panel fully functional. Historical scope: the `0.1.5-rc.1` era covered live `/dshm` ping and authenticated `303 → 200` checks; `0.1.2-rc.1` is covered by contract checks plus runtime shape-detection fallback (see the verified array) — with the deployment moved on, no live E2E is chased on retired generations; the transient `systemd-run` fallback only applies to hosts without `appExit` (all supported generations provide it) and stays a documented fallback rather than a release gate; repeated install/uninstall is covered by the profile-transaction test surface (compensation, post-install guard, 813 cases) plus the 0.4.0→0.4.2 consecutive-release evidence. Installs stream live pnpm progress (resolve → download → link → build).
 
+### Changed in 0.9.12 — re-issue of 0.9.11
+
+0.9.11 hit a npmjs ghost publish: the OIDC publish was accepted and **staged** (CLI exit 0, provenance published to the transparency log) but never committed into the registry — GET 404, and re-publishing the same version is rejected with 409 `Cannot publish over previously staged version`. After waiting out any propagation, the standard workaround applies: re-issue under a new number. **Content is identical to 0.9.11: settings force-refresh no longer takes down the community catalog card.**
+
+### Fixed in 0.9.11 — Settings "force refresh" no longer takes down the community catalog card (force semantics belong to the curated chain only)
+
+- **Scenario**: on a weak network, clicking the curated registry card's force refresh also flipped the community catalog card to "unavailable / fetch timeout" — the host forwarded `force` into the community summary, restarting its fetch flight; under a weak network the flight couldn't finish within the 3s waiter, which returned the timeout placeholder (the flight itself keeps running under its 30s hard cap and self-heals).
+- **Fix**: the `registry` force is no longer forwarded to the community summary — force semantics belong to the curated chain; the community catalog keeps its own TTL/shared-flight cadence (a first-ever load on a terrible network can still transiently time out, but force refresh no longer triggers it).
+
 ### Fixed in 0.9.10 — Desktop self-upgrade hitting the official supply-chain release-age policy now yields an honest wait guide
 
 - **Scenario**: clicking the upgrade chip routes through the official manager, whose pnpm supply-chain policy (`minimumReleaseAge`, releases must age 24h before installation) rejected the just-published version — `ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION`. **The policy is working as designed** (anti-supply-chain-attack release waiting period); dsh-m just dumped a screen of raw pnpm output as a generic failure.

package/README.md

@@ -48,6 +48,15 @@
 
 以下重启链路仅适用于 **Web**（Desktop 的生效走官方应用生命周期：安装完成后退出并重新打开 Desktop 应用即可，见 0.9.0 节）。安装 / 卸载 / 升级完成后，当前已打开的市场页与已装页会一起重新读取 profile 状态并同步徽标/卡片，不需要关闭后重新打开插件市场；随后出现「⚡ 一键重启」横幅——受 systemd 管理时通过 DSH launcher 的 `appExit` 交给服务的 `Restart` 策略，避免在待停止 unit 的 cgroup 内启动 `systemctl` helper；无 `appExit` 的 systemd 兜底改用 manager-owned transient `systemd-run`，最后才退回 detached-helper。客户端按 boot id 确认新进程已恢复后关闭横幅，交由 DSH Web 自身的后台连接重试恢复页面，不强制整页刷新，避免认证/路由切换期间白屏。重启链路已在当前 DSH Web `0.2.0-rc.2` 实机核验（2026-10-01）：dsh-m 探测 unit `Restart=` 策略后经 `appExit` 交还 systemd，`status=75/TEMPFAIL` 退出由 Restart 策略接住自动拉起，服务恢复后页面后台重连、面板全功能可用。历史口径：`0.1.5-rc.1` 时代已核验 `/dshm` ping 与带认证 `303 → 200`；`0.1.2-rc.1` 按契约核对 + 形态探测兜底收录（verified 数组），部署面演进后不再追旧代 live E2E；transient `systemd-run` 兜底仅适用于无 `appExit` 的宿主（受支持代际均提供 `appExit`），保持设计兜底而非发布门槛；连续安装/卸载由 profile 事务测试面（补偿事务、装后守卫等 813 用例）与 0.4.0→0.4.2 连续发布实证覆盖。安装过程实时显示 pnpm 进度（解析 → 下载 → 链接 → 构建）。
 
+### 0.9.12 变更：0.9.11 的重发
+
+0.9.11 在 npmjs 遭遇幽灵发布：OIDC 发布被受理并 **staged**（CLI exit 0、provenance 已上 Transparency Log），但从未 commit 进注册表——GET 404、同版本重发 409 `Cannot publish over previously staged version`。等待自愈无果后按标准解法换号重发。**内容与 0.9.11 完全一致：设置页「强制刷新」不再连坐社区清单卡。**
+
+### 0.9.11 修复：设置页「强制刷新」不再连坐社区清单卡（force 语义只属精选链）
+
+- **场景**：弱网下点精选清单的「强制刷新」，社区清单卡跟着变「不可用 + 获取超时」——根因是 host 把 `force` 一路透传给社区目录 summary，强制重开获取 flight；弱网下 flight 3s 完不成，waiter 超时返回占位摘要（flight 本身在后台 30s hard cap 内继续，跑完即自愈）。
+- **修复**：`registry` 的 force 不再透传社区 summary——「强制刷新」语义只属精选链（registry 链）；社区目录走自己的 TTL/共享 flight（首次打开等边界场景在极差网络下仍可能瞬时超时，但强刷不再触发）。
+
 ### 0.9.10 修复：Desktop 自升级撞上官方供应链等待期（minimumReleaseAge）→ 诚实指引发成可读
 
 - **场景**：点升级角标走官方管理器时，desktop profile 的 pnpm 供应链策略（`minimumReleaseAge`，发布满 24h 才可安装）拒绝了刚发布的版本——`ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION`。**这是策略在正确工作**（防供应链攻击的发布等待期），不是故障；但 dsh-m 此前把它当普通失败甩一屏 pnpm 原文。

package/lib/core/host-api.js

@@ -308,9 +308,12 @@ export function createApiDispatcher(ctx) {
                     await ctx.controller.ensureReady();
                     const snap = await ctx.controller.snapshot({ force: boolArg(body.force), signal });
                     // 社区 summary：primaryEntries 直接取本次 snapshot（displaced 与本次响应同代，不重拉主清单）；
-                    // 3s 是本 waiter 的等待上限——到点返回 unavailable summary，主清单响应按契约照常返回
+                    // 3s 是本 waiter 的等待上限——到点返回 unavailable summary，主清单响应按契约照常返回。
+                    // 0.9.11：不再透传 force——「强制刷新」语义是精选清单（registry 链），社区目录走自己的
+                    // TTL/共享 flight；此前 force 连坐会在弱网下把社区卡打成 3s 超时的「不可用」占位
+                    // （Windows 实机 2026-10-01：点强制刷新 → 社区卡「获取超时」，flight 后台自愈前一直报错）。
                     const community = await d.getCommunitySummary(snap.loaded.registry.plugins, cfg(), {
-                        force: boolArg(body.force),
+                        force: false,
                         signal,
                         deadlineAt: Date.now() + 3_000,
                     });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-m",
-  "version": "0.9.10",
+  "version": "0.9.12",
   "description": "可自定义收录清单的 DSH 插件市场：收录、安装、卸载、升级一站完成，附 agent 工具与 dshm CLI。",
   "license": "MIT",
   "type": "module",