dsh-deeppilot 0.9.13 → 0.9.14

package/COMPATIBILITY.md

@@ -1,29 +1,33 @@
 # Compatibility
 
-This branch targets exactly **eight DSH releases**: `0.2.0-rc.2`; the `alpha`
-channel releases `0.2.1-alpha.3`, `0.2.1-alpha.4`, `0.2.1-alpha.5`, and
-`0.2.2-alpha.2`; and the `next` channel releases `0.2.1-rc.2`, `0.2.1-rc.3`, and
-`0.2.1-rc.4`. The npm channels have
-moved since: `latest` now points at `0.2.1-rc.2`, promoted from `next`, `next`
-at `0.2.1-rc.4`, and `alpha` at `0.2.2-alpha.2`. All eight are
-named in both `engines.dsh` and `peerDependencies`; no other version is accepted.
-DSH evaluates that declaration before composing a profile — on every start, not
-only on install — so a newly published DSH release deactivates this plugin until
-the list is widened deliberately. That is the intended trade: a plugin that
-cannot run on an unaudited host fails visibly instead of misbehaving quietly.
-The decision and the reversal it represents are recorded in
-the maintainers' local decision record `docs/adr/0001-dsh-compatibility-policy.md`, with the supporting audit in
+This branch accepts DSH hosts inside the rolling compatibility range
+`>=0.2.1-rc.5 <0.3.0-0`. The lower bound is the newest audited `rc` release at
+decision time — npm `latest` and `next` both point at `0.2.1-rc.5` — and every
+later `0.2.x` release is admitted without a per-release source audit, including
+the `alpha` channel release `0.2.2-alpha.2` and later alphas, later rc releases,
+and `0.2.x` GA. `0.3.0` and its prereleases stay refused until a fresh audit.
+The bound is written `<0.3.0-0` because DSH evaluates the range with
+`semver.satisfies(..., { includePrerelease: true })`, where `<0.3.0` would admit
+`0.3.0-rc.1`. The range is named in both `engines.dsh` and `peerDependencies`; a
+host outside it is refused. DSH evaluates that declaration before composing a
+profile — on every start, not only on install.
+
+This is a deliberate policy trade: a new DSH release inside the range activates
+without waiting for a per-release audit, so a breaking change inside `0.2.x`
+would surface at runtime instead of at the activation gate. The gate that
+remains is the `0.3.0` boundary. The decision, its predecessor policies, and the
+reversals are recorded in the maintainers' local decision record
+`docs/adr/0001-dsh-compatibility-policy.md`, with the supporting audits in
 [`docs/DSH_RELEASE_MEMORY.md`](./docs/DSH_RELEASE_MEMORY.md).
 
-The development packages this branch builds and typechecks against stay pinned
-to the exact release-candidate baseline, currently `0.2.0-rc.2`; the audited
-`alpha` and `rc` hosts are covered by the isolated composes and live runs
-recorded in the release memory.
+The development packages this branch builds and typechecks against are pinned to
+the lower bound, currently `0.2.1-rc.5`; the audited host lines above it are
+covered by the isolated composes and live runs recorded in the release memory.
 
 | Component | Current contract | Evidence |
 |---|---|---|
 | Node.js | 22 or newer | Package engine and CI |
-| DSH CLI and Host API | `engines.dsh` and `peerDependencies` both name `0.2.0-rc.2 \|\| 0.2.1-alpha.3 \|\| 0.2.1-alpha.4 \|\| 0.2.1-alpha.5 \|\| 0.2.1-rc.2 \|\| 0.2.1-rc.3 \|\| 0.2.1-rc.4 \|\| 0.2.2-alpha.2` (dev pins `0.2.0-rc.2`) | Peer metadata, source typecheck, unit tests, bundle build, and config schema projection against a real 0.2.0-rc.2 CLI, plus isolated composes and live phone-protocol runs with the published 0.2.1-alpha.2, 0.2.1-alpha.3, and 0.2.1-alpha.4 CLIs, an isolated 0.2.1-alpha.5 host where this plugin now composes, starts, and answers `/phone/health` with 200 on its own LAN listener, a pre-widening 0.2.1-rc.2 host run where the unchanged declaration is refused at compose time, an isolated 0.2.1-rc.3 host where the widened declaration composes, starts, and answers `/phone/health` with 200, and isolated 0.2.1-rc.4 and 0.2.2-alpha.2 hosts where the eight-release declaration does the same (audits below) |
+| DSH CLI and Host API | `engines.dsh` and `peerDependencies` both name the rolling range `>=0.2.1-rc.5 <0.3.0-0` (dev pins `0.2.1-rc.5`) | Peer metadata, source typecheck, unit tests, bundle build, and config schema projection against a real 0.2.1-rc.5 CLI, plus isolated composes and live phone-protocol runs across the audited hosts recorded below (0.2.1-alpha.2 through 0.2.2-alpha.2), a full-tree audit of 0.2.1-rc.5 against 0.2.1-rc.4, and an isolated rc.5 host that composes, starts, and answers `/phone/health` with 200 (`0.2.1-rc.5 audit outcome` below) |
 | DSH history read | `SessionController.inspect` when the host has it, `SessionController.page` otherwise | DSH 0.2.2-alpha.2 removed `inspect`; the adapter branches on its presence and maps the host page's `{type:'event',event}` records onto the bridge's `{event}` contract, expressing the phone's exclusive `beforeSeq` as the inclusive `throughSeq` cut. Unit tests cover both branches (audits below) |
 | iOS bridge | DeepPilot protocol v2 | Bridge protocol tests; device behavior must be checked with the running Host and app |
 | Remote access | Tailscale Funnel on ports 443, 8443, or 10000 | Helper and supervisor tests |
@@ -43,6 +47,7 @@ recorded in the release memory.
 - The current app accepts the `deeppilot://pair` link and the JSON pairing payload. Bearer authentication, URL credentials, and first-frame shared tokens are rejected; devices register a P-256 public key and sign each WebSocket challenge.
 - The plugin's persisted device and Funnel state migration remains separate from DSH API version support. Session logs written by earlier DSH builds are readable only when the current Host's own history reader accepts them; this plugin does not rewrite those logs.
 - An unavailable optional OS facility, transport, or controller disables its dependent capability without crashing the Host.
+- Binary frames (`welcome.capabilities.binaryFrames`) are a plugin-level option between this plugin and the phone and do not depend on the DSH Host. The phone opts in per request with `binary: true`; older apps never do and keep receiving base64 text frames byte-for-byte as before, and older plugins ignore the field. The Funnel helper is a standard reverse proxy and passes binary WebSocket frames through unchanged.
 
 ## Schedules ship with the Web composition
 
@@ -67,7 +72,23 @@ built. The bridge mounts on `sessionController` / `connection` /
 `typertGateway`, all of which become ready before the Schedule service finishes
 its own initialization, so a probe taken at that moment would report `false` for
 the bridge's whole lifetime. On a live host with the service mounted the bit is
-`true` and the schedule list/create/history/delete flow passes.
+`true` and the schedule list/create/history/delete flow passes on audited hosts
+up to `0.2.2-alpha.2`.
+
+**Known limitation on `0.2.2-alpha.3`.** That release moved automation to
+host-level task management and rewrote the `dsh-schedule` service: `update` and
+`delete` no longer exist (`edit({ action })` replaces them), `list` returns a
+page object instead of an array, `create` takes its request first, and the
+request body carries `timing` / `target` instead of the selector fields. The
+bridge now serves both contracts from one adapter chosen by service shape, not
+by version string: the legacy per-session path is unchanged, and the host-level
+path adds the optional `schedulesHost` capability with host-level frames
+(list / view / create / edit / run / limits) while projecting the legacy frames
+onto host-level tasks, so an older App keeps schedule list, create, edit and
+delete on that host. The wire contract is documented under
+[`PROTOCOL.md`](./PROTOCOL.md) "Schedule 宿主级任务扩展". The audit and the
+decision are recorded in
+[`docs/DSH_RELEASE_MEMORY.md`](./docs/DSH_RELEASE_MEMORY.md).
 
 ## Configuration migration
 
@@ -77,6 +98,79 @@ carries the old top-level `debug: true` is accepted but that value is ignored:
 verbose logging must be turned on again from the settings page. No other config
 field changed shape, and the old key is not read anywhere in this version.
 
+## 0.2.2-rc.1 audit outcome
+
+- **Same code as `0.2.2-alpha.3`.** 330 shared packages, zero structural
+  manifest changes, and only four non-manifest files differ (a build-commit
+  constant and three client bundles' version strings). The evaluator is
+  byte-identical, so the alpha.3 findings, including the host-level schedule
+  adapter, apply unchanged.
+- **Vendor peers.** The host vendors `cordis 4.1.0` and `schemastery 3.19.0`,
+  the alpha.3 code renumbered as releases. The ranges append `~4.1.0` and
+  `~3.19.0`; earlier clauses stay because earlier hosts still vendor them. DSH's
+  evaluator ignores both peers; only npm's install-time resolution reads them.
+- **Activation and boot.** The real rc.1 evaluator admits `0.9.14` and refuses
+  the published `0.9.13`. An isolated rc.1 host composes and starts the plugin,
+  and `/phone/health` answers 200 with `protocolVersion` 2.
+
+## 0.2.1-rc.5 audit outcome
+
+The artifact-level audit of `dsh-v0.2.1-rc.5` (published to the npm registry
+2026-10-29T14:15:23Z; GitHub Release 2026-10-30T02:12:26Z, whose notes mention
+only improved thinking-content display) against `dsh-v0.2.1-rc.4` found **no
+runtime break**. The tree stays at 307 packages.
+
+- **Whole-tree comparison.** 42,731 shared files: 42,421 byte-identical and 310
+  differing — 296 `package.json` files plus 14 non-manifest files in 7 packages;
+  one further file is new in rc.5 only
+  (`dsh-client-ui-chat/lib/types/client/reasoning-text.d.ts`, 363 B). `cordis`
+  and `schemastery` are byte-identical including their manifests, and the rc.4
+  tree fingerprint reproduced the previous audit's value, so both rounds compared
+  the same baseline.
+- **No contract change.** All 307 manifests have zero `structural` changes (the
+  comparison covers the full 11,099-leaf union); the 3,706 dependency-spec
+  changes are mechanical `0.2.1-rc.4 → 0.2.1-rc.5` replacements. The evaluator
+  `dsh-app-boot/lib/index.js` is byte-identical to rc.4 (sha256 `5135179a…`), so
+  the activation gate behaves exactly as before.
+- **The 15 non-manifest files (14 changed, 1 added) are outside this plugin's
+  surface.** `dsh-client-ui-chat` reworks the host's internal
+  `conversation.chat.reasoning.body` Slot (owner props gain `rawText`, and
+  reasoning text is stripped of its `<signature>` wrapper before display) plus
+  its types and three READMEs; `dsh-cordis-client-runner` updates the embedded
+  Slot registry metadata; `dsh-experimental-client-ui-cot-translation` changes
+  only JSDoc/type comments; `dsh-client-modules` changes a build-commit
+  constant; three settings/sidebar client bundles change only version strings
+  (same byte size). None of these packages is in the declaration surface (10
+  peers, 4 client injects, vendored cordis/schemastery) or the plugin call
+  surface, and a machine check over the 7 packages reports
+  `allOutsideDeclarationSurface`.
+- **Patch anchor unchanged.** `dsh-web-app/cordis.patch.yml` is byte-identical to
+  rc.4 (same 595 lines / 117 entries / sha256 `cdceb423…`), so the
+  `id: directory-picker` block this plugin disables is untouched.
+- **Export and client faces unchanged.** All 3,271 `lib/` modules and 681 entry
+  modules have identical export surfaces; the four client-injected packages are
+  byte-identical.
+- **Activation matrix.** The previous closed list rejected `0.2.1-rc.5`; the
+  rolling range admits it together with `0.2.2-alpha.2`, `0.2.1`, later rc and
+  alpha releases and `0.2.x` GA. Twelve candidates are newly admitted and
+  exactly the seven former list members are newly refused; `0.3.0-rc.1`,
+  `0.3.0`, `0.3.0-0`, and `1.0.0` stay refused. Every verdict matched an
+  independent semver calculation. The range also admits unaudited
+  `0.2.2`/`0.2.3` prereleases by construction (`0.2.2-alpha.1`,
+  `0.2.2-alpha.2.1`, `0.2.2-ALPHA.2`, `0.2.2-0`); this is the accepted cost of a
+  rolling range, not an evaluator quirk.
+- **Live load.** In an isolated `DSH_HOME` the rc.5 host composes the plugin
+  (`--dump-config` exit 0, no skip line), starts it, and the plugin's own LAN
+  listener answers `/phone/health` with 200; the isolated home receives
+  `deeppilot/host-id` and `deeppilot/lan-tls/`.
+- **Vendor peers.** rc.5 still vendors `cordis 4.0.5` and `schemastery 3.18.5`,
+  both already inside the declared ranges, so no vendor clause changed.
+- **Known boundary.** `dsh-client-ui-slots` has no artifact in either tree (same
+  as the rc.4 round), so it was not byte-compared; `react` was not compared; the
+  npm install-time resolution was not run.
+- **Evidence.** `.rc5-verify/AUDIT.md`, `.rc5-verify/HOST-BOOT.md`, and the JSON
+  logs beside them.
+
 ## 0.2.2-alpha.2 audit outcome
 
 The artifact-level audit of `dsh-v0.2.2-alpha.2` (published to the npm registry

package/README.md

@@ -39,25 +39,24 @@ Host on your own computer and does not replace or modify the DSH Web UI.
 
 ## Install from npm
 
-This source checkout targets Node.js 22+ and the eight DSH releases it has been
-audited against — `0.2.0-rc.2`, the `alpha` channel releases `0.2.1-alpha.3`,
-`0.2.1-alpha.4`, `0.2.1-alpha.5`, and `0.2.2-alpha.2`, and the `next` channel
-releases it has admitted in turn, `0.2.1-rc.2`, `0.2.1-rc.3`, and `0.2.1-rc.4` —
-with a `web` profile. (The npm channels move: `latest` now points at
-`0.2.1-rc.2`, which was promoted from `next`, `next` at `0.2.1-rc.4`, and
-`alpha` at `0.2.2-alpha.2`.) DSH checks a plugin's declared
-requirements before composing a profile, on every start rather than only on
-install, so any other host version refuses to activate this plugin. From DSH
-`0.2.1-alpha.4` on, that check reads `engines.dsh` and ignores
-`peerDependencies`; older hosts know only the peer range, so both name the same
-eight releases. The package includes Funnel helpers
-for macOS, Linux, and Windows on amd64/arm64; trusted-LAN mode does not require
-the helper. The helper is built with Go 1.27, which requires **macOS 13 Ventura
-or later**: on macOS 12 and earlier, Funnel mode cannot start, while
-trusted-LAN mode keeps working.
-
-The current working tree names exactly those six versions in `engines.dsh` and
-`peerDependencies` and is built/typechecked against `0.2.0-rc.2`. A previously
+This source checkout targets Node.js 22+ and DSH hosts inside the rolling
+compatibility range `>=0.2.1-rc.5 <0.3.0-0` with a `web` profile. The lower
+bound is the newest audited `rc` release at decision time — npm `latest` and
+`next` both point at `0.2.1-rc.5` — and every later `0.2.x` release is admitted
+automatically, including the `alpha` channel release `0.2.2-alpha.2` and later
+alphas, later rc releases, and `0.2.x` GA. `0.3.0` and its prereleases stay
+refused until a fresh audit. DSH checks a plugin's declared requirements before
+composing a profile, on every start rather than only on install, so a host
+outside the range refuses to activate this plugin. From DSH `0.2.1-alpha.4` on,
+that check reads `engines.dsh` and ignores `peerDependencies`; older hosts know
+only the peer range, so both declare the identical range. The package includes
+Funnel helpers for macOS, Linux, and Windows on amd64/arm64; trusted-LAN mode
+does not require the helper. The helper is built with Go 1.27, which requires
+**macOS 13 Ventura or later**: on macOS 12 and earlier, Funnel mode cannot
+start, while trusted-LAN mode keeps working.
+
+The current working tree declares that range in `engines.dsh` and
+`peerDependencies` and is built/typechecked against `0.2.1-rc.5`. A previously
 published plugin package may still carry its own older compatibility
 declaration until a release is made from this tree.
 

package/README.zh-CN.md

@@ -34,22 +34,22 @@
 
 ## 从 npm 安装
 
-当前源码面向 Node.js 22+ 与带 `web` profile 的**八个已审计 DSH 版本**：
-`0.2.0-rc.2`、`alpha` 通道的 `0.2.1-alpha.3`、
-`0.2.1-alpha.4`、`0.2.1-alpha.5` 与 `0.2.2-alpha.2`，以及先后三版 `next` 通道的
-`0.2.1-rc.2`、`0.2.1-rc.3` 与 `0.2.1-rc.4`（npm 通道会移动：`latest` 现指向由 `next` 转正的
-`0.2.1-rc.2`，`next` 指向 `0.2.1-rc.4`，`alpha` 指向 `0.2.2-alpha.2`）。
-DSH 在组合 profile 前会校验插件声明的
-兼容要求，且**每次启动都会校验**（不只是安装时），因此其他宿主版本会拒绝
-激活本插件。从 DSH `0.2.1-alpha.4` 起，该校验只读 `engines.dsh` 并忽略
-`peerDependencies`；更早的宿主只认 peer 范围，因此两处列出同一组八个版本。
-npm 包内置 macOS、Linux、Windows 的 amd64/arm64 Funnel helper；可信局域网
-模式不依赖 helper。helper 用 Go 1.27 编译，要求 **macOS 13 Ventura 或更高版本**：
-macOS 12 及更早版本无法启动 Funnel 模式，可信局域网模式不受影响。
-
-当前工作树的 `engines.dsh` 与 `peerDependencies` 精确列出这六个版本，构建与
-类型检查针对 `0.2.0-rc.2`。从此工作树发布新版本前，已发布的旧插件包仍可能
-带有各自旧的兼容声明。
+当前源码面向 Node.js 22+ 与**滚动兼容区间** `>=0.2.1-rc.5 <0.3.0-0` 内的
+DSH 宿主（带 `web` profile）。下界是决策时最新的已审计 `rc` 版本（npm
+`latest` 与 `next` 均指向 `0.2.1-rc.5`）；其后的所有 `0.2.x` 版本自动放行，
+包括 `alpha` 通道的 `0.2.2-alpha.2` 及之后的 alpha、之后的 rc 与 `0.2.x`
+正式版。`0.3.0` 及其预发布仍需重新审计，由上界 `<0.3.0-0` 拦下。
+DSH 在组合 profile 前会校验插件声明的兼容要求，且**每次启动都会校验**（不只是
+安装时），因此区间外的宿主会拒绝激活本插件。从 DSH `0.2.1-alpha.4` 起，该校验
+只读 `engines.dsh` 并忽略 `peerDependencies`；更早的宿主只认 peer 范围，因此
+两处声明同一区间。npm 包内置 macOS、Linux、Windows 的 amd64/arm64 Funnel
+helper；可信局域网模式不依赖 helper。helper 用 Go 1.27 编译，要求 **macOS 13
+Ventura 或更高版本**：macOS 12 及更早版本无法启动 Funnel 模式，可信局域网模式
+不受影响。
+
+当前工作树的 `engines.dsh` 与 `peerDependencies` 声明该区间，构建与类型检查
+针对 `0.2.1-rc.5`。从此工作树发布新版本前，已发布的旧插件包仍可能带有各自旧的
+兼容声明。
 
 ```sh
 dsh plugin --profile web add dsh-deeppilot

package/bin/SHA256SUMS

@@ -1,6 +1,6 @@
-cc7f9ae55c7a8b717a45cd83fd671e2c9b6993f91c09f33c44fd28ea459eeba0  ./darwin-amd64/dsh-deeppilot-tunnel
-37f7430994f6ad79a2a93573f79ea2a1b1a6108fac054117548d8268dca422db  ./darwin-arm64/dsh-deeppilot-tunnel
-051ff06069db0f4ede5570a693811f380cf0740065df3969113b0b5d9ded3c0f  ./linux-amd64/dsh-deeppilot-tunnel
-f704a48365d952185e6b6c28d655db0e174cbf1b9557e3fe40493ca1f7c614fe  ./linux-arm64/dsh-deeppilot-tunnel
-ac2470db2843958af431de284212018ff8f2f9aa147a08359aada21e3a5a09b1  ./windows-amd64/dsh-deeppilot-tunnel.exe
-541da90383098daecda68f910058d8071439d07f2edd7726f0af6fdb3c778b7d  ./windows-arm64/dsh-deeppilot-tunnel.exe
+c79c889415f6fce13a2d0f19c94e2ceb5cbfc06ec5c841c1002092783663a6a6  ./darwin-amd64/dsh-deeppilot-tunnel
+affe9151e5356b574e1a85c806b198c39b5804f3a305b655cd3eb03c628ae0cc  ./darwin-arm64/dsh-deeppilot-tunnel
+a2475a2844250a6ef03853fe64db63eb1a163d9fcd7f3f438f3ec7a142d3a044  ./linux-amd64/dsh-deeppilot-tunnel
+6241de8d3c67e6e2af98e6b6040a10d9352183f893d3aed82c879a76c8b79432  ./linux-arm64/dsh-deeppilot-tunnel
+9449d3c48cc11446cd0f35c030f28000b5934512512fc1d7eeaa769d8d8304f3  ./windows-amd64/dsh-deeppilot-tunnel.exe
+fd0c912b5b39ba8bd385cb05c39665d89519c75b6f5ddbc506b7554926f6545f  ./windows-arm64/dsh-deeppilot-tunnel.exe

package/docs/DSH_022_FEATURES.md

@@ -17,6 +17,8 @@
 | `pluginManager.listVersions` / `registries` | 公开版本目录及软件源配置 | 已读 | 显示候选版本，读取精确协议声明，确定实际候选源 |
 | `pluginManager.updateBundle` / `listBundles` | 精确版本更新、实际安装清单 | 已读 | 由宿主完成 HMR 替换和失败回滚，再核对安装与运行版本 |
 | `plugin-manager/registry.registryPlan` | 公开软件源选择规则 | 已读并建立对照测试 | 预检宿主可能回退到的全部来源，禁止不同协议或完整性摘要绕过闸门 |
+| `locale/<lang>.json` 的 `meta.detail` | 插件管理页按语言链读取详情文档，缺省退回包根 README | 已读 `dsh-plugin-detail` 选择规则 | 英文 `README.md`、中文 `README.zh-CN.md` |
+| `settings.section.icon` 插槽 | 设置壳按 `settings.section` 同 id 渲染，`{size, active}` | 已读壳渲染与插槽声明 | 导航行显示单色线性手机图标；旧宿主不声明该插槽，保留默认图标 |
 | npm 精确版本 manifest | GET `{registry}/dsh-deeppilot/{version}` | 已读并限制响应大小及超时 | 核对包名、精确版本、bundle、`deepPilot.protocolVersion` 与强 SRI |
 | 其他新模块 | 新增包及发布清单 | 仅盘点 | 未接入，不引入额外产品行为 |
 
@@ -24,8 +26,8 @@
 
 | 类别 | 本轮范围内的状态 |
 |---|---|
-| 双方都有 | ZIP/Markdown 导出、瞬时流生命周期与正式事件关联、明确确认的更新及状态查询、兼容性闸门、宿主 HMR/回滚、断线后日志对账 |
-| 上游有、我方未接 | 自动化任务批量清理、Web 引用交互、插件富文本详情及其他 Web 专属入口；本轮未扩展手机对应功能 |
+| 双方都有 | ZIP/Markdown 导出、瞬时流生命周期与正式事件关联、明确确认的更新及状态查询、兼容性闸门、宿主 HMR/回滚、断线后日志对账、插件详情页多语言文档、设置导航图标 |
+| 上游有、我方未接 | Web 引用交互及其他 Web 专属入口（自动化任务批量清理已由下文 `deleteEnded` 接入）；本轮未扩展手机对应功能 |
 | 我方有、上游没有 | 手机专用分块传输、独立瞬时 wire 帧、设备隔离的持久更新日志、App 协议版本闸门 |
 | 双方都没有 | 不支持的宿主上强制重启进程、手机静默安装、替用户发布 npm/GitHub 版本 |
 
@@ -38,6 +40,39 @@
 - 更新接受回执在目标校验和日志耐久写入后发送。最近结果保留供重连对账；同请求编号不能更换目标，也不能重复安装。日志不保存凭据或会话内容，设备归属仅保存摘要并只向所属设备返回。
 - “恢复”指 HMR 后重连并恢复当前会话。宿主无 HMR 时返回 `restart-required`；不会强杀宿主，不能声称已经自动重启。安装失败由宿主恢复旧版本，桥接只核验并呈现结果。
 
+## 宿主级计划任务（DSH 0.2.2-alpha.3）
+
+`0.2.2-alpha.3` 把自动化任务改为宿主级模型（任务带 `target`，状态有
+`active` / `paused` / `ended`），并重写了 `dsh-schedule` 服务面。插件按**服务形状**
+（有 `edit`、无 `update`）选择适配器，不看版本号字符串；旧宿主逐字节保持原行为。
+wire 契约见 [PROTOCOL.md](../PROTOCOL.md) 「Schedule 宿主级任务扩展」。
+
+| 上游接口 | 本次阅读 | 桥接用途 |
+|---|---|---|
+| `schedule.list({active?,limit?,offset?})` | 分页对象 `{items,shown,total,limit,offset}` | 新帧 `c2s.schedule.host.list`；旧帧全量分页后过滤目标会话 |
+| `schedule.view({id})` | 任务或 miss | `c2s.schedule.host.view` |
+| `schedule.create(request, actorSessionId?, signal)` | `timing` + `target` 请求体 | `c2s.schedule.host.create`；旧帧把选择器转 `timing` + `target:{kind:"session"}` |
+| `schedule.edit({id, action, patch?, expectedUpdatedAt?}, …)` | update/delete 合一 | `c2s.schedule.host.edit`；旧帧 update 用 `expected` 逐字段比较后转 `patch` |
+| `schedule.run({id})` | 手动执行，执行中返回 `schedule_execution_pending` | `c2s.schedule.host.run`（E_BUSY 提示稍后） |
+| `schedule.history({id,limit,before?})` | 与旧结构相同，不再校验会话归属 | 两种模型共用 `c2s.schedule.history`；宿主级忽略 `sessionId` |
+| `schedule.deliveryLimits()` | `{newSessionIntervalSeconds}` | `c2s.schedule.host.limits` 只做展示，不自行节流 |
+| `schedule.deleteInactive()` | `{deleted}`；alpha.3 删 `status="ended"`（alpha.2 判 `inactive`） | `c2s.schedule.host.deleteEnded`，回执 `deletedEnded`；手机端二次确认后才发 |
+| 旧 `delete` / `update` / 按会话的 `list` | 仅在会话级宿主存在 | 旧帧原路径；宿主级宿主上由适配层映射 |
+
+差异对照补充：
+
+| 类别 | 状态 |
+|---|---|
+| 双方都有 | 列表、创建、编辑、删除、清理已结束任务、投递历史、变更事件 |
+| 上游有、我方未接 | `catalog`（不分页全量）——手机会话内入口改用分页列表连续翻页取全量，不需要单独的帧 |
+| 我方有、上游没有 | 旧 App 的会话级视图（由宿主级任务反向投影）、按会话过滤的列表 |
+| 双方都没有 | 任务执行结果回执、跨设备编辑锁（只用 `expectedUpdatedAt` 乐观冲突） |
+
+边界：旧视图过滤 `target.kind="session"` 且同会话、丢弃 `ended`、跳过 `rrule`（旧枚举无
+对应 kind，避免旧 App 整页解码失败）；旧 `update` 的冲突保护是「`expected` 与当前任务
+逐字段比较」的尽力而为，旧视图没有 `updatedAt`；新帧用 `expectedUpdatedAt` 做真正的
+乐观冲突检测。`run` 按 `clientRequestId` 幂等，结果未知时客户端不得自动重试。
+
 ## 验证入口
 
-插件用例：`tests/markdown-export.test.ts`、`tests/assistant-stream.test.ts`、`tests/plugin-update.test.ts`，以及 wire 注册表、历史适配和命令回归。iOS 测试及实机边界见私有项目的对接说明。真机、实际 npm 安装和 Funnel 验证不得由模拟或语法检查替代。
+插件用例：`tests/markdown-export.test.ts`、`tests/assistant-stream.test.ts`、`tests/plugin-update.test.ts`、`tests/schedule.test.ts`（双形态适配与七个新帧），以及 wire 注册表、历史适配和命令回归。iOS 测试及实机边界见私有项目的对接说明。真机、实际 npm 安装和 Funnel 验证不得由模拟或语法检查替代。

package/docs/DSH_RELEASE_MEMORY.md

@@ -1,7 +1,153 @@
 # DSH release compatibility memory
 
-> This is the durable audit record for DeepPilot's public DSH plugin. Re-audit
-> the next DSH release instead of assuming that an rc upgrade is runtime-safe.
+> This is the durable audit record for DeepPilot's public DSH plugin. Since
+> 2026-10-30 the declaration is a rolling range: audit a release when it would
+> move the lower bound, at each `0.x` minor boundary, or when a host inside the
+> range breaks at runtime.
+
+## Audit record — `dsh-v0.2.2-rc.1` (rebuild of alpha.3, no runtime change)
+
+- **Release (2026-11-04):** `dsh-v0.2.2-rc.1`, now npm `next`; `latest` stays
+  `0.2.1-rc.5`, `alpha` stays `0.2.2-alpha.3`. Inside the rolling range, so **no
+  declaration change**. The release notes summarize everything since
+  `0.2.1-rc.5`, so most listed items already shipped in `0.2.2-alpha.2/3`.
+- **Tree vs `0.2.2-alpha.3`:** 330 shared packages, zero manifest structural
+  changes after normalizing version strings, and only four non-manifest files
+  differ (`dsh-client-modules` build commit, three client bundles' version
+  strings). `cordis 4.0.6-alpha.2 → 4.1.0` and `schemastery 3.18.6-alpha.2 →
+  3.19.0` change only `package.json` (version and `cosmokit`/`cordis-plugin-*`
+  ranges); code is byte-identical. The evaluator `dsh-app-boot/lib/index.js` is
+  byte-identical (sha256 `346f8322…`), so every alpha.3 finding — including the
+  schedule host-adapter requirement — carries over unchanged.
+- **Gate (real rc.1 evaluator):** worktree `0.9.14` accepted on `0.2.2-rc.1`,
+  `0.2.2-alpha.3`, `0.2.1-rc.5`, `0.2.2`; refused on `0.3.0-rc.1`. Published
+  `0.9.13` (eight-release list) is refused on every one of them — `next`-channel
+  users need `0.9.14` published before the plugin activates.
+- **Boot:** isolated `DSH_HOME` with the rc.1 CLI: `--dump-config` exit 0, empty
+  stderr, 7 `deeppilot` hits; `/phone/health` 200 (`protocolVersion` 2,
+  `serverVersion` 0.9.14, `dataPlane` active); `deeppilot/host-id` and
+  `lan-tls/` created.
+- **Vendor peers (install-time only), decided 2026-11-05:** the previous
+  `@deepseek-ai/cordis` / `@deepseek-ai/schemastery` peers did not admit the
+  vendored `4.1.0` / `3.19.0`. Both are optional peers the evaluator ignores
+  (`engines.dsh` decides), so activation was never affected. `0.9.14` appends
+  `~4.1.0` / `~3.19.0` (append, not replace: earlier hosts still vendor the
+  older pairs); `tests/compatibility-metadata.test.ts` pins both.
+- **Not covered:** no real-device pairing, Funnel end-to-end, model turn, or
+  `npm install` from the registry via the host's plugin manager.
+
+## Audit record — `dsh-v0.2.2-alpha.3` (runtime break inside the range)
+
+- **Release (2026-11-03):** `dsh-v0.2.2-alpha.3` on the npm `alpha` channel
+  (published 2026-11-03T07:48:26Z); `latest` and `next` remain `0.2.1-rc.5`. It
+  is inside the rolling range, so **no declaration change** was needed. The real
+  `0.2.2-alpha.3` evaluator accepted the worktree `0.9.14` manifest with zero
+  requirements and refused the published `0.9.13` (eight-release list) with a
+  single `engines.dsh` requirement — alpha-channel users must upgrade the plugin
+  before it activates.
+- **Gate and install surface:** 18 candidate versions were scored with the
+  published evaluator and an independent semver recomputation with zero
+  disagreements (`0.3.0-0`, `0.3.0-rc.1`, `0.3.0`, `1.0.0` stay refused). The
+  host vendors `cordis 4.0.6-alpha.2` / `schemastery 3.18.6-alpha.2`, both
+  inside this plugin's peer ranges; its `engines.node` is `>=24.9.0`.
+- **One runtime break, confined to schedule.** `0.2.2-alpha.3` moved automation
+  to host-level task management and rewrote `dsh-schedule`: `update` and
+  `delete` are gone (`edit({ id, action: 'update' | 'delete', patch,
+  expectedUpdatedAt })` replaces them), `list` returns
+  `{ items, shown, total, limit, offset }` instead of an array, `create` takes
+  `(request, actorSessionId, signal)`, and the request body uses `timing` /
+  `target` instead of `at` / `after_seconds` / …. The four bridge call sites
+  (`src/dsh-api-proxy.ts:216/232/236/248`) still speak the `0.2.2-alpha.2`
+  contract, so the phone's schedule list, create, edit and delete fail while
+  `schedule.history` keeps working. The `schedules` capability bit stays `true`
+  because it probes service presence only, so the break is silent (each action
+  returns an internal error) instead of hiding the feature. No other contract
+  changed: 24 of the 25 audited interfaces are identical or compatibly changed
+  and the client face is untouched.
+- **Runtime verification:** an isolated `0.2.2-alpha.3` host composed and started
+  the `0.9.14` worktree (`--dump-config` exit 0, no skipped bundle, 199 composed
+  entries), `/phone/health` returned 200 with `protocolVersion` 2 and
+  `serverVersion` `0.9.14`, and the live 3080 host on the same build serves the
+  same plugin from its linked worktree. The config schema projection accepts
+  every `deeppilot` option, and `NODE_DEBUG=esm` proves the plugin's
+  `@deepseek-ai/*` imports resolve to the alpha.3 installation tree rather than
+  the pinned dev copies.
+- **Decision:** keep the rolling range; ship `0.9.14` so alpha-channel users get
+  a host-activatable plugin. The schedule adapter now serves both contracts
+  (shape-detected `legacy` / `host` adapters, additive protocol v2 capability
+  `schedulesHost`, host-level frames, legacy frames projected onto host-level
+  tasks, iOS mirror); the wire contract lives in `PROTOCOL.md` section "Schedule
+  宿主级任务扩展". The public contract consequence is recorded in
+  `COMPATIBILITY.md`.
+- **Evidence:** `.alpha3-verify/AUDIT.md`, `CHANGE_SURFACE.md`, `CLIENT_FACE.md`,
+  `HOST-BOOT.md` and `logs/` in this repository; `.alpha3-verify/gate-matrix.mjs`
+  reproduces every activation verdict.
+
+## Current decision — rolling range from `dsh-v0.2.1-rc.5`
+
+- **Decision (2026-10-30):** the compatibility declaration is one rolling range,
+  `>=0.2.1-rc.5 <0.3.0-0`, in `engines.dsh` and all ten `@deepseek-ai/dsh*`
+  peers, replacing the eight-release closed list. The lower bound is the newest
+  `rc` release (`0.2.1-rc.5`, published 2026-10-29T14:15:23Z); the current
+  `alpha` release `0.2.2-alpha.2` sorts above it and needs no second clause.
+  `<0.3.0-0` keeps the `0.3.0` audit gate. Dev packages move to the exact
+  `0.2.1-rc.5` baseline with vendored `cordis 4.0.5` / `schemastery 3.18.5`.
+  Release `0.9.14`. Recorded in `docs/adr/0001-dsh-compatibility-policy.md`
+  section 8.
+- **Trigger:** `latest` and `next` both moved to `0.2.1-rc.5`; the closed list
+  (ending `0.2.2-alpha.2`) refused to activate on it, and every DSH release
+  required eleven declaration edits plus a lockfile, test, and doc pass.
+- **Audit of `dsh-v0.2.1-rc.5` against `dsh-v0.2.1-rc.4` (`.rc5-verify/`):**
+  **no runtime break, `src/` unchanged.** 307 = 307 packages; 42,731 shared
+  files: 42,421 byte-identical, 310 differing (296 `package.json` + 14
+  non-manifest files in 7 packages), plus one file new in rc.5 only
+  (`dsh-client-ui-chat/lib/types/client/reasoning-text.d.ts`, 363 B). The rc.4
+  tree fingerprint reproduced the previous audit's value. All 307 manifests have
+  zero structural changes across the full 11,099-leaf union; 3,706 dependency
+  specs are mechanical `0.2.1-rc.4 → 0.2.1-rc.5` replacements. The evaluator
+  `dsh-app-boot/lib/index.js` is byte-identical to rc.4 (sha256 `5135179a…`,
+  same as rc.3). `dsh-web-app/cordis.patch.yml` is byte-identical, so the
+  `id: directory-picker` patch anchor is untouched. The four client faces are
+  byte-identical. 3,271 `lib/` modules and 681 entry modules show zero export
+  deltas. The 15 non-manifest files (14 changed, 1 added) live in
+  `dsh-client-ui-chat` (the internal `conversation.chat.reasoning.body` Slot
+  gains `rawText`, reasoning text strips its `<signature>` wrapper before
+  display, plus types and READMEs), `dsh-cordis-client-runner` (embedded Slot
+  registry metadata), `dsh-experimental-client-ui-cot-translation` (JSDoc/type
+  comments only), `dsh-client-modules` (build-commit constant), and three
+  settings/sidebar client bundles (version strings, same byte size). A machine
+  check over the 7 packages reports `allOutsideDeclarationSurface`; none is in
+  the declaration surface (10 peers + 4 client injects + vendored
+  cordis/schemastery) or the plugin call surface.
+- **Matrix (rc.5 evaluator, `includePrerelease: true`):** before → `0.2.1-rc.5`
+  rejected; after → `0.2.1-rc.5`, `0.2.2-alpha.2`, `0.2.1`, later rc/alpha/GA
+  admitted — 12 candidates newly admitted, exactly the seven former list members
+  newly refused — while `0.3.0-rc.1`, `0.3.0`, `0.3.0-0`, and `1.0.0` stay
+  rejected. Every verdict matched an independent semver calculation, and dropping
+  `engines.dsh` to exercise the peer path yields the same accepted set. The range
+  also admits unaudited prereleases above the bound by construction
+  (`0.2.2-alpha.1`, `0.2.2-alpha.2.1`, `0.2.2-ALPHA.2`, `0.2.2-0`); this is
+  pinned as a known admission surface in `tests/compatibility-metadata.test.ts`.
+- **Positive load (isolated `DSH_HOME`, `.rc5-verify/HOST-BOOT.md`):** with a
+  projected manifest carrying only the new range, the rc.5 host composes the
+  plugin (`--dump-config` exit 0, no `skipping profile bundle` line, 7
+  `deeppilot` hits), starts it, and the plugin's own LAN port answers
+  `/phone/health` with 200 (`ok`, `enabled`, `protocolVersion` 2, `dataPlane`
+  active). Both the committed 0.9.13 artifacts (`serverVersion` 0.9.13) and the
+  in-flight 0.9.14 worktree (`serverVersion` 0.9.14) load. The isolated home
+  received `deeppilot/host-id` and `deeppilot/lan-tls/`.
+- **Verification:** `npm test` 681 (679 pass, 1 pre-existing todo, 1 skipped),
+  `typecheck`, `build`, `check:config-schema` against the `0.2.1-rc.5` CLI,
+  `smoke:helper`, `go test ./...`, `bin/SHA256SUMS` 6/6.
+- **Evidence:** `.rc5-verify/AUDIT.md`, `CHANGE_SURFACE.md`, `HOST-BOOT.md`,
+  `tree-compare.out.json`, `matrix.out.json`, `evaluator-repro.out.json`,
+  `patch-anchor-check.out.json`, `export-symbol-diff.out.json`,
+  `pkg-manifest-delta.out.json`, `vendor-check.out.json`, `diffs/`, `logs/`.
+- **Honest boundary:** `dsh-client-ui-slots` has no artifact in either tree (as
+  in the rc.4 round), so it was not byte-compared; `react` and the npm
+  install-time resolution were not checked; no real-device pairing, Funnel
+  end-to-end, or model turn was run; `0.9.14` is prepared locally, not
+  published.
 
 ## Current decision — `dsh-v0.2.2-alpha.2`
 
@@ -2187,3 +2333,13 @@ release notes.
 2. 手机协议：模型当前选择投影新增 `s2c.models.changed`，受 `sessions.read` 控制；原生权限执行可附加 `expectedDefinitionId`，重读目录核对来源，旧客户端字段缺省兼容。无新增周期轮询或第二层主机时间缓存。
 3. 客户端：内存五分钟、磁盘最长七天，重启旧目录先展示并校验，按配对身份/主机/会话隔离；当前模型、权限和执行结果不落盘。具体约定和格式重建见[移动端目录缓存](移动端目录缓存.md)。
 4. 验证：插件 577 项通过、1 项原有待办，类型检查、生成产物构建和使用本机固定版本的离线配置校验通过；两端缓存单元与模拟器证据见各自文档。随 0.9.8（2026-10-18）发布；真机与系统分享仍未验收。
+
+## 2026-10-30 — 发布 `dsh-deeppilot@0.9.13`
+
+- **版本收口。** `0.9.12` 的版本提交 `a5a6f59` 曾落在 `main`，但从未打 tag、上传 npm 或建 GitHub Release；本次在 `0.9.11` 之上统一收口为 `0.9.13`：八版白名单（新增 `0.2.1-rc.4` 与 `0.2.2-alpha.2`，`SessionController.inspect` 缺失时 `sessions.history` 走 `page`）、运行中排队与转向、Markdown 导出、实时流式增量、插件自更新、设置页重设计，以及 helper 上报内嵌 Tailscale 版本后的六平台 `bin/` 重建。
+- **安装面。** `engines.dsh` 与十条 `dsh-*` peer 枚举八个精确版本；vendor peer 追加 `cordis ~4.0.6-alpha.1` / `schemastery ~3.18.6-alpha.1`；无配置字段变化。审计与隔离宿主证据见 `.alpha2-verify/`、`.rc4-verify/`（`0.2.1-rc.4` 27/27、`0.2.2-alpha.2` 32/32）。
+- **本地校验（发布工作树）。** `npm ci`；`npm test` 679 项（677 通过、1 项环境门禁跳过、1 项有意 TODO、0 失败）；`typecheck`；`build`（`lib/` 无变化）；`check:config-schema`（0.2.0-rc.2 CLI）；`smoke:helper`（darwin-arm64）；`go test ./...`；`bin/SHA256SUMS` 6/6；六平台 helper 重建后 `bin/` 无漂移；`npm pack` 69 项、51,405,933 字节。
+- **发布。** 发布提交 `0107efb584be4031af7279eb9f6cdf4404189081`，附注标签 `v0.9.13`；CI `40910195877` 与 CodeQL `40910195831` 绿色。`publish.yml` 首次运行 `40911590022` 的上传与来源证明步骤成功，但末尾核对在 24 次重试后仍 404，整次运行标红；重跑 `40918429580` 在发布步骤报 `E409 Cannot publish over previously staged version "0.9.13"`，由此确认**当前可信发布者绑定只允许暂存发布**：版本进入 npm staged 区，需维护者 2FA 批准后才公开。维护者批准后，注册表 `latest = 0.9.13`。
+- **发布后核验。** 来源证明类型 `https://slsa.dev/provenance/v1`，`gitCommit` 为发布提交，工作流引用 `refs/tags/v0.9.13`，invocation 为 `40911590022`；tarball SHA1 `ca2c754e3421cddd14a795c5b4d869c5ea4b3cf9`、SHA512 与注册表一致，69 个条目、解包 131,263,175 字节。全新隔离 `DSH_HOME`（`/tmp/dsh-verify-0913`，pnpm 从 npm 安装，不是 link）在真实 `0.2.2-alpha.2` 宿主上启动，`https://127.0.0.1:3098/phone/health` 返回 200，`serverVersion` 为 `0.9.13`、`dataPlane: true`；GitHub Release 在这一步通过后才公开并标记 Latest。
+- **流程变更。** 用户决定保留暂存流程；批准步骤与「工作流末尾核对在批准前必然失败」已写入 `docs/NPM_PUBLISHING.md` 与 `AGENTS.md` 发布第 4–5 步。工作流本身未改：末尾核对在 staged 版本上仍会标红，是否改成「检测到 staged 即视为成功并输出待批准」留待下次发布前决定。
+- **局限。** 未做真机、Funnel 端到端、真实 `updateBundle`/HMR 回滚安装，也没有在 `0.2.1-rc.4` 上做真实业务回合；上述健康检查只证明插件能被宿主组合、启动并应答。

package/docs/NPM_PUBLISHING.md

@@ -34,6 +34,12 @@
    npm 不在保存配置时验证绑定；首次发布成功才证明认证可用。
 4. 新绑定必须在 **2 天内完成首次成功发布**。因此准备好新版本后再绑定；若过期，
    删除过期绑定并重新创建。先验证可信发布成功，再按需调整原有令牌发布权限。
+5. **2026-10-29 实测：当前绑定只允许暂存发布。** `publish.yml` 里的 `npm publish`
+   不再直接公开版本，而是把它送进 staged 区（命令返回成功并提示“正在处理”，
+   但注册表的版本、tarball 与来源证明持续 404）。用户决定**保留暂存流程**：
+   每次发版由工作流暂存，维护者用 2FA 批准后才公开（步骤见第三节）。
+   若要恢复直接发布，需在包设置的 Trusted Publisher 中勾选 `Allow npm publish`
+   （账户强制 2FA 时可能不可用），并同步改本节、AGENTS.md 与第 4 步的核对逻辑。
 
 ## 三、每次发布
 
@@ -63,7 +69,14 @@
    压缩包发布跳过生命周期脚本（`--ignore-scripts`）；测试、类型检查和构建已在前序
    步骤执行，打包仍执行 `prepack`（打包前构建）。发布后核对版本、分发标签、
    压缩包完整性和来源证明元数据。
-6. 确认 npm 包可安装，在全新 DSH 配置中完成安装验证后，再公开 GitHub 发布草稿。
+6. **批准暂存版本（暂存模式下必需）。** 工作流把版本送进 staged 区后，由维护者完成
+   2FA 批准：在 npmjs.com 的 **Staged Packages** 标签找到
+   `dsh-deeppilot@<版本>` → Approve；或本机 `npm login` 后
+   `npm stage list dsh-deeppilot` → `npm stage approve <id>`。
+   批准即公开该版本，并按发布命令写入分发标签（`latest` / `alpha`）。
+   工作流末尾「核对发布版本、包完整性与来源证明」在批准前必然 404 失败、整次运行标红；
+   这是暂存模式的预期结果，不代表上传失败，发布证据以批准后的手工核验为准。
+7. 确认 npm 包可安装，在全新 DSH 配置中完成安装验证后，再公开 GitHub 发布草稿。
    工作流不自动公开发布草稿；npm 上传和发布后的核对分别记录在步骤中。
 
 ## 四、失败处理与证据边界
@@ -156,6 +169,25 @@
     **遗留处理：** `0.9.10` 的 GitHub Release 原为 Draft，按用户决定于本轮**删除**
     （远端标签 `v0.9.10` 与 npm 上的 `0.9.10` 包均保留，未做任何版本删除或回撤）。
 
+11. `0.9.13` 的实际发布结果（2026-10-29/30）：附注标签 `v0.9.13` 指向
+    `0107efb584be4031af7279eb9f6cdf4404189081`，该提交的 CI（运行号
+    `40910195877`，7 分 27 秒）与 CodeQL（运行号 `40910195831`）均绿。
+    `publish.yml` 首次运行 `40911590022` 的上传与来源证明步骤成功，但末尾核对在
+    24 次重试后仍抛 `读取 npm 发布信息失败（dsh-deeppilot/0.9.13，HTTP 404）`，
+    整次运行标红；重跑 `40918429580` 在发布步骤报
+    `E409 Cannot publish over previously staged version "0.9.13"`。由此确认
+    **当前绑定只允许暂存发布**，版本进入 staged 区后需维护者 2FA 批准（见第二节
+    第 5 条与第三节第 6 步）。批准后注册表 `latest = 0.9.13`；来源证明类型为
+    `https://slsa.dev/provenance/v1`、`gitCommit` 为该提交、工作流引用
+    `refs/tags/v0.9.13`、invocation 为 `40911590022`；tarball SHA1
+    `ca2c754e3421cddd14a795c5b4d869c5ea4b3cf9` 与 SHA512 同注册表一致，共 69 个
+    条目、解包 131,263,175 字节。随后在全新隔离 `DSH_HOME` 中从 npm 安装
+    `dsh-deeppilot@0.9.13`（pnpm 安装，不是 link），用真实 `0.2.2-alpha.2` 宿主
+    启动，插件自有端口 3098 的 `/phone/health` 返回 200，`serverVersion` 为
+    `0.9.13`、`dataPlane: true`；GitHub Release 在这一步通过后才公开并标记 Latest。
+    暂存流程与批准步骤已写入第二、三节与 `AGENTS.md`；工作流末尾核对在暂存模式下
+    的标红问题本轮未改，留待下次发布前决定是否检测 staged 后按成功处理。
+
 ## 五、官方资料
 
 1. [npm 可信发布配置与限制](https://docs.npmjs.com/trusted-publishers/)