dsh-deeppilot 0.9.2 → 0.9.4

package/COMPATIBILITY.md

@@ -12,7 +12,7 @@ range before the plugin will install there.
 | Component | Current contract | Evidence |
 |---|---|---|
 | Node.js | 22 or newer | Package engine and CI |
-| DSH CLI and Host API | `>=0.2.0-rc.2 <0.3.0-0` (audited against `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 |
+| DSH CLI and Host API | `>=0.2.0-rc.2 <0.3.0-0` (dev pins `0.2.0-rc.2`; source audits through `0.2.1-alpha.2`) | Peer metadata, source typecheck, unit tests, bundle build, and config schema projection against a real 0.2.0-rc.2 CLI, plus an isolated compose with the published 0.2.1-alpha.2 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,7 +21,7 @@ range before the plugin will install there.
 - The Host adapter uses Session and Workspace controllers, Gateway Remote Events, and `typertGateway.wireStream.open(endpoint, payload, uplink, peer, signal)`. Its in-process carrier passes `undefined` for `uplink` and `peer` and the cancellation signal in argument five.
 - The resident Client sends relative RPC paths such as `api/$events/result`. The in-process transport resolves those paths to a local URL before constructing a Node `Request`; the shared Fetch handler dispatches it without a network request. This is required for iOS approval and question answers to settle at the Gateway.
 - The client settings page binds `configForms.get('deeppilot')` when the service becomes available. The Host reads volatile config references from its profile entry and reconciles transports on `loader/volatile-update`.
-- Typert strict codecs publish `create()` factories. Session opening reads `session.projections` for a complete baseline.
+- Typert strict codecs publish `create()` factories. Session opening reads `session.projections` for a complete baseline; that controller requires a cancellation signal from `0.2.1-alpha.2` on, so the adapter always passes one.
 - The Host adapter retains a stable bridge-facing API so the phone protocol does not depend directly on DSH controller shapes. This adapter is an internal design boundary, not support for an older DSH Host.
 
 ## Separate protocol and data boundaries
@@ -31,28 +31,30 @@ range before the plugin will install there.
 - 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
+## Schedules ship with the Web composition
 
-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.
+Reminders need no user action on a current host. DSH 0.2.0 briefly moved
+automation out of the shipped Web composition into the optional
+`@deepseek-ai/dsh-experimental-schedule-bundle`, and the following release
+removed that bundle again: it is listed in `RETIRED_BUNDLES`,
+`@deepseek-ai/dsh-web-app` mounts `schedule` and `ui-schedule` in every Web
+profile, and loading a profile strips the retired entry from
+`dsh.profile.bundles`. The plugin manager no longer shows an **Automation
+tasks** switch, so no profile is expected to enable anything for reminders.
 
-The plugin needs no change for this. It still resolves the service through
+The plugin needed no change for either step. It 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.
+schedule frame when the service is absent. On a Web host the service is mounted,
+so the capability bit is `true` by default; a profile that drops the rows still
+reports `false` and still degrades cleanly.
 
 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.
+`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.
 
 ## Configuration migration
 
@@ -62,6 +64,30 @@ 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.1-alpha.2 audit outcome
+
+The source-level audit of `dsh-v0.2.1-alpha.2` against `dsh-v0.2.1-alpha.1`
+(669 commits, 3226 changed files) found the peer set almost untouched — 10 of
+the 12 peer packages have zero changed source files — but one real break
+outside it: `SessionController.projections` now aborts before it reads
+anything, so the adapter's signal-less call lost the entire projection baseline.
+That is fixed here: `src/dsh-api-proxy.ts` passes a signal, its controller
+mirror declares one required, and a regression test fails against the previous
+call form. Install and phone-protocol risk are unchanged — the peer range admits
+`0.2.1-alpha.2`, and protocol v2, pairing state, and device records are
+untouched.
+
+A live `0.2.1-alpha.2` host has now exercised the bridge. An isolated profile
+built from the shipped Web template, booted by the published CLI, passed the
+phone-protocol checklist over the LAN TLS listener — health, SPKI, pairing
+rejection, WSS upgrade, challenge/prove with all six scopes, session and
+workspace RPCs, archive/unarchive, the schedule create/history/delete flow, and
+reconnect replay (25 pass, 0 fail, 3 skipped). Running the published `0.9.3` on
+the same host version instead logged
+`[deeppilot] sessions.projections failed: internal` while still passing every
+step, which is the silent degradation this release fixes. A real model turn, the
+Funnel transport, and a real iPhone are still unverified.
+
 ## 0.2.0-rc.2 audit outcome
 
 The source-level audit of `dsh-v0.2.0-rc.2` against `dsh-v0.2.0-rc.1` found no

package/bin/SHA256SUMS

@@ -1,6 +1,6 @@
-69f2d9793f750ca68863eae0aaf40a2c670ed52579349e907c213529754356de  ./darwin-amd64/dsh-deeppilot-tunnel
-f9fe205fb8d97684ddb9350e02cb766ffb53e8610a3c5dfce0d265872ac6a8b3  ./darwin-arm64/dsh-deeppilot-tunnel
-d5c97703970e595a4f341fb446fa3337f87fefbf766ab81aea12d983318b98c1  ./linux-amd64/dsh-deeppilot-tunnel
-f1eb837e02eb9ee63801d12be9df45351a895963b9f635079eb2287a7f59954a  ./linux-arm64/dsh-deeppilot-tunnel
-88cca9341aa9f87215c0de2ebb69d0971bc4fa39548df332a000c63560c830f2  ./windows-amd64/dsh-deeppilot-tunnel.exe
-5b81075d986fd387192084f916964d2c4a51ca494ce331e0346a8a75fc3e7b8d  ./windows-arm64/dsh-deeppilot-tunnel.exe
+c70401fd9530f2fae6abe7aec5eacacca239ba315cedc7197db530df8c6f97bd  ./darwin-amd64/dsh-deeppilot-tunnel
+45ff6b53d3e27fe6242e4904055d647d8b220a5c56ca76e542ffcd861ad3bbad  ./darwin-arm64/dsh-deeppilot-tunnel
+8d4937de90564327dcf8392dba6241e4facc30044a48447b22de99f3e62c9808  ./linux-amd64/dsh-deeppilot-tunnel
+cd4638f9aa3e60340d4f446301b2b6f6452f5cb89fc012884e5a893ab8dbd577  ./linux-arm64/dsh-deeppilot-tunnel
+d5435d4e0c02056b3fac39a5f289acb404e6f060dc566e5dea724ee2b86a4296  ./windows-amd64/dsh-deeppilot-tunnel.exe
+7d79c848b2b74286764bd284005edbcfdf539be90ce0b160ea464ae3af70e005  ./windows-arm64/dsh-deeppilot-tunnel.exe

package/docs/DSH_RELEASE_MEMORY.md

@@ -5,50 +5,173 @@
 
 ## Current decision
 
-- **Audited release:** `dsh-v0.2.1-alpha.1` (official release page:
-  <https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.1-alpha.1>),
-  published 2026-10-03 on the npm `alpha` dist-tag. It is **not** `latest`;
-  `latest`/`next` still point at `0.2.0-rc.2`, which is what the current Host runs.
-- **Comparison baseline:** `dsh-v0.2.0-rc.2` (the previous plugin baseline).
-- **Plugin runtime verdict:** **no breaking change in the DSH APIs that DeepPilot
-  currently calls.** All 12 peer packages have **zero** changed `src/` files
-  between the two tags — each changed only its `package.json` version field and
-  its READMEs. See the 2026-10-03 entry below for the full finding-by-finding
-  table and for the three official upgrade guides checked against this plugin.
-- **Nothing was changed to support this release.** `package.json`,
-  `package-lock.json`, generated `lib/`, `COMPATIBILITY.md`, and `PROTOCOL.md`
-  deliberately still describe the `0.2.0-rc.2` baseline. The release-audit-only
-  scope was agreed before the audit ran, so no version bump, no dependency
-  install, and no `lib/` regeneration was performed.
-- **Peer range still admits it:** `>=0.2.0-rc.2 <0.3.0-0` satisfies
-  `0.2.1-alpha.1` under `semver.satisfies(..., { includePrerelease: true })`,
-  which is how DSH's `evaluatePluginCompatibility` gates activation. The same
-  holds for the `~4.0.4` / `~3.18.4` vendor ranges against `4.0.5-alpha.1` /
-  `3.18.5-alpha.1`. Under npm's **default** prerelease handling those three do
-  not match, so installing on an alpha host from npm reports peer warnings.
+- **Audited release:** `dsh-v0.2.1-alpha.2` (official release page:
+  <https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.1-alpha.2>),
+  published to npm 2026-10-09T08:18:00Z on the `alpha` dist-tag. It is **not**
+  `latest`; `latest`/`next` still point at `0.2.0-rc.2`.
+- **Comparison baseline:** `dsh-v0.2.1-alpha.1` (the previous audited tag).
+- **Plugin runtime verdict: one confirmed break, fixed in this audit.**
+  `SessionController.projections` now requires its cancellation signal — the
+  published implementation calls `signal.throwIfAborted()` as the first
+  statement of its `try` and reads `signal.aborted` in its `catch`, while the
+  adapter called it with no signal at all, so every projection baseline read
+  failed with a `TypeError` instead of returning values. The adapter now passes
+  a signal and its hand-written mirror declares `signal` required. See "The one
+  confirmed break" in the 2026-10-09 entry for the reproduction, the fix, and
+  the regression test that pins it.
+- **What is unaffected:** `list`, `inspect(sessionId)` (its signal is still
+  optional upstream), `create`, `fork`, `rename`, `cancel`, `attachment`,
+  `prompt`, `selectModel`, `modelCatalog`, the workspace controller, the Gateway
+  wire-stream seam the resident approval/question client depends on, the shared
+  Fetch carrier, and every peer package's exported runtime surface.
+- **Install verdict:** the peer range `>=0.2.0-rc.2 <0.3.0-0` admits
+  `0.2.1-alpha.2` under `semver.satisfies(..., { includePrerelease: true })`,
+  which is how DSH's `evaluatePluginCompatibility` gates activation; npm's
+  **default** prerelease handling still reports peer warnings for
+  `@deepseek-ai/dsh`, `cordis`, and `schemastery`. Composing a real Web profile
+  with this plugin's `cordis.patch.yml` on the published CLI adds the plugin's
+  three rows plus its own config schema and no plugin-attributed diagnostic; the
+  four base-profile schema errors it prints reproduce identically without the
+  patch.
 - **Protocol verdict:** no required DeepPilot phone-protocol break. Protocol v2,
   pairing state, and device records are unchanged; already-paired phones need no
   action.
-- **Release verdict (`0.9.2`, shipped 2026-10-04):** `scripts/smoke-live.mts`
-  was run against a live **`dsh-v0.2.1-alpha.1`** web profile and passed with
-  **0 failures**. This is the first live-host verification since the 0.9.1
-  entry, and it retires the gate that entry left open ("pending separate
-  authorization before the `0.9.1` release ships") — on a newer host than the
+- **Capability gaps, not regressions:** the new `workingDirectory` projection,
+  the new `formatStatus` list field, the `mode: 'external'` subagent catalog, and
+  the `session/migration-required` fork refusal are all things this plugin does
+  not consume, and none of them change a call it already makes.
+
+### Plugin release verdicts
+
+- **Release verdict (`0.9.4`, prepared 2026-10-10, NOT published):** carries the
+  `projections` adapter fix and the Automation tasks documentation correction
+  described in the 2026-10-09 entry below. `package.json`, both root
+  `package-lock.json` version entries, and `tests/apply-baseline.snapshot.json`
+  are on `0.9.4`, and `lib/` is regenerated. The full checklist passed locally:
+  `npm ci`, 538 unit tests, typecheck, build, the config-schema check against a
+  real `0.2.0-rc.2` CLI, Go helper tests, helper checksums, and
+  `npm pack --dry-run` (65 files, 50,916,470 bytes packed). The fix was also
+  verified on a live `0.2.1-alpha.2` host against the published `0.9.3` as an
+  A/B control (25 pass / 0 fail either way, with the `sessions.projections
+  failed: internal` diagnostic present only on `0.9.3`). Nothing was
+  published, tagged, or pushed; npm `latest` still points at `0.9.3`, so users on
+  `0.2.1-alpha.2` keep hitting the projections defect until this ships.
+  - **The release also had to fix the helper's toolchain and its refresh
+    workflow.** CI's `govulncheck` job reported 11 reachable Go standard-library
+    vulnerabilities for the pinned `go 1.26.6`; this is time-triggered, not
+    caused by the release — `0.9.3`'s CI was green on 2026-10-05 with the same
+    helper source. `helper/go.mod` now pins `go 1.26.9`, and the six `bin/`
+    binaries were rebuilt with it. That rebuild only became correct after fixing
+    `.github/workflows/build-helpers.yml`: each build job uploaded the whole
+    `bin/` tree, so every artifact also carried the checked-out copies of the
+    targets its runner never rebuilt, and `merge-multiple` let those stale files
+    overwrite the fresh ones (the first refresh PR mixed two toolchains — only
+    darwin-arm64 embedded `go1.26.9`). The workflow now uploads only the
+    per-matrix target globs; PR #19 then carried all six at `go1.26.9` and was
+    merged as `f0f243b`.
+  - **Checklist environment notes for the next release.**
+    (a) `~/.npm/_cacache` contains root-owned files on this machine, so `npm view`
+    and `npm pack` fail with `EPERM` unless `npm_config_cache` points at a
+    writable cache — the run above used the workspace audit cache.
+    (b) Go's default build cache lives outside the workspace and the file sandbox
+    blocks it (`open .../Library/Caches/go-build/...: operation not permitted`,
+    reported as `[setup failed]`); point `GOCACHE` at a workspace directory.
+    (c) `gh` writes its run-log cache under `~/.cache/gh` and fails the same way;
+    point `XDG_CACHE_HOME` at a workspace directory.
+    None of the three is a repository defect.
+- **Release verdict (`0.9.3`, published 2026-10-05, tag `v0.9.3` @ `b85869b`):**
+  shipped to `latest`. Verified on the registry: version present, `dist-tags.latest`
+  moved off `0.9.2`, 65 files, `dist.shasum` `90f0c665c395a7043eb3689a291cf28c88bc39ab`
+  byte-identical to the locally verified `npm pack` output, and a clean install plus
+  a real `dsh --profile web --dump-config` compose (188 entries) with the plugin's
+  three `cordis.patch.yml` entries present and no missing-module error. Ships
+  issue #24 (`100.64.0.0/10` becomes a selectable pairing target) and the Windows
+  journal `fsync` tolerance fix. Protocol v2 unchanged; paired phones need no action.
+  - **`gitHead` deviation, recorded rather than hidden.** The registry records
+    `gitHead` `fbda6a5`, the docs-only commit that added `RELEASE_NOTES-0.9.3.md`,
+    while tag `v0.9.3` points at `b85869b`. The cause is ordering, not content:
+    the tarball was packed before that docs commit, and npm stamps `gitHead`
+    from HEAD at publish time. The shipped bytes are provably `b85869b`'s tree —
+    the published `dist.shasum` equals the local `npm pack` output and the tarball
+    does not contain `RELEASE_NOTES-0.9.3.md`. `fbda6a5` is `b85869b`'s child and
+    changes no packaged file. Versions are immutable on npm, so this cannot be
+    corrected retroactively; **do it differently next time: commit every doc file
+    before packing, and pack after the last commit.** The 0.9.2 entry below had
+    `gitHead` matching the tag because no commit landed between pack and publish.
+  - **Install caveat users will hit — DSH's release-age policy.** Confirmed again
+    while verifying this release: `dsh plugin add --profile web` writes a
+    `minimumReleaseAgeExclude` entry in `pnpm-workspace.yaml` and an explicit
+    `dsh-deeppilot@0.9.3` installs the new version. Expect the unversioned form to
+    resolve to a slightly older release for a while; this is expected DSH
+    behaviour, not a publishing failure.
+- **Release verdict (`0.9.2`, published 2026-10-05, tag `v0.9.2` @ `4b43671`):**
+  shipped to `latest`. Verified on the registry: version present, `dist-tags.latest`
+  moved off `0.9.1`, `gitHead` `4b436715` matches the tag and HEAD, 65 files,
+  and a clean DSH profile install of `dsh-deeppilot@0.9.2` composes with the
+  plugin's three `cordis.patch.yml` entries present and no missing-module error.
+  `scripts/smoke-live.mts` passed with **0 failures** against a live
+  **`dsh-v0.2.1-alpha.1`** web profile — the first live-host verification since
+  the 0.9.1 entry, retiring the gate it left open ("pending separate
+  authorization before the `0.9.1` release ships"), on a newer host than the
   rc.2 that entry contemplated, which is strictly stronger evidence: the
   `0.2.1-alpha.1` source-diff above found zero changed `src/` files across all
   12 peer packages, and the live run agrees. The plugin's own build and type
-  baselines stay pinned to `0.2.0-rc.2`; nothing about the pin changed for this
-  release.
+  baselines stay pinned to `0.2.0-rc.2`; nothing about the pin changed.
+  - **Install caveat users will hit — DSH's release-age policy.** On a clean
+    profile, `dsh plugin add dsh-deeppilot` installed **`0.9.1`**, not the just
+    published `0.9.2`, even though `latest` already pointed at `0.9.2`. DSH
+    deliberately prefers a slightly older release and offers an exact-version
+    path instead; `dsh plugin add dsh-deeppilot@0.9.2` installs the new one.
+    This is expected DSH behaviour, not a publishing failure — do not read the
+    older version in the installer as a broken release.
+  - **Peer-range note for future audits.** `evaluatePluginCompatibility` checks
+    each peer against the *running DSH version*, but `cordis` and `schemastery`
+    are host-vendored third parties and `react` comes from the Web app. Judging
+    those three against a DSH version number reports false mismatches. They are
+    also `optional` in `peerDependenciesMeta`. Confirm installability by
+    composing a real profile, not by iterating the peer table.
 - **Two tracked follow-ups:**
-  1. **Schedule documentation is now stale.** Automation tasks became a
-     built-in Web capability and `@deepseek-ai/dsh-experimental-schedule-bundle`
-     is in DSH's new `RETIRED_BUNDLES` set, so the user instruction "enable
-     Automation tasks in the plugin manager" points at a retired bundle.
-     Affects `PROTOCOL.md`, `COMPATIBILITY.md`, and the iOS copy. **Open.**
-  2. ~~`subagent_session` is unmapped.~~ **Resolved 2026-10-03:** mapped to
+  1. ~~Projection signal.~~ **Resolved 2026-10-10:** the adapter passes
+     `new AbortController().signal` to `session.projections` and the mirror
+     declares `signal` required, so the compiler enforces it. Covered by a new
+     regression test that fails against the previous call form. 538 unit tests,
+     typecheck, and build pass with regenerated `lib/`.
+  2. **Automation tasks documentation: public docs fixed, iOS copy open.**
+     Automation was a short-lived optional bundle: DSH 0.2.0 moved it out of the
+     shipped Web composition, and the following release retired
+     `@deepseek-ai/dsh-experimental-schedule-bundle` again — `dsh-web-app` now
+     mounts `schedule` and `ui-schedule` in every Web profile. `COMPATIBILITY.md`,
+     `PROTOCOL.md`, `docs/DEEPPILOT_FEATURE_PLAN.md`, and the schedule-service
+     comment in `src/dsh-api-proxy.ts` now state that; the private app still
+     ships `error.scheduleUnsupported` and `schedule.unsupported` copy telling
+     the user to enable it (`app-private/ios/L10nFragments/schedule.json` and the
+     generated `zh-Hans.lproj` / `en.lproj` string tables). **iOS copy still
+     open** — it belongs to the private repository and to its own release flow.
+  3. ~~`subagent_session` is unmapped.~~ **Resolved 2026-10-03:** mapped to
      `E_PROTOCOL` in `src/wire-errors.ts` and added to the frozen expectation in
      `tests/wire-errors.test.ts`. 525 unit tests, typecheck, and build pass.
 
+### Previous decision — `dsh-v0.2.1-alpha.1`
+
+- **Audited release:** `dsh-v0.2.1-alpha.1`, published 2026-10-03 (npm
+  `alpha` dist-tag, also not `latest`). Comparison baseline was
+  `dsh-v0.2.0-rc.2`.
+- **Plugin runtime verdict:** no breaking change in the DSH APIs DeepPilot calls.
+  All 12 peer packages had **zero** changed `src/` files; each changed only its
+  `package.json` version field and its READMEs. Full table in the 2026-10-03
+  entry below.
+- **Nothing was changed to support that release.** `package.json`,
+  `package-lock.json`, generated `lib/`, `COMPATIBILITY.md`, and `PROTOCOL.md`
+  stayed on the `0.2.0-rc.2` baseline — no version bump, no dependency install,
+  no `lib/` regeneration. The same held for its source diff; the alpha.2 audit
+  that followed then produced one adapter fix (see the 2026-10-09 entry).
+- **Peer range:** `>=0.2.0-rc.2 <0.3.0-0` admitted `0.2.1-alpha.1` through
+  `semver.satisfies(..., { includePrerelease: true })`; the `~4.0.4` / `~3.18.4`
+  vendor ranges admitted `4.0.5-alpha.1` / `3.18.5-alpha.1` the same way, and
+  npm's default prerelease rules reported warnings for those three.
+- **Protocol verdict:** no required phone-protocol break; protocol v2, pairing
+  state, and device records unchanged.
+
 ### Previous decision — `dsh-v0.2.0-rc.2`
 
 - **Audited release:** `dsh-v0.2.0-rc.2` (official release page:
@@ -84,6 +207,252 @@
   bundle" below. The plugin needs no code change; the phone's copy now points
   at the bundle.
 
+## 2026-10-09 — audit of `dsh-v0.2.1-alpha.2`
+
+### Scope and method
+
+Compared `dsh-v0.2.1-alpha.1...dsh-v0.2.1-alpha.2` (**669 commits, 3226 changed
+files, 114,987 insertions, 28,177 deletions**) from a full clone
+(`git clone --filter=blob:none --no-checkout`, unshallowed before measuring).
+Baseline SHA `5badb150`, target SHA `d7432673`, annotated tag object `6851e496`.
+Peer package names were mapped to monorepo paths by reading every `package.json`
+in the tree, then each peer package's `src/**/*.ts` was diffed with
+`git diff --name-status`. Every changed source file under `packages/api`,
+`packages/session*`, `packages/client`, and `packages/core` was read in full —
+including the complete 836-line session-controller diff — rather than being
+summarised from release notes. All **20** upgrade guides added since the last
+audit (19 under `docs/upgrade-guide/v0.2.1-alpha.1/` plus `bundled-python-tests`
+under `v0.2.0-rc.2/`) were read in Chinese in full, and each one that could touch
+an integration seam was traced to its implementation before being judged. No
+guide from an earlier release was modified between the two tags.
+
+### Peer packages: 2 of 12 changed source
+
+| Package | Path | Changed `src/` files |
+| --- | --- | --- |
+| `@deepseek-ai/dsh` | `apps/cli` | 1 (`src/args.ts`) |
+| `@deepseek-ai/dsh-client-connection` | `packages/client/connection` | 5 (`api-request-trust.ts`, `browser-auth.ts`, `index.ts`, `rpc-host.ts`, `rpc.ts`) |
+| `@deepseek-ai/dsh-api-gateway` | `packages/api/gateway` | 0 |
+| `@deepseek-ai/dsh-api-remotes` | `packages/api/remotes` | 0 |
+| `@deepseek-ai/dsh-client-locale` | `packages/client/locale` | 0 |
+| `@deepseek-ai/dsh-client-ui-settings` | `packages/client/ui-settings` | 0 |
+| `@deepseek-ai/dsh-client-ui-slots` | `packages/client/ui-slots` | 0 |
+| `@deepseek-ai/dsh-settings` | `packages/settings/settings` | 0 |
+| `@deepseek-ai/dsh-typert-protocol` | `packages/typert/protocol` | 0 |
+| `@deepseek-ai/dsh-typert-registry` | `packages/typert/registry` | 0 |
+| `@deepseek-ai/cordis` | `vendor/cordis` | 0 |
+| `@deepseek-ai/schemastery` | `vendor/schemastery` | 0 |
+
+`react` is not an upstream package and was not measured. Two non-peer packages
+that the bridge reaches through `ctx.get` did change and are covered below:
+`packages/api/session-controller` and `packages/client/connection`.
+
+### The one confirmed break
+
+`packages/api/session-controller/src/index.ts` started dereferencing a parameter
+that upstream's own published declaration already marks as required:
+
+```ts
+async projections(request: SessionProjectionsRequest, signal: AbortSignal): Promise<SessionProjectionsValue> {
+  const { sessionId } = request
+  if (sessionId.length === 0) throw new RemoteError('gateway/bad-request', ...)
+  try {
+    signal.throwIfAborted()                                   // now the first statement
+    const live = this.liveProjections(sessionId)
+    ...
+  } catch (error) {
+    ...
+    if (signal.aborted || ...) throw new RemoteError('gateway/cancelled', ...)   // now unconditional
+    ...
+  }
+}
+```
+
+In alpha.1 the same method only forwarded `signal` into `observeSession` and read
+`signal.aborted` inside the `catch`, so an omitted signal still survived the happy
+path. In alpha.2 the omission throws before any work is done — reproduced against
+the published `0.2.1-alpha.2` bundle with the real class, a stub context whose
+live-projection path returns a value, and no signal:
+
+```sh
+# published @deepseek-ai/dsh-api-session-controller@0.2.1-alpha.2, lib/index.js
+SessionController.prototype.projections.call(receiver, { sessionId: 'x' })
+# → TypeError (signal is undefined at signal.throwIfAborted(), then again at signal.aborted)
+SessionController.prototype.projections.call(receiver, { sessionId: 'x' }, new AbortController().signal)
+# → { kind: 'sequenced', asOfSeq: 7, values: { title: 'audit' } }
+```
+
+DeepPilot's call site is `src/dsh-api-proxy.ts:235`:
+
+```ts
+projections: async (request) => this.call(() => this.session.projections(request.payload!)),
+```
+
+The hand-written mirror at `src/dsh-api-proxy.ts:45` declares `signal?` optional,
+which is exactly what let the omission typecheck; the upstream declaration
+(`@deepseek-ai/dsh-api-session-controller@0.2.1-alpha.2`,
+`lib/types/index.d.ts:209`) requires it. `DshApiProxy.call()`
+(`src/dsh-api-proxy.ts:413`) converts the `TypeError` into
+`{ ok: false, error: { code: 'internal' } }`, so this degrades rather than
+crashes: `HostBridge.refreshProjections` (`src/host-bridge.ts:799`) already treats
+a failed baseline as a diagnostic and logs
+`sessions.projections failed: internal`.
+
+**Observable effect.** The phone's session summary loses the on-open complete
+projection baseline. It still receives title, todo counts, and token usage from
+the session list rows' cached projections (`src/dsh-api-proxy.ts:458`,
+`src/host-bridge.ts:1546`) and from live `session/projection` frames
+(`src/host-bridge.ts:453`), so nothing breaks outright; the loss shows up on
+hosts where the baseline read was the only source — a session whose list row
+carries no cached projections stays without those values longer than it should.
+Cold history reads are **not** affected: they run through
+`inspect(sessionId)`, whose signal is still optional upstream.
+
+**Fix (applied 2026-10-10).** The adapter now passes a signal the way `list` and
+`prompt` already do —
+`this.session.projections(request.payload!, new AbortController().signal)` — and
+the mirror's `signal` is required, so the compiler keeps it that way.
+`refreshProjections` is fire-and-forget and has no cancellation source of its
+own, so a dedicated long-lived controller is not warranted; following the
+existing convention in the same file is enough. `lib/index.js` was regenerated.
+
+The fix ships in `0.9.4`, which is prepared but not published (see "Plugin release
+verdicts"); until it is published, a host on `0.2.1-alpha.2` running the
+published `0.9.3` still loses the on-open projection baseline. That was observed
+directly: on a live `0.2.1-alpha.2` host running published `0.9.3` the diagnostic
+appeared, and on the same host version running this build it did not (see "Live
+run on a real `0.2.1-alpha.2` host" under Validation evidence).
+
+`tests/dsh-api-proxy.test.ts` adds "projection baseline reads pass the
+AbortSignal the Host now requires": a controller stub that calls
+`signal.throwIfAborted()` before returning, plus an assertion that the adapter
+handed it a real `AbortSignal`. The test was verified red against the previous
+call form (1 failure) and green after the fix, so it pins the behaviour rather
+than the implementation coincidence.
+
+### Other session-controller changes, checked against this plugin
+
+`Where` names the upstream `packages/api/session-controller/src/` file unless it
+says otherwise; `lib/types` means the published declarations of
+`@deepseek-ai/dsh-api-session-controller@0.2.1-alpha.2`.
+
+| Change | Where | DeepPilot impact |
+| --- | --- | --- |
+| `projections` return type is now a union: `{ kind: 'sequenced', asOfSeq, values }` / `{ kind: 'migration-required', values }` / `null` | `src/index.ts:506-541` | The mirror's flat `{ asOfSeq, values }` type is now narrower than upstream, but the plugin reads only `values`, so a successful read still folds. Type-mirror drift, not a runtime defect. |
+| `inspect(sessionId, signal?)` | `packages/session/session-query` | Signal is still optional in the published declaration, so the plugin's `inspect(sessionId)` call keeps working. Cold log reading, scanner row decoding, and the V4 codec path were read and are unchanged for this caller. |
+| `search(request, signal)` requires a signal | `lib/types/index.d.ts:93` | The plugin never calls `search`. |
+| `page(request, signal)` requires a signal | `src/index.ts:1412` | Not called; history paging still goes through `inspect`. |
+| `fork` gains `allowMigration` (default `true`) | `src/index.ts` | The plugin does not send it, so the upstream default keeps automatic migration. The new `session/migration-required` error is unreachable from the phone. |
+| `skill-catalog` injects `workingDirectory` and lists skills by execution directory | `src/skill-catalog.ts` | Not consumed; the plugin lists no skills. |
+| Session ownership helper | `packages/api/session-controller` | Unchanged; `session/agent-busy` still maps to `E_BUSY`. |
+| Subagent catalog v2 `mode: 'external'` | `packages/subagent/subagent` | Descriptor version is still 3 and the earlier one-shot read types are retained; the plugin filters by origin/parent and does not fold catalogs. |
+
+### Connection carrier: unchanged on the paths this plugin uses
+
+`packages/client/connection` gained five changed source files, including a new
+`api-request-trust.ts` and browser-auth changes. Those trust, authentication, and
+TLS checks run through `requestRejection`/`admit`, which guard **physical**
+requests. The plugin's resident client uses
+`connection.createSharedFetchHandler('/api')`, which dispatches routes directly
+and never calls `admit` (`packages/client/connection/src/rpc-host.ts:136-154`), and
+its stream call keeps the
+five-argument `wireStream.open(endpoint, payload, uplink, peer, signal)` order.
+The plugin's own LAN TLS pin check and `/phone` listener are unaffected.
+
+### Four-way comparison at `0.2.1-alpha.2`
+
+| Surface | Both sides | Upstream has, plugin does not consume | Plugin has, upstream does not |
+| --- | --- | --- | --- |
+| Session RPCs | `list`, `inspect`, `create`, `fork`, `rename`, `cancel`, `prompt`, `attachment`, `selectModel`, `modelCatalog`, `projections` | `search`, `page`, `follow`, `updateQueue`, `initializeDefaultModel`, `canOpenWorkspacePath`, `openWorkspacePath`, `workspacePathApplications` | phone-shaped `sessions.*` envelope, history windowing, projection folding, notification suppression |
+| Workspace RPCs | `create`, `archiveSession`, `unarchiveSession`, `follow` | `initializeDefault`, `rename`, `delete`, `insertBefore`, `insertSessionBefore`, `pinSession`, `unpinSession` | archived mirror, `sessionRestore` capability bit |
+| Directory picker | `list`, `pick` | `createDirectory` | browse host/client patch rows, phone-side directory browsing |
+| Schedule | `list`, `history`, `create`, `update`, `delete` | `catalog`, stream delivery modes | phone schedule frames, `schedule.manage` scope, prompt-free mutation journal |
+| Projections | reading `values` | `workingDirectory`, `formatStatus`, the migration-required branch | `title` / `todos` / `sessionStats` / `tokenUsage` folding |
+| Subagents | — | `prompt`, `interruptByParent`, catalog v2 | subagent-session exclusion and notification policy |
+| Trust and auth | shared Fetch route dispatch, TLS pin check | `webStartup.trustedHosts`, listener-address validation | device records, pairing tokens, signed challenge |
+
+Rows marked "upstream has, plugin does not consume" are capability gaps by
+choice, not regressions: none of them changes a call the bridge already makes.
+`neither side` is empty for every row that matters to the phone.
+
+### Validation evidence
+
+- **Unit tests:** `tsx --test tests/*.test.ts` → **537 pass, 0 fail, 0 skipped**
+  on the source diff alone. After the adapter fix and its new regression test the
+  same command reports **538 pass, 0 fail, 0 skipped**, and `npm run typecheck`
+  and `npm run build` pass with regenerated `lib/`.
+- **Config schema on the published CLI:** an isolated `DSH_HOME` and npm cache ran
+  `dsh --profile deeppilot-audit --from-default-profile sdk-minimal
+  --dump-config-schema --patch cordis.patch.yml` against
+  `@deepseek-ai/dsh@0.2.1-alpha.2` → the plugin entry reports
+  `status: 'schema'` with its own `$defs` config, the volatile-field checks pass,
+  and the only warning is the `sdk-minimal` template's own missing
+  `directory-picker` row.
+- **Web composition:** the same CLI composed a real Web profile with the plugin
+  patch → 188 rows versus 185 without it; the plugin's three rows
+  (`deeppilot-directory-picker-browse`, `…-browse-client`, `deeppilot`) are
+  present with the plugin config schema at `#/$defs/config100`. The four
+  `unrecognized Loader tree carrier` errors the dump prints at `/181`–`/184`
+  reproduce **identically without** the patch, so they belong to the base Web
+  profile and not to this plugin.
+- **Published client bundles:** the two resident-client tests
+  (`tests/dsh-wire-stream-contract.test.ts`) were re-run against the actual
+  published `0.2.1-alpha.2` client bundles, resolved through a temporary
+  resolution hook instead of the rc.2 dev pins → pass. This covers client-face
+  composition and the stream's abort-signal argument contract with a **mocked**
+  Host gateway.
+- **Documentation corrected in the same change:** `COMPATIBILITY.md`,
+  `PROTOCOL.md`, `docs/DEEPPILOT_FEATURE_PLAN.md`, and the schedule-service
+  comment in `src/dsh-api-proxy.ts` no longer tell users to enable a retired
+  bundle. The private app's schedule-unsupported strings still do; that copy
+  lives in the other repository and is listed as an open follow-up above.
+- **Live run on a real `0.2.1-alpha.2` host (2026-10-10).** An isolated
+  `DSH_HOME` (`.audit-smoke-home`, workspace root) was given a `smoke` profile
+  built from the shipped Web template with this working tree linked in, plus a
+  second profile pinning the published `dsh-deeppilot@0.9.3`. The published
+  `0.2.1-alpha.2` CLI booted each one in turn and
+  `scripts/smoke-live.mts run` drove the phone protocol against it over the LAN
+  TLS listener (no `--prompt`, so no model turn). **Both runs: 25 pass / 0 fail /
+  0 warn / 3 skipped** — health, TLS SPKI, pairing rejection, WSS upgrade,
+  challenge/prove with all six scopes, session list/create/open/history,
+  model catalog and switch, workspace list/create, archive/unarchive, pending
+  snapshot, the full schedule create/history/delete flow, and reconnect replay.
+  The skips are the log-pin cross-check (needs `SMOKE_LOG`), the real prompt, and
+  the approval/question round trip.
+- **The A/B result is the evidence that matters.** The published `0.9.3` host
+  logged `[deeppilot] sessions.projections failed: internal` while still passing
+  every checklist step, which is exactly the silent degradation predicted above;
+  the working-tree build, same checklist, same host version, logged **zero**
+  `sessions.projections` lines. The defect and the fix are therefore both
+  confirmed at runtime on `0.2.1-alpha.2`, not only in unit tests.
+- **The live run also settles the automation question.** The welcome frame on a
+  stock Web profile advertised `schedules: true` with no bundle enabled and no
+  user action, and the full schedule create/history/delete flow passed against
+  it. That is the behaviour the corrected `COMPATIBILITY.md`, `PROTOCOL.md`, and
+  feature-plan copy now describe.
+- **Still untested:** a real model turn inside the plugin's live path (the
+  isolated home has no model credentials), the Funnel/remote transport (the
+  isolated host ran `remote.enabled` at its default `false`; the live host's
+  phone path goes through the Funnel helper), and a real iPhone. The live smoke
+  gate still refuses to run against the machine's own host without a restart,
+  because `DeviceStore` snapshots `devices-v2.json` once at mount.
+- **Repository pins unchanged:** `npm run check:config-schema` and the CI
+  `config-schema` job still target the `0.2.0-rc.2` CLI. The alpha.2 schema dump
+  above was run separately in an isolated home instead of re-pinning the
+  repository's own gate, so the gate keeps reporting its `0.2.0-rc.2` baseline
+  and nothing in the working tree depends on alpha.2.
+
+### Re-audit procedure used
+
+The same full-clone method as the alpha.1 entry, with one addition: because two
+non-peer packages (`api/session-controller`, `client/connection`) carry the
+integration seams this plugin depends on, the diff was extended past the peer
+set and every changed source file in `packages/api`, `packages/client`,
+`packages/session*`, and `packages/core` was read in full. Judging only the peer
+list would have missed the `projections` break entirely — the peer-list check
+reported 10 of 12 packages clean while the defect sat in a package reached
+through `ctx.get('sessionController')`.
+
 ## 2026-10-03 — audit of `dsh-v0.2.1-alpha.1`
 
 ### Scope and method
@@ -201,6 +570,31 @@ in the same class as the other input-shaped Schedule refusals. Without the
 mapping `wireErrorOf` falls through to `WIRE_ERROR_FALLBACK` (`E_INTERNAL`), which
 would tell the client the failure was worth retrying.
 
+### Cross-platform trap found while shipping 0.9.2
+
+CI's `plugin` job hung on `npm test` four times while shipping 0.9.2. Worth
+recording because macOS could never reproduce it and the fix is one line each.
+
+`tests/journal-parity.test.ts` used `join('/proc/definitely/not/writable', …)`
+as its "unwritable path" probe, in two places. `/proc` is a Linux-only pseudo
+filesystem: on macOS the path simply does not exist, so the branch had only ever
+been exercised on macOS and had never run on Linux at all. On Linux, writing
+under `/proc` does not return an error — and because `dispatch-journal`'s
+`save()` is entirely synchronous `fs` calls (`mkdirSync`/`openSync`/
+`writeFileSync`/`fsyncSync`/`renameSync`), a single write blocks the whole event
+loop. Even `setTimeout` stops firing, and node's `--test-timeout` can only report
+a file-level timeout. Both sites now build the unwritable target inside the
+scratch directory (a file-with-a-child shape that yields `ENOTDIR` identically on
+every platform); recorded values are unchanged because all three candidate paths
+returned the same status on macOS.
+
+Two lessons for future audits: the workflow sets no `timeout-minutes`, so a hang
+costs the full 6-hour default before failing — cancel and re-run rather than
+waiting; and reproduce Linux-only behaviour in a container instead of inferring
+it. `docker run --rm --cpus=2 -v $PWD:/app -w /app node:22` matches the runner
+closely enough (2 cores, and the same `v22.23.x` that `node-version: 22` floats
+to).
+
 ### Re-audit procedure used
 
 Same blobless-clone method as the rc.2 and rc.1 entries, with two refinements: