dsh-any-background 0.3.1 → 0.3.3

package/README.md

@@ -4,7 +4,7 @@
   <a href="https://www.npmjs.com/package/dsh-any-background"><img alt="npm version" src="https://img.shields.io/npm/v/dsh-any-background?color=4d6bfe"></a>
   <a href="https://www.npmjs.com/package/dsh-any-background"><img alt="npm monthly downloads" src="https://img.shields.io/npm/dm/dsh-any-background?color=4d6bfe"></a>
   <a href="https://github.com/Tkingxiao/dsh-any-background/blob/main/LICENSE"><img alt="License: MIT" src="https://img.shields.io/npm/l/dsh-any-background?color=4d6bfe"></a>
-  <a href="https://www.npmjs.com/package/@deepseek-ai/dsh?activeTab=versions"><img alt="Supported DSH versions: 0.1.5-rc.2 ~ 0.1.7-rc.1" src="https://img.shields.io/badge/DSH-0.1.5--rc.2%20~%200.1.7--rc.1-4d6bfe" /></a>
+  <a href="https://www.npmjs.com/package/@deepseek-ai/dsh?activeTab=versions"><img alt="Supported DSH versions: 0.1.5-rc.2 ~ 0.2.0-rc.1" src="https://img.shields.io/badge/DSH-0.1.5--rc.2%20~%200.2.0--rc.1-4d6bfe" /></a>
   <a href="https://github.com/topics/dsh-better-sidebar"><img alt="Plugin ecosystem: GitHub topic dsh-better-sidebar" src="https://img.shields.io/badge/plugin%20ecosystem-topic%20dsh--better--sidebar-4d6bfe" /></a><br /><br />
   <a href="https://github.com/Tkingxiao/dsh-any-background"><img src="https://img.shields.io/github/stars/Tkingxiao/dsh-any-background?style=social" alt="GitHub stars"></a>
   <a href="https://dsh.directory/plugins/tkingxiao/dsh-any-background"><img src="https://dsh.directory/badges/listed.svg" alt="dsh.directory listed"></a>
@@ -12,7 +12,7 @@
 
 English | [中文](README.zh.md)
 
-A **DeepSeek Harness** appearance plugin: custom theme color, background wallpaper (image / video / algorithmically generated), and fine-grained per-surface opacity & blur controls. Compatible with **DSH 0.1.5-rc.2 ~ 0.1.7-rc.1** (official-Sidebar UI such as the "Theme" card enables itself where the host exposes the Sidebar registry extension point, and is skipped silently where it does not).
+A **DeepSeek Harness** appearance plugin: custom theme color, background wallpaper (image / video / algorithmically generated), and fine-grained per-surface opacity & blur controls. Compatible with **DSH 0.1.5-rc.2 through the whole 0.1.7 line below 0.2.0, plus `0.2.0-rc.1`** (official-Sidebar UI such as the "Theme" card enables itself where the host exposes the Sidebar registry extension point, and is skipped silently where it does not).
 
 ---
 
@@ -91,33 +91,23 @@ A **DeepSeek Harness** appearance plugin: custom theme color, background wallpap
 
 ## Changelog (latest two releases)
 
-### v0.3.1 (Isolated per-version adaptation: one folder per host release)
-
-- **Front-loaded release detection**: resolving the host release and bucketing its channel now lives in `src/host-compat/` (the Node half reads the release out of the very `@deepseek-ai/dsh/package.json` the process was composed from — `ctx.profileContext.installAnchor` — falling back to the manifest beside the launcher's `homes/<ver>` and then to the directory name; the verdict travels in the `read` RPC payload), with `src/client/host-compat/` receiving it on the client, broadcasting changes, and re-cutting the static stylesheet the moment the verdict lands. Version logic that used to be spread across `src/client/host.ts` and its call sites is consolidated there; that module is gone.
-- **One folder per release**: under `src/client/host-compat/versions/`, the `v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `unknown` folders each describe that version's panel mechanics (which layer carries the promotion and the blur) and its header slot keys, and `versions/registry.ts` is the plugin's only release → code mapping. Base code only asks the adapter questions (who owns the guide surface, which slot selectors apply) and never compares version strings — supporting a new host means adding a folder and registering it, leaving base code untouched.
-- **Release identity is named down to the channel**: an adapter key is no longer a bare patch number like `0.1.5` but "patch line + prerelease channel" — `0.1.5-rc`, `0.1.6-alpha`, `0.1.7-alpha`. Each folder's mechanics were checked tag by tag against a specific channel, so recording `0.1.5-rc.3` and a hypothetical `0.1.5-beta.1` under one key would let an unverified shape inherit a verified conclusion. Folders and adapter ids now name the exact tags behind them (`v0-1-6-alpha-1-2` reporting `0.1.6-alpha.1/alpha.2`), so how far a table reaches is readable without opening it — and where two builds on one line genuinely differ (`leading` header slot and the plugin-manager page only exist from `0.1.6-alpha.2`), the folder carries that prerelease gate itself.
-- **Releases outside the verified table take the nearest adapter**: the `SUPPORTED_RELEASES` table in `src/host-compat/channel.ts` (`0.1.5-rc.2` / `0.1.6-alpha.2` / `0.1.7-alpha.2` / `0.1.7-rc.1`, oldest first — one row per build whose facts were checked, so one line may carry two) is matched by PATCH LINE first: a machine on `0.1.6-alpha.4` gets the `0.1.6-alpha` adapter even though verification stopped at `alpha.2`, because the number after the channel is only a build counter on that line — and `0.1.6-beta.1` or a future channel-less `0.1.6` count as the same line too. Only when no verified line covers the patch number does it clamp: newer than the newest → that newest adapter, older than the oldest → the oldest, strictly between two → the LOWER one, since an adapter may only claim what it was verified for. A clamped verdict logs one line saying the host is outside the verified range and which adapter is standing in, so a report against a new host build starts from that fact. Falling into `unknown` — where the DOM arbitrates — is left for the case where no release parses at all (a plain `~/.dsh` install, for instance).
-- **`0.1.7-rc.1` joins the verified range without an adapter change**: diffed against `0.1.7-alpha.2`, every anchor this plugin matches is still emitted where it was, so the 0.1.7 folder only gained that build in its name (`v0-1-7-alpha-1-2-rc-1`) plus a `SUPPORTED_RELEASES` row — which turns an rc.1 host's verdict from `line` into `exact`. What did change is how the host reads the manifest: from rc.1 the profile composition checks each plugin's `@deepseek-ai/dsh*` `peerDependencies` against the running release and **disables its row before importing a single module** when a declared range does not match, the only way past that being an exact-version exemption the plugin manager stores in the profile's own `compatibility.json`. `engines.dsh` remains declarative, so the peer list is what decides whether the plugin runs — hence `|| 0.1.7-rc.1` on all seven `@deepseek-ai/dsh-*` peers.
-- **No `:has()` dependency once the host is known**: a resolved release emits its own targeted branches, ungated. That also fixes a latent problem: on an engine without `:has()` the previous gate dropped the panel promotion entirely on 0.1.5 / 0.1.6. An unresolvable release still falls into `unknown` and lets the DOM shape arbitrate (`:has()` dual arms) instead of guessing a version.
-- **Header popover selectors spelled once**: the top-bar surface list was duplicated three times inside `wallpaper.ts`; it is now composed once and shared by the opacity rule and the outline rule (the latter deliberately keeps the bare tag without `[role]`, with the reason documented in place). Slot keys come from the adapter, so the `leading` slot unique to `0.1.6-alpha.2` no longer leaks into base code.
-- **The plugin page's card list is framed**: `Settings → Plugins` renders each group's plugins in a `ul` that has no surface of its own, so with the settings surfaces faded the whole table floated straight on the wallpaper. Each group's list now gets what the composer capsule gets — a rounded frosted block on an `::before` underlay, painted from the settings-interface opacity and frosted by the settings blur (the page is a sibling of the settings dialog on 0.1.7, so reading the dialog's own token re-scope would have left it on the homepage alpha). It is contributed only by the adapters whose release ships that page, so the selector never rides a host that cannot match it.
-- **Fixed the wallpaper disappearing while the right Sidebar animates**: the AppFrame's own translucent background was cleared with an inline `background: transparent`, and the host's `style` rewrite during the sidebar open/close animation dropped it — the frame snapped back to an opaque layer, hiding the wallpaper and flattening every frost above it, because a `backdrop-filter` with nothing behind it has nothing to blur. The clear is a class rule with `!important` now, which the host's style writes cannot reach (measured on the live frame: `rgb(200,207,218)` opaque → `rgba(0,0,0,0)` with the class, opaque again without it).
-- **Fixed the chat card landing on a settings page at startup**: while no conversation view is mounted (starting the host with the settings panel open, for instance), the marker-less chat-card fallback picked "the largest scrollable element" by geometry — so the settings page got card chrome plus a frost underlay (`<div class="dab-part-underlay">`) spread over the whole window. The fallback can now only refine a conversation that already exists: with none of `[data-chat-flow]` / `[data-conversation-scroll]` / `[data-composer-seat]` / `[data-conversation-composer-overlay]` present in the center column it no longer guesses, and candidates inside the settings dialog are still rejected.
-- **Fixed the covered area of the per-part frosted blur**: the class rule for the hosting element was missing its leading dot (`dab-part-blur{isolation:isolate}`), so that layer never created a stacking context and the `z-index:-1` frost underlay fell into the page-level one — its sampling region and its painted position both stopped matching the surface (measured live: the host element's computed `isolation` was `auto`). With the dot restored, the frost stays inside its own surface. This defect predates v0.3.0.
-- Corrected several wrong assumptions about the host: the native right Sidebar and `ctx.sidebarRightTabs` are not a new-host feature (`0.1.5-rc.2` already ships them), and dockkit itself predates 0.1.7 — only its `host` / `empty` attributes are 0.1.7 markers.
-- README: the Compatibility section gains a "Isolated per-version adaptation" entry and Known limitations names the layer where version-specific selectors live; the intro no longer implies the official-Sidebar UI exists only on newer hosts.
-
-### v0.3.0 (DSH 0.1.7 adaptation, compatible with 0.1.5-rc.2 ~ 0.1.7-alpha.1)
-
-- **0.1.7 right Sidebar**: the host reworked that panel — it is now a *stationary* frame whose docked children (`[data-dockkit-host="dock"]` / `[data-dockkit-empty]`) carry the slide transform, and the panel no longer paints its own background. The plugin follows the new shape: the blur rides the sliding children so it travels with the sidebar instead of staying pinned, and the surface tokens are re-scoped where the panel actually renders. The previous unconditional `position:fixed` promotion was removed — on 0.1.7 it detached the panel from the animated track.
-- **0.1.6 right Sidebar blur restored**: `[data-dockkit-host]` only exists from 0.1.7, so the child-based blur selector matched nothing on 0.1.6 (which slides the panel itself). A second, `:has()`-gated arm now frosts the panel wrapper there, and the pre-0.1.7 promotion is re-applied only where it is needed.
-- **Gradient "shimmer" text is no longer flattened by the outline feature**: `-webkit-text-stroke` is inherited, so the conversation-frame rule reached the `background-clip: text` activity chrome — the "深度求索中" turn-status line (0.1.5/0.1.6) and the turn-process/shimmer rows (0.1.7) turned into a flat stroke-coloured blob. They are now explicitly exempt, matched by `[role="status"]`, `[data-turn-process]` and the TextShimmer marker.
-- **New "Header popovers" surface**: the Agent Team panel, background-job list, open-in-app / session-log menus and the subagent lineage tree get their own opacity + blur sliders, plus a matching outline group. Because these popovers are portalled to `<body>` (severed from the header) and 0.1.7 moved open-in-app to a portal and made the session-row menu a dynamic slot, a runtime tagger watches the stable `conversation.session.header*` slot anchors and marks the open popover. The exempt confirm dialogs and session-row menu are pinned opaque with real color literals — no self-referencing `var()` fallback, which is a CSS cycle that would render them fully transparent.
-- **Host release detection**: the client context exposes no host version (`window.__DSH_BOOT__.version` is a module-table tag, not a release), so the release plus a generation bucket is resolved on the Node half from the launcher's on-disk layout and handed to the client through the `read` RPC payload. Feature gates use it; when it cannot be determined they fall back to capability probing rather than guessing.
-- **Native support for the official right Sidebar**: a "Theme" card is contributed to the official Sidebar's guide page through its public extension points (a page type in `ctx.sidebarRightTabs` plus the keyed `sidebar.right.pane.tab` body seat), opening the same five pages as the settings panel. Active without dsh-better-sidebar; when that plugin is present, its own "Theme" page takes over and the official guide card withdraws itself. Registration waits on the service at runtime — hosts without the Sidebar registry API skip it silently, so older hosts are unaffected.
-- **The right-sidebar slider row follows the environment**: the Interface page's panel group (`panelOpacity` / `blurs.panel`) reads "右方侧边栏" (Right sidebar) without better-sidebar — driving the official right Sidebar's surface tokens and frosted blur on 0.1.5-rc.2 through 0.1.7 — and "bettersidebar" with it. The row is now always visible instead of hiding when better-sidebar is absent.
-- The better-sidebar presence probe no longer counts `[data-sidebar-right-panel]`: on every host generation that is the official right Sidebar's stable marker (present whenever a session is open), so counting it pinned the "bettersidebar" verdict to true forever.
-- Compatibility declarations now cover `0.1.5-rc.2`, `0.1.5-rc.3`, `0.1.6-alpha.1`, `0.1.6-alpha.2` and `0.1.7-alpha.1`; peerDependencies widened to span every generation of the client packages; `@deepseek-ai/dsh-home-paths` stays at the lockfile-consistent `^0.1.0-rc.6` (build-time only — the host injects its own copy at runtime).
+### v0.3.3 (Menu paint per release, DSH 0.2.0-rc.1 supported)
+
+- **The card and header sliders drive menus on `0.1.7-rc.2` again.** That build moved a menu's fill and frost onto a child layer and turned `--dsw-specific-menu` into an alias, so the token the plugin had always been writing was no longer read by anything on a menu. Which tokens a menu paints from, and which layer does the frosting, is now a fact each version folder supplies instead of an assumption baked into shared code.
+- **DSH `0.2.0-rc.1` is supported** — checked at the tag, then given its own folder and channel. The manifest names that one build rather than opening the whole 0.2.0 line: a release nobody diffed is a different host.
+- **Shimmer text survives the 0.2.0 rewrite**: the outline exemption gained `[data-shimmer]`, so the activity line is no longer drawn as two stacked copies.
+- **The plugin page's loading skeleton** gets the same frosted card as the list it stands in for.
+- Installing on a 0.2.0 host needs a `dsh web` restart: since `0.1.7-rc.1` the host decides whether a plugin loads from its peer ranges, and a release it does not name is disabled before a single module is imported.
+
+### v0.3.2 (Produced artifacts fully bound, 0.1.7-rc.2 loads again)
+
+- **The produced slider now covers every artifact 0.1.7 renders**: tool-detail cards, turn-event rows, diff blocks, the changed-files card, inline `code` frost and the hover preview window — that last one portals its card to `<body>`, which is why no slider reached it before.
+- **Code-card headers follow the theme again** instead of staying a pale slab that ignored the slider.
+- **dsh-better-sidebar's workbench now belongs to the produced slider**; the panel row means only the host's own right Sidebar.
+- **One artifact card no longer answers to two sliders** — its root reads the produced slider's own raw layer token.
+- **The composer stops carrying a stacking context once its blur returns to 0.**
+- **antd confirm dialogs are no longer mistaken for the settings panel**: they inherited its surface colour, frost and outline group, because the old selector only asked for the three ARIA attributes antd also emits.
+- **`0.1.7-rc.2` loads again, and later 0.1.x builds with it**: `engines.dsh`, the seven `@deepseek-ai/dsh-*` peers and `dsh.compatibility` now close with `|| 0.1.7-rc.2 || >=0.1.7-alpha.1 <0.2.0-alpha.0` — a bare `>=0.1.7` would match no prerelease build at all.
 
 ## Installation
 
@@ -161,8 +151,8 @@ pnpm dsh web
 
 ## Compatibility
 
-- **[`dsh web`](https://github.com/deepseek-ai/deepseek-harness) 0.1.5-rc.2 ~ 0.1.7-rc.1** — The range covers all seven published releases (`0.1.6-alpha.2` and `0.1.7-alpha.1` / `0.1.7-alpha.2` verified hands-on, `0.1.7-rc.1` verified by diffing it against `0.1.7-alpha.2`); `engines.dsh`, the `@deepseek-ai/dsh-*` `peerDependencies` and `dsh.compatibility.dshReleases` list them explicitly — from `0.1.7-rc.1` the host itself enforces the peer list, so naming a release there is what makes the plugin load, not documentation. The host release is resolved on the Node half at runtime, and features that depend on a specific host release channel (the right Sidebar's panel blur, the official Sidebar's "Theme" card) enable themselves only where the corresponding host structure exists; everything else behaves identically across the range.
-- **Isolated per-version adaptation**: the release is resolved on the Node half from the app manifest the process was composed from (`ctx.profileContext.installAnchor`, with the launcher's on-disk layout behind it — the client context exposes no version) and, once handed down through the `read` RPC, is routed only by the front-layer adapter — `src/host-compat/` detects and buckets channels, while `src/client/host-compat/versions/` holds **one folder per release** (`v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `unknown`), each describing that version's panel mechanics and header slot keys. Base code just asks the adapter questions (who owns the guide surface, which layer carries the blur) and never compares version strings. Another build on a verified patch line (`0.1.6-alpha.4` against a table checked at `alpha.2`) keeps that line's adapter, and a patch line nothing was checked against clamps to the nearest one with a log line saying so. Only a release that will not parse at all falls into `unknown` and probes the DOM shape instead of guessing (`:has()` dual arms); supporting a new host means adding one folder and registering it.
+- **[`dsh web`](https://github.com/deepseek-ai/deepseek-harness) 0.1.5-rc.2 ~ &lt;0.2.0, plus `0.2.0-rc.1`** — `engines.dsh`, the seven `@deepseek-ai/dsh-*` `peerDependencies` and `dsh.compatibility.dsh` list the `0.1.5-rc` and `0.1.6-alpha` builds this plugin has been checked against one by one, close that part of the range with `>=0.1.7-alpha.1 <0.2.0-alpha.0` so every 0.1.7 release loads, and then name `0.2.0-rc.1` on its own — the umbrella stops below 0.2.0 deliberately, because a 0.2.0 build this plugin has not diffed is a different host and its facts belong in their own folder. `0.1.7-rc.1` / `0.1.7-rc.2` and `0.2.0-rc.1` were checked by diffing their tags, the builds before them hands-on. From `0.1.7-rc.1` the host itself enforces that peer list — a release the ranges do not name is disabled before its modules are imported — so naming it is what makes the plugin load, not documentation; the declarations in `dsh.compatibility.dshReleases` record which builds were checked. That enforcement is also why a machine already on 0.2.0 needs a plugin release (or a manual exact-version exemption) *and* a host restart: the check runs while the profile is composed, not when the plugin is updated. The host release is resolved on the Node half at runtime, and features that depend on a specific host release channel (the right Sidebar's panel blur, the official Sidebar's "Theme" card) enable themselves only where the corresponding host structure exists; everything else behaves identically across the range.
+- **Isolated per-version adaptation**: the release is resolved on the Node half from the app manifest the process was composed from (`ctx.profileContext.installAnchor`, with the launcher's on-disk layout behind it — the client context exposes no version) and, once handed down through the `read` RPC, is routed only by the front-layer adapter — `src/host-compat/` detects and buckets channels, while `src/client/host-compat/versions/` holds **one folder per release** (`v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `v0-1-7-rc-2` / `v0-2-0-rc-1` / `unknown`), each describing that version's panel mechanics, header slot keys, plugin-page shape and where a menu's paint lives. Base code just asks the adapter questions (who owns the guide surface, which layer carries the blur, which token fades a menu) and never compares version strings. Another build on a verified patch line (`0.1.6-alpha.4` against a table checked at `alpha.2`) keeps that line's adapter, and a patch line nothing was checked against clamps to the nearest one with a log line saying so. Only a release that will not parse at all falls into `unknown` and probes the DOM shape instead of guessing (`:has()` dual arms); supporting a new host means adding one folder and registering it.
 - **[DSHA](https://github.com/DSH-APP/DSHA)** — DeepSeek Harness Android launcher (ROOT-free, Termux-free). Its bundled `dsh` is `0.1.5-rc.2`, inside the supported range; the mobile UI shell is provided by `dsh-web-mobile`.
 - **[deepseek-harness-desktop](https://github.com/anywhere-labs/deepseek-harness-desktop)** — Supported
 

package/README.zh.md

@@ -4,7 +4,7 @@
   <a href="https://www.npmjs.com/package/dsh-any-background"><img alt="npm 版本" src="https://img.shields.io/npm/v/dsh-any-background?color=4d6bfe"></a>
   <a href="https://www.npmjs.com/package/dsh-any-background"><img alt="npm 月下载量" src="https://img.shields.io/npm/dm/dsh-any-background?color=4d6bfe"></a>
   <a href="https://github.com/Tkingxiao/dsh-any-background/blob/main/LICENSE"><img alt="License: MIT" src="https://img.shields.io/npm/l/dsh-any-background?color=4d6bfe"></a>
-  <a href="https://www.npmjs.com/package/@deepseek-ai/dsh?activeTab=versions"><img alt="支持的 DSH 版本：0.1.5-rc.2 ~ 0.1.7-rc.1" src="https://img.shields.io/badge/DSH-0.1.5--rc.2%20~%200.1.7--rc.1-4d6bfe" /></a>
+  <a href="https://www.npmjs.com/package/@deepseek-ai/dsh?activeTab=versions"><img alt="支持的 DSH 版本：0.1.5-rc.2 ~ 0.2.0-rc.1" src="https://img.shields.io/badge/DSH-0.1.5--rc.2%20~%200.2.0--rc.1-4d6bfe" /></a>
   <a href="https://github.com/topics/dsh-better-sidebar"><img alt="插件生态：GitHub topic dsh-better-sidebar" src="https://img.shields.io/badge/%E6%8F%92%E4%BB%B6%E7%94%9F%E6%80%81-topic%20dsh--better--sidebar-4d6bfe" /></a><br /><br />
   <a href="https://github.com/Tkingxiao/dsh-any-background"><img src="https://img.shields.io/github/stars/Tkingxiao/dsh-any-background?style=social" alt="GitHub stars"></a>
   <a href="https://dsh.directory/plugins/tkingxiao/dsh-any-background"><img src="https://dsh.directory/badges/listed.svg" alt="dsh.directory listed"></a>
@@ -12,7 +12,7 @@
 
 [English](README.md) | 中文
 
-一个 **DeepSeek Harness** 外观插件：自定义主题色、背景壁纸（图片 / 视频 / 算法动态生成），以及逐表面的透明度与模糊度控制。兼容 **DSH 0.1.5-rc.2 ~ 0.1.7-rc.1**（官方右侧栏「主题」卡片等界面按宿主是否提供右侧栏注册表扩展点自动启用，缺失时静默跳过）。
+一个 **DeepSeek Harness** 外观插件：自定义主题色、背景壁纸（图片 / 视频 / 算法动态生成），以及逐表面的透明度与模糊度控制。兼容 **DSH 0.1.5-rc.2 起、0.2.0 之前的整条 0.1.7 线，外加 `0.2.0-rc.1`**（官方右侧栏「主题」卡片等界面按宿主是否提供右侧栏注册表扩展点自动启用，缺失时静默跳过）。
 
 ---
 
@@ -89,35 +89,25 @@
 - **中英双语** — 完整的中英文界面，自动跟随语言设置。
 - **主题守护** — 宿主重置主题后自动重新激活自定义主题。
 
-## 更新日志（只保留最新两个版本）
-
-### v0.3.1（版本适配隔离：每个宿主版本一个目录）
-
-- **前置版本检测层**：宿主 release 的探测与渠道归类收进 `src/host-compat/`（Node 半侧读取进程所由以启动的那份 `@deepseek-ai/dsh/package.json`，即 `ctx.profileContext.installAnchor`，拿不到时再退回启动器 `homes/<ver>` 旁边 `versions/<ver>` 里的同名清单与目录名，经 `read` RPC 下发），客户端侧由 `src/client/host-compat/` 承接判定、广播变更，并在判定到达时重切静态样式表。原本散落在 `src/client/host.ts` 与各消费方里的版本判定统一到这一层，该模块已删除。
-- **每个版本一个独立目录**：`src/client/host-compat/versions/` 下 `v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `unknown` 各自描述本版本的面板力学（提升与模糊挂在哪一层）与头部槽位键，`versions/registry.ts` 是全插件唯一的「release → 代码」映射。底码只向适配层提问（引导页表面归谁、用哪些槽位选择器），不再出现版本字符串比较——适配新宿主等于新增一个目录并登记，底码不用动。
-- **版本标识细化到发布渠道**：适配键不再是 `0.1.5` 这种补丁号，而是「补丁行 + 预发布渠道」的 `0.1.5-rc` / `0.1.6-alpha` / `0.1.7-alpha`。理由是每个目录的力学都是照着某个具体渠道的 tag 逐条核对出来的，把 `0.1.5-rc.3` 与假想中的 `0.1.5-beta.1` 记成同一个键，等于让未核对过的形状继承已核对过的结论。目录名与适配器 id 现在也直接写出核对过的具体 tag（`v0-1-6-alpha-1-2`，id 报 `0.1.6-alpha.1/alpha.2`），不打开目录就知道这张表覆盖到哪一步；同一条补丁行内两个构建确有差别的地方（`leading` 槽位与插件管理页都只在 `0.1.6-alpha.2` 起存在）由该目录自己带预发布门控。
-- **落在已核对范围外的宿主按就近原则取档**：`src/host-compat/channel.ts` 里那张 `SUPPORTED_RELEASES` 表（`0.1.5-rc.2` / `0.1.6-alpha.2` / `0.1.7-alpha.2` / `0.1.7-rc.1`，从旧到新——一行记一个核对过事实的构建，所以同一条补丁行可以有两行）先按**补丁行**匹配：本机是 `0.1.6-alpha.4` 而表上只核对到 `0.1.6-alpha.2` 时，用的仍是 `0.1.6-alpha` 这一档（渠道序号只是同一条线里的构建计数，`0.1.6-alpha.1` 比核对基准更早的情况另有适配器就近处理）；`0.1.6-beta.1`、乃至假想中不带渠道的 `0.1.6` 也算同一条线，落回该线。整条补丁行都不在表上时才收边：高于最新一档取最新，低于最低一档取最低，夹在两档中间取**较低**的那一档（适配层只声明它核对过的东西）。这类收边判定会打一条日志说明「本宿主不在核对范围内，按 X 档处理」，新宿主报问题时应先看这行。只有**完全解析不到 release**（例如 `~/.dsh` 这种没有启动器布局的安装）才归入 `unknown`，交给 DOM 形状仲裁。
-- **`0.1.7-rc.1` 进入已核对范围，且不需要新的适配目录**：把它与 `0.1.7-alpha.2` 逐包比对后，本插件匹配的每个锚点都还在原处，所以 0.1.7 目录只是在名字里多记了这个构建（`v0-1-7-alpha-1-2-rc-1`），并在 `SUPPORTED_RELEASES` 里多一行——rc.1 宿主的判定因此从 `line` 变成 `exact`。真正变了的是宿主读清单的方式：从 rc.1 起，profile 组装阶段会把插件声明的 `@deepseek-ai/dsh*` `peerDependencies` 与运行版本比对，范围不匹配就**在导入任何模块之前把该插件整行禁用**，唯一放行办法是在插件管理器里授予「精确版本豁免」（写进 profile 自己的 `compatibility.json`）。`engines.dsh` 仍然只是声明，决定插件能不能加载的是 peer 列表——七个 `@deepseek-ai/dsh-*` peer 因此都补上 `|| 0.1.7-rc.1`。
-- **确定宿主版本时不再依赖 `:has()`**：解析到 release 的宿主直接发本版本的定位分支，不带 `:has()` 门。这顺带修掉一个潜在问题：在不支持 `:has()` 的引擎上，原来的门控会让 0.1.5 / 0.1.6 的面板提升整条失效。解析不到 release 时仍归入 `unknown`，由 DOM 形状（`:has()` 双臂）仲裁，而不是猜一个版本。
-- **头部浮层选择器单一来源**：顶栏表面的选择器此前在 `wallpaper.ts` 里重复了三份，现在拼一次、由透明度与描边两条规则共用（描边那条刻意用不加 `[role]` 的原始标记，原因就近写明）。槽位键改由适配器提供，`0.1.6-alpha.2` 独有的 `leading` 槽位不再散落在底码里。
-- **插件页的卡片列表加上块级底板**：`设置 → 插件` 里每组插件的 `ul` 自身没有表面，设置界面淡出后整张表直接浮在壁纸上。现在每个分组列表拿到与对话输入框同一套处理——`::before` 底板撑出圆角磨砂块，底色由「设置界面」这一组驱动、模糊由「设置模糊」驱动（0.1.7 上该页是 centerCol 的子节点而不是设置对话框的后代，只跟着对话框的令牌重挂就会读错滑块）。这条规则只由确实带该页的版本适配器发出，没有插件管理页的宿主不会背上匹配不到的选择器。
-- **修复展开右侧栏动画期间壁纸消失**：AppFrame 自身的半透明底色此前是用内联 `background: transparent` 抹掉的，而宿主在侧栏开合动画里重写 `style` 时把它丢了——框架回到不透明，壁纸被盖住，其上每一层磨砂同时被压平（`backdrop-filter` 背后没有内容就无从模糊）。现在改为带 `!important` 的 class 规则，宿主的 style 写入碰不到它（同一个 frame 现场实测：不透明 `rgb(200,207,218)` → 挂上 class 后 `rgba(0,0,0,0)`，去掉又回到不透明）。
-- **修复启动时「对话卡片」套到设置页上**：聊天视图尚未挂载时（例如开着设置面板启动），对话卡片的无标记回退会按几何挑「最大的可滚动元素」，于是设置里的页面被穿上卡片外壳、并挂上一层磨砂垫（`<div class="dab-part-underlay">`）覆盖整个窗口。现在回退只能细化**已经存在**的对话：中心列里找不到任何对话标记（`[data-chat-flow]` / `[data-conversation-scroll]` / `[data-composer-seat]` / `[data-conversation-composer-overlay]`）时不再靠几何猜；属于设置对话框表面的候选也一并拒绝。
-- **修复分部位毛玻璃的覆盖区域**：承载磨砂的元素那条类名规则漏写了开头的点（`dab-part-blur{isolation:isolate}`），所以该层从来没建立自己的层叠上下文，`z-index:-1` 的磨砂垫跑进了页面级的层叠上下文——模糊取样的范围和落位的位置都不再对应那个表面（现场实测宿主元素的 `isolation` 计算值为 `auto`）。补上点号后磨砂回到表面自身之内。这个缺陷早于 v0.3.0 就存在。
-- 更正了几条对宿主的错误假设：原生右侧栏与 `ctx.sidebarRightTabs` 并非新宿主特性（`0.1.5-rc.2` 即已提供），dockkit 本身也存在得更早——只有 `host` / `empty` 两个属性才是 0.1.7 的标记。
-- README：兼容性一节新增「版本适配隔离」条目，已知限制补充版本相关选择器的所在层；引言不再暗示官方右侧栏特性只出现在新宿主上。
-
-### v0.3.0（DSH 0.1.7 适配，兼容 0.1.5-rc.2 ~ 0.1.7-alpha.1）
-
-- **适配 0.1.7 官方右侧栏**：宿主重做了该面板——它现在是一个**静止外框**，滑动位移落在内部的 dockkit 子元素（`[data-dockkit-host="dock"]` / `[data-dockkit-empty]`）上，且面板本身不再绘制背景。插件随之调整：模糊改挂在真正滑动的子元素上，因此会跟随侧边栏一起移动而不是卡在原地；表面令牌也改为在面板实际渲染处重新作用域。原先无条件的 `position:fixed` 提升已移除——在 0.1.7 上它会让面板脱离动画轨道。
-- **修复 0.1.6 右方侧边栏模糊失效**：`[data-dockkit-host]` 从 0.1.7 才存在，所以基于子元素的选择器在 0.1.6 上匹配空集（0.1.6 的滑动打在面板自身）。现在新增一条用 `:has()` 门控的分支为面板包装元素加磨砂，且 pre-0.1.7 的提升只在真正需要处重新生效。
-- **修复流光文字被描边压成纯色**：`-webkit-text-stroke` 是继承属性，对话文本框的规则会一路继承到 `background-clip: text` 的活动状态文字上——「深度求索中」状态行（0.1.5/0.1.6）与轮次过程 / 流光行（0.1.7）会被糊成一块描边色。现在这些表面按 `[role="status"]`、`[data-turn-process]` 与 TextShimmer 标记被显式豁免。
-- **新增「顶栏选项」表面**：Agent Team 面板、后台任务列表、「用其它应用打开」/「会话日志」菜单与子代理血缘树拥有独立的透明度 + 模糊滑块，以及对应的描边分组。这些浮层被 portal 到 `<body>`（与头部断开），且 0.1.7 把「用其它应用打开」改为 portal、把会话行菜单改为动态槽位，因此插件新增一个运行时标记器，监听稳定的 `conversation.session.header*` 槽位锚点来标记展开的浮层。豁免的确认对话框与会话行菜单用真实颜色字面量钉死——不再使用自引用的 `var()` 回退，那是 CSS 循环，会让表面彻底透明。
-- **宿主版本探测**：客户端上下文不暴露宿主版本（`window.__DSH_BOOT__.version` 是模块表格式标记，不是 release），因此改由 Node 半侧从启动器的磁盘布局解析出 release 与渠道（`0.1.7-alpha` 这一级），再经 `read` RPC 下发。功能开关据此判定；无法确定时回退到能力探测，而不是猜一个版本。
-- **原生适配官方右侧栏**：通过官方公开扩展点（`ctx.sidebarRightTabs` 注册页面类型 + `sidebar.right.pane.tab` 键控槽位挂载页面本体）在官方侧边栏的引导页挂上「主题」卡片，点开就是和设置面板一样的五页。未安装 dsh-better-sidebar 时生效；装了 better-sidebar 则让位给它自己的「主题」页（官方引导页卡片自动撤下，不重复占位）。注册走运行时动态等待：宿主没有右侧栏注册表 API 时静默跳过，旧宿主不受影响。
-- **右方侧边栏栏位随环境改名**：界面页的面板分组（`panelOpacity` / `blurs.panel`）未安装 better-sidebar 时显示为「右方侧边栏」，直接驱动官方右侧栏的表面令牌与毛玻璃模糊（0.1.5-rc.2 至 0.1.7 均适用，该行现在始终显示）；安装了 better-sidebar 时改名为「bettersidebar」，语义不变。
-- better-sidebar 存在性探测摘除了 `[data-sidebar-right-panel]` 标记——各代宿主中它都是官方右侧栏的稳定标记（随会话始终存在），继续计数会让「bettersidebar」判定永远为真。
-- 兼容性声明现已覆盖 `0.1.5-rc.2`、`0.1.5-rc.3`、`0.1.6-alpha.1`、`0.1.6-alpha.2`、`0.1.7-alpha.1`；peerDependencies 放宽为同时覆盖各代客户端包版本；`@deepseek-ai/dsh-home-paths` 维持与 lockfile 一致的 `^0.1.0-rc.6`（仅构建期使用，运行时由宿主注入自身版本）。
+## 更新日志（只保留最近两个版本）
+
+### v0.3.3（菜单按版本交出绘制事实，支持 DSH 0.2.0-rc.1）
+
+- **`0.1.7-rc.2` 上「卡片」「顶栏选项」两组滑块对菜单又有效了**：那个构建把菜单的底色与磨砂移到子层，并把 `--dsw-specific-menu` 改成别名，插件一直在写的令牌在菜单上再没有别的读者。「菜单从哪些令牌取色、磨砂由哪一层承担」现在由每个版本目录各自交出，公共代码里不再留假设。
+- **支持 DSH `0.2.0-rc.1`**：逐 tag 核对后给它自己的目录与渠道。清单只点名这一个构建，不放开整条 0.2.0 线——没人比对过的版本就是另一个宿主。
+- **流光文字跟上 0.2.0 的重写**：描边豁免补入 `[data-shimmer]`，进度文字不再被勾成叠放的两份。
+- **插件页首屏的加载骨架屏**拿到与它所代替的那张卡片列表相同的磨砂底。
+- 装到 0.2.0 宿主上要重启 `dsh web`：从 `0.1.7-rc.1` 起宿主按 peer 范围决定插件能不能加载，没被点名的版本在导入任何模块之前就被整行禁用。
+
+### v0.3.2（产出物表面全量绑定，0.1.7-rc.2 恢复加载）
+
+- **产出物滑块覆盖 0.1.7 渲染的每一件产物**：工具详情卡片、事件行、diff 块、变更文件卡片、内联 `code` 磨砂，以及悬浮预览窗——它把卡片 portal 到 `<body>`，所以此前不归任何滑块管。
+- **代码卡片的头部横幅恢复跟随主题**，不再是一块无视滑块的近白条。
+- **dsh-better-sidebar 的工作台改由产出物滑块接管**；面板行现在只代表宿主自己的右侧栏。
+- **一张产物卡片不再同时听两个滑块**：它的根节点改读产出物自己的原始层级令牌。
+- **输入框模糊回到 0 之后不再残留层叠上下文。**
+- **antd 的确认弹窗不再被当成设置面板**：它原先继承了设置表面色、磨砂与描边分组，因为旧选择器只认那三个 antd 同样会发出的 ARIA 属性。
+- **`0.1.7-rc.2` 恢复加载，其后的 0.1.x 一并放行**：`engines.dsh`、七个 `@deepseek-ai/dsh-*` peer 与 `dsh.compatibility` 都以 `|| 0.1.7-rc.2 || >=0.1.7-alpha.1 <0.2.0-alpha.0` 收尾——只写 `>=0.1.7` 一个预发布构建都匹配不到。
 
 ## 安装
 
@@ -161,8 +151,8 @@ pnpm dsh web
 
 ## 兼容性
 
-- **[`dsh web`](https://github.com/deepseek-ai/deepseek-harness) 0.1.5-rc.2 ~ 0.1.7-rc.1** — 兼容范围覆盖全部七个已发布版本（`0.1.6-alpha.2` 与 `0.1.7-alpha.1`、`0.1.7-alpha.2` 已实测验证，`0.1.7-rc.1` 以逐包比对核对）；`engines.dsh`、`@deepseek-ai/dsh-*` 的 `peerDependencies` 与 `dsh.compatibility.dshReleases` 都逐一列出——从 `0.1.7-rc.1` 起宿主自己就会按 peer 列表拒绝加载，列不列决定插件能不能跑，不是写给人看的说明。宿主版本在运行时由 Node 半侧解析，依赖特定宿主版本渠道的功能（右侧栏面板模糊、官方侧栏「主题」卡片）只在对应宿主结构存在时启用，其余功能在整个范围内表现一致。
-- **版本适配隔离**：release 由 Node 半侧从进程自身那份 `@deepseek-ai/dsh/package.json` 读出（客户端上下文不暴露版本；`ctx.profileContext.installAnchor` 指不到时退回启动器的磁盘布局），经 `read` RPC 下发后只由前置适配层路由——`src/host-compat/` 负责探测与渠道归类，`src/client/host-compat/versions/` 下**每个版本一个目录**（`v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `unknown`），各自描述该版本的面板力学与头部槽位键。底码只向适配层提问（引导页表面归谁、模糊挂在哪一层），不比较版本字符串。同一补丁行内的其它构建（`0.1.6-alpha.4` 之于核对基准 `0.1.6-alpha.2`）用该行的档位；整条补丁行都不在已核对范围内才收边取最近的一档并写日志。只有解析不到 release 时归入 `unknown`，回退到按 DOM 形状探测（`:has()` 双臂）而不是猜一个版本；适配新宿主 = 新增一个版本目录并在注册表登记。
+- **[`dsh web`](https://github.com/deepseek-ai/deepseek-harness) 0.1.5-rc.2 ~ &lt;0.2.0，外加 `0.2.0-rc.1`** — `engines.dsh`、七个 `@deepseek-ai/dsh-*` 的 `peerDependencies` 与 `dsh.compatibility.dsh` 先逐一列出本插件核对过的 `0.1.5-rc` 与 `0.1.6-alpha` 各构建，再以 `>=0.1.7-alpha.1 <0.2.0-alpha.0` 收尾让 0.1.7 全线加载，最后单独写上 `0.2.0-rc.1`——总括刻意停在 0.2.0 之前，因为没比对过的 0.2.0 构建就是另一个宿主，它的事实要由它自己的目录来写。`0.1.7-rc.1`、`0.1.7-rc.2`、`0.2.0-rc.1` 以逐包比对 tag 核对，它们之前的构建是实测过的。从 `0.1.7-rc.1` 起宿主自己强制这份 peer 列表——范围没写到的版本会在模块被导入之前整个禁用——所以列不列决定插件能不能跑，它不是写给人看的说明；`dsh.compatibility.dshReleases` 里则记录哪些构建真的核对过。同一道门禁也解释了为什么已经在 0.2.0 上的机器需要插件发版（或手工授予精确版本豁免）**并**重启宿主：检查发生在 profile 组装时，而不是插件更新时。宿主版本在运行时由 Node 半侧解析，依赖特定宿主版本渠道的功能（右侧栏面板模糊、官方侧栏「主题」卡片）只在对应宿主结构存在时启用，其余功能在整个范围内表现一致。
+- **版本适配隔离**：release 由 Node 半侧从进程自身那份 `@deepseek-ai/dsh/package.json` 读出（客户端上下文不暴露版本；`ctx.profileContext.installAnchor` 指不到时退回启动器的磁盘布局），经 `read` RPC 下发后只由前置适配层路由——`src/host-compat/` 负责探测与渠道归类，`src/client/host-compat/versions/` 下**每个版本一个目录**（`v0-1-5-rc-2-3` / `v0-1-6-alpha-1-2` / `v0-1-7-alpha-1-2-rc-1` / `v0-1-7-rc-2` / `v0-2-0-rc-1` / `unknown`），各自描述该版本的面板力学、头部槽位键、插件页形状，以及菜单的底色与磨砂落在哪一层。底码只向适配层提问（引导页表面归谁、模糊挂在哪一层、菜单该重写哪些令牌），不比较版本字符串。同一补丁行内的其它构建（`0.1.6-alpha.4` 之于核对基准 `0.1.6-alpha.2`）用该行的档位；整条补丁行都不在已核对范围内才收边取最近的一档并写日志。只有解析不到 release 时归入 `unknown`，回退到按 DOM 形状探测（`:has()` 双臂）而不是猜一个版本；适配新宿主 = 新增一个版本目录并在注册表登记。
 - **[DSHA](https://github.com/DSH-APP/DSHA)** — DeepSeek Harness 安卓启动器（免 ROOT、免 Termux）。其包内 dsh 为 `0.1.5-rc.2`，落在兼容范围内；移动端界面由 `dsh-web-mobile` 提供。
 - **[deepseek-harness-desktop](https://github.com/anywhere-labs/deepseek-harness-desktop)** — 支持