@ours.network/install 0.17.0-nightly.2 → 0.17.0-nightly.4

package/README.md

@@ -43,41 +43,148 @@ dependency on the things it installs): an ASCII banner, tasteful colour (degrade
    answers `--version` promptly. A shell alias / hanging wrapper is **never called** (that would
    hang the run) — it's reported plainly with a fix, and a manual-install path is always offered.
    If neither harness exists it says so and exits.
-2. **Config-first** (first install only) — the daemon's two base settings, up front:
-   the **broker** (end-to-end encrypted; the broker never sees message content — almost everyone
-   just presses Enter) and the **port** (probes `3050`; only asks if it's busy; never hands out
-   `3051`, reserved for the Telegram connector). Applied once, then the stack is built with it.
-3. **Four consent gates**, each paced with a clean `✓ … No problems.` line + an explicit
+2. **Five consent gates**, each paced with a clean `✓ … No problems.` line + an explicit
    **Continue?** — never a start-twice-then-ask, never a silent failure:
-   - **1/4 ours core (the daemon)** — write config → optional voice setup → install/start ONCE
-     → boot service. On a re-run it reuses the running config (no re-ask) and only updates when
-     you say yes. Complete voice setup is kept without prompting. Missing/incomplete setup is
-     offered before the first start or pending update restart, then delegated to the canonical
-     `ours-mcp voice-setup` provider selector and hidden API-key prompt. Accepted setup owns the
-     one restart/readiness transaction; declining or already-ready setup preserves the normal
-     core lifecycle. The secret is written atomically to mode-`0600` config; a failed daemon
-     reload rolls back.
-   - **2/4 harness plugins** — the installer **drives the plugin CLIs itself**
+   - **1/5 the shared ours daemon** — its own step, before every consumer, and it owns its own
+     configuration: the **broker** (end-to-end encrypted; the broker never sees message content —
+     almost everyone just presses Enter) and the **listen port**, which is now an explicit
+     question rather than one you only hear about when `3050` is busy. The default is still
+     `3050` (the next free port when that is taken), so **Enter and every non-interactive run
+     land exactly where they always did**. The answer is validated (a real port, not reserved by
+     another component, not already in use, not already claimed by another daemon in this run),
+     persisted to `~/.ours/config.json`, and it is the endpoint everything below is wired to.
+     Then: write config → optional voice setup → install/start ONCE → boot service. On a re-run
+     it reuses the running config (no re-ask) and only updates when you say yes. Complete voice
+     setup is kept without prompting. Missing/incomplete setup is offered before the first start
+     or pending update restart, then delegated to the canonical `ours-mcp voice-setup` provider
+     selector and hidden API-key prompt. Accepted setup owns the one restart/readiness
+     transaction; declining or already-ready setup preserves the normal core lifecycle. The
+     secret is written atomically to mode-`0600` config; a failed daemon reload rolls back.
+   - **2/5 harness plugins** — the installer **drives the plugin CLIs itself**
      (`claude plugin marketplace add …` + `claude plugin install ours@ours.network`;
      `codex plugin marketplace add …` + `codex plugin add ours@ours-codex-marketplace`). Choosing
      Codex also installs the `ours-codex` live launcher in the same step. Any failure / alias
      prints the exact manual commands and continues — it **never dead-ends**.
-   - **3/4 ours-fleet** — makes your harnesses persistent, always-online agent teams that survive
+   - **3/5 ours-fleet** — makes your harnesses persistent, always-online agent teams that survive
      a reboot; runs `ours-fleet init`. Default **Yes**.
-   - **4/4 Telegram connector** — install-only (no bot tokens here), **pointed at the daemon
-     step 1 just built**, then optionally as a boot service.
-4. **Summary + hand-off** — a recap (skipped/failed rows call out the fix), then a **literal
-   copy-paste prompt** (root identity + fleet + Telegram) with the steps for any skipped/failed
-   component dropped out. Copied to the clipboard where supported.
+   - **4/5 Telegram connector** — install-only (no bot tokens here), then a question asked
+     **independently of every other consumer**: use the shared daemon from step 1, or run against
+     its **own dedicated daemon**? Default (and Enter, and non-interactive) is the shared one.
+     A dedicated daemon is provisioned with its own port, its own state directory
+     (`~/.ours-tg`) and its own boot unit (`ours-tg.service`), and the connector is wired to
+     that endpoint. Then optionally installed as a boot service itself.
+   - **5/5 Rooms (ours-cowork)** — durable mission rooms. Default **No**. Configures its own
+     surface (the deployment's broker, its state directory `~/.ours-cowork`, and its loopback
+     **console port** — default `3052`, validated the same way), then asks the same
+     shared-vs-dedicated daemon question, defaulting to shared. A dedicated Rooms daemon gets
+     `~/.ours-rooms` and `ours-rooms.service`. Then `ours-cowork install-service`. See
+     **Daemon topology** for when the question is asked at all.
+3. **Summary + hand-off** — a recap (skipped/failed rows call out the fix), then a **literal
+   copy-paste prompt** (human identity + fleet + Telegram + Rooms) with the steps for any
+   skipped/failed component dropped out. Copied to the clipboard where supported.
 
 The human identity is created idempotently after the daemon becomes reachable. Because
 `curl … | bash` gives the script its input over the pipe, every prompt is read from the
 controlling terminal (`/dev/tty`), so the flow still works piped.
 
-## One daemon, and everything pointed at it
+## Nightly-only profile flow
+
+The `nightly` channel uses a topology-first flow. This is a hard release boundary: `latest`
+keeps the five-step behavior, prompts, package tags, files, service names, and uninstall output
+described above and never reads the profile registry.
+
+Nightly first discovers only configured local candidates: the registry, the historical default
+config, known `~/.ours-tg` / `~/.ours-rooms` configs, Telegram and Rooms daemon blocks, known ours
+systemd/launchd definitions, and an exact manual entry. It never scans a port range. Hosts are
+limited to `localhost` / `127.0.0.1` (stored as `127.0.0.1`); remote names, URLs, credentials,
+`0.0.0.0`, IPv6 loopback, and HTTPS are rejected. A candidate is deduplicated only when both its
+endpoint and canonical state directory agree. Port, state, service, or config collisions stop the
+plan before mutation.
+
+The durable registry is `~/.ours/installer-profiles.json` (schema v1, atomic mode `0600`):
+
+```json
+{
+  "version": 1,
+  "profiles": {
+    "default": {
+      "label": "Default ours daemon",
+      "host": "127.0.0.1",
+      "port": 3050,
+      "configPath": "/home/me/.ours/config.json",
+      "stateDir": "/home/me/.ours",
+      "serviceName": "",
+      "ownership": { "config": true, "service": true, "state": true }
+    }
+  },
+  "harnessAssociations": { "codex": "default" }
+}
+```
 
-A clean deployment installs, configures and starts **one** ours daemon first, then wires every
-client to that same daemon. What that takes differs per client:
+It stores topology and explicit installer ownership only—never tokens, token sources, status,
+PIDs, versions, or running state. `OURS_INSTALL_PROFILES` is a test/operator override. Telegram
+and Rooms remain authoritative in their own configs; their associations are reverse-indexed from
+those real daemon blocks rather than copied into the registry.
+
+After selecting or creating one profile, Nightly selects Claude Code, Codex/`ours-codex`, Hermes,
+Telegram, and Rooms for that exact daemon, shows one review, and confirms once. A harness already
+associated elsewhere requires explicit reassignment. The global `@ours.network/mcp@nightly`
+package is installed/updated at most once; only the selected installer-owned daemon is restarted.
+Snapshotted connector/registry config bytes roll back if validation or service apply fails. Npm changes and
+new identity state are intentionally not destroyed during rollback.
+
+`OURS_ASSUME_YES=1` selects or creates only the historical `3050` / `~/.ours` default, preserves
+existing harness assignments, assigns otherwise-unassociated detected harnesses to it, keeps the
+current harness/fleet defaults, and skips Telegram and Rooms.
+
+## Daemon topology
+
+A clean deployment installs, configures and starts **one shared** ours daemon first, then wires
+every client to that same daemon. That is the default and the backward-compatible answer.
+
+**Optional isolation.** The Telegram connector and Rooms may each instead be given their own
+daemon, chosen independently of one another. Isolation is only real when all three of these are
+separate, which is what the installer provisions:
+
+| | shared | dedicated (Telegram) | dedicated (Rooms) |
+|---|---|---|---|
+| listen port | your step-1 answer | its own, validated against every other daemon in the run | likewise |
+| state directory | `~/.ours` | `~/.ours-tg` — the daemon's API token lives here | `~/.ours-rooms` |
+| boot unit | `ours.service` | `ours-tg.service` (via `OURS_SERVICE_NAME`) | `ours-rooms.service` |
+| config file | `~/.ours/config.json` | `~/.ours-tg/config.json` | `~/.ours-rooms/config.json` |
+
+Without a distinct service name, `ours-mcp install-service` would write the **same** unit for
+both and the second daemon would silently overwrite the first's port and state directory. See
+`packages/core/src/service-instance.ts`; a daemon with no instance name keeps exactly the
+historical `ours.service` / `solutions.adaptframework.ours`.
+
+**Rooms has a third answer.** `ours-cowork` used to host its own daemon, always. It now also
+supports an **external** one, so Rooms answers the same shared-vs-dedicated question — plus
+`embedded`, cowork's own, which is what every install predating that support runs.
+
+Its config carries an optional `daemon` block. Absent means embedded; external is
+`{ mode: 'external', endpoint, stateDir }` and **requires both halves**, because cowork stores no
+token and its SDK reads `<stateDir>/daemon-token`. Env equivalents are `OURS_COWORK_DAEMON_MODE`
+/ `_ENDPOINT` / `_STATE_DIR`, and the service unit carries only those — never a token.
+
+Two things follow from cowork's boot being **fail-closed** (an unreachable endpoint, a non-ours
+daemon, or a mismatched state directory aborts startup, with no embedded fallback):
+
+- A build that **predates** the external mode is never handed a block. The check is on the
+  **installed version**, not the channel: `COWORK_EXTERNAL_MIN_VERSION` in `lib/logic.mjs` is
+  pinned to `0.4.1-nightly.20260816.4aaf940`, the first published cowork that implements it
+  (verified against the registry *and* the tarball's contents). A channel-only gate would have
+  accepted an earlier nightly of the same core version. `cowork@latest` (0.4.0) predates the
+  mode, so the stable installer keeps Rooms embedded, names the build it found and the version it
+  needed, and points at `OURS_CHANNEL=nightly`. An unreadable version keeps Rooms embedded too —
+  it never guesses.
+- An install **already running embedded** is never migrated behind the user's back — headless
+  runs leave it exactly as it is, and interactive runs ask first.
+
+Note the two different `stateDir` keys: the top-level one is cowork's own private state;
+`daemon.stateDir` is the **ours daemon's** state directory. Confusing them fails closed at boot.
+
+What wiring a client to a daemon takes differs per client:
 
 - **The harness plugins** need nothing extra: each is `ours-mcp proxy`, which reads the daemon's
   own config (`OURS_CONFIG`, else `~/.ours/config.json`). `autoStart` is off by default, so a proxy
@@ -104,9 +211,27 @@ while the summary claims success.
 
 ## Release channel
 
-`OURS_CHANNEL=nightly` (or `OURS_INSTALL_CHANNEL`) installs the `nightly` dist-tag for the packages
-that publish one — `mcp`, `tg-connector`, and the `claude-code` / `codex` / `hermes` launchers —
-while `@ours.network/fleet` stays `@latest` always (it publishes no nightly).
+`OURS_CHANNEL=nightly` (or `OURS_INSTALL_CHANNEL`) installs each package's **own** prerelease
+dist-tag. The tag is not the same string everywhere, so the mapping is per package:
+
+| package | stable channel | nightly channel |
+|---|---|---|
+| `mcp`, `tg-connector`, `claude-code`, `codex`, `hermes` | `latest` | `nightly` |
+| `fleet` | `latest` | `nightly` |
+| `cowork` (Rooms) | `latest` | `nightly` |
+
+`fleet` follows the channel: it publishes its own `nightly` dist-tag, and the nightly stack needs
+the fleet build carrying the SDK integration. A nightly installer that quietly installed stable
+fleet is the same split-brain deployment the channel exists to prevent.
+
+`cowork` publishes `nightly` alongside every other service (it previously used `next`). The
+nightly channel must reach that line, because the external-daemon mode the Rooms step configures
+ships there; taking `latest` would pair a config carrying a `daemon` block with a build that
+predates it.
+
+A package with no mapping for the selected channel installs `@latest` rather than a guessed tag,
+because a 404 fails the *whole* install — which is also why the nightly installer must not be
+published before every package it names actually has the tag it will ask for.
 
 **With no explicit selection the installer follows its own version.** A published nightly build
 carries the `-nightly.N` suffix the release bump stamps, so `npm i -g @ours.network/install@nightly`
@@ -140,8 +265,14 @@ is reported and left unchanged.
 | `OURS_CONFIG` | daemon config file location (default `~/.ours/config.json`) |
 | `OURS_STATE_DIR` | daemon state directory (default `~/.ours`) — also what the Telegram connector is told to expect |
 | `OURS_TG_CONFIG` | Telegram connector config file location (default `~/.ours-telegram/config.json`) |
+| `OURS_COWORK_CONFIG` | Rooms config file location (default `~/.ours-cowork/config.json`) |
+| `OURS_COWORK_DAEMON_MODE` / `_ENDPOINT` / `_STATE_DIR` | cowork's own env equivalents of its `daemon` block (read by cowork, not set by the installer) |
 | `OURS_CHANNEL` | `nightly` or `latest`; unset follows the installer's own version |
 
+A non-interactive run takes the shared daemon on its existing default port and installs no
+dedicated daemon and no Rooms — the topology is unchanged from before this flow existed. It also
+never converts an existing embedded Rooms install to an external daemon.
+
 ## Uninstall
 
 The companion `uninstall.sh` reverses what the installers created — same thin-bootstrap +
@@ -163,6 +294,17 @@ directory (`~/.ours`), and the `ours-mcp` daemon. It removes **only** what the i
 created, and guards the two destructive items — the data directory and the daemon — behind
 an explicit typed `yes`.
 
+On Nightly, uninstall is profile-aware. Removing a harness removes only its one association and
+managed plugin artifacts. A daemon/profile cannot be forgotten or removed while any harness,
+Telegram, or Rooms still depends on it. A dependent connector can be explicitly detached (stop its
+service and remove only its daemon target), uninstalled, or reassigned to a different retained
+profile; connector secrets and unrelated settings are preserved. These connector changes roll back
+if exact daemon removal or the registry commit fails. Only a profile with `ownership.service: true`
+may have its exact named service uninstalled; external profiles are forgotten as metadata only.
+Data removal is a separate confirmation that requires typing the exact state path and explicitly
+warns about identity/key loss. The global MCP package is retained while any profile/application
+still needs it.
+
 Headless (no terminal), drive it with environment variables:
 
 ```sh
@@ -177,16 +319,21 @@ OURS_UNINSTALL_DAEMON=yes \
 | `OURS_UNINSTALL` | harnesses to remove (space/comma list of `claude-code codex hermes`, or `all`) |
 | `OURS_UNINSTALL_DATA` | `yes` — remove the ours data directory (`~/.ours`) |
 | `OURS_UNINSTALL_DAEMON` | `yes` — remove the `ours-mcp` daemon |
+| `OURS_UNINSTALL_PROFILE` | Nightly profile id to forget/remove |
+| `OURS_UNINSTALL_FORGET_PROFILE` | Nightly `yes` — forget external/profile metadata only |
+| `OURS_UNINSTALL_TELEGRAM` | Nightly dependency action: `detach`, `uninstall`, or `reassign:<profile-id>` |
+| `OURS_UNINSTALL_ROOMS` | Nightly dependency action: `detach`, `uninstall`, or `reassign:<profile-id>` |
 
 ## Notes
 
 - This package is **not published to npm** (`private: true`); it ships as the hosted
   `install.sh` bootstrap plus the `install.mjs` Node installer (and its `lib/`), and exposes the
   `ours-install` bin. The pieces it installs — the daemon (`@ours.network/mcp`), the harness
-  plugins via each marketplace, `@ours.network/fleet`, and `@ours.network/tg-connector` — are the
-  published components.
+  plugins via each marketplace, `@ours.network/fleet`, `@ours.network/tg-connector`, and
+  `@ours.network/cowork` — are the published components.
 - **Idempotent + safe to re-run.** A re-run adds a skipped piece, re-points the plugins, or (only
   when you say yes) updates a component; an already-current daemon is left untouched, its running
   port and complete voice setup are reused everywhere — and the Telegram connector's daemon
-  selection is rewritten only if it actually changed. Bot tokens and fleet roles remain in the
-  copy-paste hand-off; provider keys never enter that prompt or agent chat.
+  selection, a dedicated daemon's config, and the Rooms config are each rewritten only if they
+  actually changed. Bot tokens and fleet roles remain in the copy-paste hand-off; provider keys
+  never enter that prompt or agent chat.