home-hosted 0.6.0 → 0.6.2

package/AGENTS.md

@@ -85,6 +85,19 @@ exists, so the first release has to be published by hand.
 - `uis/<name>/` — each UI is a Vite app (Vue 3 + Tailwind v4) built through `uis/vite.shared.ts`;
   `stock` is the one shipped inside the package. Aliases: `@` → that UI's `src`, `@shared` →
   `src/shared`, `@server` → `src` (**types only** — never import runtime server code into a UI).
+  Its `public/ui.json` is the UI's identity: `name` and `version` (what Settings shows),
+  `repo`/`tag`/`asset` (which release carries it, for `ui-update`) and `unix` (when it was built).
+  `UiService` carries those fields into the installed `$HHOSTED_HOME/.ui/ui.json` unchanged and adds
+  `uploadedAt`/`files` of its own.
+- **Bumping a UI ships a new asset, so its `ui.json` is part of the change.** Any commit that alters
+  a UI under `uis/<name>/` bumps that `ui.json`'s `version` and sets `unix` to the commit's own epoch
+  seconds: patch for a fix, minor for a feature, and **major only for a rewrite or a restyle**. The
+  number is what tells a person how big the change is — `ui-update` prints it and holds it against
+  the release it is offering. `tag` is what pairs an official UI with its panel, and it is **stamped
+  by `build-uis.mjs`**, not trusted from the source file: a UI zip is built before its release is cut,
+  so the committed value is always a release behind the asset it ends up inside. The release workflow
+  passes `HHOSTED_UI_TAG`; anywhere else the build stamps `v<package.json version>`. Do not hand-edit
+  `tag` to chase a release — a stale one makes `ui-update` re-install the same UI on every boot.
 - `bin/home-hosted.mjs` — the published bin: `dist/cli.js`, or `src/cli.ts` through tsx when the
   build is missing (a linked checkout).
 - `scripts/` — `build-uis.mjs` (build one UI, optionally zip it), `typecheck-uis.mjs`,

package/README.md

@@ -40,8 +40,9 @@ You run a handful of services at home. The usual choices are extremes — 🧟 `
 forget about, 📜 a hand-written systemd unit per service (times six), or 🐳 a whole docker/k8s
 stack??? - too extreme! — plus 😩 monitoring, rebooting and changing the host machine, yuck!
 
-🙂 home-hosted, well, joins in somewhere: a panel/supervisor that starts them, watches them, restarts what dies, and
-puts the whole stack on one page, with deep backup support.
+🙂✨ home-hosted enhances on top: a panel/supervisor that starts them, watches them, restarts what
+dies, and puts the whole stack on one page, with deep backup support — whether a server is a plain
+command or a `docker compose` stack.
 
 ```text
                    ┌──────────────────────────────────────┐
@@ -54,8 +55,13 @@ puts the whole stack on one page, with deep backup support.
    ┌─────────┐               ┌─────────┐                ┌─────────┐
    │ gateway │               │ files   │                │ bot     │
    │ :4000   │               │ :4010   │                │  ...    │
-   └─────────┘               └─────────┘                └─────────┘
-     health ✓                  health ✓                  restarts ↻
+   └────┬────┘               └─────────┘                └─────────┘
+        │ compose up -d
+        ▼
+   ┌────────────┬────────────┬────────────┐
+   │  gateway   │  postgres  │   redis    │          restarts ↻
+   └────────────┴────────────┴────────────┘
+     health ✓ (the published port is the probe)
 ```
 
 |  |  |
@@ -147,7 +153,7 @@ data/                         # per-server data directories, declared through da
 
 One clone, `pnpm install --frozen-lockfile`, `pnpm run up` — the setup is up on any machine with Node.
 Worked example, with per-server data inside the project:
-**[hhosted-9router-dsh](https://github.com/NamesMT/hhosted-9router-dsh)**.
+**[hhosted-ai-pack](https://github.com/NamesMT/hhosted-ai-pack)**.
 
 <sub>Call them as `pnpm run up` — `pnpm up` is pnpm's own update, not your script.</sub>
 
@@ -190,8 +196,8 @@ home-hosted set-token --generate
 #   hh_9uA2…                     (printed once; only its hash is kept, mode 0600)
 
 curl -H "Authorization: Bearer hh_9uA2…" http://127.0.0.1:3999/api/state
-curl -H "Authorization: Bearer hh_9uA2…" -X POST http://127.0.0.1:3999/api/servers/9router/restart
-curl -N -H "Authorization: Bearer hh_9uA2…" 'http://127.0.0.1:3999/api/events?serverId=9router'   # SSE
+curl -H "Authorization: Bearer hh_9uA2…" -X POST http://127.0.0.1:3999/api/servers/omniroute/restart
+curl -N -H "Authorization: Bearer hh_9uA2…" 'http://127.0.0.1:3999/api/events?serverId=omniroute'   # SSE
 home-hosted status --json        # machine-readable: pid, url, health, paths
 ```
 
@@ -251,7 +257,7 @@ can be told what to be: *"Help me build a UI for home-hosted: nostalgic game the
 | 🤖 **Token API** | Scripts and agents drive it with `Authorization: Bearer` — no browser, no session. [↑](#-agents-scripts-and-tools) |
 | 🔔 **Notifications** | Telegram on crash, unhealthy, forced restart, recovery and host thresholds — [setup here](./docs/NOTIFICATIONS.md). |
 | 💾 **Backups** | One click for config, secrets, TLS and your declared data directories — plain `.zip`, or AES-256 with a password, restored per path. |
-| 🎨 **BYOU — Bring Your Own UI** | Upload a static build, `home-hosted ui-revert` to go back. [UI_CREATION.md](./docs/UI_CREATION.md) |
+| 🎨 **BYOU — Bring Your Own UI** | Upload a static build, `ui-update` to follow its releases, `ui-revert` to go back. [UI_CREATION.md](./docs/UI_CREATION.md) |
 | 🔐 **Security** | Cookie sessions, API tokens, scrypt hashes, per-IP lockout, optional TLS, and a refusal to expose itself without a password. |
 | 🧩 **No special treatment** | A server is `command` + `args` + `env` + `cwd`; nothing is built in for any particular app. |
 | 🖥 **Cross-platform** | Linux, macOS and Windows: `/proc`, `ps` or Win32_Process, process groups or `taskkill /T`, no shell dependencies. |
@@ -292,6 +298,7 @@ restarts itself), and how hand-edits are validated: [SERVERS.md](./docs/SERVERS.
 | `home-hosted migrate` | bring `servers.config.json` up to this release's schema (`--dry-run`, `--yes`) |
 | `home-hosted init` | scaffold a project that keeps `state/` and its data in the repo |
 | `home-hosted ui-switch` | install a UI from a release asset, a zip file or a URL (interactive) |
+| `home-hosted ui-update` | bring an installed UI up to date, or pick a release (`--old`, `--check`) |
 | `home-hosted ui-revert` | go back to the stock panel UI after uploading your own |
 
 <details>
@@ -309,6 +316,7 @@ set-password      --clear
 set-token         --generate --clear
 migrate           --config --dry-run -y/--yes
 ui-switch         --repo --tag --asset --file --list --token -y/--yes
+ui-update         --check --tag --asset --old --repo --token -y/--yes
 ui-revert         (no flags)
 
 every command     --home <dir> --project <dir>       (or $HHOSTED_HOME, $HHOSTED_PROJECT)
@@ -394,7 +402,7 @@ archive and restore. Definitions come back, data lands where *this* machine's co
 `autostart` entries come up immediately.
 
 It works because an archive carries its own `servers.config.json` and paths are matched by the
-**declaration** (`9router:DATA_DIR`), not by an absolute path from the source machine. A restore never
+**declaration** (`omniroute:DATA_DIR`), not by an absolute path from the source machine. A restore never
 writes where no config declares.
 
 </details>
@@ -412,7 +420,9 @@ attaches both as `home-hosted-ui-<name>.zip`. Yours can be anything that compile
 the server never cares what built it.
 
 <sub>Install a UI from the CLI: `home-hosted ui-switch` — with no flags it fetches the official asset
-built for this release.</sub>
+built for this release. An **official** UI keeps itself paired with the panel: upgrade the panel and
+the next `up` re-installs the matching asset. Someone else's UI declares its own `repo`/`asset` in
+`ui.json`, and `home-hosted ui-update` offers its newer releases to pick from — `--old` for older ones.</sub>
 
 <details>
 <summary><b>🤖 Or have an agent build the UI you actually want</b></summary>