patchcord 0.5.1 → 0.5.3

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "patchcord",
   "description": "Cross-machine agent messaging with push delivery. Messages from other agents arrive as native channel notifications.",
-  "version": "0.5.1",
+  "version": "0.5.3",
   "author": {
     "name": "ppravdin"
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "patchcord",
-  "version": "0.5.1",
+  "version": "0.5.3",
   "description": "Cross-machine agent messaging for Claude Code and Codex",
   "author": "ppravdin",
   "license": "MIT",

package/scripts/subscribe.mjs

@@ -17,6 +17,17 @@ const JWT_REFRESH_SAFETY_MARGIN_SEC = 120;
 const HEARTBEAT_INTERVAL_MS = 25_000;
 const RECONNECT_BACKOFF_MS = [1000, 2000, 4000, 8000, 15_000, 30_000];
 
+// Guarantee a terminal stderr line on any unhandled failure so the agent
+// reading Monitor's output file always sees WHY the process died.
+process.on("uncaughtException", (err) => {
+  process.stderr.write(`subscribe: fatal: uncaught: ${err?.stack || err?.message || err}\n`);
+  process.exit(1);
+});
+process.on("unhandledRejection", (err) => {
+  process.stderr.write(`subscribe: fatal: unhandled rejection: ${err?.stack || err?.message || err}\n`);
+  process.exit(1);
+});
+
 function die(msg, code = 1) {
   process.stderr.write(msg + "\n");
   process.exit(code);

package/skills/subscribe/SKILL.md

@@ -68,13 +68,19 @@ then the script is at
      description: "patchcord realtime listener (<agent>@<ns>)",
      persistent: true,
      timeout_ms: 3600000,
-     command: "exec node \"<absolute-path-to-subscribe.mjs>\" 2>&1 | grep --line-buffered -E '^PATCHCORD:|^subscribe: (fatal|ws error|token|already|connected|reconnecting|cwd|agent)'"
+     command: "exec node \"<absolute-path-to-subscribe.mjs>\""
    )
    ```
-   The `grep` filter is intentional — it surfaces the signal lines
-   (`PATCHCORD:` arrivals, connect/disconnect, errors) and drops the
-   noise. The filter catches every terminal/state-change event, so the
-   Monitor won't silently miss a crash.
+   No `2>&1`, no grep filter. By construction the script only writes
+   `PATCHCORD: ...` lines to stdout. Everything else — `connected`,
+   `token refreshed`, startup diagnostics, errors — goes to stderr,
+   which Monitor captures into its output file but does NOT fire as
+   notifications. So there's nothing to filter and no way to get the
+   filter wrong.
+
+   Crash detection is handled automatically by Monitor itself: when the
+   process exits, Monitor emits a built-in "stream ended" task
+   notification with the output file path and exit code.
 
 6. **Tell the user one short line:**
    "Patchcord listener active — I'll pick up new messages as they arrive."
@@ -97,18 +103,45 @@ There is no `/patchcord:unsubscribe` command. Tell the user either:
 - Run `kill $(cat /tmp/patchcord_subscribe_<namespace>_<agent>.pid)` in
   a terminal.
 
-# If it fails to start
+# If the Monitor stream ends — STRICT PROTOCOL
+
+The stream-end task notification includes the path to Monitor's output
+file. Do exactly this, in this order:
+
+1. Read that output file using the Read tool.
+2. Look at the last ~15 lines for a line matching one of the known
+   failure strings below. There will always be at least one terminal
+   error line — the script's error handlers guarantee it.
+3. Report the specific cause to the user in one short sentence.
+4. STOP.
+
+**Forbidden on failure — do not do any of these:**
+- Do NOT run `pgrep`, `ps`, `kill`, `pkill`, `killall`, or any command
+  that targets PIDs or process names.
+- Do NOT modify, delete, or write to the pidfile yourself. The script
+  manages it; it's already cleaned up by the time Monitor emits the
+  stream-end event.
+- Do NOT spawn another Monitor or another `node subscribe.mjs`. One
+  failure means something is wrong with the config or environment;
+  respawning will not fix it and will make things worse.
+- Do NOT search for orphaned processes or try to "clean up" state.
 
-Stderr shows the exact cause. Report it to the user verbatim and stop
-— do not loop or retry:
+Concrete failure strings you may see and what they mean:
 
 - `no .mcp.json in <cwd>` — session is not in a patchcord project dir.
-- `token rejected` — bearer in `.mcp.json` is bad; regenerate from the
-  dashboard.
-- `server not configured for realtime` — server hasn't had
-  `SUPABASE_JWT_SECRET` / `SUPABASE_ANON_KEY` set. Self-hosted without
-  Supabase does not support this feature yet.
-- `namespace not owned` — the token's namespace lost its owner row;
-  regenerate from the dashboard.
-- `already running (pid N)` — pidfile guard tripped. Another subscribe
-  is active. Report and stop.
+  Tell the user which directory to `cd` into.
+- `ticket: token rejected (HTTP 401|403)` — bearer in `.mcp.json` is
+  bad; regenerate from the dashboard.
+- `ticket: server not configured for realtime` — the patchcord server
+  hasn't had `SUPABASE_JWT_SECRET` / `SUPABASE_ANON_KEY` set. This is
+  a cloud-only feature.
+- `ticket: namespace not owned — regenerate your token` — the token's
+  namespace lost its owner row; regenerate from the dashboard.
+- `already running (pid N)` (exit code 2) — pidfile guard tripped,
+  another listener is active. Report and stop. Do NOT kill the other
+  listener to make room.
+- `subscribe: fatal: ...` — unhandled error. Show the user the line
+  verbatim, stop.
+
+If the process exited cleanly (exit 0) with no error line, the user
+closed the session or killed the process. Nothing to do.