@ours.network/install 1.2.1-nightly.1 → 1.2.1-nightly.11

package/README.md

@@ -1,141 +1,117 @@
-# @ours.network/install — `ours-install`
+# @ours.network/install — one installer for the whole stack
 
-The all-in-one installer for the ours.network stack. One run installs and
-configures the shared daemon, MCP adapter, cowork, Telegram connector, Fleet,
-and plugins for every safely detected agent harness.
+Requires Node.js 22+ and npm. Install the selected release channel:
 
 ```sh
-npm install --global @ours.network/install
+npm install -g @ours.network/install@nightly
 ours-install
 ```
 
-### Stable and nightly channels
-
-Installing `@ours.network/install@latest` selects the stable channel; installing
-`@ours.network/install@nightly` selects the nightly channel. Before changing the
-machine, the installer resolves `@ours.network/mcp`,
-`@ours.network/claude-code`, and `@ours.network/codex`, verifies that their
-selected dist-tags expose one exact lockstep version, and fails closed if they
-do not. MCP and the Codex launcher are installed by exact version, and local
-Claude Code and Codex marketplace manifests pin the corresponding plugin
-packages to that same version.
-
-`OURS_CHANNEL=latest|nightly` (or the legacy `OURS_INSTALL_CHANNEL`) remains an
-explicit override. Without an override, the installed package's own version
-selects the channel.
-
-The normal flow uses one daemon at `~/.ours` on port 3050, shows an eight-stage
-progress bar, and asks only for information it cannot safely infer (normally the
-Human identity's display name). Existing daemon conflicts and moving a Telegram
-connector from another daemon still require explicit confirmation.
-
-## What the installer does
-
-- Installs `@ours.network/cli`, `@ours.network/mcp`,
-  `@ours.network/tg-connector`, `@ours.network/cowork`, and
-  `@ours.network/fleet` on one release channel.
-- Configures, starts, and enables the single shared daemon with a CLI-managed
-  user systemd service on Linux or LaunchAgent on macOS.
-- Creates the daemon's Human identity (historically called the root identity),
-  or preserves the existing one on a re-run.
-- Installs the ours plugin into safely detected Claude Code, Codex, and Hermes
-  installations.
-- Configures and starts cowork as a durable shim over the shared daemon.
-- Configures and starts Telegram as a durable shim over the same daemon.
-- Runs Fleet's native initialization through prepared settings or its interactive wizard. Fleet owns and
-  publishes its v2 configuration, including subscriptions, models, roles,
-  templates, and permissions. The installer does not start Fleet roles.
-
-The operator CLI owns daemon configuration, lifecycle, and boot persistence.
-The MCP package is only the stdio adapter spawned by agent harnesses; the
-installer never asks `ours-mcp` to start a daemon.
-
-Daemon state is temporarily scoped to its package major version. On a same-major
-update, the installer refreshes the packages and runs `ours daemon restart`; the
-CLI streams structured startup phases until restore is complete instead of
-appearing to hang. A different-major update is detected before package
-replacement. The installer explains the incompatibility and, only in an
-interactive run, offers to stop the CLI-managed daemon, copy the complete state
-directory to a timestamped directory under `~/.ours-backups/`, remove the
-managed service and old state, then initialize the new major. The default answer is no, and
-`OURS_ASSUME_YES` never authorizes this purge.
-
-## What remains stopped
-
-Only Fleet is intentionally not started. Review and activate it when ready:
+With no arguments, the wizard explains each step and offers keyboard choices.
+Use arrow keys and Enter to choose, and Space to select integrations. Recommended
+settings keep advanced ports and package overrides out of the usual flow. Text
+input is used for your name and explicitly customized paths or ports. Linux x64
+recommends native mode; macOS and Windows recommend Docker. On Windows run the
+installer inside WSL with Docker Desktop integration. This recommendation concerns
+packaging and isolation, not a guarantee that emulated x64 is faster on ARM Macs.
+
+The same installer accepts complete CLI presets. It reports missing answers before
+changing the machine and never opens hidden prompts when arguments are supplied.
+Both forms show the same preparation, identity, update and readiness progress.
 
 ```sh
-# After completing Fleet's wizard and reviewing ~/fleet.yaml:
-ours-fleet doctor
-ours-fleet config
-ours-fleet up
-ours-fleet ls
+# Whole stack, with prepared Fleet settings and no interactive prompts:
+ours-install --mode docker --state-dir "$HOME/ours-docker" \
+  --identity-name "Your Name" --integrations codex,fleet \
+  --fleet-settings "$HOME/fleet-settings.json"
+
+# Native server only; native and packages mean the same mode:
+ours-install server --mode native --state-dir "$HOME/ours-native" \
+  --identity-name "Your Name"
+
+# Clients connected to an existing server:
+ours-install client --config /private/client/profile.json \
+  --integrations codex,fleet --fleet-settings /private/fleet-settings.json
+
+# Update a retained complete installation and its clients:
+ours-install all update --mode docker --state-dir "$HOME/ours-docker" \
+  --identity-name "Your Name" --integrations codex,fleet \
+  --fleet-settings "$HOME/fleet-settings.json" --compatible
 ```
 
-The final installer screen repeats these commands and provides a copy-paste
-prompt for Claude Code, Codex, or Hermes. The agent should guide local bot-token
-entry without asking the user to paste the secret into chat.
+`server` and `client` are presets of the same flow, not separate interactive
+installers. `--integrations none` explicitly skips client integrations. Use
+`--dry-run` with a complete preset to preview it, and `--help` for all options.
+Fleet's own wizard is available only in interactive setup; CLI Fleet setup requires
+its JSON settings file. Fleet stays stopped until you review and activate it.
 
-## Preview and automation
+The server installs the daemon/SDK/CLI, Telegram, Cowork and Messenger.
+It starts the daemon, preserves the existing Human identity (or creates it once),
+then starts its applications. Full-stack setup issues a separate local client
+credential and configures the selected Codex, Claude Code and Fleet integrations.
+Existing identity keys and names are retained on update. An update's storage
+compatibility must be reviewed before supplying `--compatible`.
 
-```sh
-ours-install --dry-run
-OURS_ASSUME_YES=1 ours-install
-ours-install --state-dir /absolute/path --port 3070
-```
+The installer embeds exact component versions and SHA-512 values for its release.
+An existing server's retained release selects matching local clients. Secrets are
+read from protected files, and client setup never copies the daemon API master.
 
-Dry-run walks the real plan without writing files, installing packages, starting
-processes, or changing services. `OURS_ASSUME_YES=1` uses the OS username for a
-new Human identity and asks no ordinary setup questions, but it never bypasses
-selection conflicts, connector moves, or destructive safeguards.
-
-A non-default daemon must be selected coherently with a config file or matching
-port and state directory. Hermes and the generated Fleet role persist that
-selection through `OURS_CONFIG`. Claude Code and Codex plugin registrations
-cannot store an environment value; for those harnesses the installer prints the
-exact `export OURS_CONFIG=...` line that must be added to the shell profile
-before starting the harness. There is no per-application daemon.
-
-`OURS_CONFIG` may also name a prepared private host profile containing the
-complete `endpoint`, `expectedInstanceId`, and absolute `credentialPath` tuple.
-The profile and credential must already be regular current-user files with
-private permissions. In this mode the installer verifies `/selection` before
-sending the credential to `/version`, installs only MCP, detected Claude/Codex
-plugins, and Fleet client support, and never creates, starts, stops, or services
-a host daemon. Telegram, cowork, messenger, daemon voice, and daemon state stay
-Compose-owned. If `OURS_CONFIG` is unset, the same profile is discovered at
-`~/.ours/config.json`; a legacy config there keeps the existing local behavior.
-
-## Uninstall
+## Runtime and client packages
 
-```sh
-ours-uninstall --state-dir "$HOME/.ours"
-ours-uninstall --state-dir "$HOME/.ours" --purge
-```
+Server selections include `@ours.network/daemon`, whose `ours-daemon` binary owns
+runtime startup and service administration. Docker runs `ours-daemon serve`;
+native installations install its systemd/launchd service. Existing retained
+installations can still stop and restore their older CLI-owned runtime.
 
-The uninstaller delegates service and daemon removal to the `ours` CLI. Identity
-state is retained by default. Purging requires the existing destructive gates and
-targets only the explicit state directory.
+Client selections contain the thin SDK and CLI, plus MCP when a harness needs
+it. They exclude the daemon and its native database/ADAPT dependencies. Fleet
+runs beside the harnesses on the client machine and calls the daemon HTTP API.
+Client commands report an unavailable server and never start one automatically.
 
-When `OURS_CONFIG` selects a host profile, uninstall removes only selected
-client attachments. The operator-owned profile and shared credential are kept
-even with `--purge`, and no Compose daemon, service, or state is touched.
+The development policy selects published SDK `3.8.1-nightly.9`, CLI
+`2.8.1-nightly.7`, and daemon `3.8.1-nightly.1`, together with exact reviewed
+consumer source commits. The isolated host CLI pair uses these released client
+artifacts. The nightly release manifest selects the complete published consumer
+set and standalone daemon with verified SHA512 integrities. Packaged installers
+use this exact release set; mixed or unselected nested SDK versions remain rejected.
 
-## Release channel
+## Migrate an existing global installation
 
-`OURS_CHANNEL=nightly` (or `OURS_INSTALL_CHANNEL`) selects the packages' nightly
-dist-tags. Without an override, the installer's own version selects the channel.
-The operator CLI intentionally has no nightly dist-tag and remains untagged on
-both channels.
+The wizard detects the old `~/.ours/config.json` and offers to keep its identities,
+messages, keys and settings in the new installation. It follows the configured
+state directory, including a custom location. An equivalent unattended preset is:
 
-## Environment
+```sh
+ours-install all --mode docker --state-dir "$HOME/ours-docker" \
+  --migrate-from "$HOME/.ours/config.json" --compatible --integrations codex
+```
 
-- `OURS_ASSUME_YES=1`: accept safe defaults without prompting.
-- `OURS_INSTALL_DRY_RUN=1`: preview without mutation.
-- `OURS_NPM`: npm executable.
-- `OURS_CONFIG`: explicit legacy daemon config or prepared private host profile.
-- `OURS_STATE_DIR`: explicit daemon state directory.
-- `OURS_CHANNEL`: `latest` or `nightly`.
+Run the old daemon before the first migration so the installer can record and
+verify its identities. The new runtime is downloaded/built first. Then the old
+boot service and daemon stop, and the complete daemon state is copied while its
+writer lock is held. Docker migration imports that copy into its named storage
+volume. Existing Human/role names and CIDs must match before applications start;
+migration never creates a replacement Human.
+
+The original state/configuration remain unchanged. A private `legacy-backup`
+directory stores the original config/service definition, and
+`legacy-client/profile.json` is a prepared connection profile for the new server.
+Selected integrations are configured by the usual client setup. The global `ours` command is switched to a launcher for the managed installation
+only after verifying ownership of its existing npm entry; foreign or read-only
+commands are refused before migration. Ordinary `ours identity list` is checked
+after cutover. Lifecycle commands manage the new installation, and selection
+overrides cannot accidentally return to the old daemon. The old configuration is
+not reinterpreted as a client profile. Do not start the old state alongside the
+migrated daemon. Reinstalling the global CLI with npm can replace the launcher;
+repeat the same migration command to verify and repair that routing.
+
+Repeat the same command after an interruption. Once the destination has started,
+retries repair it in place instead of replacing it with an older source snapshot.
+The source is kept stopped after an activation failure to avoid diverging identity
+sessions. Migration requires local Linux/macOS (or WSL) with `node:sqlite` support,
+a verifiable old CLI/service, and a separate target directory. External PostgreSQL
+history or unsupported external MCP/token-delivery paths are refused before
+shutdown. Unrelated application data outside the daemon tree is not copied.
 
 ## Selected network installations (2.0)
 
@@ -145,15 +121,15 @@ SHA-512 values. Acquisition validates the ours dependency graph before activatio
 A development override without a release binding is not a qualified product release.
 
 ```sh
-ours-install server install --mode docker --state-dir /private/ours-install
-ours-install server install --mode packages --state-dir /private/ours-install
+ours-install server install --mode docker --state-dir /private/ours-install --identity-name "Your Name"
+ours-install server install --mode packages --state-dir /private/ours-install --identity-name "Your Name"
 ours-install server status --state-dir /private/ours-install
 ours-install server stop --state-dir /private/ours-install
 ours-install server start --state-dir /private/ours-install
 ours-install server restart --state-dir /private/ours-install
 ```
 
-Choose one mode for a private installation root. The private `installation.json`
+Choose one mode and a folder for its programs and data. The private `installation.json`
 records mode, instance selection, configuration/source paths and service selection;
 it never records master bytes or an issued-token registry. The selected policy
 is resolved to an exact, role-filtered `sources.json` before acquisition.
@@ -169,8 +145,19 @@ Linux/WSL or a launchd GUI user domain on macOS. Source builds also require Git,
 Python 3, a C/C++ toolchain, make, and the selected repositories' own prerequisites.
 Docker mode requires a working Docker engine and Compose 2.35+; its build image
 contains the source-build prerequisites. No bind or Docker socket mounts are used.
-Server runtime installation selects SDK/CLI, main MCP, Telegram, Cowork and
-Messenger. Main MCP is injected into the daemon, not started as a second daemon.
+Docker is recommended for macOS and Windows. Install and start Docker Desktop
+on those hosts; on Linux, install Docker Engine and the Compose plugin. If Docker
+is unavailable, the installer explains how to install/start it or use
+`server install --mode packages --state-dir <new-empty-directory>` instead.
+Native Windows installations require WSL with a working systemd user manager.
+The installer never switches an existing installation's mode automatically.
+Server installation shows each stage before it starts, streams Docker builds and
+native package acquisition, and reports completion only after service readiness.
+If a Docker service fails, the error includes its last 50 log lines (bounded in
+size) and a command to inspect the logs. A failed daemon prevents consumers from
+starting; a failed consumer does not prevent checks of unrelated consumers.
+Server runtime installation selects SDK/CLI, Telegram, Cowork and
+Messenger. MCP runs locally with the Codex and Claude Code plugins and calls the daemon API through the SDK.
 The daemon starts first; consumers are checked through their owning readiness
 interfaces. Messenger uses its existing identity prerequisite and never creates an
 identity. Its failure is reported after attempting unrelated consumers. Package
@@ -219,7 +206,7 @@ client-owned installer settings:
 ```
 
 ```sh
-ours-install client install --config /private/client/profile.json
+ours-install client install --config /private/client/profile.json --integrations codex,claude-code
 ```
 
 Optional `sourcesPath` and `fleetSettingsPath` values are absolute or resolved
@@ -227,9 +214,9 @@ relative to the profile file. Select any nonempty subset of integrations; Fleet
 When Fleet settings are supplied, the installer passes them to Fleet's strict
 noninteractive `init --settings`; otherwise it opens Fleet's existing wizard.
 Fleet validates and publishes its own configuration. Client setup verifies the selected
-daemon and packaged OURS MCP before registering native integrations. It acquires
+authenticated daemon API before registering native integrations. It acquires
 only selected integration packages and their actual client dependencies. It does
-not install main MCP, administer daemon state or invoke Docker. Exact npm client
+not administer daemon state or invoke Docker. Codex and Claude Code include the local stdio MCP server as a dependency. Exact npm client
 installation needs no Python; Git source builds use the supplied source recipes
 and their build prerequisites. Normal native clients need neither Docker nor
 server maintenance tools.
@@ -256,7 +243,7 @@ Interactive no-argument installation asks for package/Docker server mode, a
 prepared client profile, or `client`. Client setup offers the saved server when
 present. On first setup it asks for the server HTTP endpoint, issued-token file,
 source manifest and integration choices, obtains the instance UUID from
-`/selection`, displays it, then checks authenticated daemon and MCP access before
+`/selection`, displays it, then checks authenticated daemon API access before
 saving anything. No UUID must be entered manually. The 2.0 HTTP flow assumes the
 approved trusted same-host deployment; selection metadata is not cryptographic
 server authentication. Fleet collects missing setup answers through its own wizard.
@@ -269,7 +256,7 @@ For a managed server, maintenance runs on the server machine through the install
 ours-install server backup server snapshot --state-dir /path/to/installation
 ours-install server restore server snapshot --state-dir /path/to/installation
 ours-install server rebuild --state-dir /path/to/installation
-ours-install server update --state-dir /path/to/installation --compatible
+ours-install server update --mode docker --state-dir /path/to/installation --identity-name "Your Name" --compatible
 ```
 
 Backup and restore support the full server or an individual `daemon`, `telegram`,
@@ -313,3 +300,36 @@ maintenance reads both formats. Format2 is not readable by older maintenance too
 so this change does not promise executable downgrade support. Restore validates the
 original archive records unchanged, then writes markers for the active target runtime.
 Mixed/incomplete context and component record sets are refused before activation.
+
+### Retrying a Docker installation after a source-policy permission failure
+
+Setup verifies the selected Docker image before reusing it, including when the image
+already exists. If an older installer left a root-owned, mode-0600
+`/opt/ours/sources.json`, setup repairs only that image file's permissions and
+continues. The selected package bytes, build provenance, image execution settings,
+credentials and stored data are retained. The old materialized Dockerfile's known
+COPY instruction is also corrected for future builds. No manual image or volume
+deletion is required; repeat the original setup with the updated installer.
+
+The repair runs isolated verification containers without state mounts or network
+access. Other image verification failures stop setup without replacing the image.
+An interrupted repair can be retried, including after the image tag was replaced.
+
+### Remote clients over HTTPS
+
+A client may select an `https://` origin backed by a TLS reverse proxy. Keep the
+daemon listener private and configure the proxy separately with a certificate
+trusted by the client and matching the hostname. Node uses its normal trust
+store; a private CA may be supplied through `NODE_EXTRA_CA_CERTS` before starting
+the client. Certificate verification must remain enabled.
+
+The existing issued client credential works over either transport; changing the
+URL scheme does not require a new credential. Keep the server's master on the
+server. Forward `x-ours-api-token` and the `x-ours-*` session headers unchanged,
+and support streamed request/response bodies and long polling. Client requests
+refuse redirects, including HTTPS-to-HTTP redirects: configure the final HTTPS
+origin directly. UUID/capability checks still precede credential-bearing calls.
+
+This adds client HTTPS support, not an HTTPS daemon listener, certificate
+provisioning or automatic reverse-proxy configuration. Existing local HTTP and
+SSH-tunnel profiles continue to work.

package/assets/Dockerfile

@@ -3,7 +3,9 @@ FROM node:24 AS toolchain
 RUN apt-get update && apt-get install -y --no-install-recommends build-essential python3 ca-certificates git && rm -rf /var/lib/apt/lists/*
 FROM toolchain AS build
 WORKDIR /opt/ours
-COPY sources.json /opt/ours/sources.json
+# The host selection is private (0600); this non-secret image policy must be
+# readable by arbitrary runtime UIDs while remaining root-owned and non-writable.
+COPY --chmod=644 sources.json /opt/ours/sources.json
 COPY scripts/build/*.mjs /build-scripts/
 COPY scripts/maintenance/build-context.mjs scripts/maintenance/provenance-compare.mjs scripts/maintenance/release-graph.mjs /maintenance/
 RUN --mount=type=secret,id=github_token --mount=type=cache,id=ours-dist-2-npm,target=/root/.npm,sharing=locked node /build-scripts/build.mjs
@@ -21,6 +23,7 @@ COPY scripts/runtime/runtime-common.mjs /opt/ours/docker/runtime-common.mjs
 COPY scripts/runtime/check-client.mjs /opt/ours/docker/check-client.mjs
 COPY scripts/runtime/check-start.mjs /opt/ours/docker/check-start.mjs
 COPY scripts/runtime/client-setup.mjs /opt/ours/docker/client-setup.mjs
+COPY scripts/runtime/legacy-import.mjs /opt/ours/docker/legacy-import.mjs
 COPY scripts/runtime/entrypoint.sh /opt/ours/docker/entrypoint.sh
 COPY scripts/runtime/healthcheck.mjs /opt/ours/docker/healthcheck.mjs
 COPY scripts/runtime/start-telegram.sh scripts/runtime/health-telegram.sh scripts/runtime/start-cowork.sh scripts/runtime/health-cowork.sh scripts/runtime/start-messenger.sh scripts/runtime/health-messenger.mjs /opt/ours/docker/

package/assets/docker-compose.yaml

@@ -177,6 +177,26 @@ services:
       start_period: 30s
       retries: 12
 
+  legacy-import:
+    profiles: [maintenance]
+    build:
+      <<: *source-build
+      target: maintenance
+    platform: linux/amd64
+    image: "${OURS_MAINTENANCE_IMAGE:-ours-compose-2-maintenance:local}"
+    user: "0:0"
+    network_mode: none
+    read_only: true
+    cap_drop: [ALL]
+    cap_add: [CHOWN, DAC_OVERRIDE]
+    security_opt: [no-new-privileges:true]
+    entrypoint: [node, /opt/ours/docker/legacy-import.mjs]
+    environment:
+      OURS_UID: "${OURS_UID:-1000}"
+      OURS_GID: "${OURS_GID:-1000}"
+    volumes:
+      - {type: volume, source: server-storage, target: /storage, volume: {nocopy: true}}
+
   state-operation:
     profiles: [maintenance]
     build:
@@ -195,7 +215,7 @@ services:
       OURS_STATE_ROOT: /storage
       OURS_LIVE_ROOT: "${OURS_LIVE_ROOT:-/storage/state}"
       OURS_BUILD_ROOT: /opt/ours
-      OURS_CLI_PATH: /opt/ours/node_modules/.bin/ours
+      OURS_DAEMON_BIN_DIR: /opt/ours/node_modules/.bin
       OURS_DAEMON_CONFIG: /var/lib/ours/config.json
       OURS_COWORK_CLI_PATH: /opt/ours/node_modules/.bin/ours-cowork
       OURS_COWORK_CONFIG: /var/lib/ours-cowork/config.json