dsh-home-hosted 0.7.6 → 0.8.0

package/README.md

@@ -179,7 +179,7 @@ Topic docs, one per area — written for whoever has to touch it next:
 
 One entry (`dsh`), one toggle: the panel keeps it alive, restarts it and reclaims its port. A
 detached restart is recognised on macOS and Linux (`follow`); Windows cannot prove identity through
-a `.cmd` shim, so it uses `onPortConflict: kill`. The plugin pins home-hosted 0.7+, so every key it
+a `.cmd` shim, so it uses `onPortConflict: kill`. The plugin pins home-hosted 0.8+, so every key it
 writes is one that panel parses.
 <sub>Web only — see **dsh Desktop** above.</sub>
 

package/docs/BOOT.md

@@ -232,7 +232,7 @@ would be: `BootStatus.recommended` is the host's own `recommend()` answer, and `
 to it when nothing is installed (`pickOf(mechanism ?? before.mechanism ?? before.recommended)`). So
 "Automatic" says which mechanism the next install would use, instead of leaving a person to install it
 and read the result. The sentence is only shown while nothing is installed under that mechanism, and it
-is absent — never "undefined" — when an older panel does not send the field.
+is absent — never "undefined" — when a response omits the field.
 
 The `Details` block describes the mechanism that is actually **installed**, which is a different one
 while a switch is pending, so both it and the picker read one shared lookup rather than each formatting

package/docs/DESIGN.md

@@ -35,12 +35,14 @@ its page.
 
 ## Config compatibility was dropped, deliberately
 
-`onPortConflict: kill` arrived in home-hosted 0.6.0 and `persistent` in 0.6.3, and an older panel
-handed either key can refuse to *boot* from the config. The plugin used to consult the answering
-panel's version and refuse or drop them (`KILL_UNSUPPORTED`). That is gone on purpose: it pins
-`home-hosted@^0.7.20` and autostarts its own copy, so a panel older than those keys is only reachable by
-deliberately preferring an old global install — and this is pre-1.0. Supporting older panels again means
-bringing that check back from history, not re-deriving it.
+`onPortConflict: kill` (0.6.0), `persistent` (0.6.3), `restart <id>` (0.7.13) and the nullable-`label`
+patch (0.7.21) all predate the release this plugin pins. The plugin used to consult the answering
+panel's version and refuse or drop those keys (`KILL_UNSUPPORTED`), and later to retry a `restart` as a
+stop-then-start pair. Both are gone: it pins `home-hosted@^0.8.0`, which refuses an older panel
+outright, so neither check could ever fire again.
+
+An old state root is upgraded by running the latest 0.7.x **once, before installing 0.8** — its first
+run moves the state into `.hh/`.
 
 ## Tests
 

package/docs/ENTRIES.md

@@ -130,7 +130,8 @@ entry's own successor, and it still refuses to touch the panel or any process th
 This process may itself be the entry being managed (`HHOSTED_SERVER_ID`).
 
 - Deleting that entry is refused: it would stop the session doing the deleting.
-- Starting/restarting it is allowed — that is the "reclaim now" case — but the UI says the page will
+- Starting/restarting it is allowed — that is the "reclaim now" case — and it does end this session:
+  an explicit stop tears the entry down even when it is `persistent`. The UI says the page will
   disconnect, and the agent tools need approval first.
 
 ## A managed entry that was deleted

package/docs/PANEL.md

@@ -51,9 +51,27 @@ Verified against a real 0.7.20 panel and its own CLI: `PATCH {port:null}` delete
 and `bootstrap` have a schema that admits `null`; `_hh` is still exactly four routes; and every route,
 subcommand and flag this plugin drives is unchanged. The console **file** — `.hh/.logs/home-hosted.log`
 plus its `.1`, and the 5 MB rotation — is unchanged too, and this plugin's reader still matches
-`home-hosted logs` line for line. A capability that needs a *newer* 0.7.x degrades rather than raising
-the floor: `logs` (0.7.12) is a file read either way, and `restart <id>` (0.7.13) falls back to the
-stop/start pair it replaced.
+`home-hosted logs` line for line.
+
+**0.8.0 is the release that stopped relocating an old state root, and this plugin follows it.** A
+0.6.x root used to be moved into `.hh/` on the first run of 0.7; 0.8 refuses such a root instead, before
+any command resolves a path into it, so that a config sitting at the old paths is never read as an empty
+panel. Nothing is changed or deleted by that refusal. **If you are upgrading from 0.7 or earlier, run
+the latest 0.7.x once first** — that release performs the move — **then install 0.8.** The plugin's own
+floor is `0.8.0` for the same reason: a 0.7.x panel is one it cannot drive, so it says so rather than
+degrading. That removed the last version-conditional code here — a stop-then-start fallback for a panel
+without `restart <id>` — along with the `panel.migrate` action, whose CLI no longer performs that move.
+
+**0.7.21 widens that nullable set by one field, and it closed a bug here.** Clearing a server's label
+sent an empty string, which the panel accepts and saves — so the entry kept a blank label instead of
+falling back to its id, and nothing reported a failure. Only `null` clears the key, and 0.7.21 is the
+release that let the *patch* schema carry one for `label`; before it, that request was refused with
+`label must be a string (was null)`. The editor now sends `null`, and the parity guard reads the
+nullable fields from the pinned release instead of a list that went stale at exactly this bump. The
+release's other five fixes — proxy pid identity, a duplicate liveness predicate, a removed entry
+recreating its own log, an unflushed log batch, a Windows test skip — touch nothing this plugin names:
+no `.proxy/proxy.json`, `ProxyService`, `terminatePid`, or `DELETE /api/logs`, and `serverSchema`,
+`CONFIG_SCHEMA`, `/_hh` and the CLI are unchanged.
 
 That copy resolves to a pnpm path carrying a version and a peer hash, which moves on the next install
 and disappears when the profile is rebuilt. A boot entry that baked it in would fail exactly when it
@@ -93,9 +111,11 @@ over. `authNotice` turns it off; `{url}` is read per 401.
 that is the whole out-of-the-box path when nothing is running.
 
 `panel.takeover` replaces an answering panel with the preferred copy. Stopping the old panel also stops
-every server it supervises, this dsh included, so a detached helper does the work and the guard refuses
-unless this session is an adopted entry with `autostart: true` (something must bring it back). The
-response says the page will disconnect; the helper logs to `bin/panel-takeover.log`.
+the non-persistent servers it supervises — this dsh only if it is one, which an entry this plugin
+manages is not: it is written `persistent: true`, so it survives the panel and the session stays up.
+The guard still refuses unless this session is an adopted entry with `autostart: true`, because a
+non-persistent entry would have nothing to bring it back. A detached helper does the work and logs to
+`bin/panel-takeover.log`.
 
 `panel.start`, `panel.takeover` and `cli.installGlobal` answer a *successful* envelope whose payload
 can still carry `ok: false` — the page reads the payload's `detail`/`output` rather than trusting

package/docs/WORKSPACES.md

@@ -42,8 +42,8 @@ machines. The RPC endpoint still defaults an absent value (the page always sends
 call should not break), but a model is never left to guess.
 
 A pre-0.7 root is not read or written at all. It is recognised (`legacyRoot` on the status), refused on
-every write, and fixed through one action that runs `home-hosted migrate --yes` — the same relocation a
-first 0.7 start does on its own.
+every write, and the refusal names the one remedy: run the latest 0.7.x once — its first run moves the
+state into `.hh/` — before installing 0.8. Nothing is changed or deleted by the refusal.
 
 ## Several panels on one machine
 
@@ -76,12 +76,8 @@ that endpoint has, least invasive first:
   credential, but no live status either, and a running panel applies a changed definition at that
   entry's next start;
 - `cli` runs the CLI against its state root — the only runtime path the panel itself offers.
-  `start`/`stop` act on one entry; a restart is now the CLI's own `restart <id>` (home-hosted
-  0.7.13), which is what the panel's UI does and leaves no window in which the entry is down. A
-  local panel older than that refused the command before touching anything, so the plugin falls
-  back to the stop-then-start pair and reports `downgraded` in the result — the refusal is
-  detected from the CLI's own text, including the `Unexpected argument` a 0.7.12 CLI prints for
-  the positional id;
+  `start`/`stop` act on one entry, and a restart is the CLI's own `restart <id>`, which is what the
+  panel's UI does and leaves no window in which the entry is down;
 - `api` mints a token for that panel, enrols it and uses its HTTP API — the only way to get live
   status, and it replaces any token that panel had, which the question says outright.