@yefengr/remote-pi 0.7.4 → 0.7.6

package/docs/daemon.md

@@ -1,64 +1,31 @@
-# Daemon mode — troubleshooting
+# Daemon mode — operations and troubleshooting
 
-Companion to the README's [Daemon mode](../README.md#daemon-mode) section.
-Each scenario starts with the symptom you'd actually observe, followed by
-likely causes and how to fix.
+Daemon mode is an explicit v2-registry opt-in for keeping selected Pi endpoints alive under one user-level supervisor. It is not part of ordinary interactive pairing.
 
----
-
-## 1. `remote-pi install` fails
+Each registration has an opaque daemon/endpoint identifier, canonical cwd, display name, creation time, and persisted desired lifecycle:
 
-### "supervisor script not found"
-
-```
-[remote-pi] install failed: Error: supervisor script not found at
-/Users/x/dist/bin/supervisord.js. Run `pnpm build` (dev) or
-`npm install -g @yefengr/remote-pi` (prod) first.
+```text
+running | stopped
 ```
 
-You're running `remote-pi install` from a dev clone where `dist/` doesn't
-exist yet, or from a partial install.
-
-```bash
-# Dev clone:
-cd pi-extension && pnpm build
-
-# Production install:
-npm install -g @yefengr/remote-pi      # or pnpm install -g @yefengr/remote-pi
-which pi-supervisord          # confirm bin is on PATH
-remote-pi install
-```
+A daemon process is a runtime of that stable endpoint. Restarting the daemon creates a new runtime identity without changing the endpoint card selected by the PWA.
 
-### "launchctl: bootstrap … already running"
+---
 
-A previous install left a stale entry. The fix is built into `install` —
-re-run it and the supervisor unloads the old entry before bootstrapping
-the new one. If it still fails:
+## Install the supervisor once per computer
 
 ```bash
-launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/dev.remotepi.supervisord.plist
-launchctl unload ~/Library/LaunchAgents/dev.remotepi.supervisord.plist 2>/dev/null
-rm ~/Library/LaunchAgents/dev.remotepi.supervisord.plist
+npm install -g @yefengr/remote-pi
 remote-pi install
 ```
 
-### "systemctl --user … No such file or directory"
-
-Linux without a logged-in graphical session (headless server). On most
-distros `systemctl --user` requires `loginctl enable-linger <user>` so
-the unit survives logout:
-
-```bash
-loginctl enable-linger $USER
-systemctl --user daemon-reload
-remote-pi install
-```
+`install` configures `launchd` on macOS or `systemd --user` on Linux, links `remote-pi` and `pi-supervisord`, and starts the service. The service reads the v2 registry from `~/.pi/remote/daemons.json`.
 
----
+The supervisor launches Pi in RPC mode without passing an extra extension argument. Pi settings are the only source for extension loading, model selection, providers, and tool permissions. Correct Pi settings before registering an unattended daemon.
 
-## 2. Supervisor doesn't start at login
+### Service does not start at login
 
-### Check the service status
+Check the service first:
 
 ```bash
 # Linux
@@ -70,220 +37,137 @@ launchctl list | grep remotepi
 tail -100 ~/.pi/remote/supervisord.log
 ```
 
-### Common failures
-
-- **`pi: command not found`** in the log — Pi's binary isn't on the
-  PATH that the unit inherited. `remote-pi install` captures
-  `process.env.PATH` at install time; if you installed Pi *after*
-  running install, re-run `remote-pi install` to refresh.
-- **`Cannot find module …`** — the path baked into the unit doesn't
-  match where `dist/bin/supervisord.js` actually lives. Happens if you
-  uninstalled then reinstalled the package to a different location.
-  Fix: `remote-pi uninstall && remote-pi install`.
-- **Permission denied on UDS** — `~/.pi/remote/` exists with wrong
-  perms (rare; only happens if you ran `pi` as `sudo` once). Delete
-  the dir and let it re-create: `rm -rf ~/.pi/remote && remote-pi install`.
-
-### Run the supervisor in the foreground for debugging
-
-Bypass systemd/launchd and run it directly so you can see startup
-errors live:
+Common causes:
 
-```bash
-pi-supervisord
-# or: node /path/to/remote-pi/dist/bin/supervisord.js
-```
+- **`pi: command not found`** — reinstall the service after fixing the PATH seen by the user service.
+- **Missing compiled package files** — build a development clone or reinstall the global package, then run `remote-pi install` again.
+- **Linux user service unavailable after logout** — enable lingering where required by the distribution: `loginctl enable-linger $USER`.
 
-Ctrl-C to stop. If that works but the service doesn't, the problem is
-in the unit/plist environment (PATH, HOME) — re-run `remote-pi install`.
+For foreground diagnosis, run `pi-supervisord` in a terminal and stop it with Ctrl-C when done.
 
 ---
 
-## 3. A specific daemon stays `crashed`
-
-`remote-pi daemon status` shows one row with `state=crashed` and a
-restart count near 4 (the supervisor gives up after exponential
-backoff: 1s, 5s, 30s, 5min).
-
-### Step 1 — read the daemon's stderr
+## Register and control daemons
 
-The supervisor forwards each daemon's stderr with a `[<cwd>]` prefix:
+Registering is explicit and starts with desired state `running`:
 
 ```bash
-# Linux
-journalctl --user -u remote-pi-supervisord -f | grep '\[/Users/x/Movies\]'
-
-# macOS
-tail -f ~/.pi/remote/supervisord.log | grep '\[/Users/x/Movies\]'
+remote-pi create ~/Projects/backend
+remote-pi daemons
+remote-pi daemon status
 ```
 
-### Step 2 — run that daemon manually
-
-Reproduce the failure with full visibility:
+The supervisor starts the registration immediately when it is online. At a future supervisor start, it restores only registrations whose desired state remains `running`. A stopped registration remains stopped.
 
 ```bash
-cd /Users/x/Movies
-REMOTE_PI_DAEMON=1 pi --mode rpc -e $(npm root -g)/remote-pi/dist/index.js
+remote-pi daemon start <daemon-id>
+remote-pi daemon stop <daemon-id>
+remote-pi daemon restart <daemon-id>
+remote-pi daemon start                 # every registration
+remote-pi daemon stop                  # every registration
+remote-pi daemon restart               # every registration
+remote-pi remove <daemon-id>
+remote-pi remove-cwd ~/Projects/backend
 ```
 
-Common reasons a daemon won't start:
-
-- **Local config missing.** `cd` into the daemon's folder and check
-  `.pi/remote-pi/config.json` exists with `auto_start_relay: true`.
-  Recreate via `remote-pi create <cwd>` (it provisions a default config
-  when missing).
-- **Pi extension config drift.** Pi's own settings (model, API keys)
-  reset → daemon fails to authenticate to the provider. Run
-  `cd <cwd> && pi` interactively to fix.
-- **Port/UDS collision.** Another Pi process is already running in
-  that cwd. The cwd-lock should reject the second one, but stale UDS
-  sockets sometimes linger; check `lsof ~/.pi/remote/locks/<roomId>.sock`.
+`remove-cwd <cwd>` is idempotent: it succeeds whether or not that cwd currently has a registration. It is safe for external worktree cleanup integrations.
 
-### Step 3 — force a re-spawn
-
-After fixing the underlying problem, kick the supervisor:
-
-```bash
-remote-pi daemon restart      # bounces every daemon
-```
+The browser PWA may show multiple endpoints on the same computer. Pairing is independent for every computer, and revoking a pairing on one computer does not alter another computer's local pairing records.
 
 ---
 
-## 4. `daemon send` says "daemon not running"
+## Read status as independent dimensions
 
-The supervisor has the registry entry but no live child for that id.
-Most common cause: the daemon never started OR it crashed past the
-retry budget.
+Do not infer health from a single summary label. `remote-pi daemon status` reports:
 
-```bash
-remote-pi daemon status       # is state running?
-remote-pi daemon start        # spawn any that aren't running
-# Then retry send.
-```
+| Field | Interpretation |
+|---|---|
+| registration | The persisted registration is present; a missing cwd is marked missing |
+| desired | Persistent operator intent: `running` or `stopped` |
+| process | OS child lifecycle: absent, spawning, running, or exited |
+| runtime | RPC readiness: pending, ready, or failed |
+| relay | Disconnected, connecting, connected, or reconnecting |
+| health | Derived stopped, starting, healthy, degraded, failed, or blocked state |
 
-If `daemon start` shows `started=0, already_running=N`, the supervisor
-isn't actually spawning. Possible reasons:
-- Registry empty: `remote-pi daemons` to verify.
-- Child crashes faster than the status check: `daemon status` immediately
-  after start may still show `running` for a few seconds before the
-  exit event marks it crashed. Re-check 2-3 seconds later.
+A runtime can be ready while the Relay reconnects. That is a **degraded** state, not a reason to restart Pi. The runtime remains available locally and reconnects through its normal transport path.
 
----
+A deterministic bad configuration, unsupported startup condition, or exhausted retry budget becomes **blocked**. Read `last_error_code`, `last_error_message`, and `startup_stage`, correct the cause, then explicitly start or restart the daemon. The supervisor does not loop forever on a blocked failure.
 
-## 5. Browser PWA doesn't connect to a daemon
+---
 
-The daemon is up but the browser PWA doesn't see it.
+## Missing and moved working directories
 
-### Confirm the daemon is paired
+The registry records the canonical cwd that existed at registration time. A daemon send to a missing cwd is denied immediately. The supervisor then reconciles stale registrations after bounded confirmation: it stops any child, removes the registration, and prevents later restoration.
 
-`pair_request` must have happened **before** the folder became a daemon
-(daemons don't show QRs themselves):
+If a project moved, register its new canonical cwd intentionally rather than editing the registry by hand:
 
 ```bash
-cd <daemon-cwd>
-pi
-> /remote-pi devices         # confirm the device is listed
-> /remote-pi stop            # stop interactive session — daemon takes over
-remote-pi daemon restart
+remote-pi create /new/path/to/project
+remote-pi remove-cwd /old/path/to/project
 ```
 
-### Confirm the relay URL matches
+A corrupted or pre-v2 registry is an operator-visible error. It is never treated as an empty registry, because doing so could overwrite registrations. Replace the registry only after inspecting and backing up its contents.
 
-The daemon uses the cwd's local config (`<cwd>/.pi/remote-pi/config.json`
-agent_name + `~/.pi/remote/config.json` relay). Verify with:
+---
 
-```bash
-cd <daemon-cwd>
-pi
-> /remote-pi status
-```
+## Scheduled prompts
+
+Cron schedules prompt delivery; it never starts a daemon. A fire is accepted only when all of these are true:
 
-The relay line should match what the browser PWA is connecting to. If
-not, update the relay URL and bounce the daemon:
+1. The registration exists and its cwd is present.
+2. Desired lifecycle is `running`.
+3. The RPC runtime is ready.
+4. The daemon is not busy, unless the job uses `--no-skip-busy`.
 
 ```bash
-remote-pi set-relay https://relay.example.tld
-remote-pi daemon restart
+remote-pi cron add <daemon-id> "0 9 * * 1-5" "Summarize the new PRs" --tz America/Sao_Paulo
+remote-pi cron list
+remote-pi cron run <job-id>
+remote-pi cron disable <job-id>
+remote-pi cron log --tail 20
 ```
 
+Schedules closer than 60 seconds are rejected. `--tz Area/City` uses a DST-aware timezone. `--catchup` allows one missed fire after supervisor startup. The cron audit at `~/.pi/remote/cron.jsonl` records every acceptance and skip, including desired-stopped, starting, retrying, failed, blocked, missing, disabled, busy, and rejected outcomes.
+
 ---
 
-## 6. Registry corrupted / partial
+## Pairing and Relay diagnosis
 
-Symptom: `remote-pi daemons` errors out or shows nothing despite
-having created entries.
+Generate a fresh QR from an interactive endpoint:
 
-```bash
-cat ~/.pi/remote/daemons.json    # inspect
+```text
+/remote-pi pair
+/remote-pi devices
+/remote-pi revoke <shortid>
 ```
 
-The file should be:
+The QR identifies the current endpoint and runtime. In the PWA, check that the expected device and endpoint card are selected. If a daemon was restarted, select its current runtime state and allow the endpoint to reconnect; a Relay reconnect should report degraded health rather than causing a Pi restart.
 
-```json
-{
-  "daemons": [
-    { "cwd": "/Users/x/Movies" },
-    { "cwd": "/Users/x/Projects/backend" }
-  ]
-}
-```
-
-Fix manually if needed (it's a JSON list of `{cwd}` entries), or wipe
-and re-create:
+Confirm both sides use the same Relay URL:
 
-```bash
-rm ~/.pi/remote/daemons.json
-remote-pi create ~/Movies --name "Video Editor"
-remote-pi create ~/Projects/backend --name "Backend"
-remote-pi daemon restart
+```text
+/remote-pi config
+/remote-pi set-relay https://relay.example.com
 ```
 
+After correcting a Relay URL, restart only the affected endpoint if it does not reconnect on its own.
+
 ---
 
-## 7. Uninstall cleanly + re-install from scratch
+## Logs and reset
 
-When you suspect everything is misconfigured:
+| Platform | Command |
+|---|---|
+| Linux | `journalctl --user -u remote-pi-supervisord -f` |
+| macOS | `tail -f ~/.pi/remote/supervisord.log` |
+
+For a complete service reset:
 
 ```bash
-remote-pi uninstall              # removes service, keeps registry
-rm -rf ~/.pi/remote               # nukes registry + paired devices + keys
-npm uninstall -g remote-pi
+remote-pi uninstall
+npm uninstall -g @yefengr/remote-pi
 npm install -g @yefengr/remote-pi
 remote-pi install
-# Then re-pair + re-create daemons from scratch.
-```
-
-This is the "nuke everything" path. After this, the only state left is
-each cwd's `<cwd>/.pi/remote-pi/config.json` — which you can either
-keep (re-create restores the daemon) or delete (full reset).
-
----
-
-## 8. Diagnostic commands cheat-sheet
-
-```bash
-# Where is the supervisor's UDS?
-ls -la ~/.pi/remote/supervisor.sock
-
-# Talk to the supervisor manually (raw JSONL):
-echo '{"op":"list"}' | nc -U ~/.pi/remote/supervisor.sock
-
-# Where are the daemon configs?
-find ~/Projects -name "config.json" -path "*/.pi/remote-pi/*" 2>/dev/null
-
-# Where are the cwd locks?
-ls ~/.pi/remote/locks/
-
-# Where are the paired devices?
-cat ~/.pi/remote/peers.json
-
-# What Pi binary is the supervisor about to spawn?
-remote-pi install --dry-run      # (not implemented; check ~/Library/LaunchAgents or systemd unit manually)
-
-# Quick liveness check
-remote-pi daemon status
 ```
 
-If after walking the list you're still stuck, file an issue with the
-output of `remote-pi daemon status`, the recent supervisor log, and
-the contents of `~/.pi/remote/daemons.json`.
+Uninstalling the service preserves registrations. Remove individual registrations with `remote-pi remove` or `remote-pi remove-cwd`; do not delete registry state unless a deliberate full reset is required.

package/package.json

@@ -1,10 +1,10 @@
 {
   "name": "@yefengr/remote-pi",
-  "version": "0.7.4",
+  "version": "0.7.6",
   "publishConfig": {
     "access": "public"
   },
-  "description": "Browser PWA remote control and local agent mesh for the Pi coding agent. Pair a browser profile via QR over a relay, watch tool calls in real time, run multi-Pi sessions over a local Unix Domain Socket broker, and let agents talk to each other through structured request/reply.",
+  "description": "Browser PWA remote control for Pi coding agent endpoints over a Relay.",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",
@@ -12,6 +12,15 @@
     "remote-pi": "dist/index.js",
     "pi-supervisord": "dist/bin/supervisord.js"
   },
+  "scripts": {
+    "build": "tsc",
+    "typecheck": "tsc --noEmit",
+    "dev": "tsx src/index.ts",
+    "test": "vitest run",
+    "verify": "pnpm typecheck && pnpm test && pnpm build",
+    "prepublishOnly": "pnpm verify",
+    "publish:npm": "bash ./publish-npm.sh"
+  },
   "keywords": [
     "pi",
     "pi-package",
@@ -21,10 +30,7 @@
     "browser",
     "pwa",
     "coding-agent",
-    "agent-mesh",
-    "agent-network",
-    "uds",
-    "broker",
+    "endpoint",
     "qr-pairing",
     "websocket"
   ],
@@ -47,7 +53,6 @@
   },
   "files": [
     "dist",
-    "skills",
     "service-templates",
     "docs",
     "README.md",
@@ -56,6 +61,14 @@
   "engines": {
     "node": ">=20.0.0"
   },
+  "pnpm": {
+    "onlyBuiltDependencies": [
+      "@google/genai",
+      "esbuild",
+      "koffi",
+      "protobufjs"
+    ]
+  },
   "devDependencies": {
     "@types/node": "^25.8.0",
     "@types/ws": "^8.18.1",
@@ -67,7 +80,6 @@
   "dependencies": {
     "@earendil-works/pi-coding-agent": "^0.79.10",
     "@earendil-works/pi-tui": "^0.79.10",
-    "@modelcontextprotocol/sdk": "^1.29.0",
     "@napi-rs/keyring": "^1.3.0",
     "@noble/ed25519": "^3.1.0",
     "croner": "^10.0.1",
@@ -75,13 +87,5 @@
     "typebox": "^1.1.38",
     "ws": "^8.21.0",
     "zod": "^4.4.3"
-  },
-  "scripts": {
-    "build": "tsc",
-    "typecheck": "tsc --noEmit",
-    "dev": "tsx src/index.ts",
-    "test": "vitest run",
-    "verify": "pnpm typecheck && pnpm test && pnpm build",
-    "publish:npm": "pnpm verify && pnpm publish --access public"
   }
-}
+}

package/dist/daemon/id.d.ts

@@ -1,24 +0,0 @@
-/**
- * Stable 8-character hex id for a daemon, derived from the cwd it manages.
- *
- * Derivation: `sha256(realpath(cwd))` truncated to 8 hex chars (32 bits ≈
- * 4 billion). Collision risk is negligible at fleet sizes a single user
- * will ever have (<1000 daemons), and 8 hex characters are short enough
- * to type on the CLI (`/remote-pi send a1b2c3d4 "..."`).
- *
- * Same scheme as `roomIdForCwd` in `src/rooms.ts` — but we use hex
- * instead of base64url so the id has no `_`/`-` (cleaner double-click
- * selection in terminals).
- *
- * Symlinks resolve to a single canonical id via `realpath`, so
- * `/Users/x/Movies` and `/Users/x/link-to-Movies` map to the same daemon.
- * Falls back to the raw path when realpath fails (cwd doesn't exist —
- * shouldn't happen in production but covers test sandboxes).
- *
- * plan/41 audit (2026-06-08): this stays **per-cwd** (no name axis). The
- * multiagent-per-folder model (plan/38/41) applies to the App↔Pi room and the
- * mesh address; a *supervisor daemon* is **one per cwd** by design — the
- * registry keys exactly one entry per cwd (`registry.ts`), so a daemon id never
- * needs the name to disambiguate. Decision: leave `daemonIdForCwd` cwd-only.
- */
-export declare function daemonIdForCwd(cwd: string): string;

package/dist/daemon/id.js

@@ -1,36 +0,0 @@
-import { createHash } from "node:crypto";
-import { realpathSync } from "node:fs";
-/**
- * Stable 8-character hex id for a daemon, derived from the cwd it manages.
- *
- * Derivation: `sha256(realpath(cwd))` truncated to 8 hex chars (32 bits ≈
- * 4 billion). Collision risk is negligible at fleet sizes a single user
- * will ever have (<1000 daemons), and 8 hex characters are short enough
- * to type on the CLI (`/remote-pi send a1b2c3d4 "..."`).
- *
- * Same scheme as `roomIdForCwd` in `src/rooms.ts` — but we use hex
- * instead of base64url so the id has no `_`/`-` (cleaner double-click
- * selection in terminals).
- *
- * Symlinks resolve to a single canonical id via `realpath`, so
- * `/Users/x/Movies` and `/Users/x/link-to-Movies` map to the same daemon.
- * Falls back to the raw path when realpath fails (cwd doesn't exist —
- * shouldn't happen in production but covers test sandboxes).
- *
- * plan/41 audit (2026-06-08): this stays **per-cwd** (no name axis). The
- * multiagent-per-folder model (plan/38/41) applies to the App↔Pi room and the
- * mesh address; a *supervisor daemon* is **one per cwd** by design — the
- * registry keys exactly one entry per cwd (`registry.ts`), so a daemon id never
- * needs the name to disambiguate. Decision: leave `daemonIdForCwd` cwd-only.
- */
-export function daemonIdForCwd(cwd) {
-    let target;
-    try {
-        target = realpathSync(cwd);
-    }
-    catch {
-        target = cwd;
-    }
-    return createHash("sha256").update(target).digest("hex").slice(0, 8);
-}
-//# sourceMappingURL=id.js.map

package/dist/daemon/id.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"id.js","sourceRoot":"","sources":["../../src/daemon/id.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,aAAa,CAAC;AACzC,OAAO,EAAE,YAAY,EAAE,MAAM,SAAS,CAAC;AAEvC;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,UAAU,cAAc,CAAC,GAAW;IACxC,IAAI,MAAc,CAAC;IACnB,IAAI,CAAC;QACH,MAAM,GAAG,YAAY,CAAC,GAAG,CAAC,CAAC;IAC7B,CAAC;IAAC,MAAM,CAAC;QACP,MAAM,GAAG,GAAG,CAAC;IACf,CAAC;IACD,OAAO,UAAU,CAAC,QAAQ,CAAC,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC,KAAK,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC;AACvE,CAAC"}

package/dist/mcp/mesh_result.d.ts

@@ -1,10 +0,0 @@
-import type { AckResult } from "../session/peer.js";
-type MeshAckResult = {
-    content: [{
-        type: "text";
-        text: string;
-    }];
-    isError?: true;
-};
-export declare function formatMeshAckResult(to: string, ack: AckResult): MeshAckResult;
-export {};

package/dist/mcp/mesh_result.js

@@ -1,42 +0,0 @@
-export function formatMeshAckResult(to, ack) {
-    switch (ack.status) {
-        case "received":
-            return textResult(`Delivered to ${ack.target ?? to}`);
-        case "busy":
-            return errorResult(`NOT delivered — "${to}" came back BUSY, which only happens when an ` +
-                `OUT-OF-DATE broker leader dropped the message (busy was removed in the ` +
-                `current version). Restart the agent that leads the local broker (the ` +
-                `oldest Pi/remote-pi process) so it picks up the new build, then resend.`);
-        case "denied":
-            return errorResult(formatDenied(to, ack));
-        case "timeout":
-            return errorResult(formatTimeout(to, ack));
-    }
-}
-function formatDenied(to, ack) {
-    const errorSuffix = ack.error ? ` (${ack.error})` : "";
-    if (ack.reason === "not_authorized") {
-        return `Relay did not authorize delivery to ${to}${errorSuffix}. ` +
-            `Do not blindly retry; verify authorization first.`;
-    }
-    if (ack.reason === "bad_envelope") {
-        return `Relay rejected the envelope for ${to}${errorSuffix}. ` +
-            `Do not blindly retry; correct the envelope first.`;
-    }
-    return `${to} denied the message`;
-}
-function formatTimeout(to, ack) {
-    if (ack.reason === "offline") {
-        const errorSuffix = ack.error ? ` (${ack.error})` : "";
-        return `Immediate Relay offline transport error for ${to}${errorSuffix}; ` +
-            `reported as timeout without waiting for an ACK.`;
-    }
-    return `No ACK from ${to} (timeout) — peer may be offline`;
-}
-function textResult(text) {
-    return { content: [{ type: "text", text }] };
-}
-function errorResult(text) {
-    return { content: [{ type: "text", text }], isError: true };
-}
-//# sourceMappingURL=mesh_result.js.map

package/dist/mcp/mesh_result.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"mesh_result.js","sourceRoot":"","sources":["../../src/mcp/mesh_result.ts"],"names":[],"mappings":"AAOA,MAAM,UAAU,mBAAmB,CAAC,EAAU,EAAE,GAAc;IAC5D,QAAQ,GAAG,CAAC,MAAM,EAAE,CAAC;QACnB,KAAK,UAAU;YACb,OAAO,UAAU,CAAC,gBAAgB,GAAG,CAAC,MAAM,IAAI,EAAE,EAAE,CAAC,CAAC;QACxD,KAAK,MAAM;YACT,OAAO,WAAW,CAChB,oBAAoB,EAAE,+CAA+C;gBACrE,yEAAyE;gBACzE,uEAAuE;gBACvE,yEAAyE,CAC1E,CAAC;QACJ,KAAK,QAAQ;YACX,OAAO,WAAW,CAAC,YAAY,CAAC,EAAE,EAAE,GAAG,CAAC,CAAC,CAAC;QAC5C,KAAK,SAAS;YACZ,OAAO,WAAW,CAAC,aAAa,CAAC,EAAE,EAAE,GAAG,CAAC,CAAC,CAAC;IAC/C,CAAC;AACH,CAAC;AAED,SAAS,YAAY,CAAC,EAAU,EAAE,GAAc;IAC9C,MAAM,WAAW,GAAG,GAAG,CAAC,KAAK,CAAC,CAAC,CAAC,KAAK,GAAG,CAAC,KAAK,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC;IACvD,IAAI,GAAG,CAAC,MAAM,KAAK,gBAAgB,EAAE,CAAC;QACpC,OAAO,uCAAuC,EAAE,GAAG,WAAW,IAAI;YAChE,mDAAmD,CAAC;IACxD,CAAC;IACD,IAAI,GAAG,CAAC,MAAM,KAAK,cAAc,EAAE,CAAC;QAClC,OAAO,mCAAmC,EAAE,GAAG,WAAW,IAAI;YAC5D,mDAAmD,CAAC;IACxD,CAAC;IACD,OAAO,GAAG,EAAE,qBAAqB,CAAC;AACpC,CAAC;AAED,SAAS,aAAa,CAAC,EAAU,EAAE,GAAc;IAC/C,IAAI,GAAG,CAAC,MAAM,KAAK,SAAS,EAAE,CAAC;QAC7B,MAAM,WAAW,GAAG,GAAG,CAAC,KAAK,CAAC,CAAC,CAAC,KAAK,GAAG,CAAC,KAAK,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC;QACvD,OAAO,+CAA+C,EAAE,GAAG,WAAW,IAAI;YACxE,iDAAiD,CAAC;IACtD,CAAC;IACD,OAAO,eAAe,EAAE,kCAAkC,CAAC;AAC7D,CAAC;AAED,SAAS,UAAU,CAAC,IAAY;IAC9B,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,CAAC;AAC/C,CAAC;AAED,SAAS,WAAW,CAAC,IAAY;IAC/B,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AAC9D,CAAC"}

package/dist/mcp/mesh_server.d.ts

@@ -1,16 +0,0 @@
-#!/usr/bin/env node
-/**
- * MCP server that bridges Claude Code to the remote-pi agent mesh.
- *
- * Spawned by Claude Code as an MCP server subprocess (stdio).
- * Joins the mesh through the shared `MeshNode` abstraction — the SAME
- * composition the Pi extension uses — so Claude is a first-class mesh
- * participant: it can lead the local UDS broker when no Pi/daemon is up,
- * and (as leader) bring up its own cross-PC relay bridge with its own
- * Pi-key. As a follower it rides the existing leader's bridge.
- *
- * Launched by `remote-pi claude` (registers this in Claude's local MCP
- * scope). Args: [--cwd <path>] [--name <agentName>] [--no-bridge]
- * Env: REMOTE_PI_MCP_CWD, REMOTE_PI_MCP_NAME
- */
-export {};