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

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,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 --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
 

package/bin/hermes-config-install.mjs

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/hermes",
-  "version": "0.17.0-nightly.9",
+  "version": "0.17.0",
   "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, 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".
+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".
 metadata:
   hermes:
     tags: [ours, ours.network, a2a, adapt, e2e, messaging, identity]
@@ -21,9 +21,8 @@ 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**): 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.
+- **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.
 
 Identities come in exactly two kinds, in a fixed order:
 
@@ -100,13 +99,12 @@ 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.
-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.
+6. **(Optional) Oversight.** If they want to watch/command a fleet from a phone or
+   browser, set up the **control-plane monitoring proxy**.
 
 - **Configuration.** Port, state dir, broker, and GC interval are configurable
   (env > `~/.ours/config.json` > default; port default 3050). Daemon config is
@@ -190,7 +188,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.
 
@@ -364,24 +362,48 @@ 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
+## 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.
 
-**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
@@ -394,7 +416,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 common 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,9 +1,8 @@
 # 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**:
+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**:
 
 | Setting | Env | config.json | Default |
 |---|---|---|---|
@@ -13,9 +12,10 @@ and documented watch commands use the same application. Resolution is
 | 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.
+**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.
 
 **Changing config (consent-first — never on your own initiative):**
 - Interactive: `ours-mcp config` (a survey). It needs a TTY, so ask the **user**