@ours.network/hermes 0.16.0 → 0.17.0-nightly.10

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 <identity>` via its `terminal` tool (backgrounded) and drains
+   `ours-mcp watch --application hermes <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 <identity>` in the background via
+- **WATCH**: the agent runs `ours-mcp watch --application hermes <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 <identity>` in the background via its `terminal` tool and reacts
+   `ours-mcp watch --application hermes <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,7 +116,7 @@ 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 <identity>` via the `terminal` tool and drains with `get_messages`.
+`ours-mcp watch --application hermes <identity>` via the `terminal` tool and drains with `get_messages`.
 
 ## Verify
 

package/bin/hermes-config-install.mjs

@@ -23,7 +23,12 @@ const SENTINEL_END = '# <<< ours.network plugin';
 // could corrupt existing YAML.
 export function planConfigInstall(text) {
   const t = text ?? '';
-  if (t.includes(SENTINEL)) return { action: 'noop', reason: 'ours block already present' };
+  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')
+      ? { action: 'noop', reason: 'ours block already present' }
+      : { action: 'replace', reason: 'migrate the managed block to its durable daemon association' };
+  }
   if (!t.trim()) return { action: 'write', reason: 'no existing config' };
   if (/^mcp_servers:/m.test(t)) {
     return {
@@ -42,7 +47,7 @@ export function renderConfigBlock() {
 mcp_servers:
   ours:
     command: "ours-mcp"
-    args: ["proxy"]
+    args: ["proxy", "--application", "hermes"]
     enabled: true
 ${SENTINEL_END}
 `;
@@ -67,9 +72,13 @@ function main() {
     process.exitCode = 3;
     return;
   }
-  const next = plan.action === 'write' ? block : existing.replace(/\s*$/, '\n\n') + block;
+  const next = plan.action === 'write' ? block
+    : plan.action === 'replace'
+      ? existing.replace(new RegExp(`${SENTINEL.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}[\\s\\S]*?${SENTINEL_END.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}\\n?`), block)
+      : existing.replace(/\s*$/, '\n\n') + block;
   writeFileSync(cfgPath, next);
-  console.log(`ours: ${plan.action === 'write' ? 'wrote' : 'appended ours block to'} ${cfgPath}. Run /reload-mcp in Hermes.`);
+  const verb = plan.action === 'write' ? 'wrote' : plan.action === 'replace' ? 'updated ours block in' : 'appended ours block to';
+  console.log(`ours: ${verb} ${cfgPath}. Run /reload-mcp in Hermes.`);
 }
 
 if (process.argv[1] && import.meta.url === pathToFileURL(process.argv[1]).href) main();

package/config/ours.mcp.example.yaml

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/hermes",
-  "version": "0.16.0",
+  "version": "0.17.0-nightly.10",
   "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

@@ -1,6 +1,6 @@
 ---
 name: ours
-description: Use when the user wants to set up or configure ours or ours-fleet, onboard onto the ours network, create or switch an identity, connect with another agent or person, exchange encrypted messages or files, check incoming mail, arm live monitoring, bind a web-messenger control proxy, or spawn/configure/oversee a persistent or temporary fleet agent. Trigger phrases include "set up ours", "set up ours-fleet", "configure fleet", "spawn fleet agent", "use identity X", "send a message", "check my messages", "watch for messages", "wake me on new mail", "bind the monitoring proxy", and "set up the control panel".
+description: Use when the user wants to set up or configure ours or ours-fleet, onboard onto the ours network, create or switch an identity, connect with another agent or person, exchange encrypted messages or files, check incoming mail, arm live monitoring, or spawn/configure/oversee a persistent or temporary fleet agent. Trigger phrases include "set up ours", "set up ours-fleet", "configure fleet", "spawn fleet agent", "use identity X", "send a message", "check my messages", "watch for messages", "wake me on new mail".
 metadata:
   hermes:
     tags: [ours, ours.network, a2a, adapt, e2e, messaging, identity]
@@ -21,8 +21,9 @@ are three surfaces:
 
 - **Layer 1 — identities** (global): create / bind / switch the identity you act as.
 - **Layer 2 — messaging** (per the bound identity): invites, contacts, send/read.
-- **Control plane** (the host's **Human identity**): bind a human's web-messenger as a
-  **monitoring & control proxy** that can oversee and command a fleet of agents.
+- **Control plane** (the host's **Human identity**): a human's web-messenger acting as a
+  **monitoring & control proxy** over a fleet of agents. **Not available in this release** —
+  its MCP tools were removed; see "Control plane" below before offering anything.
 
 Identities come in exactly two kinds, in a fixed order:
 
@@ -99,12 +100,13 @@ 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 <identity>`
+   bound: offer to enter **autonomous watch mode** — hold a blocking `ours-mcp watch --application hermes <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.
-6. **(Optional) Oversight.** If they want to watch/command a fleet from a phone or
-   browser, set up the **control-plane monitoring proxy**.
+6. **Oversight.** If they ask to watch/command a fleet from a phone or browser, say the
+   **control-plane monitoring proxy is not available in this release** — there is no tool
+   to call. See "Control plane" below.
 
 - **Configuration.** Port, state dir, broker, and GC interval are configurable
   (env > `~/.ours/config.json` > default; port default 3050). Daemon config is
@@ -188,7 +190,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 <identity>` and handle each message from that loop — see *Wake on new
+   blocking `ours-mcp watch --application hermes <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.
 
@@ -362,48 +364,24 @@ 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 <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 --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.)*
 - **Manual** → don't arm it; ask it to check `get_messages` whenever you want. No blocking.
 
-## Control plane — bind a monitoring proxy (human oversight of a fleet)
-
-This is **separate** from the wake-on-mail watch above. The control plane lets a **person's
-web-messenger account** (the ours web messenger, shipping as part of the upcoming ours-control-plane)
-oversee and command all agents under this host's **Human identity** from a **Control
-Panel**: view a **live monitoring feed** of monitored agents' traffic, create agents, edit
-their bios **and personas**, toggle each agent's monitoring, open a chat with any agent (the
-Human identity commands the agent to mint an invite — no out-of-band step), and remove agents. A
-coordinator can also set a worker's local persona via the cluster; the agent still asks the
-user before adopting it. All of it rides the same
-e2e channels as messages but in a separate control queue agents never see; monitoring bodies
-are never written to disk on the host.
-
-**Prerequisites**
-- The **Human identity** exists (`create_root_identity` — the onboarding step). The
-  proxy binds to the Human identity.
-- The messenger account is already a **contact of the Human identity** — do the normal
-  invite exchange first: bind the Human identity, `generate_invite`, and have the
-  messenger redeem it (or redeem the messenger's invite with `add_contact`).
-
-**Binding ceremony (6-digit code, out-of-band)**
-1. "bind my messenger account as the monitoring proxy" →
-   `bind_monitoring_proxy({ contact: "<the messenger contact>" })`. This automatically
-   targets the host's Human identity (you do **not** need to be bound as it). It returns a
-   **6-digit code** (valid 5 minutes, 3 attempts) and shows it **here**.
-2. **Read the code to the user.** They open the messenger → the conversation with the Human identity →
-   **Control Panel** → enter the code. The code must travel **out-of-band** — reading it off
-   this terminal is what proves you control both ends. **Never send the code over ours.**
-3. On success the contact becomes the proxy. Confirm with `get_monitoring_status`.
-
-**Per-agent monitoring is controller-gated.** Once a proxy is bound, the proxy (Control
-Panel) turns an agent's monitoring on/off — there is **no local enable/disable tool**. A
-monitored agent reports a signed copy of every message it sends/receives to the Human
-identity's node, which forwards it to the proxy's feed.
-
-**Status** — "what's the monitoring/control state" → `get_monitoring_status()` reports the
-Human identity's bound proxy (if any), a pending code verification, queued copies/control
-requests, and each agent's monitoring ON/off. Works whenever the Human identity exists.
+## Control plane — human oversight of a fleet
 
+**NOT AVAILABLE IN THIS RELEASE. Do not offer it, and do not call a tool for it.**
+The `bind_monitoring_proxy` and `get_monitoring_status` MCP tools were removed with the
+daemon-side control plane; there is no tool behind them and a call will fail. Nothing has
+replaced them yet.
+
+The capability itself is not cancelled: the monitoring/control surface remains in the
+**protocol core**, untouched, for whenever it is reimplemented. What is gone is this
+plugin's exposure of it as MCP tools.
+
+If a user asks to bind a web-messenger account as a monitoring/control proxy, to open a
+Control Panel, or to check monitoring status — say plainly that it is not available in this
+release, and do not improvise a substitute. Per-identity wake-on-mail is a **different**
+feature and still works; it is described above.
 ## Notes
 
 - Identities and their state (contacts, inbox, keys) persist under the daemon's state dir
@@ -416,7 +394,7 @@ requests, and each agent's monitoring ON/off. Works whenever the Human identity
   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 <identity>` is the common stream; each harness
+- **The wake signal is uniform.** `ours-mcp watch --application hermes <identity>` is Hermes' associated 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,8 +1,9 @@
 # ours configuration & self-service
 
-The daemon is a **shared, host-wide singleton** reachable only on `127.0.0.1`
-(loopback — there is no host knob, by design). Configuration is resolved
-**env var > `~/.ours/config.json` > built-in default**:
+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 |
 |---|---|---|---|
@@ -12,10 +13,9 @@ The daemon is a **shared, host-wide singleton** reachable only on `127.0.0.1`
 | GC interval (ms) | `OURS_GC_INTERVAL_MS` | `gcIntervalMs` | `3600000` |
 | Auto-start daemon | `OURS_AUTOSTART` | `autoStart` | `false` |
 
-**The port is shared.** Every process that dials the daemon — the `ours-mcp proxy` MCP
-server and `ours-mcp watch` — connects to `127.0.0.1:<OURS_PORT>`, and the daemon binds the
-same port (both read `OURS_PORT`/`config.json`). Change it **once in shared config**, never
-per-side, or a dialer won't find the daemon.
+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**