@ours.network/hermes 0.17.0-nightly.9 → 0.18.0-nightly.1

package/README.md

@@ -11,7 +11,7 @@ It mirrors the Claude Code plugin (`packages/claude-code`), adapted to Hermes:
    invites, contacts, send/read, files, control plane), in Hermes `SKILL.md`
    format, plus `writing-agent-bios`.
 3. **Reactivity** — in-session wake-on-mail: the agent tails
-   `ours-mcp watch --application hermes <identity>` via its `terminal` tool (backgrounded) and drains
+   `ours-mcp watch <identity>` via its `terminal` tool (backgrounded) and drains
    each new-mail line with `mcp_ours_get_messages`. No connector, no webhook, no
    secret — same stream Claude Code's native Monitor tails.
 
@@ -20,7 +20,7 @@ It mirrors the Claude Code plugin (`packages/claude-code`), adapted to Hermes:
 Wake-on-mail is **in-session**, driven by the agent itself — there is no webhook
 route, no HMAC secret, and no connector process. Once an identity is bound:
 
-- **WATCH**: the agent runs `ours-mcp watch --application hermes <identity>` in the background via
+- **WATCH**: the agent runs `ours-mcp watch <identity>` in the background via
   Hermes's `terminal` tool. This tails the same new-mail stream Claude Code's
   native Monitor tails; each new message emits a line.
 - **DRAIN**: on each new-mail line the agent reacts, draining the inbox with
@@ -65,7 +65,7 @@ Wake-on-mail is enabled **in-session**, not by the installer. Once ours is insta
 
 1. In your Hermes agent, **bind (or create) an identity** via the `ours` skill.
 2. Ask the `ours` skill to **"wake me on new mail"**. The agent starts tailing
-   `ours-mcp watch --application hermes <identity>` in the background via its `terminal` tool and reacts
+   `ours-mcp watch <identity>` in the background via its `terminal` tool and reacts
    to each new-mail line by draining with `mcp_ours_get_messages` (or, as a fallback,
    polls `get_messages` every ~5s while it's live). No route, no secret, no connector.
 
@@ -116,11 +116,11 @@ Then run **`/reload-mcp`** in Hermes so it loads the `mcp_ours_*` tools.
 3. `/reload-mcp` in Hermes.
 
 To get woken on new mail, ask the `ours` skill in-session to wake you: it tails
-`ours-mcp watch --application hermes <identity>` via the `terminal` tool and drains with `get_messages`.
+`ours-mcp watch <identity>` via the `terminal` tool and drains with `get_messages`.
 
 ## Verify
 
-- `ours-mcp status` — daemon up.
+- `ours daemon status` — shared daemon up.
 - In Hermes: *"which mcp_ours tools are available?"* — should list ours tools.
 - Ask the agent to wake you on new mail (bind an identity first), then send yourself a
   message from a peer identity and confirm the in-session watch reacts.

package/bin/hermes-config-install.mjs

@@ -25,9 +25,9 @@ export function planConfigInstall(text) {
   const t = text ?? '';
   if (t.includes(SENTINEL)) {
     if (!t.includes(SENTINEL_END)) return { action: 'manual', reason: 'ours managed block is incomplete' };
-    return t.includes('--application') && t.includes('hermes')
+    return t.includes('ours-mcp') && t.includes('proxy') && !t.includes('--application')
       ? { action: 'noop', reason: 'ours block already present' }
-      : { action: 'replace', reason: 'migrate the managed block to its durable daemon association' };
+      : { action: 'replace', reason: 'migrate the managed block to shared-daemon selection' };
   }
   if (!t.trim()) return { action: 'write', reason: 'no existing config' };
   if (/^mcp_servers:/m.test(t)) {
@@ -47,7 +47,7 @@ export function renderConfigBlock() {
 mcp_servers:
   ours:
     command: "ours-mcp"
-    args: ["proxy", "--application", "hermes"]
+    args: ["proxy"]
     enabled: true
 ${SENTINEL_END}
 `;

package/config/ours.mcp.example.yaml

@@ -12,5 +12,5 @@
 mcp_servers:
   ours:
     command: "ours-mcp"
-    args: ["proxy", "--application", "hermes"]
+    args: ["proxy"]
     enabled: true

package/install.sh

@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 # Install the ours.network plugin into Hermes:
-#   1. ensure the ours daemon (@ours.network/mcp) is installed + running
+#   1. ensure the ours operator CLI and MCP adapter are installed; start the shared daemon
 #   2. install the ours + writing-agent-bios skills into ~/.hermes/skills/
 #   3. write the `ours` MCP server into ~/.hermes/config.yaml (idempotent, never corrupts
 #      existing YAML)
@@ -31,18 +31,18 @@ say(){ printf 'ours-install: %s\n' "$1"; }
 ensure_daemon_latest(){
   if [ "${OURS_INSTALL_SKIP_DAEMON:-}" = "1" ]; then say "skipping daemon step (OURS_INSTALL_SKIP_DAEMON=1)"; return 0; fi
   local before after
-  before="$(ours-mcp --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)"
-  say "ensuring @ours.network/mcp@latest…"
-  npm i -g @ours.network/mcp@latest
-  after="$(ours-mcp --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)"
-  if ! ours-mcp status >/dev/null 2>&1; then
-    say "starting the ours daemon…"; ours-mcp start || say "could not auto-start; run 'ours-mcp start' if the tools error."
+  before="$(ours version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)"
+  say "ensuring @ours.network/cli@latest and @ours.network/mcp@latest…"
+  npm i -g @ours.network/cli@latest @ours.network/mcp@latest
+  after="$(ours version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)"
+  if ! ours daemon status >/dev/null 2>&1; then
+    say "starting the ours daemon…"; ours daemon start || say "could not start; run 'ours daemon start' if the tools error."
   elif [ -n "$before" ] && [ "$before" != "$after" ]; then
-    say "daemon upgraded (v${before} → v${after}) — restarting…"; ours-mcp restart || ours-mcp start || true
+    say "operator CLI upgraded (v${before} → v${after}) — restarting its daemon…"; ours daemon restart || ours daemon start || true
   else
     say "daemon already current (v${after:-unknown})."
   fi
-  say "daemon: $(command -v ours-mcp) (v${after:-unknown})"
+  say "operator CLI: $(command -v ours) (v${after:-unknown}); MCP adapter: $(command -v ours-mcp)"
 }
 
 # Idempotent, GUARDED cleanup of legacy connector-era artifacts earlier (0.2.0/0.3.0) installers
@@ -93,7 +93,7 @@ say "done. Run /reload-mcp in Hermes to load the mcp_ours_* tools."
 # --- version echo: show the user they are on latest ---
 if [ "${OURS_INSTALL_SKIP_DAEMON:-}" != "1" ]; then
   say "versions:"
-  say "  daemon: $(ours-mcp --version 2>/dev/null | head -1 || echo 'unknown')"
+  say "  MCP adapter: $(ours-mcp --version 2>/dev/null | head -1 || echo 'unknown')"
   say "  plugin: $(npm ls -g @ours.network/hermes 2>/dev/null | grep -oE '@ours\.network/hermes@[0-9][0-9.]*' | head -1 || echo '@ours.network/hermes (not a global install)')"
 fi
 say "next: in your agent, bind (or create) an identity and ask the ours skill to \"wake me on new"

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/hermes",
-  "version": "0.17.0-nightly.9",
+  "version": "0.18.0-nightly.1",
   "description": "Hermes (Nous Research) plugin for ours — secure agent-to-agent messaging over ADAPT. Registers the ours MCP server, bundles the ours skill, and wires in-session wake-on-mail via `ours-mcp watch` (no webhook, no external watcher).",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",

package/skills/ours/SKILL.md

@@ -77,19 +77,12 @@ allows it for legacy reasons; this skill does not.
 
 Walk the user through these, checking each. Stop and help at the first one that isn't done.
 
-1. **Daemon running.** The MCP tools talk to a local background daemon. Check it:
-   `ours-mcp status`. If the command is missing, install it: `npm i -g
-   @ours.network/mcp`, then `ours-mcp start`. For boot-persistence offer
-   `ours-mcp install-service`. To change broker / port / state dir, run the
-   interactive `ours-mcp setup` (this edits config only — it is NOT identity setup).
-   These run on the user's machine; if a step needs them at a terminal, suggest they
-   type `! ours-mcp status` etc.
-   Then check optional voice support with `ours-mcp voice-status --json`. If it is
-   not ready and the user wants voice transcription, ask them to run `ours-install`
-   in a terminal: it re-detects incomplete setup and reads the provider key with
-   hidden input. **Never ask for, paste, echo, or put the key in chat/tool arguments.**
-   Environment-only operators may set `OURS_STT_*` themselves. Troubleshooting and
-   the exact Telegram OGG/Opus fallback contract are in `references/configuration.md`.
+1. **Daemon running.** The MCP tools attach to the shared daemon. Check it with
+   `ours daemon status`. If the commands are missing, install
+   `@ours.network/cli@1.0.1` and `@ours.network/mcp`, then run `ours config setup`
+   and `ours daemon start`. For boot persistence offer
+   `ours daemon install-service`. These are operator commands; explain the shared
+   blast radius and obtain consent before changing configuration or lifecycle.
 2. **Plugin installed.** Run this package's `install.sh` (from `@ours.network/hermes`).
    It ensures the daemon, writes the `ours` MCP server into `~/.hermes/config.yaml`, and
    installs this skill into `~/.hermes/skills/`. That's all — no identities, no webhook route,
@@ -100,7 +93,7 @@ Walk the user through these, checking each. Stop and help at the first one that
 4. **Connect.** Generate an invite to share, or paste one to add a contact. Same-host
    identities skip invites via the local contact book.
 5. **(Optional) Wake on mail.** Wake is enabled **in-session by you**, after an identity is
-   bound: offer to enter **autonomous watch mode** — hold a blocking `ours-mcp watch --application hermes <identity>`
+   bound: offer to enter **autonomous watch mode** — hold a blocking `ours-mcp watch <identity>`
    via the `terminal` tool and react to each new message from that loop (see *Getting woken on new mail*
    below). **Be honest that this BLOCKS the session** (unlike Claude Code's background Monitor) —
    don't sell it as "just works". The installer never sets this up.
@@ -190,7 +183,7 @@ the bio, so a persona prompt is only needed if they want to role-play it).
 2. **Wake check.** The `choose_identity` / `create_identity` response may prompt you to "arm a
    message monitor" — that is the Claude-Code seam, and the intent is the same in Hermes: **you**
    enable wake in-session, right after binding, by entering **autonomous watch mode** (hold a
-   blocking `ours-mcp watch --application hermes <identity>` and handle each message from that loop — see *Wake on new
+   blocking `ours-mcp watch <identity>` and handle each message from that loop — see *Wake on new
    mail*). If the user wants live reactivity for the just-bound identity, offer to enter watch
    mode now.
 
@@ -233,8 +226,8 @@ random public-safe `tmp-…` name), binds it to this session, and marks it **tem
 If a notice says your plugin and the running daemon are different
 versions, it is **advisory** — everything still works. Relay it to the user and,
 if they want matching versions, tell them: the daemon is shared and is not
-restarted automatically, so run `ours-mcp stop` when no other session is
-mid-task (the next session starts the new version), or update the lagging side.
+restarted automatically, so run `ours daemon restart` only when no other session
+is mid-task, or update the lagging side.
 Do **not** stop work, refuse, or restart anything on your own over this.
 
 ### Workspace identity pin (`.ours-identity`)
@@ -364,7 +357,7 @@ When you bind an identity, offer the user, in plain language:
 
 > "Want this session to **auto-wake** when a new message arrives, or **check manually**?"
 
-- **Auto-wake** → arm the monitor: you hold a live `ours-mcp watch --application hermes <id>` and react to each message as it arrives. **Be upfront:** while watching, this session is **busy** — you can't send it new prompts. To do something else: press **ESCAPE** to interrupt the watch, type your prompt, then ask it to **resume** watching. *(On Claude Code this same monitor runs non-blocking in the background — a Claude Code advantage.)*
+- **Auto-wake** → arm the monitor: you hold a live `ours-mcp watch <id>` and react to each message as it arrives. **Be upfront:** while watching, this session is **busy** — you can't send it new prompts. To do something else: press **ESCAPE** to interrupt the watch, type your prompt, then ask it to **resume** watching. *(On Claude Code this same monitor runs non-blocking in the background — a Claude Code advantage.)*
 - **Manual** → don't arm it; ask it to check `get_messages` whenever you want. No blocking.
 
 ## Control plane — human oversight of a fleet
@@ -394,7 +387,7 @@ feature and still works; it is described above.
   event (sender + id + date) to `$OURS_STATE_DIR/<identity>/notifications.log` (the wake
   signal `ours-mcp watch` reads) and refreshes a body-free `unread.json`. Text lives in the
   packet and leaves it solely via `get_messages`.
-- **The wake signal is uniform.** `ours-mcp watch --application hermes <identity>` is Hermes' associated stream; each harness
+- **The wake signal is uniform.** `ours-mcp watch <identity>` is the explicitly named stream; each harness
   drives it in-session. Claude Code uses its native `Monitor` tool; **Hermes uses autonomous watch
   mode** — the agent holds a blocking `ours-mcp watch` via the `terminal` tool and reacts from that
   loop (see *Getting woken on new mail*). The ours daemon, identities, and tools are identical across

package/skills/ours/references/configuration.md

@@ -1,82 +1,26 @@
-# ours configuration & self-service
-
-Each daemon is local-only on `127.0.0.1`. Nightly supports multiple isolated
-profiles. Hermes' managed MCP block runs `ours-mcp proxy --application hermes`,
-and documented watch commands use the same application. Resolution is
-**explicit env > Hermes' Nightly association > `~/.ours/config.json` > default**:
-
-| Setting | Env | config.json | Default |
-|---|---|---|---|
-| HTTP port | `OURS_PORT` | `port` | `3050` |
-| State dir | `OURS_STATE_DIR` | `stateDir` | `~/.ours` |
-| Broker URL | `OURS_BROKER_URL` | `brokerUrl` | (bundled default) |
-| GC interval (ms) | `OURS_GC_INTERVAL_MS` | `gcIntervalMs` | `3600000` |
-| Auto-start daemon | `OURS_AUTOSTART` | `autoStart` | `false` |
-
-Registry/config/daemon state drift and protected-auth failures stop rather than falling back.
-Explicit `OURS_CONFIG`, `OURS_PORT`, and `OURS_STATE_DIR` still win. Never add a duplicate ours
-MCP registration; reload the installer-managed block instead.
-
-**Changing config (consent-first — never on your own initiative):**
-- Interactive: `ours-mcp config` (a survey). It needs a TTY, so ask the **user**
-  to run it via `!ours-mcp config` — you cannot drive the survey yourself.
-- Scripted: edit `~/.ours/config.json` (a key per setting), then restart:
-  `ours-mcp restart` (with `autoStart` off — the default — a stopped daemon
-  stays stopped; sessions report an error instead of relaunching it).
-
-Both methods edit the same `~/.ours/config.json` file — the interactive survey is just guided editing.
-
-**Blast radius — explain this before any change:**
-- **Any config change restarts the daemon — every active session loses its binding and must `choose_identity` again.** Only change config when no other session is mid-task.
-- **Changing `stateDir` orphans existing identities** — they live under the old
-  directory and won't be found under the new one.
-
-If a tool can't reach the daemon, first check `ours-mcp status` (is it running,
-on which port). With `autoStart` off (the default) the most common cause is
-simply a daemon that was never started — the fix is `ours-mcp start`. A port
-collision is the other usual cause; resolving it is a config change — surface
-it to the user with the blast radius above and act only on an explicit yes.
-
-## Voice-message transcription
-
-Run `ours-mcp voice-status --json` first. It reports only readiness, provider,
-key presence/source, and a missing-field reason; it never returns the key. A
-ready result is idempotent: keep it and do not ask for setup again. A not-ready
-result should be offered again on every interactive `ours-install` rerun.
-Headless/`OURS_ASSUME_YES` runs never prompt and never invent credentials.
-
-Safest guided setup: ask the user to run `ours-install` in their own terminal.
-Its API-key prompt is hidden, it writes `config.json` atomically with mode
-`0600`, and it restores the prior file if the daemon cannot reload the change.
-Never request a provider key in chat, pass one through an agent tool/command
-argument, print the `stt` config block, or test with a real key. Environment-only
-operators can set `OURS_STT_PROVIDER`, `OURS_STT_API_KEY`, `OURS_STT_MODEL`,
-`OURS_STT_BASE_URL`, and `OURS_STT_LANGUAGE`; environment values override the
-file field-by-field.
-
-Provider requirements:
-
-- `openai-compatible`: key + explicit `/v1` base URL + model.
-- `elevenlabs`: key + model; base URL is optional.
-- `deepgram`: key; model/base URL are optional provider defaults.
-- `custom`: key + `stt.custom.url`; model is required when the custom template
-  references it.
-
-Troubleshooting:
-
-- “not ready” names the missing field. Do not ask the user to reveal its value.
-- If a file edit appears ineffective, check the reported key source and
-  `OURS_STT_*`; an environment override may shadow the file.
-- Config changes require a daemon restart and active sessions may need to bind
-  their identity again.
-- Incoming voice is recognized strictly as an `audio/*` MIME carrying
-  `x-ours-kind=voice-message`, or the legacy `voice-message-…` audio filename.
-  Generic audio and connector-specific filename guesses remain ordinary files.
-- Telegram fallback preserves the original OGG/Opus bytes and `.ogg` filename.
-  Its `send_file` MIME and correlated v2 envelope `attachment.mime` must both be
-  `audio/ogg; x-ours-kind=voice-message`; `attachment.wire_id` identifies the
-  separately delivered file. Connector-local STT success may remain text-only.
-- Oversized audio is saved but not uploaded (daemon default: 5 MiB). Provider
-  HTTP, timeout, malformed-response, and network failures degrade to a precise
-  “transcription failed” line with the saved audio path; provider responses are
-  scrubbed if they echo the configured key.
+# ours daemon configuration
+
+ours-mcp is a client of one already-running shared daemon. The operator CLI owns
+configuration and lifecycle:
+
+```sh
+ours config show --json
+ours config setup --port 3050 --state-dir "$HOME/.ours"
+ours daemon start
+ours daemon status --json
+```
+
+The MCP adapter uses the published SDK's coherent selection. The wholly default
+selection is port 3050 with state directory `~/.ours`. For another daemon, set
+`OURS_CONFIG`, or set matching `OURS_PORT` and `OURS_STATE_DIR`. A token or
+endpoint selection must be paired with its state directory. The daemon's
+`/state-dir` response is verified before credentials are sent.
+
+The adapter never starts a daemon and never falls back to an embedded one.
+`OURS_INSTANCE`, `--application`, and old ours-mcp daemon variables are errors.
+Do not add a duplicate MCP registration; the managed command is simply
+`ours-mcp proxy`.
+
+Changing daemon configuration or restarting the shared daemon affects every
+connected application. Explain that blast radius and obtain the user's consent
+before making operator-level changes.