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.
Антонов Антон Владимирович
antonov