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