dsh-settings-order 0.2.6

dsh-settings-order 0.2.6 — 0.2.0 exercised on both harnesses, and a claim corrected.

Docs only; no code change. lib/index.js and lib/client.js are unchanged from
0.2.2, so this release changes nothing about behaviour.

Fixed

• A wrong claim in the 0.2.3 entry. It said 0.2.0-rc.2 "satisfied neither
  settings peer" and that the widened range was what unblocked the install. That
  was measured with default semver. DSH's real audit — dsh-app-boot's
  evaluatePluginCompatibility — inspects only @deepseek-ai/dsh* peers and
  compares with semver.satisfies(runtime, range, { includePrerelease: true }),
  under which 0.2.0-rc.2 already satisfied the existing ranges. So 0.2.2 was
  never blocked on a 0.2.0 host.
  The widened range is still right to keep — it states the support explicitly
  rather than leaning on prerelease comparison, and stays correct once 0.2.0 ships
  stable — but it was never the difference between installing and not.
  更正此前对 peer 范围的判断。

Verified

• The Web harness at 0.2.0-rc.2, not just the Desktop build: the web profile
  was upgraded from 0.1.7-rc.1 to 0.2.0-rc.2, the plugin (0.2.2) is present in the
  boot payload and its client bundle is served, and the startup is free of
  incompatible, failed to apply and register is not a function.
  Three unrelated plugins in that profile — dsh-backup@0.13.1,
  dsh-cost-meter@1.7.37, dsh-memory-vault@0.1.5 — really were blocked by their
  own 0.1.x-only peers and needed dsh plugin allow-version exemptions, which is
  what distinguishes them from this plugin.
  Web harness 0.2.0-rc.2 上的实测结果。

• Both READMEs now carry a compatibility table (Desktop 0.2.0-rc.2, Web
  0.2.0-rc.2, Web 0.1.7-rc.1) and name the audit rule, so a future reader checks
  a peer range the way the harness does instead of guessing from default semver.

Verification: npm run check (bundle in sync), npm test (23/23),
npm pack (18 files, 0.2.6).

dsh-settings-order 0.2.5

dsh-settings-order 0.2.5 — the npm install path is now the documented default.

0.2.4 is on the npm registry as dsh-settings-order (published by the
jackozou account). This release makes the registry the first install option in
both READMEs.

Added

• npm distribution: dsh-settings-order on registry.npmjs.org (0.2.4 is the
  first npm release). Both READMEs now lead with
  dsh plugin --profile web add dsh-settings-order, and dsh-settings-order@0.2.5
  to pin. The DSH Desktop section uses dsh-settings-order@0.2.5 as well,
  through the app's own CLI.
  现在可以直接从 npm 安装：dsh plugin --profile web add dsh-settings-order。
• homepage, bugs and publishConfig.access: public, so the npm page links
  back to the GitHub repository and its issue tracker.

Changed

• The Desktop install snippet uses a concrete, copy-pasteable path
  (D:\DSH Desktop\resources\runtime\cli\bin\dsh.cmd) instead of a relative
  $env:LOCALAPPDATA\..\..\… expression that only happened to resolve on one
  machine.

Verification: npm run check (bundle in sync), npm test (23/23),
npm pack (18 files, 0.2.5). The 0.2.4 npm tarball was verified by downloading
it back from the registry: volatile Config, the configForms transport, the
legacy settingsScope fallback, the refused-false path and the 0.2.0 peer
range are all present.

dsh-settings-order 0.2.4

dsh-settings-order 0.2.4 — documentation only.

No code changed. This release records how to install into a DSH Desktop profile
and turns the 0.2.0-rc.2 note from "API checked" into "verified end to end".

Added

• A DSH Desktop install section in both READMEs. The Desktop build carries its
  own harness (0.2.0-rc.2 bundles the whole @deepseek-ai/dsh-* set at that
  version) and its own desktop profile, so the npm-installed dsh cannot
  install into it: it boots a different harness and refuses even to read that
  profile (error: profile "desktop" is managed exclusively by the Electron application). The section documents the app's own CLI
  (<install>\resources\runtime\cli\bin\dsh.cmd), why it must be that one — the
  Desktop profile's lockfile is the app's to write, under its bundled pnpm — and
  that the app must be restarted, because the host half registers at boot and the
  client bundles are served from a boot-time snapshot.
  桌面版要用它自带的 CLI 装进 desktop profile，装完必须重启应用。

Changed

• The compatibility notes now state the end-to-end result: on DSH Desktop
  0.2.0-rc.2 the navigation footer renders, and a reorder is persisted into
  ~/.dsh/profiles/desktop/cordis.patch.yml under settings-order.config.order.
  That file is the proof — a rejected or missing transport would have kept the
  order in browser-local storage and never written it.
  已在桌面版 0.2.0-rc.2 端到端验证：页脚出现，顺序落盘到 profile 补丁。
• Both READMEs say plainly that the DOM-layer npm run e2e:dom harness is not
  part of CI (it needs playwright-core and a matching chromium).

Verification: npm run check (bundle in sync), npm test (23/23),
npm pack (18 files, 0.2.4).

dsh-settings-order 0.2.3

dsh-settings-order 0.2.3 — declare support for the DSH 0.2.0 line.

The DSH Desktop build already runs the harness at 0.2.0 (0.2.0-rc.2 bundles every
@deepseek-ai/dsh-* package at that version). The plugin code was checked against
that payload and is compatible; the declared peer ranges were not, because they
ended at <0.2.0 and a semver prerelease only matches a comparator that names its
own tuple.

Fixed

• The optional peers for @deepseek-ai/dsh-settings and
  @deepseek-ai/dsh-client-ui-settings now carry || >=0.2.0-rc.1 <0.3.0
  alongside the 0.1.x lines, so a 0.2.0-rc host (the Desktop build, for example)
  no longer reports a peer mismatch. 0.2.0-rc 的宿主不再报 peer 不匹配。
• The contract test asserts both prerelease lines, so removing either fails.

Verified against the DSH Desktop 0.2.0-rc.2 payload (resources/app.asar)

• the settings domain still exports SettingsForms and isVolatilePath, and
  still has no register() — so the host half's volatile Config and its legacy
  guard both stay correct; 宿主半的 volatile Config 与旧 API 守卫依然正确。
• the browser-side configForms service still serves get(entryId) with
  set(field, value), unset(field) and the loading | ready | unavailable
  snapshot status — so the client half's transport is right;
  客户端半的 configForms 传输依然成立。
• the Settings shell still renders _navList / _navCell / _navLabel, still
  keys rows by section id, and still reads
  ctx.slots.entries("settings.section") — so the DOM layer stays valid.
• 0.2.0 no longer ships .d.ts files in the published payload; the API was read
  from lib/index.js and lib/client.js.

Verification: npm run check (bundle in sync), npm test (23/23), npm pack
(18 files, 0.2.3). Still no end-to-end GUI run: this machine has no
playwright-core or matching chromium, so npm run e2e:dom remains unexecuted.

dsh-settings-order 0.2.2

dsh-settings-order 0.2.2 — host persistence restored on DSH 0.1.7.

DSH 0.1.7 replaced both halves of the settings transport this plugin used: the
host-side settings.register() namespace API is gone (schema-derived
SettingsForms now reads each loader plugin's Config), and the browser-side
settingsScope registry was replaced by the configForms service. This release
moves to both, keeping the legacy paths as fallbacks.

Fixed

• The host half exports Config with a volatile order field, so 0.1.7's
  SettingsForms exposes and persists the preference in the active profile patch
  (cordis.patch.yml, entry settings-order). 宿主半改为导出 volatile Config。
• The browser half reads and writes that entry through
  ctx.configForms.get('settings-order'); without this it found no transport,
  silently stayed on browser-local storage and never reached the host document.
  Legacy hosts keep the settingsScope.bind({ namespace }) path, and an
  unusable form falls through instead of throwing.
  浏览器半改用 configForms，旧宿主仍有 settingsScope 回退。
• A Host refusal reported as a resolved false (the 0.1.7 contract; only
  transport failures reject) is no longer treated as saved: the refusal keeps
  the gesture effective for this browser and shows 保存失败，仅本浏览器生效.
  宿主以 false 拒绝写入时不再被当作保存成功。
• Optional peer ranges admit the 0.1.7 prerelease line for dsh-settings and
  dsh-client-ui-settings.
• Both READMEs now name the active profile patch (not the removed
  ~/.dsh/settings.yaml) as the persistence location, and state plainly that the
  API was checked against installed 0.1.7-rc.1 source/types rather than a live
  GUI end-to-end run.

Verification: npm run check (bundle in sync), npm test (23/23),
npm pack (18 files, 0.2.2). The new contract tests pin the configForms
transport, the legacy fallback and the refused-write path; the installed-host
block checks the 0.1.7 schema-derived SettingsForms API against the local DSH.

dsh-settings-order 0.2.1

dsh-settings-order 0.2.1 — four interaction-layer fixes.

Fixed

• A rejected host write no longer rolls the rows back: the order is marked
  pendingLocal and refresh() refuses to adopt a host value that does not
  match it, so a rejected write stays effective instead of being silently
  overwritten once the 5-second echo window closes (and the footer no longer
  claims a browser-local store the plugin never reads back).
  宿主写被拒后不再在 echo 窗口结束时静默回滚。
• Dispose now removes the _navList drag/keyboard listeners and the
  data-dshso-bound marker, so a disabled or reloaded plugin leaves no ghost
  listeners that keep handling drags and Alt+Arrow (and can write through a dead
  scope). 卸载/重载后不再残留幽灵监听与幽灵写。
• Rapid ↑/↓ presses or a held Alt+Arrow no longer lose moves: both
  keyboard paths shift relative to the logical order (desiredOrder(nav))
  instead of the DOM order, which only catches up 50 ms later.
  50ms 同步窗口内的连击不再丢步。
• Label-fallback ids (label:<text>) are never persisted to the host
  namespace; commit() refuses such a list and the footer keeps showing
  无法识别设置项 while such a row is present (self-heals once the row is
  identifiable again). label 兜底 id 不再落盘。

Known issues (tracked for a later release; none loses data on its own)

• reset is unreachable while the slots service is unavailable.
• writeFailed / scopeUnbound diagnoses are sticky until the next commit().
• A host that echoes slower than the 5-second window can still cause a flicker.
• A drop trusts the dropAt captured by the last dragover.
• Alt+Arrow at the first/last row does not preventDefault().
• With no ctx.effect the plugin registers no cleanup at all.
• A selector mismatch (a shell rename of _navList / _navCell) stays silent.
• A transient getSnapshot() failure flashes the list back once.
• dragId can outlive its row if the drag source is removed mid-drag.

Verification: npm run check, npm test (18/18), npm run pack:check
(18 files, 0.2.1) and .scratch-home/awesome-pr/validate.cjs (ENTRY OK).

dsh-settings-order 0.2.0

[0.2.0] — 2026-09-23

Touch/remote support, visible degradation, and a test suite that pins the DSH
internals this plugin stands on.

Added

• Footer ↑ / ↓ controls that move the page you are currently viewing
  one place. A phone or remote browser has neither a mouse drag nor an Alt
  key, so those controls are the only workable path there — and they double as
  a discoverable alternative on the desktop.
• 恢复默认 / Reset action in the footer, offered only once the order
  differs from the shell's own. The built-in order is read live from
  ctx.slots.entries('settings.section'); when that slot service is not
  reachable the action stays hidden instead of guessing.
• Diagnoses in the footer for the two failure modes that used to be silent:
  rows the plugin cannot identify (无法识别设置项 (DSH 结构变化？)) and a
  rejected host write (保存失败，仅本浏览器生效).
• test/contract.test.mjs — pins the shell's _navList / _navCell /
  _navLabel suffixes, the row key (row.id), the active-row marker
  (aria-current), and SlotCore's priority-then-order list sort against the
  installed DSH, and imports the installed host half to check the namespace.
  Skips with a note when no DSH install is present (DSH_CORE_ROOT overrides).
• test/invariants.test.mjs — the served bundle is the built source, the patch
  mounts exactly one loader row, the browser half writes only order to the
  host and only its own two keys to localStorage, and the docs match the
  shipped version.
• .github/workflows/ci.yml — GitHub Actions on every push and pull request:
  npm run check (the served bundle is its own source) plus npm test, on Node
  22 and 24, with no install step because both scripts use Node built-ins only.
  The READMEs carry the badge; .gitignore, README.zh-CN.md and this changelog
  came with it.
• Tagged v0.2.0 with a GitHub release, and both READMEs now document the
  pinned install (…dsh-settings-order#v0.2.0), the requirements, what a
  successful install looks like on screen, and how to update.

Changed

• The one-line hint retires after the first successful reorder
  (localStorage: dsh.settings-order.hint-seen) instead of occupying the
  navigation footer forever.
• The footer became a compact control row plus one hint line, replacing the
  three-line hint block.
• package.json gained repository, keywords, engines, the test/e2e
  scripts and the published file list, and is no longer private.

Fixed

• A row whose React fiber is unreadable no longer disables the whole feature
  silently: identity falls back to the row's label text, and the failure is
  reported in the footer.
• The e2e suite no longer misreads a quoted YAML scalar
  ("@weibaohui/skills-management") as a failed host write, and no longer
  treats session-list churn in workspace.json as an ordering side effect.
  e2e/settings-order-e2e.mjs now snapshots the host order before it runs and
  restores it afterwards, so running it never rewrites the user's own order.
• The host-write assertions poll settings.yaml instead of trusting one
  fixed sleep, and report how long the write took (4–7 ms on a local instance).
  A second dsh web sharing an existing ~/.dsh accepts the change in memory
  but never rewrites the file — which looked like a plugin failure until the
  harness was pointed at an instance that owns its home.
• Both harnesses now dismiss the first-run overlays (beta notice, sidebar tip)
  before reaching for the Settings trigger, so they also run against a fresh
  DSH_HOME; the console filter ignores combo-bundle URL dumps that merely
  mention the plugin's name; the README illustration is captured as a
  dialog-side crop (docs/settings-order.png) instead of a full-window shot.
• The e2e order restore now walks each row through its keyboard path (focus
  the row, Alt+Arrow) and verifies every position, instead of clicking the
  footer controls: those act on the active page, so an activation that did not
  take moved a different row and left the restored order subtly wrong. The walk
  fails loudly when it cannot reach the requested order.
• No hard-coded local paths ship any more: the ops scripts derive the repository
  root from $PSScriptRoot (with a -Root override) and the README's
  scratch-home recipe is relative, so the published tree carries no
  author-machine layout — in the working tree or in history.