dsh-home-hosted 0.1.3 → 0.2.0

package/README.md

@@ -9,8 +9,8 @@ A DeepSeek Harness plugin for [home-hosted](https://github.com/NamesMT/home-host
 - **Boot autostart** — installs, verifies and removes the OS entry that starts `home-hosted` at boot (systemd on Linux, launchd on macOS, Run key / Task Scheduler on Windows). Off by default; opt in from the plugin's page.
 - **Runs its own home-hosted** — the pinned copy ships as a dependency, so the panel that starts at boot is the version this plugin was built against. The page can start that panel, or replace a running one with it.
 - **Server management** — add, edit, start, stop and restart home-hosted's servers without leaving dsh, with the panel's API as the write path so nothing is restarted behind your back.
-- **Reclaim the harness** — a managed `dsh` entry gets `onPortConflict: kill`, so a leftover process holding the web port is reclaimed at boot instead of blocking forever.
-- **Agent tools** — off by default, allowlisted one by one; every tool that changes something asks for approval first.
+- **Reclaim the harness** — a managed `dsh` entry follows its own detached restart on POSIX, and uses `onPortConflict: kill` on Windows where a detached restart cannot be identified.
+- **Agent tools** — on by default. `status`, `servers_list`, `servers_lifecycle` (start/stop/restart), `servers_edit` (create/update/delete), `autostart_manage` (install/uninstall), `ui_manage` (status/update/revert/switch the panel's own UI). A tool that changes something asks for approval only in a session that is not already Full access.
 
 ## Install
 
@@ -41,7 +41,7 @@ Everything a person toggles lives in `<stateDir>/settings.json`, including **Opt
 - The plugin ships its own `home-hosted` (pinned range) and runs that copy by default; Options in the page can switch to a global install instead. Boot entries run a small stable launcher it writes, so a `node_modules` path that moves never breaks boot.
 - Boot (pre-login) needs privilege somewhere, and the page shows the exact commands when it cannot elevate: on macOS pick the boot-scope **launchd-daemon** (a one-time `sudo` install), on Linux **systemd-system** or `loginctl enable-linger`. A `LaunchAgent` and an XDG entry start at login only.
 - The panel API token this plugin uses is minted on first write and kept 0600 under the plugin state directory; it is never rendered or logged.
-- `onPortConflict: kill` needs home-hosted 0.6.0 or newer; against an older panel the plugin refuses that write and says so, because that panel cannot parse the config it would produce.
+- `onPortConflict: kill` needs home-hosted 0.6.0 or newer; against an older panel the plugin refuses that write and says so, because that panel cannot parse the config it would produce. The POSIX default is `follow`, which needs nothing extra.
 
 ## License
 

package/docs/DESIGN.md

@@ -31,6 +31,32 @@ node_modules (flat or pnpm), then PATH — and forwards its argv, so the entry
 survives plugin upgrades and profile reinstalls. The plugin preflights the
 launcher the way the unit invokes it and shows the version it answers.
 
+## Agent tools are merged and on by default
+
+Six tools, not ten: `servers_lifecycle` carries start/stop/restart, `servers_edit`
+carries create/update/delete, `autostart_manage` carries install/uninstall, and
+`ui_manage` drives the panel's own UI (`ui-update` / `ui-revert` / `ui-switch`).
+They are registered on by default; what gates a mutating call is the session's
+own permission mode, not a plugin-level default.
+
+## The dsh entry is the only entry the page manages
+
+The page shows one toggle: manage `dsh` as a home-hosted entry, or not. Adding
+one sends a minimal intent (`{ id: 'dsh', autostart: true }`) and the host fills
+the rest from the platform default policy; removing one restores an entry this
+plugin merely adopted, and deletes one it created. Removing an entry the panel
+supervises stops that process — which may be the session asking for it.
+
+## Approvals follow the session's sandbox
+
+A mutating agent tool asks the approval service only when the calling session is
+*not* already `danger-full-access` (`ctx.sandboxPolicy.resolve({ session })`).
+Asking anyway made a Full-access run fail whenever the deployment's approvals
+auto-reject — the session had already granted exactly what the tool was asking
+about. Below full access the tool still asks and still fails closed, and the
+refusal names the mode and the remedy (Full access, or an answerable approval
+channel).
+
 ## Config compatibility
 
 `onPortConflict: kill` did not exist before home-hosted 0.6.0, and an older panel