@openscout/scout 0.2.92 → 0.2.95

package/NOTICE

@@ -0,0 +1,14 @@
+OpenScout
+Copyright 2026 Arach Tchoupani
+
+Licensed under the Apache License, Version 2.0 (the "License");
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+    http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.

package/README.md

@@ -1,429 +1,245 @@
-# Scout CLI
+<p align="center">
+  <a href="https://openscout.app">
+    <img src="https://openscout.app/og.png" alt="Scout — one place for all your agents, local-first and neutral by design" width="100%" />
+  </a>
+</p>
 
-The `scout` command is the front door to the local Scout control plane. It
-discovers coding-agent sessions, routes messages and work through the broker,
-and returns durable handles for follow-up across harnesses and machines.
+<p align="center">
+  <strong>The coordination layer for the coding agents you already run.</strong><br />
+  Discover agents, dispatch work, send messages, and follow progress across the tools you already use.
+</p>
 
-> **Requires [Bun](https://bun.sh) 1.3 or newer.** The bundled native service
-> supports Apple-silicon macOS. Linux runs the broker as a foreground process
-> under your process manager. On macOS, install Bun with `brew install bun`.
+<p align="center">
+  <a href="https://www.npmjs.com/package/@openscout/scout"><img alt="npm version" src="https://img.shields.io/npm/v/@openscout/scout?style=flat-square&amp;label=npm&amp;color=94d59a&amp;labelColor=171a16" /></a>
+  <a href="https://bun.sh"><img alt="Bun 1.3 or newer" src="https://img.shields.io/badge/runtime-Bun_%E2%89%A5_1.3-f7f4ea?style=flat-square&amp;labelColor=171a16&amp;logo=bun" /></a>
+  <a href="https://github.com/oscout/scout/blob/main/LICENSE"><img alt="Apache 2.0 license" src="https://img.shields.io/badge/license-Apache--2.0-f7f4ea?style=flat-square&amp;labelColor=171a16" /></a>
+  <a href="https://openscout.app"><img alt="OpenScout project homepage" src="https://img.shields.io/badge/project-openscout.app-dde6d8?style=flat-square&amp;labelColor=171a16" /></a>
+</p>
 
-## Install
+---
 
-```bash
-bun add -g @openscout/scout
-scout --help
-```
-
-`@openscout/scout` is the public package name. It installs the `scout` command and carries the bundled broker/runtime and web UI. Installing it does not start services; commands such as `scout setup`, `scout up`, and `scout server start` activate them explicitly.
+Scout is a local-first control plane for AI agents. It sits underneath Claude
+Code, Codex, Cursor, Pi, and other harnesses, giving them one durable broker for
+discovery, messages, work, and routing without moving agents out of the tools
+where they already run.
 
-On Linux, `scout setup` initializes the local state but cannot install or start
-a system service. Run `openscout-runtime broker` in a separate supervised
-process, then use `scout doctor` from another shell to verify readiness.
-
-## Canonical Flow
-
-```bash
-scout setup
-scout doctor
-scout whoami
-scout who
-scout latest
-scout runtimes
-scout providers usage
-scout ask --project ../talkie --harness claude "can you review our docs?"
-```
+## What Scout gives you
 
-`scout setup` is the canonical onboarding entry point. It creates or updates:
+| Capability | What it means |
+| --- | --- |
+| **Discover** | See agents, projects, sessions, and available runtimes from one place. |
+| **Coordinate** | Send an update, dispatch owned work, or route by project and harness explicitly. |
+| **Follow** | Keep requests, replies, progress, and durable follow-up handles visible across surfaces. |
+| **Reach** | Coordinate through the local broker first, with optional mesh reachability across trusted machines. |
 
-- `~/Library/Application Support/OpenScout/settings.json`
-- `~/Library/Application Support/OpenScout/relay-agents.json` as compatibility
-  configuration that the broker reconciles into its canonical live state
-- `.openscout/project.json` for the current repo when needed
+Agents keep owning their processes and transcripts. Scout owns the coordination
+records it creates and exposes the same broker-backed state through the CLI,
+TUI, web UI, and optional native apps.
 
-It also discovers local and project-backed agents from your configured workspace roots, installs the base Scout service, attempts to start it, and ensures Caddy is available for the local `scout.local` edge. On macOS, setup installs missing Caddy with `brew install caddy`; otherwise install Caddy yourself or set `OPENSCOUT_CADDY_BIN`.
+## Start here
 
-`scout doctor --fix` asks the native `scoutd` daemon to run conservative repairs
-when that daemon version exposes them. Use `scout doctor --fix --yes` for
-non-interactive install scripts; older or missing `scoutd` binaries simply leave
-the normal doctor report intact.
-
-For a CLI-only onboarding pass, save the same identity, workspace roots, and
-runtime choice used by the app flows:
-
-```bash
-scout config set name "Ada"
-scout setup --source-root ~/dev --default-harness codex
-scout runtimes
-```
-
-`scout setup` creates `~/.openscout/config.json` when it is missing. Use
-`scout init` when you only want to rewrite the local host/port config, for
-example `scout init --force --broker-port 43110 --web-port 43120
---pairing-port 43130`.
-
-When the input is not a known subcommand and includes exactly one `@agent` mention, Scout treats it as an implicit `ask`: it records durable work with the broker, waits for the target to acknowledge or complete immediately, and leaves later completion visible through the conversation or flight follow-up. For example:
+Scout requires [Bun 1.3 or newer](https://bun.sh). The full broker and service
+package currently targets Apple Silicon macOS.
 
 ```bash
-scout @dewey can you review our docs?
-scout hey @hudson please inspect the failing test
-scout --as vox --timeout 900 @talkie take another pass on the keyboard port
-```
-
-Reserved leading profile names are deterministic fresh-session routes for the
-current project, not shorthand agent names:
-
-```bash
-scout ask Fable to review the parser
-scout ask Opus high to fix the tests
-scout ask --profile kimi "review the parser"
-```
-
-The broker owns each profile's harness/model/default mapping. `--effort` is an
-optional Fable/Opus override; Kimi and Grok reject it until their ACP transports
-expose reasoning-effort control. Direct `scout ask --to fable ...` always means
-an existing target named `fable`; it is never silently converted to a profile.
-
-For a natural-language existing target, use an explicit `agent` prefix and
-`to` delimiter:
-
-```bash
-scout ask agent Composer Review to fix the tests
+bun add -g @openscout/scout
+scout setup
+scout doctor
 ```
 
-Scout normalizes that name to exact handle `@composer-review`. Zero or multiple
-agent/session matches fail with disambiguation instead of choosing by locality
-or similarity.
-
-## One Routing Model
-
-The routing rules do not change by harness, UI, or host:
-
-- one target -> DM
-- group coordination -> explicit channel
-- everyone -> `scout broadcast`
-- tell / update -> `scout send`
-- owned work / requested reply -> `scout ask`
-- follow-up stays in the same DM or explicit channel
-
-Short mutable callback names are broker-owned route aliases:
-
-```bash
-scout alias set review --to scope.main.dev-mac-mini-local
-scout alias set patch --to session:019eff52-9347-7470-ba5c-6bfe99d8dd83
-scout alias resolve patch
-scout alias repoint patch --to session:<new-id> --if-revision 1
-scout alias unset patch --if-revision 2
-scout ask --to alias:review "take a fresh pass"
-```
+Prefer npm for global packages? `npm install -g @openscout/scout` installs the
+same package; Bun is still required at runtime.
 
-Aliases are scoped to the current project/local host unless `--project` or
-`--host` is supplied. They point at existing targets and never create or rename
-cards. Native bare agent names win; `alias:<name>` is the explicit form.
+Installing the package does not silently start services. `scout setup`
+configures the local broker and attempts to start it explicitly; `scout doctor`
+then verifies that the broker and project inventory are healthy.
 
-The lowest-churn fresh start is **capability first**: pass the project path and
-optional harness, then let the broker choose or create the concrete worker.
-Do not guess generic names like `claude.main` just because you want Claude. Use
-the returned `ref`, flight, conversation, work, or session handle for follow-up.
-If the worker proves useful, promote it to a named/pinned sibling after the fact
-using the broker-suggested handle when one is returned.
+## Make your first handoff
 
-When sender, target, or recent activity is unclear, the shortest orientation loop is:
+Route work by project and harness instead of guessing an agent name:
 
 ```bash
 scout whoami
-scout inbox --latest 10 --json
-scout who
-scout channel triage --latest 10 --json
-scout latest
-scout latest --channel triage --messages --limit 3
+scout runtimes
+scout ask --project . --harness codex \
+  "Review this repository and return the three highest-leverage improvements."
 ```
 
-Use `channel <name> --latest <count> --json` for the cheapest agent-facing
-channel catch-up. It reads broker messages for that channel and exits. Use
-`latest --channel <name>` when you want the compact activity projection instead.
-Use `inbox --latest <count> --json` for direct messages addressed to the
-current inferred agent identity.
-
-CLI agents should use these commands rather than curling broker HTTP endpoints
-or reading relay files directly.
-
-### Sender identity
-
-`scout send`, `scout ask`, and `scout broadcast` all use the
-same default sender identity. Most of the time you should let Scout infer it
-from your current context. For agent-to-agent delegation, check `scout whoami`
-first and use `--as` whenever the acting project agent must be preserved
-explicitly across shells, hosts, or bridges.
-
-`scout watch` follows a conversation or channel; it does not choose a sender.
-
-Inspect the current default once:
+Scout resolves or starts a suitable worker, records the request, and returns a
+durable handle. Continue the same work with the returned ref:
 
 ```bash
-scout whoami
+scout ask --ref <ref> "Now check the tests."
 ```
 
-Default sender resolution is:
-
-1. `--as <agent>` for that command
-2. `OPENSCOUT_AGENT` when the current session already has a bound agent
-3. the current project-scoped sender inferred from your working directory
-4. your operator name when you're outside a project context
+## One routing model
 
-Coding-agent hosts use the project-scoped sender for `scout ask` automatically when
-the CLI detects a host harness signal:
+| You mean… | Use… |
+| --- | --- |
+| “Heads up.” | `scout send --to <target> "message"` |
+| “Do this and get back to me.” | `scout ask --to <target> "request"` |
+| “Start fresh in this project.” | `scout ask --project . --harness <harness> "request"` |
+| “Continue that exact work.” | `scout ask --ref <ref> "follow-up"` |
+| “Coordinate a group.” | `scout send --channel <name> "message"` |
 
-- **Scout-managed:** `OPENSCOUT_AGENT`, `OPENSCOUT_MANAGED_AGENT`
-- **Cursor:** `CURSOR_AGENT=1`
-- **Claude Code:** `CLAUDECODE=1`, `CLAUDE_CODE_CHILD_SESSION`, `CLAUDE_CODE_REMOTE`, session ids
-- **Codex:** `CODEX_THREAD_ID`, `CODEX_CI=1`, `CODEX_SANDBOX`, proposed `AGENT=codex`
+One explicit target is a direct message. Group coordination uses an explicit
+channel. Shared broadcast is opt-in, and routing lives in structured metadata
+rather than accidental mentions in message text.
 
-Run `scout whoami --json` to see which signal matched. Human terminal shells still
-default to `operator` unless `--as` or a host signal is present.
+## What ships in this package
 
-That keeps ordinary collaboration simple:
-
-```bash
-scout send --to vox "heads up: I’m on the runtime side"
-scout ask --to vox "can you confirm the broker fix?"
-scout ask --project ../talkie --harness claude "review the build spec"
-scout ask --harness codex "review this in a fresh Codex worker"
-```
-
-Known on-demand or offline agents are supposed to wake on first delivery. `scout send` and `scout ask` should be the default path; `scout up` is for explicit prewarming or for creating/registering a target the broker does not know yet.
-
-Prefer `scout send --to <agent> "message"` for tells. Legacy
-`scout send "@agent message"` remains for compatibility, but it makes the
-message body participate in route discovery. With `--to`, quoted handles inside
-the text stay text.
-
-### File-backed input
-
-Use a file when the primary prompt or message is too large or too structured to
-belong in shell argv.
-
-Nomenclature:
-
-- **Prompt file**: the primary work prompt for `scout ask`; pass it with `--prompt-file <path>`.
-- **Message file**: the message body for `scout send`, `scout broadcast`, or `scout speak`; pass it with `--message-file <path>`.
-- **Body file**: shared alias for either command family; `--body-file <path>` reads the same UTF-8 text into the broker `body` field.
-
-Examples:
-
-```bash
-scout ask --to hudson --prompt-file ./handoff.md
-scout @hudson --prompt-file ./review-request.md
-scout send --channel triage --message-file ./status-update.md
-scout broadcast --message-file ./maintenance-window.md
+```text
+Claude Code  ─┐
+Codex        ─┼── local Scout broker ── CLI · Monitor · Web
+Other agents ─┘   messages · work · routing
+                         │
+                         └── optional surfaces: Rust TUI · macOS · iOS
 ```
 
-The file is read locally before dispatch. The local broker still receives one
-structured request containing the target, body, sender, routing fields, and
-metadata, so the rest of the broker and mesh path can choose the right transport
-without depending on shell argument size.
-
-### One-to-one delegation
-
-When one project agent is delegating concrete work to one other agent, treat it
-as a private handoff:
-
-- keep it in a DM, not `channel.shared`
-- preserve the acting project agent as the sender
-- keep progress and completion in that same DM
+`@openscout/scout` installs:
 
-Today the best CLI surface for that handoff is `scout ask`, because it opens a
-DM by default when no explicit channel is pinned:
+- the `scout` command;
+- the bundled local broker and runtime;
+- the local web control surface opened by `scout server open`;
+- the bundled terminal console launched by `scout monitor`.
 
-```bash
-scout whoami
-scout ask --to hudson "Build the editable CodeViewer and report back with the integration-ready surface."
-```
-
-If the invoking shell or host path might not already be bound to the acting
-project agent, make it explicit:
-
-```bash
-scout ask --as premotion.master.mini --to hudson "Build the editable CodeViewer and report back with the integration-ready surface."
-```
+The Rust TUI launched by `scout tui` and the macOS and iOS apps are optional
+OpenScout surfaces; they are not installed by the npm package. They read and
+write the same coordination state when present.
 
-Use `channel.shared` only when the work is genuinely for a group, not for a
-single owner.
+## CLI at a glance
 
-### Label-scoped catch-up
+| Goal | Commands |
+| --- | --- |
+| Bootstrap and verify | `scout setup`, `scout doctor`, `scout config` |
+| Find your bearings | `scout whoami`, `scout who`, `scout runtimes`, `scout inbox` |
+| Coordinate | `scout send`, `scout ask`, `scout broadcast`, `scout watch` |
+| Follow activity | `scout latest`, `scout flight`, `scout label`, `scout tail` |
+| Operate local agents | `scout up`, `scout down`, `scout ps`, `scout restart` |
+| Open a bundled surface | `scout monitor`, `scout server open` |
+| Open an optional surface | `scout tui`, `scout menu` |
+| Connect tools | `scout mcp`, `scout pair`, `scout mesh` |
 
-Use labels to tie related asks together without creating a new workflow object:
+Run `scout --help` for the complete command list and
+`scout <command> --help` for current flags and examples.
 
-```bash
-scout ask --to hudson --label release:0.2.66 "Review the package bump."
-scout ask --to lattices --label release:0.2.66 "Check the install path."
-scout label feed release:0.2.66 --since 10m
-scout label watch release:0.2.66 --interval 2
-scout label brief release:0.2.66
-```
+## Works with the tools you already use
 
-Labels are plain metadata. They can mean a goal, release, milestone, incident,
-or any local convention. `scout label watch` streams a normalized firehose of
-matching Scout-owned activity; `scout label brief` gives a compact digest. Scout
-does not assign a lifecycle to the label.
+Scout has host integrations for Claude Code, Codex, Cursor, Pi, and Hermes, plus
+MCP, ACP, Slack, Telegram, voice, and webhook paths where those transports are
+configured. The broker provides the shared coordination model; each harness
+keeps its native runtime and workflow.
 
-### Addressing specific agents
+See the [integration guide](https://github.com/oscout/scout/blob/main/docs/integrations.md)
+for the current package and setup map.
 
-Agent identity has six dimensions: `definitionId`, workspace qualifier, `profile`, `harness`, `model`, `node`. Canonical form:
+## Advanced CLI reference
 
-```
-@<definitionId>[.<workspaceQualifier>][.profile:<profile>][.harness:<harness>][.model:<model>][.node:<node>]
-```
+<details>
+<summary><strong>Setup and local configuration</strong></summary>
 
-Short `@name` only resolves when exactly one matching agent is available from the current context. If multiple agents share a name (e.g. one Codex-backed, one Claude-backed), pin the dimension you care about with a typed qualifier:
+`scout setup` is the canonical onboarding command. It saves the local identity
+and workspace roots, discovers project-backed agents, installs the base service,
+and attempts to start the broker. A CLI-only setup can make its inputs explicit:
 
 ```bash
-scout send --to vox.harness:codex "message from hudson: please retry the build"
-scout ask --to vox.harness:claude "what did the reviewer flag?"
-scout ask --to arc.profile:reviewer "take another pass"
-scout ask --to vox.harness:codex.node:mini "run locally on mini"
-scout ask --to lattices#codex?5.5 "take task A"
-scout ask --to lattices#claude?sonnet "take task B"
+scout config set name "Ada"
+scout setup --source-root ~/dev --default-harness codex
+scout doctor
 ```
 
-Aliases: `runtime:` = `harness:`, `persona:` = `profile:`, `branch:` / `worktree:` = workspace qualifier. Shorthand `#codex` maps to `harness:codex`; `?sonnet` or `?5.5` maps to `model:<model>`. Dimensions combine in any order.
+Use `scout doctor --fix` for conservative native-daemon repairs when the
+installed daemon supports them. Use `scout init` only when you need to rewrite
+the low-level local host and port configuration.
 
-If direct send/ask still comes back unresolved, treat that as a routing problem, not a mere "target is offline" problem. The right follow-up is to disambiguate the target, inspect broker context with `scout who` / `scout latest`, or create/register the missing identity. Do not default to pushing the bring-up step back onto the operator for a known target.
+See the [install guide](https://github.com/oscout/scout/blob/main/install.md)
+and [quickstart](https://openscout.app/docs/quickstart) for prerequisites,
+filesystem footprint, and first-run success criteria.
 
-For current-project work where the harness is the only important choice, omit
-`--to` and `--project`; Scout infers the current project and creates or chooses
-a compatible worker:
+</details>
 
-```bash
-scout ask --harness codex "take a fresh pass on this repo"
-```
+<details>
+<summary><strong>Routing, profiles, sessions, and follow-up</strong></summary>
 
-That routes by the current project path and asks the broker to create or choose
-a compatible worker. For another repo, pass the repo path explicitly:
+Capability-first routing is the lowest-churn way to start fresh work. Give Scout
+the project and, when it matters, the harness; use a concrete target only when
+you mean one known agent or session.
 
 ```bash
-scout ask --project ../talkie --harness claude "review the modular build spec"
-```
+# Fresh worker for the current project
+scout ask --harness codex "Review the parser."
 
-Use an exact `--ref` or `session:<id>` only when the intent is to continue prior
-context. If the broker returns a friendly worker handle, treat it as the human
-mnemonic; promote/pin it only after the routed worker proves useful.
+# Fresh worker through a broker-owned runtime profile
+scout ask --profile kimi "Review the parser."
 
-Local product handoffs use the public Scout address:
+# One known target
+scout ask --to hudson "Check the release package."
 
-```bash
-scout send --to scout "message for the local Scout inbox"
+# Continue from a returned handle or exact session
+scout ask --ref <ref> "Take another pass."
+scout ask --to session:<id> "Continue this exact runtime context."
 ```
 
-Broker names and concrete node or agent ids are diagnostic details. Normal send
-output should say whether the message was sent, not which broker or internal
-session handled it. Reusing an existing session is an explicit continuity
-choice, not the default.
+One target means a direct message. Groups use explicit channels. `scout send`
+is for durable updates where no response is expected; `scout ask` creates owned
+work with a reply path. Runtime profiles such as Fable, Opus, Kimi, and Grok are
+broker-owned fresh-session routes, not guessed agent names.
 
-Session refs are separate route targets for continuing a concrete bound
-session. Use the bare `ref:<suffix>` form in receipts/history, and pass the
-suffix with `--ref`; do not encode refs into `@agent#harness?model` identity
-syntax.
-
-```bash
-scout ask --ref 7f3a9c21 "continue from that handoff"
-scout send --ref 7f3a9c21 "status for that same session"
-```
+See [runtime sessions](https://github.com/oscout/scout/blob/main/docs/runtime-sessions.md)
+and [Scout comms](https://github.com/oscout/scout/blob/main/docs/scout-comms.md)
+for identity dimensions, session continuation, aliases, delivery state, and
+advanced routing grammar.
 
-Diagnostic views may show both layers, for example:
+</details>
 
-```text
-sent to Scout via DM (ref:7f3a9c21)
-```
+<details>
+<summary><strong>Operator views, files, and local surfaces</strong></summary>
 
-## Current Commands
+The shortest orientation loop is:
 
 ```bash
-scout --help
-scout version
-scout doctor
-scout setup
-scout runtimes
-scout providers usage
 scout whoami
-scout send
-scout speak
-scout ask
-scout watch
+scout inbox --latest 10 --json
 scout who
 scout latest
-scout broadcast
-scout up
-scout down
-scout ps
-scout restart
-scout menu
-scout pair
-scout server start
-scout server open
-scout tui
-```
-
-### Provider Usage (`scout providers usage`)
-
-Read every quota window from the live `/providers` feed without opening the
-web UI. Status-only provider cards are intentionally omitted:
-
-```bash
 scout providers usage
-scout providers usage --json
-scout providers usage --cached
 ```
 
-The default command refreshes the shared service-budget pipeline and prints
-every available quota window with percent used and remaining, the local reset
-time, source, and observation freshness. `--cached` skips live provider probes
-when a recent server snapshot is available; a cold or expired cache still reads
-the providers normally.
-
-### Menu Bar App (`scout menu`)
-
-On macOS, `scout menu` is the quick launcher for the native menu bar app.
+Use file-backed input when a request is too large or structured for shell argv:
 
 ```bash
-scout menu
-scout menu status
-scout menu restart
-scout menu quit
+scout ask --to hudson --prompt-file ./review-request.md
+scout send --channel triage --message-file ./status-update.md
 ```
 
-For an installed product, `scout menu` opens the helper embedded in
-`/Applications/OpenScout.app`; use `scout install` to install or update it.
-Private OpenScout product checkouts may also provide a developer-only repo
-helper. That native source and its build/DMG commands are not part of this
-public repository.
-
-### Web UI (`scout server start`, `scout server open`)
+`scout monitor` opens the bundled terminal console. `scout server open` reuses
+or starts the bundled local web UI. `scout tui` launches the separately built
+Rust TUI when `scout-tui` is installed or available from a source checkout, and
+`scout menu` opens an installed macOS app when available.
 
-Runs the current OpenScout web UI used by the repo’s `bun run dev` entry. **Bun must be on your PATH.** Published CLI builds ship `dist/scout-control-plane-web.mjs` and `dist/client/` (Vite build); when `dist/client/index.html` is present, **`scout server start` defaults to static assets** unless you pass `--vite-url` to proxy a dev server.
+Run `scout --help` for the current command inventory and
+`scout <command> --help` for all flags.
 
-```bash
-scout whoami
-scout who
-scout latest
-scout server open
-scout server start
-scout server start --port 43120
-scout server open --path /agents/arc-codex-2.master.mini
-scout server start --public-origin http://scout.local
-scout server edge --local-name m1
-scout server start --vite-url http://127.0.0.1:43173   # SPA dev server
-scout server start --static --static-root /custom/client
-```
+</details>
 
-`scout server open` reuses an already-running matching Scout server on that port, or starts one in the background and opens the browser for you. Use `scout server` or `scout server help` for full flags.
+## Current posture
 
-The application server binds to `0.0.0.0` by default, treats `scout.local` as the local portal name, and derives the node URL as `<machine>.scout.local` unless the user configures a short alias such as `m1`. `scout server edge` publishes `scout.local` plus the node host with Bonjour/mDNS and runs Caddy against the active web port. The managed edge defaults to HTTP on port `80` for zero-cert local browsing. HTTPS remains an explicit opt-in via `--edge-scheme https` or `--edge-scheme both` plus `scout server trust`.
+> Scout is in active v0.x development for high-trust local developer pilots.
+> It is not yet an enterprise-ready, compliance-ready, or hardened multi-tenant
+> runtime. Optional mesh features provide reachability and coordination, not
+> global consensus or exactly-once delivery.
 
-`scout setup` verifies Caddy for this path. The setup command installs it with Homebrew on macOS when `caddy` is not already available, but Scout still runs Caddy directly with the generated `~/.scout/local-edge/Caddyfile` instead of registering a separate Homebrew service. The base LaunchAgent is labelled `app.openscout` and supervises the broker, local edge, web startup, and menu bar app; `scout doctor` prints the exact `launchctl bootout ...` command for the current mode.
+## Go deeper
 
-When the edge is up but the web app is down, Caddy serves a same-origin "Start Scout" page. The button calls Caddy's internal `/__openscout/web/start` path, which proxies to the always-on broker and starts the web server while keeping the user-facing URL at `scout.local` or `<name>.scout.local`.
+- [OpenScout project homepage](https://openscout.app)
+- [Quickstart](https://openscout.app/docs/quickstart)
+- [Documentation](https://openscout.app/docs)
+- [Architecture](https://openscout.app/docs/architecture)
+- [Current status and scope](https://openscout.app/docs/current-posture)
+- [Public source](https://github.com/oscout/scout)
+- [Issues](https://github.com/oscout/scout/issues)
 
-`packages/web` remains the internal web workspace. Published installs get that same server and client through `@openscout/scout`.
+## License
 
-For source development, `bun run dev:edge -- --local-name m1` starts the web dev stack and the local edge together. It generates Caddy config against the actual selected dev port, so worktree-specific ports and busy-port fallback still route through `scout.local`.
+Apache-2.0. See the [license](https://github.com/oscout/scout/blob/main/LICENSE)
+and [notice](https://github.com/oscout/scout/blob/main/packages/cli/NOTICE).

package/dist/build-manifest.json

@@ -1,9 +1,9 @@
 {
   "schemaVersion": 1,
   "packageName": "@openscout/scout",
-  "version": "0.2.92",
-  "commit": "3ecfa87be344339cf5479bc035b4c34f757d3a8c",
+  "version": "0.2.95",
+  "commit": "edcbc2933b914dee199c741ffa986d8c4127a318",
   "branch": "HEAD",
   "sourceDirty": false,
-  "builtAt": "2026-08-26T16:01:30.574Z"
+  "builtAt": "2026-08-31T02:14:41.975Z"
 }