The notes described a machine that no longer matches: the runtime paths
they hardcoded do not exist on this one, and three of their claims turned
out to be wrong when the plugin was actually installed.
What was wrong, and what is true:
1. Runtime paths. `~/.dsh/dsh-runtimes/...` is only where a downloaded
runtime lives; this install carries it in the application. The notes
now probe both locations and take the one that exists.
2. "You cannot install into the desktop profile from the CLI". The
launcher refuses `desktop` only for booting and for --dump-config;
`dsh plugin --profile desktop ...` is allowed because the Desktop
carrier passes manageDesktopProfile. Verified: install, list, remove
all work, and each one keeps dsh.profile.bundles in sync by itself.
3. "An application restart is required". Not on Desktop. The base bundle
enables hmr whenever profileContext is supplied, and the application
supplies it, so editing the profile manifest recomposes the tree live
and the client half reaches an open page over the HMR transport. The
application had started at 16:36 and the pill appeared in that same
process after the 16:41 install.
Also documented, because it decides whether an edit reaches the harness:
`file:` on Windows produces hardlinks out of the pnpm store, so an
in-place write is visible immediately but an atomic replace silently
breaks the link; `link:` is a junction and always sees edits. The plugin
is now installed as `link:` for that reason.
The design note keeps its original text and carries dated corrections
plus a table of what was actually verified, so the next install does not
repeat the probing.
pnpm pack produces a 12 KB tarball with only the two halves and the bundle
patch; it was installed into a throwaway profile to prove it works and
that both halves parse. The notes make the composition step explicit,
because a package can sit in a profile without ever loading -- which is
the state dsh-bottom-info-bar is in on this machine.
The plugin manager accepts an absolute local path, so the package can be
installed from this workspace. Two requirements make or break it: a DSH
peer range (runtime is 0.2.0-rc.2) and a declared bundle patch. Notes that
HMR is absent from the desktop profile, so a restart is required and the
restart is therefore the last step.
Spike proves response.body.tee() splits a real routerai SSE stream: the
consumer sees chunks progressively (first at 1ms of 1643ms) and our branch
still recovers the generation id and usage.cost. It also found a real
defect -- a rebuilt Response loses url, which the OpenAI SDK reads -- and
that Object.defineProperty is the only way to restore it.
Records what was verified against the live routerai API and the harness
code: the provider reports usage.cost on every response, the harness
discards it in mapUsage, and the cost can still be recovered by wrapping
globalThis.fetch while session attribution rides the llm/stream seam.