dsh-deeppilot 0.8.2 → 0.9.0

package/COMPATIBILITY.md

@@ -1,11 +1,11 @@
 # Compatibility
 
-This branch targets **DSH 0.1.7-rc.1**. The DSH peer dependencies and the development packages are pinned to that exact release. Earlier DSH builds and later release candidates are outside this branch's support scope.
+This branch targets **DSH 0.2.0-rc.1**. The DSH peer dependencies and the development packages are pinned to that exact release. Earlier DSH builds and later release candidates are outside this branch's support scope.
 
 | Component | Current contract | Evidence |
 |---|---|---|
 | Node.js | 22 or newer | Package engine and CI |
-| DSH CLI and Host API | `0.1.7-rc.1` | Peer metadata, source typecheck, unit tests, bundle build, and config schema projection against rc.1 |
+| DSH CLI and Host API | `0.2.0-rc.1` | Peer metadata, source typecheck, unit tests, bundle build, and config schema projection against a real 0.2.0-rc.1 CLI |
 | 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 |
 
@@ -21,9 +21,59 @@ This branch targets **DSH 0.1.7-rc.1**. The DSH peer dependencies and the develo
 
 - Protocol v2 is the only supported phone wire version. Protocol-v1 devices must pair again. The LAN listener uses its own TLS identity and certificate pinning; old LAN pairings without a fingerprint must also pair again.
 - 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 rc.1 Host's own history reader accepts them; this plugin does not rewrite those logs.
+- 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.
 
+## Schedules require an optional DSH bundle
+
+DSH 0.2.0 moved automation out of the shipped Web composition. The shipped
+`packages/bundle/web-app/cordis.patch.yml` no longer carries the `time-context`,
+`schedule`, or `ui-schedule` rows; they are supplied by the optional
+`@deepseek-ai/dsh-experimental-schedule-bundle`, which ships switched off and is
+enabled by the user through **Automation tasks** in the plugin manager.
+
+The plugin needs no change for this. It still resolves the service through
+`ctx.get('schedule')`, never declares `schedule` in `inject`, and reports
+`welcome.capabilities.schedules = false` with a stable `E_UNSUPPORTED` for every
+schedule frame when the service is absent. What changes is that a stock 0.2.0
+Host now always takes that degraded path, so the phone tells the user to enable
+Automation tasks instead of reporting a generic capability gap.
+
+The capability is resolved lazily rather than captured when the bridge is
+built. The bridge mounts on `sessionController` / `connection` /
+`typertGateway`, all of which become ready before the optional Schedule service
+finishes its own initialization, so a probe taken at that moment would report
+`false` for the bridge's whole lifetime. With the bundle enabled, a live
+0.2.0-rc.1 host advertises `schedules=true` and the schedule
+list/create/history/delete flow passes.
+
+## 0.2.0-rc.1 audit outcome
+
+The source-level audit of `dsh-v0.2.0-rc.1` against the previous baseline
+`dsh-v0.1.7-rc.2` found no breaking change in the DSH service surfaces the
+plugin calls. Of the 78 service-surface files compared, 75 are byte-identical
+and the three that changed are additive: `fork()` gained an optional
+`onCreated` callback, and a `run()` helper call gained an internal `'hidden'`
+argument. The `api/gateway` package, including the `wireStream.open` argument
+order, is unchanged, as are the Typert protocol exports, `configForms`, and
+every `schedule` source file.
+
+The exact 0.2.0-rc.1 package pins, the regenerated registry lockfile (228
+packages, all carrying `resolved` and `integrity`), the compatibility
+assertions, generated output, unit tests, typecheck, build, Go helper tests,
+helper checksums, and a config-schema check against a real 0.2.0-rc.1 CLI all
+pass locally. A real 0.2.0-rc.1 `web` profile smoke test also passes: 25 checks,
+0 failures, driven by `scripts/smoke-live.mts` in the source repository (it is
+a maintainer tool and is not part of the published package) against a booted
+profile. Approval and question round trips are the one gap —
+the stock profile auto-approves tool calls, so those paths need a profile with
+a restrictive tool policy. The planned phone additions for durable schedules
+and session forking are specified in
+[`docs/DEEPPILOT_FEATURE_PLAN.md`](./docs/DEEPPILOT_FEATURE_PLAN.md); they are
+not advertised until the protocol, iOS mirror, and integration tests land.
+
+The complete audit evidence and re-audit procedure remain in [`docs/DSH_RELEASE_MEMORY.md`](./docs/DSH_RELEASE_MEMORY.md).
+
 ## Evidence limits
 
 Unit tests and config schema projection do not prove every network, Mac, Linux, Windows, or iPhone combination. In particular, physical-device performance, signed helper distribution, and production APNs delivery need their own checks. Include the exact DSH version, plugin commit, Node version, OS, connection mode, and sanitized status output when reporting a compatibility issue; never include credentials or message content.

package/README.md

@@ -9,7 +9,7 @@
 
 The open-source DSH companion plugin for **DeepPilot**, a native iPhone client
 for using DeepSeek Harness remotely. It connects the app directly to the DSH
-Host on your own Mac and does not replace or modify the DSH Web UI.
+Host on your own computer and does not replace or modify the DSH Web UI.
 
 > DeepPilot is currently in TestFlight review. The invitation link will accept
 > testers after Apple approves the build.
@@ -32,12 +32,12 @@ Host on your own Mac and does not replace or modify the DSH Web UI.
 
 ## Install from npm
 
-This source checkout targets Node.js 22+ and **DSH 0.1.7-rc.1** with a `web` profile. The package includes
+This source checkout targets Node.js 22+ and **DSH 0.2.0-rc.1** with a `web` profile. The package includes
 Funnel helpers for macOS, Linux, and Windows on amd64/arm64; trusted-LAN mode
 does not require the helper.
 
 The current working tree pins its DSH packages and compatibility checks to
-`0.1.7-rc.1`. A previously published plugin package may still carry its own
+`0.2.0-rc.1`. A previously published plugin package may still carry its own
 older compatibility declaration until a release is made from this tree.
 
 ```sh
@@ -80,12 +80,12 @@ DeepPilot state under `$DSH_HOME/deeppilot/`.
 
 ## Publishing (maintainers)
 
-Release from this branch only after validating against DSH `0.1.7-rc.1`:
+Release from this branch only after validating against DSH `0.2.0-rc.1`:
 
 1. Bump `version` in `package.json` and in the root `""` entry of
    `package-lock.json`, then run `npm test && npm run typecheck && npm run build`
    and inspect `npm pack --dry-run --json`. The compatibility metadata test
-   enforces the exact rc.1 peer and development dependency versions.
+   enforces the exact audited peer and development dependency versions.
 2. Commit the release and push it. `npm publish` runs `prepack` (build) and
    `prepublishOnly` (test + typecheck) automatically.
 3. Publish pre-releases without touching `latest`:
@@ -95,7 +95,7 @@ Release from this branch only after validating against DSH `0.1.7-rc.1`:
    ```
 
    After a successful publish, verify the dist tag and install the package in
-   a DSH `0.1.7-rc.1` profile before pointing users at it.
+   a DSH `0.2.0-rc.1` profile before pointing users at it.
 4. Tag the release commit `vX.Y.Z` and prepare a GitHub Release
    (English + 简体中文 notes) that links this README section.
 5. Publish stable releases with `npm publish --tag latest`, which moves
@@ -117,7 +117,10 @@ connection, one-time pairing, and health endpoints, not the complete DSH Web UI.
 The DeepPilot settings page exposes **Connections per public source** under
 the collapsed **Advanced settings** section. It defaults to `8`, accepts
 `1`–`16`, and briefly restarts the Funnel helper when changed, so connected
-remote clients reconnect once.
+remote clients reconnect once. The device list also supports a custom name for
+each paired device. Names are stored in the host registry and survive iPhone
+reconnects or changes to the system-reported name; saving an empty value restores
+the iPhone-reported default.
 
 Offline push is optional. Relay mode sends only the target APNs device token
 and a limited notification payload; full conversation history and live output

package/README.zh-CN.md

@@ -8,7 +8,7 @@
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](./LICENSE)
 
 **DeepPilot** 的开源 DSH 配套插件。DeepPilot 是一款原生 iPhone 客户端，
-可远程使用 DeepSeek Harness；插件让 App 直接连接用户自己 Mac 上的 DSH Host，
+可远程使用 DeepSeek Harness；插件让 App 直接连接用户自己电脑上的 DSH Host，
 不会替换或修改 DSH Web UI。
 
 > DeepPilot 目前正在等待 TestFlight 审核。Apple 审核通过后，邀请链接即可加入测试。
@@ -30,10 +30,10 @@
 
 ## 从 npm 安装
 
-当前源码仅面向 Node.js 22+ 与带 `web` profile 的 **DSH 0.1.7-rc.1**。npm 包内置 macOS、Linux、Windows
+当前源码仅面向 Node.js 22+ 与带 `web` profile 的 **DSH 0.2.0-rc.1**。npm 包内置 macOS、Linux、Windows
 的 amd64/arm64 Funnel helper；可信局域网模式不依赖 helper。
 
-当前工作树的 DSH 包和兼容性检查均固定为 `0.1.7-rc.1`。从此工作树发布新版本前，
+当前工作树的 DSH 包和兼容性检查均固定为 `0.2.0-rc.1`。从此工作树发布新版本前，
 已发布的旧插件包仍可能带有各自的旧兼容声明。
 
 ```sh
@@ -68,12 +68,12 @@ dsh plugin --profile web remove dsh-deeppilot
 
 ## 发布说明（维护者）
 
-此分支仅在 DSH `0.1.7-rc.1` 下完成验证后发布：
+此分支仅在 DSH `0.2.0-rc.1` 下完成验证后发布：
 
 1. 同步修改 `package.json` 与 `package-lock.json` 根 `""` 条目中的
    `version`，然后运行 `npm test && npm run typecheck && npm run build`，
    并检查 `npm pack --dry-run --json`。兼容性元数据测试会校验 peer 与开发依赖
-   均固定为 rc.1。
+   均固定为当前审计基线。
 2. 提交发布并推送。`npm publish` 会自动执行 `prepack`（构建）与
    `prepublishOnly`（测试 + 类型检查）。
 3. 发布预发布版本，不要动 `latest`：
@@ -82,7 +82,7 @@ dsh plugin --profile web remove dsh-deeppilot
    npm publish --tag alpha
    ```
 
-   发布成功后检查 dist tag，并在 DSH `0.1.7-rc.1` profile 中安装验证发布的包。
+   发布成功后检查 dist tag，并在 DSH `0.2.0-rc.1` profile 中安装验证发布的包。
 4. 为发布提交打 `vX.Y.Z` tag，并准备包含英文与简体中文说明的
    GitHub Release，链接本 README 的发布说明。
 5. 稳定版用 `npm publish --tag latest` 发布，使 `latest` 切换到新版本。
@@ -101,7 +101,9 @@ DSH Web UI。
 
 DeepPilot 设置页在默认折叠的“高级设置”中提供“每个公网来源的连接上限”，默认
 `8`，可设置为 `1`–`16`。修改后 Funnel helper 会短暂重启，已连接的远程客户端
-会自动重连一次。
+会自动重连一次。设备列表支持为每台已配对设备设置自定义名称；名称会保存在主机
+设备注册表中，即使 iPhone 重连或上报了新的系统名称也不会被覆盖。留空保存可恢复
+iPhone 上报的默认名称。
 
 离线推送是可选功能。中继模式只发送目标 APNs 设备 Token 和有限的通知内容；
 完整会话历史与实时输出不会经过中继。启用远程访问或推送前，请阅读

package/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: dsh-release-audit
+description: Audit DeepSeek Harness releases for the dsh-deeppilot plugin. Use when a DSH version changes, when checking plugin compatibility, or when looking for new DSH capabilities that could become safe DeepPilot features.
+---
+
+# DSH release audit for DeepPilot
+
+Use this skill to keep the public `dsh-deeppilot` plugin aligned with DeepSeek
+Harness without repeatedly rediscovering the compatibility rules.
+
+## Source of truth
+
+Read these files before making a compatibility decision:
+
+- `docs/DSH_RELEASE_MEMORY.md` — the last audited release, risk decisions,
+  feature opportunities, and the re-audit rule;
+- `COMPATIBILITY.md` — the currently supported DSH baseline and validation
+  limitations;
+- `AGENTS.md` — repository contracts and validation requirements;
+- `package.json` and `package-lock.json` — the exact DSH peer/development pins.
+
+Treat the official DSH release page and tagged source as evidence, not the
+release-note summary alone.
+
+## Audit workflow
+
+1. Identify the new DSH tag and the last audited tag. Fetch the official
+   release page and the complete tag-to-tag comparison.
+2. Read this repository's `package.json`, lockfile, compatibility assertions,
+   and DSH adapter source. Identify the exact Host services, Events, Remote
+   methods, Gateway carriers, and Client bundles that the plugin imports.
+3. Inspect the corresponding tagged DSH source for each used surface. Check
+   method presence, argument/result shapes, stream envelopes, lifecycle
+   behavior, and package version constraints.
+4. Classify the result separately as:
+   - **install/deployment**: package metadata, peer constraints, loader and
+     profile compatibility;
+   - **runtime**: Host service, Gateway, Cordis lifecycle, and event behavior;
+   - **phone protocol**: DeepPilot `PROTOCOL.md` v2, iOS mirror, pairing,
+     replay, and authorization boundaries.
+5. Identify new capabilities. For each candidate, state the user value, the
+   DSH API it would use, the required DeepPilot protocol/UI work, the
+   authorization scope, and the tests needed before shipping it.
+6. Update `docs/DSH_RELEASE_MEMORY.md` with the tag, date, evidence links,
+   decision, risks, feature backlog, and upgrade gate. Update
+   `COMPATIBILITY.md` when the supported baseline changes.
+7. Never claim a release is supported until the dependency pins, generated
+   output, automated checks, and a real DSH Host smoke test have passed.
+
+## DeepPilot-specific rules
+
+- Keep `/phone` and `/phone/health` compatible with the current iOS app.
+- Treat `PROTOCOL.md` as normative. Any phone wire change must update the
+  TypeScript mirror and coordinate with the private iOS repository.
+- Protocol v2 is the current baseline. New optional capabilities should be
+  capability-gated; do not silently change existing frame meanings.
+- A DSH controller change belongs behind the stable `ApiProxyLike` boundary;
+  do not leak DSH controller shapes into the phone protocol.
+- Reminder prompts, message bodies, pairing tokens, APNs tokens, relay
+  credentials, and tool arguments must not be written to logs.
+- New file-open or shell-like behavior must use DSH's verified Host path seam
+  and explicit user confirmation. Never add arbitrary remote command execution.
+- Scheduled tasks must remain bound to their original DSH Session and use a
+  dedicated authorization scope when exposed to phones.
+
+## Required validation
+
+For documentation-only audits, run `git diff --check` and verify every link.
+For an actual DSH dependency upgrade, run the repository's full release
+checklist, including tests, typecheck, build, config schema projection, Go
+helper tests, and binary checksums. Add a real DSH `web` profile smoke test for
+sessions, history, prompts, models, workspaces, approvals, questions, replay,
+and any newly exposed capability.
+
+## Output format
+
+When reporting an audit, lead with one of these verdicts:
+
+- **compatible** — tested and ready to support;
+- **source-compatible, upgrade required** — no code break found, but pins or
+  validation still block release;
+- **runtime risk** — a used service or event needs an integration change;
+- **protocol impact** — DeepPilot/iOS wire coordination is required;
+- **unsupported** — a confirmed incompatibility remains.
+
+Never turn a source-level review into a false claim of runtime or iPhone
+compatibility.

package/docs/DSH_RELEASE_MEMORY.md

@@ -0,0 +1,274 @@
+# 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.
+
+## Current decision
+
+- **Audited release:** `dsh-v0.2.0-rc.1` (published 2026-09-28; official release
+  page: <https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.0-rc.1>).
+- **Comparison baseline:** `dsh-v0.1.7-rc.2` (the previous plugin baseline).
+- **Plugin runtime verdict:** **no breaking change in the DSH APIs that DeepPilot
+  currently calls**. 75 of 78 compared service-surface files are byte-identical;
+  the three that changed are additive.
+- **Install/deployment verdict:** the exact peer/dev pins, the registry lockfile
+  (228 packages, all carrying `resolved` and `integrity`), the compatibility
+  assertions, generated `lib/`, 303 unit tests, typecheck, build, Go helper
+  tests, helper checksums, and a config-schema check against a **real
+  `0.2.0-rc.1` CLI** all pass locally. A real `0.2.0-rc.1` `web` profile smoke
+  test now also passes — 25 checks, 0 failures — via
+  `scripts/smoke-live.mts`. Two behaviours remain unverified there and are
+  listed under the 2026-09-29 findings: approval/question round trips (the
+  stock profile auto-approves tools) and the immediate consistency of the
+  archived list.
+- **Protocol verdict:** no required DeepPilot phone-protocol break. Protocol v2,
+  pairing state, and device records are unchanged; already-paired phones need no
+  action.
+- **One behavioural change:** DSH 0.2.0 moved automation out of the shipped Web
+  composition. See "Automation is now an optional bundle" below. The plugin needs
+  no code change; the phone's copy now points at the bundle.
+
+## 2026-09-28 — audit of `dsh-v0.2.0-rc.1`
+
+### Scope and method
+
+Compared `dsh-v0.1.7-rc.2...dsh-v0.2.0-rc.1` (261 commits, 1109 files). Rather
+than read release notes, every DSH package the plugin actually imports was
+compared file by file: `api/session-controller` (34 files),
+`api/workspace-controller` (10), `schedule/schedule` (10), `api/gateway` (11),
+and `typert/protocol` + `settings/settings` (13). Release notes were treated as
+a hint, never as evidence.
+
+### Findings by risk class
+
+| Area | Finding | DeepPilot impact |
+| --- | --- | --- |
+| Install | All ten peer and five dev packages publish `0.2.0-rc.1` on npm. `cordis` stays `4.0.4`, `schemastery` stays `3.18.4`, Node `engines` and pnpm `11.7.0` are unchanged. The lockfile had to be regenerated from the registry: the old one still pinned `0.1.7-rc.2` and made both `npm ci` and `npm install` fail with ERESOLVE. | Resolved. `npm ci`, typecheck, build, and the real-CLI config-schema check all pass. |
+| Session / Workspace controllers | `client/contract/sessions.ts` and `client/sessions/service.ts` changed only to add an **optional** `onCreated?: (childId: SessionId) => void` to `fork()`. `workspace-controller/src/default-directory.ts` changed only to pass an extra internal `'hidden'` argument to its own `run()` helper. | Additive. The plugin's hand-written `SessionControllerLike` / `WorkspaceControllerLike` mirrors still match. |
+| Schedule service | **All ten `schedule/schedule/src` files are byte-identical to rc.2.** The change is packaging, not API: see below. | The existing facade needs no change. |
+| Gateway / Remote Events | **All eleven `api/gateway/src` files are byte-identical**, including `stream-protocol.ts` and `stream-server.ts`. `typertGateway.wireStream.open(endpoint, payload, uplink, peer, signal)` keeps its argument order — the order DSH changed once in 0.1.7. | The highest-risk integration seam is unchanged. Approval and question delivery re-run clean on the new baseline. |
+| Typert / settings | `typert/protocol` and `settings/settings` sources are byte-identical, so `TypertRemoteService`, `InvocationDescriptor`, `TypertCodec`, `TypertRemoteContribution`, `TypertSchema`, and `configForms.get` are all unaffected. | No change. |
+| Phone protocol | No DSH-facing wire change. Protocol v2, `schedule.manage` scope, and the mutation journal are untouched. | Paired phones keep working. |
+
+### Automation is now an optional bundle
+
+The shipped `packages/bundle/web-app/cordis.patch.yml` in rc.2 carried
+`time-context`, `schedule`, and `ui-schedule` at lines 118–126 and 370–371. In
+0.2.0-rc.1 that file contains no schedule rows at all. Those three rows are now
+inserted by `packages/experimental/schedule-bundle`
+(`@deepseek-ai/dsh-experimental-schedule-bundle`), which `OPTIONAL_BUNDLES` in
+`packages/boot/app-boot/src/profile.ts` ships **switched off**; the user enables
+it as **Automation tasks** in the plugin manager.
+
+This is the only substantive product change in the release. The plugin's
+existing design is already correct: it resolves the service via
+`ctx.get('schedule')`, never puts `schedule` in `inject`, and degrades to a
+stable `E_UNSUPPORTED` with `welcome.capabilities.schedules = false`. What
+changed is that a stock host now always takes that degraded path, so the iOS
+copy for the two schedule errors now names the bundle instead of reporting a
+generic capability gap. `PROTOCOL.md` records that the capability bit reflects
+actual mounting, not the host version.
+
+### Re-audit procedure used
+
+To redo this comparison: `git clone --filter=blob:none --no-checkout
+https://github.com/deepseek-ai/deepseek-harness.git`, fetch both tags, list each
+package's `src/**/*.ts` from `git/trees/<sha>?recursive=1` at both commits, and
+diff the two file sets file by file. Avoid `git grep` on a blob-filtered clone —
+it re-fetches blobs and times out. Record which files are byte-identical, not
+merely which packages still exist.
+
+## 2026-09-29 — live smoke test on a real `web` profile (0.2.0-rc.1)
+
+### How it was run
+
+`scripts/smoke-live.mts` drives the phone protocol against a real
+`dsh --profile <name> web` host that has this working copy linked in. It
+asserts the seams unit tests fake out: the LAN TLS listener, the
+challenge/prove handshake, and every Host RPC the bridge forwards through
+`ctx.apiProxy`. It is repeatable, so the next DSH release can re-run it instead
+of trusting a source diff.
+
+```sh
+npx tsx scripts/smoke-live.mts register   # pre-authorize a device, then restart the host
+npx tsx scripts/smoke-live.mts run [--prompt] [--interactions]
+```
+
+The pairing-code happy path is intentionally not driven: the code only exists
+inside the host process and can only be minted through the plugin's own
+`deeppilot/beginPairing` Host RPC, i.e. from a DSH client session. The script
+asserts instead that `/phone/pair` is mounted and refuses a bogus code, and
+covers the real challenge/prove handshake with a pre-authorized device.
+
+### Result: 25 checks pass, 0 fail
+
+Verified on a real 0.2.0-rc.1 `web` profile: `/phone/health`, the WSS upgrade,
+challenge/prove → welcome with all six scopes, session list/create/open/tail,
+history paging, the model catalog and a live model switch, workspace
+list/create, archive → archived list → unarchive, the pending approval/question
+snapshot, a real model turn (`clientSendId` receipt `accepted`,
+`message.final` + `turn.end` observed), disconnect/reconnect replay
+(`resumed=true`, `s2c.resume.done` received), and — with the Automation tasks
+bundle mounted — the schedule list/create/history/delete flow.
+
+The TLS pin check is worth keeping: the bridge pins the **SPKI** digest
+(`src/lan-tls.ts:35`), not the certificate DER, and the script's independently
+computed pin matched the one the plugin logged on a live host.
+
+### Finding 1 — `--patch` does not install the plugin
+
+Composing the plugin through `dsh --profile X --patch ./cordis.patch.yml`
+leaves the profile with `deeppilot: failed to import` and no reason logged.
+`dsh-app-boot/lib/index.js:3904` shows why: a bare specifier in a patch layer is
+never resolved into a package, so the loader never creates a fiber for it. The
+plugin only mounts after `dsh plugin --profile X add dsh-deeppilot@link:<path>`.
+The install docs should say so; the silent failure looks exactly like a broken
+plugin.
+
+### Finding 2 — `capabilities.schedules` stayed false even with the bundle enabled (fixed)
+
+The optimistic reading of "Automation is now an optional bundle" above did not
+hold on a real host. With
+`@deepseek-ai/dsh-experimental-schedule-bundle` **installed and mounted** — the
+bundle's three rows (`time-context`, `schedule`, `ui-schedule`) do reach the
+composed profile, and `ScheduleService` still exposes
+`create/list/catalog/history/delete/update` — welcome advertised
+`schedules=false` and every `c2s.schedule.*` request took the `E_UNSUPPORTED`
+path.
+
+Root cause: the bridge is constructed from a `ctx.inject` on
+`sessionController` / `connection` / `typertGateway` (`src/index.ts:1212`), and
+`schedule` is deliberately **not** in that list. `DshApiProxy` then resolved
+`ctx.get('schedule')` once in its constructor and cached it in a `readonly`
+field. On DSH 0.2.0 those three services become ready well before
+`ScheduleService` finishes its own async init, so the cached value was
+`undefined` for the bridge's entire lifetime. Reordering `dsh.profile.bundles`
+to mount the schedule bundle first did not help, which is what ruled out a
+pure composition-order cause.
+
+Fix: resolve the optional service lazily on every read and keep it once found
+(`src/dsh-api-proxy.ts`). `capabilities` is already a getter, so a device that
+connects after the service is up now gets `schedules=true`, and the full
+create/list/history/delete flow passes on a live host. Covered by
+`tests/dsh-api-proxy.test.ts`.
+
+A profile that has not enabled the bundle still reports `schedules=false` and
+still degrades to `E_UNSUPPORTED` — that path is unchanged.
+
+### Finding 3 — approvals are auto-approved on a default profile
+
+`--interactions` produced a real `tool.start`/`tool.end` pair for a "create
+this file" instruction but no `s2c.pending.approval`, so the stock profile
+auto-approves and the approval round trip stays unverified. The question round
+trip is also unverified: dispatching a second prompt into the same session
+timed out on the delivery ack. Both need a profile with a restrictive tool
+policy before they can be called verified.
+
+### Finding 4 — the archived mirror is stale right after archiving
+
+`archiveSession` updates `archivedSessionIds` but does not call
+`refreshSummaries()`, so `c2s.sessions.archived` can omit the session that was
+just archived until an unrelated event triggers a refresh (it converged within
+10 s in practice). Pre-existing behaviour, not a 0.2.0 regression, but the app
+must not assume the archived list is immediately consistent.
+
+## Previous decision — `dsh-v0.1.7-rc.2`
+
+- **Audited release:** `dsh-v0.1.7-rc.2` (official release page: <https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.7-rc.2>).
+- **Plugin runtime verdict:** **no confirmed breaking change in the DSH APIs
+  that DeepPilot currently calls**.
+- **Install/deployment verdict:** the exact peer/dev pins and lockfile are now
+  updated to `0.1.7-rc.2`; `npm test`, `npm run typecheck`, `npm run build`, and
+  the rc.2 config-schema check pass locally. Support still awaits a real rc.2
+  `web` profile smoke test and the release checklist's clean-install gate.
+- **Protocol verdict:** no required DeepPilot phone-protocol break was found in
+  the rc.2 release notes or the inspected rc.2 source. This does not waive the
+  normal integration test against a real rc.2 Host.
+- **Current implementation:** the optional DSH Schedule facade, schedule phone
+  frames, `schedule.manage` authorization, DSH `schedule/changed` projection,
+  a prompt-free persistent mutation journal, and the DSH Session fork facade
+  with fork idempotency are implemented and locally tested. The private iOS
+  protocol mirror, BridgeClient/AppModel integration, reminder list/editor/
+  history UI, and message “Branch from here” action are implemented; real
+  Host/iPhone integration remains pending.
+
+## Evidence and risk assessment
+
+| Area | rc.2 finding | DeepPilot impact |
+| --- | --- | --- |
+| Session controller | The rc.2 source still exposes the methods used by the adapter: `list`, `inspect`, `create`, `modelCatalog`, `selectModel`, `rename`, `prompt`, `attachment`, `cancel`, and `projections`. It adds `search`, `page`, `follow`, `fork`, `updateQueue`, `initializeDefaultModel`, and native workspace-path operations. | Existing calls are source-compatible at the inspected API level. New calls must remain optional and capability-gated. |
+| Workspace controller | `create`, `archiveSession`, `unarchiveSession`, and `follow` remain. rc.2 adds rename/delete/order/pin operations and archive activity handling. | Existing bridge behavior is source-compatible. Archive behavior is stricter when a Session has active work, including scheduled reminders. |
+| Gateway / Typert | The in-process `typertGateway.wireStream.open(endpoint, payload, uplink, peer, signal)` seam used by the resident approval/question Client remains. Typert registration still exposes `register(contribution)`. | No confirmed break in the resident Remote Events path. Re-run the approval/question tests on rc.2 because this is the highest-risk integration seam. |
+| Release metadata | The plugin's peer/dev pins and lockfile now target rc.2 with real rc.2 integrity metadata. | Keep `package.json`, `package-lock.json`, compatibility assertions, generated `lib/`, and release documentation synchronized before claiming rc.2 support. |
+| DSH event/history internals | rc.2 continues to evolve session projections, history paging, and assistant stream presentation. The plugin currently consumes the older `session/event`/`inspect` projection seam rather than the newer Remote `page`/`follow` surface. | Treat as a compatibility risk requiring a real Host smoke test, not as a confirmed wire break. Keep the phone protocol independent of DSH controller shapes. |
+
+Official comparison: <https://github.com/deepseek-ai/deepseek-harness/compare/dsh-v0.1.7-rc.1...dsh-v0.1.7-rc.2>.
+
+## New rc.2 capabilities worth using
+
+Prioritized for DeepPilot, in this order:
+
+1. **Durable reminders and schedules (highest value).** DSH now has
+   `schedule_create`, `schedule_list`, `schedule_delete`, and
+   `schedule_update`, persistent one-shot/fixed-rate/daily/weekly/cron tasks,
+   restart survival, delivery history, and a minimum one-minute interval. Add
+   an optional, session-bound schedule surface to the phone: list tasks, create
+   or edit a task, delete it, and show delivery history. Keep all operations
+   behind `sessions.manage` plus a dedicated schedule scope; never log reminder
+   prompts. A reminder must remain bound to its original Host Session.
+   *(Implemented in 0.8.3. As of DSH 0.2.0 this capability is no longer
+   bundled by default — see "Automation is now an optional bundle" above, and
+   any real-host verification must enable Automation tasks first.)*
+2. **Host Session search.** `sessionController.search(query)` returns bounded
+   snippets without activating an Agent. This maps naturally to a phone search
+   screen and can reduce the amount of history transferred over a mobile link.
+   Return only the bounded snippet/session identity and keep it in the
+   `sessions.read` authorization domain.
+3. **Conversation forking.** `sessionController.fork({ sessionId, atSeq? })`
+   enables a phone action such as “branch from this turn”. It is additive to
+   the phone protocol but needs an iOS mirror, cursor/ownership tests, and a
+   deliberate policy for subagent and archived Sessions.
+4. **Queue editing.** `sessionController.updateQueue` supports editing,
+   removing, or steering a pending queue item. This is useful for a phone when
+   a turn is already running, but it needs first-class queue UI and conflict
+   handling rather than silently changing the existing prompt path.
+5. **Open/reveal on the Mac.** rc.2 adds verified native workspace-path opening
+   and application discovery. This could power a deliberate “Reveal in Finder /
+   Open associated app” action. Keep the Host's path verification and show an
+   explicit confirmation on the phone; do not expose arbitrary shell access.
+
+Features that are primarily Web/Desktop UX (onboarding, keyboard shortcut
+management, archived-only filters, account/API-key model entry separation, and
+background continuation) should not be copied into the phone plugin unless
+they solve a mobile-specific need.
+
+## Required rc.2 upgrade gate
+
+> Superseded by the 2026-09-28 `0.2.0-rc.1` audit at the top of this file. The
+> gate below still applies to that release with one change: a schedule smoke
+> test additionally requires the user to enable the **Automation tasks** bundle,
+> because a stock 0.2.0 Host does not mount the Schedule service.
+
+Do not call the rc.2 baseline fully supported until all of these are true:
+
+1. The exact DSH peer/dev pins and lockfile remain on `0.1.7-rc.2`.
+2. The plugin's full release checklist passes: `npm ci`, `npm test`,
+   `npm run typecheck`, `npm run build`, `npm run check:config-schema`, Go helper
+   tests, and the binary checksum verification.
+3. A real DSH rc.2 `web` profile smoke test covers: session list/open, history,
+   prompt, model selection, workspace list/create/archive/unarchive, approval,
+   question, and disconnect/reconnect replay.
+4. A phone-visible schedule create/list/update/delete/history flow is tested
+   after the schedule surface is implemented; a passing plugin build alone does
+   not prove mobile protocol compatibility.
+5. Fork is tested for exact event-prefix behavior, idempotent retries, and
+   original-session immutability after the fork surface is implemented.
+6. `COMPATIBILITY.md`, README compatibility text, generated `lib/`, and this
+   file are updated with the tested DSH version and intentional support range.
+
+## Re-audit rule
+
+For every future DSH release, compare the new tag against the last audited tag,
+inspect the package/service surfaces actually imported by this repository,
+classify install/runtime/protocol risk separately, and append a dated decision
+here. Do not treat a release-note summary as proof of compatibility.