@rubytech/create-maxy-code 0.1.614 → 0.1.616

package/payload/platform/plugins/quickbooks/lib/mcp-spawn-tee/index.js

@@ -25,10 +25,13 @@
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
- * Lifecycle lines, correlation key `session=<id8> server=<name>` — unchanged:
+ * Lifecycle lines, correlation key `session=<id8> server=<name>`:
  *   [mcp-helper] op=spawn ... pid= entry=
  *   [mcp-helper] op=boot  ... head=<first stderr bytes>
  *   [mcp-helper] op=exit  ... code= signal= lifetimeMs= stderr-tail=
+ *   [mcp-helper] op=fatal ... kind=uncaught|rejection deferred=yes|no
+ *                              disposition=survived|exit error=
+ *     preceded by an `op=fatal-stack` block carrying the full stack (Task 2787).
  *
  * Process model (Task 989): the shim IS the server's process. op=exit fires
  * from process.on("exit"), so it covers a normal exit, a non-zero exit, an
@@ -37,6 +40,17 @@
  * and leaves no op=exit line — the per-session stderr tail already on disk and
  * Claude Code's own transport-drop are the evidence for that death mode.
  *
+ * op=exit records THAT a fatal killed the process; it never records WHICH one,
+ * because Node's fatal printer writes beneath the tee (Task 2787). The op=fatal
+ * pair is what names the error.
+ *
+ * Task 2788 — a fatal no longer always kills. `disposition=` says what the guard
+ * did: the shim exits 1 only when it is the sole listener for the event AND no
+ * stdio transport is connected. A fatal on a connected transport is recorded
+ * and survived, because Claude Code's policy after a helper dies is one
+ * reconnect then stop, so killing a live server removes its whole tool surface
+ * for the rest of the session.
+ *
  * The shim never writes to fd 1 (stdout) — that is the JSON-RPC channel.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
@@ -114,14 +128,22 @@ function postToServerLog(suffix, level) {
 // Claude Code visibility, never re-teed), and a best-effort server.log mirror.
 // `suffix` is the line body after the tag and carries no newline (the
 // log-ingest route rejects newlines).
-function emitLifecycle(suffix, level) {
+//
+// Task 2787 — `mirror` is false for op=exit and op=fatal. Both fire while the
+// loop is stopping, so the async fetch cannot flush: server.log held 2 op=exit
+// lines against 160 op=spawn and 135 op=boot. The sync raw sink is the
+// authoritative carrier for those two; posting them was a near-total loss
+// dressed as a mirror. op=spawn/op=boot/op=error keep it — they fire while the
+// loop is live and land.
+function emitLifecycle(suffix, level, mirror = true) {
     const line = `[mcp-helper] ${suffix}\n`;
     appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
     catch { /* stderr closed */ }
-    postToServerLog(suffix, level);
+    if (mirror)
+        postToServerLog(suffix, level);
 }
 if (!ENTRY) {
     emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason="no entry given (argv[2] missing)"`, "error");
@@ -165,6 +187,97 @@ function onSignal(sig, code) {
 process.on("SIGTERM", onSignal("SIGTERM", 143));
 process.on("SIGINT", onSignal("SIGINT", 130));
 process.on("SIGHUP", onSignal("SIGHUP", 129));
+// Task 2787 — the fatal guard. Three measured facts drove it here rather than
+// into the 26 plugin entries: Node's default fatal printer writes to fd 2
+// BENEATH the JS `process.stderr.write` the tee replaces, so on both 18 Aug
+// deaths the stack reached neither the raw sink nor Claude Code's own
+// `Server stderr:` capture; the shim is the single seam every entry already
+// loads through; and 26 copies would have to stay in step for ever.
+//
+// The stack is written through appendSafe and rawStderrWrite directly, never
+// through teeWrite — the tee is the thing that was blind to it.
+/** The three fields a fatal contributes. A rejection reason need not be an
+ *  Error, in which case there is no stack and the stringified reason stands in
+ *  for all three. */
+function describeFatal(err) {
+    if (err instanceof Error) {
+        return { name: err.name, message: err.message, stack: err.stack ?? `${err.name}: ${err.message}` };
+    }
+    const s = String(err);
+    return { name: typeof err, message: s, stack: s };
+}
+/** Write a fatal's full stack as its own block, before the lifecycle line that
+ *  summarises it. Multi-line by nature, which is why it is not a field on that
+ *  line. Goes through appendSafe and the RAW writer — never teeWrite, which is
+ *  the thing Node's own fatal printer writes beneath. */
+function writeFatalStack(kind, stack) {
+    const block = `[mcp-helper] op=fatal-stack session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind}\n${stack}\n`;
+    appendSafe(rawSinkPath, block);
+    try {
+        rawStderrWrite(block);
+    }
+    catch { /* stderr closed */ }
+}
+/** Task 2788 — has a stdio transport connected in this process?
+ *
+ *  `server.connect(transport)` calls `StdioServerTransport.start()`, whose body
+ *  is `this._stdin.on("data", …)`. So a stdin `data` listener exists if and only
+ *  if a stdio transport has started, and `close()` removes it again — a fatal
+ *  after the transport closed correctly reads as not connected.
+ *
+ *  Read at the moment of the fatal rather than latched at first connect, so a
+ *  transport that has since closed is not remembered as live. Nothing is
+ *  patched: all 26 plugin entries construct a StdioServerTransport and none
+ *  reads stdin itself, so this listener has exactly one source. The three
+ *  channel services carry no stdio transport, so every fatal in them still
+ *  exits — unchanged from before this task. */
+function transportConnected() {
+    return process.stdin.listenerCount("data") > 0;
+}
+// Task 2788 — the disposition. `disposition=` names what THIS guard did with
+// the process: `exit` means it called process.exit(1); `survived` means it
+// returned and left the process running.
+//
+// Claude Code owns the spawn (Task 706: no ChildProcess handle; Task 989: the
+// shim IS the server process) and its post-failure policy is one reconnect then
+// stop — measured on 18 Aug, when the retry died the same way 2.6s in and the
+// CLI never spawned again, leaving that session with `No such tool available`
+// for the rest of its life. Nothing in this tree can change that policy, so not
+// dying is the only mechanism available.
+//
+// The boundary is the connect, not a time window, because that is the fact that
+// separates "a live server hit a bad request" from "this server never came up".
+// Masking the second as the first would replace a visible outage with a silent
+// one.
+//
+//   * another listener present -> record and STAND DOWN, exactly as before. The
+//     email plugin installs its own pair (plugins/email/mcp/src/lib/setup-probe.ts)
+//     and deliberately survives errors it attributes to imapflow/nodemailer.
+//     The guard does not exit, so disposition=survived; if that handler then
+//     exits, the op=exit line that follows is the death record, and the census
+//     reads it as dark on its own terms.
+//   * sole listener, transport connected -> record and keep serving.
+//   * sole listener, no transport -> exit 1, which is Node's own default for an
+//     uncaught throw and (Node >= 15) for an unhandled rejection.
+//
+// The stack is written either way: surviving must not cost the diagnosis, which
+// is what Task 2787 exists to preserve.
+function onFatal(event, kind) {
+    return (err) => {
+        const sole = process.listenerCount(event) === 1;
+        const exiting = sole && !transportConnected();
+        const d = describeFatal(err);
+        // The stack first, so it is on disk before anything else can fail.
+        writeFatalStack(kind, d.stack);
+        emitLifecycle(`op=fatal session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind} ` +
+            `deferred=${sole ? "no" : "yes"} disposition=${exiting ? "exit" : "survived"} ` +
+            `error=${JSON.stringify(JSON.stringify({ name: d.name, message: d.message }))}`, "error", false);
+        if (exiting)
+            process.exit(1);
+    };
+}
+process.on("uncaughtException", onFatal("uncaughtException", "uncaught"));
+process.on("unhandledRejection", onFatal("unhandledRejection", "rejection"));
 // op=exit, emitted once from the process "exit" event. Sync-only — the loop is
 // stopping. When a catchable signal caused the exit, report code=— signal=<sig>
 // to match the prior wrapper's format; otherwise code=<exit code> signal=—.
@@ -177,7 +290,7 @@ process.on("exit", (code) => {
     const codeField = exitSignal ? "—" : String(code);
     const level = exitSignal || code !== 0 ? "error" : "info";
     emitLifecycle(`op=exit session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} ` +
-        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
+        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level, false);
 });
 emitLifecycle(`op=spawn session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} entry=${ENTRY}`, "info");
 // Task 2356 — present argv as a direct `node <entry>` invocation before the
@@ -194,11 +307,20 @@ process.argv = [process.argv[0], ENTRY, ...process.argv.slice(3)];
 // Run the real MCP server in THIS process. Dynamic import() (not top-level
 // await — this file compiles to CommonJS) loads the ESM entry; a load-time
 // failure mirrors the old child spawn-error path (op=error, exit 127). The
-// op=exit handler is suppressed on this path so op=error stays the sole record.
+// op=exit handler is suppressed on this path so op=error stays the sole
+// lifecycle record.
+//
+// Task 2787 — this .catch() settles the rejection, so a throw during the
+// entry's module EVALUATION never reaches the uncaughtException guard above.
+// The stack is written here explicitly; without it a boot-time death leaves
+// its message on the op=error line and nothing else — no type, no frames. The
+// op=error line itself is unchanged: `describeFatal().message` is the same
+// value the old inline expression produced.
 import((0, node_url_1.pathToFileURL)(ENTRY).href).catch((err) => {
-    const msg = err instanceof Error ? err.message : String(err);
+    const d = describeFatal(err);
     exitEmitted = true;
-    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${msg}`)}`, "error");
+    writeFatalStack("import", d.stack);
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${d.message}`)}`, "error");
     process.exit(127);
 });
 //# sourceMappingURL=index.js.map

package/payload/platform/plugins/replicate/lib/mcp-spawn-tee/index.js

@@ -25,10 +25,13 @@
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
- * Lifecycle lines, correlation key `session=<id8> server=<name>` — unchanged:
+ * Lifecycle lines, correlation key `session=<id8> server=<name>`:
  *   [mcp-helper] op=spawn ... pid= entry=
  *   [mcp-helper] op=boot  ... head=<first stderr bytes>
  *   [mcp-helper] op=exit  ... code= signal= lifetimeMs= stderr-tail=
+ *   [mcp-helper] op=fatal ... kind=uncaught|rejection deferred=yes|no
+ *                              disposition=survived|exit error=
+ *     preceded by an `op=fatal-stack` block carrying the full stack (Task 2787).
  *
  * Process model (Task 989): the shim IS the server's process. op=exit fires
  * from process.on("exit"), so it covers a normal exit, a non-zero exit, an
@@ -37,6 +40,17 @@
  * and leaves no op=exit line — the per-session stderr tail already on disk and
  * Claude Code's own transport-drop are the evidence for that death mode.
  *
+ * op=exit records THAT a fatal killed the process; it never records WHICH one,
+ * because Node's fatal printer writes beneath the tee (Task 2787). The op=fatal
+ * pair is what names the error.
+ *
+ * Task 2788 — a fatal no longer always kills. `disposition=` says what the guard
+ * did: the shim exits 1 only when it is the sole listener for the event AND no
+ * stdio transport is connected. A fatal on a connected transport is recorded
+ * and survived, because Claude Code's policy after a helper dies is one
+ * reconnect then stop, so killing a live server removes its whole tool surface
+ * for the rest of the session.
+ *
  * The shim never writes to fd 1 (stdout) — that is the JSON-RPC channel.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
@@ -114,14 +128,22 @@ function postToServerLog(suffix, level) {
 // Claude Code visibility, never re-teed), and a best-effort server.log mirror.
 // `suffix` is the line body after the tag and carries no newline (the
 // log-ingest route rejects newlines).
-function emitLifecycle(suffix, level) {
+//
+// Task 2787 — `mirror` is false for op=exit and op=fatal. Both fire while the
+// loop is stopping, so the async fetch cannot flush: server.log held 2 op=exit
+// lines against 160 op=spawn and 135 op=boot. The sync raw sink is the
+// authoritative carrier for those two; posting them was a near-total loss
+// dressed as a mirror. op=spawn/op=boot/op=error keep it — they fire while the
+// loop is live and land.
+function emitLifecycle(suffix, level, mirror = true) {
     const line = `[mcp-helper] ${suffix}\n`;
     appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
     catch { /* stderr closed */ }
-    postToServerLog(suffix, level);
+    if (mirror)
+        postToServerLog(suffix, level);
 }
 if (!ENTRY) {
     emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason="no entry given (argv[2] missing)"`, "error");
@@ -165,6 +187,97 @@ function onSignal(sig, code) {
 process.on("SIGTERM", onSignal("SIGTERM", 143));
 process.on("SIGINT", onSignal("SIGINT", 130));
 process.on("SIGHUP", onSignal("SIGHUP", 129));
+// Task 2787 — the fatal guard. Three measured facts drove it here rather than
+// into the 26 plugin entries: Node's default fatal printer writes to fd 2
+// BENEATH the JS `process.stderr.write` the tee replaces, so on both 18 Aug
+// deaths the stack reached neither the raw sink nor Claude Code's own
+// `Server stderr:` capture; the shim is the single seam every entry already
+// loads through; and 26 copies would have to stay in step for ever.
+//
+// The stack is written through appendSafe and rawStderrWrite directly, never
+// through teeWrite — the tee is the thing that was blind to it.
+/** The three fields a fatal contributes. A rejection reason need not be an
+ *  Error, in which case there is no stack and the stringified reason stands in
+ *  for all three. */
+function describeFatal(err) {
+    if (err instanceof Error) {
+        return { name: err.name, message: err.message, stack: err.stack ?? `${err.name}: ${err.message}` };
+    }
+    const s = String(err);
+    return { name: typeof err, message: s, stack: s };
+}
+/** Write a fatal's full stack as its own block, before the lifecycle line that
+ *  summarises it. Multi-line by nature, which is why it is not a field on that
+ *  line. Goes through appendSafe and the RAW writer — never teeWrite, which is
+ *  the thing Node's own fatal printer writes beneath. */
+function writeFatalStack(kind, stack) {
+    const block = `[mcp-helper] op=fatal-stack session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind}\n${stack}\n`;
+    appendSafe(rawSinkPath, block);
+    try {
+        rawStderrWrite(block);
+    }
+    catch { /* stderr closed */ }
+}
+/** Task 2788 — has a stdio transport connected in this process?
+ *
+ *  `server.connect(transport)` calls `StdioServerTransport.start()`, whose body
+ *  is `this._stdin.on("data", …)`. So a stdin `data` listener exists if and only
+ *  if a stdio transport has started, and `close()` removes it again — a fatal
+ *  after the transport closed correctly reads as not connected.
+ *
+ *  Read at the moment of the fatal rather than latched at first connect, so a
+ *  transport that has since closed is not remembered as live. Nothing is
+ *  patched: all 26 plugin entries construct a StdioServerTransport and none
+ *  reads stdin itself, so this listener has exactly one source. The three
+ *  channel services carry no stdio transport, so every fatal in them still
+ *  exits — unchanged from before this task. */
+function transportConnected() {
+    return process.stdin.listenerCount("data") > 0;
+}
+// Task 2788 — the disposition. `disposition=` names what THIS guard did with
+// the process: `exit` means it called process.exit(1); `survived` means it
+// returned and left the process running.
+//
+// Claude Code owns the spawn (Task 706: no ChildProcess handle; Task 989: the
+// shim IS the server process) and its post-failure policy is one reconnect then
+// stop — measured on 18 Aug, when the retry died the same way 2.6s in and the
+// CLI never spawned again, leaving that session with `No such tool available`
+// for the rest of its life. Nothing in this tree can change that policy, so not
+// dying is the only mechanism available.
+//
+// The boundary is the connect, not a time window, because that is the fact that
+// separates "a live server hit a bad request" from "this server never came up".
+// Masking the second as the first would replace a visible outage with a silent
+// one.
+//
+//   * another listener present -> record and STAND DOWN, exactly as before. The
+//     email plugin installs its own pair (plugins/email/mcp/src/lib/setup-probe.ts)
+//     and deliberately survives errors it attributes to imapflow/nodemailer.
+//     The guard does not exit, so disposition=survived; if that handler then
+//     exits, the op=exit line that follows is the death record, and the census
+//     reads it as dark on its own terms.
+//   * sole listener, transport connected -> record and keep serving.
+//   * sole listener, no transport -> exit 1, which is Node's own default for an
+//     uncaught throw and (Node >= 15) for an unhandled rejection.
+//
+// The stack is written either way: surviving must not cost the diagnosis, which
+// is what Task 2787 exists to preserve.
+function onFatal(event, kind) {
+    return (err) => {
+        const sole = process.listenerCount(event) === 1;
+        const exiting = sole && !transportConnected();
+        const d = describeFatal(err);
+        // The stack first, so it is on disk before anything else can fail.
+        writeFatalStack(kind, d.stack);
+        emitLifecycle(`op=fatal session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind} ` +
+            `deferred=${sole ? "no" : "yes"} disposition=${exiting ? "exit" : "survived"} ` +
+            `error=${JSON.stringify(JSON.stringify({ name: d.name, message: d.message }))}`, "error", false);
+        if (exiting)
+            process.exit(1);
+    };
+}
+process.on("uncaughtException", onFatal("uncaughtException", "uncaught"));
+process.on("unhandledRejection", onFatal("unhandledRejection", "rejection"));
 // op=exit, emitted once from the process "exit" event. Sync-only — the loop is
 // stopping. When a catchable signal caused the exit, report code=— signal=<sig>
 // to match the prior wrapper's format; otherwise code=<exit code> signal=—.
@@ -177,7 +290,7 @@ process.on("exit", (code) => {
     const codeField = exitSignal ? "—" : String(code);
     const level = exitSignal || code !== 0 ? "error" : "info";
     emitLifecycle(`op=exit session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} ` +
-        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
+        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level, false);
 });
 emitLifecycle(`op=spawn session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} entry=${ENTRY}`, "info");
 // Task 2356 — present argv as a direct `node <entry>` invocation before the
@@ -194,11 +307,20 @@ process.argv = [process.argv[0], ENTRY, ...process.argv.slice(3)];
 // Run the real MCP server in THIS process. Dynamic import() (not top-level
 // await — this file compiles to CommonJS) loads the ESM entry; a load-time
 // failure mirrors the old child spawn-error path (op=error, exit 127). The
-// op=exit handler is suppressed on this path so op=error stays the sole record.
+// op=exit handler is suppressed on this path so op=error stays the sole
+// lifecycle record.
+//
+// Task 2787 — this .catch() settles the rejection, so a throw during the
+// entry's module EVALUATION never reaches the uncaughtException guard above.
+// The stack is written here explicitly; without it a boot-time death leaves
+// its message on the op=error line and nothing else — no type, no frames. The
+// op=error line itself is unchanged: `describeFatal().message` is the same
+// value the old inline expression produced.
 import((0, node_url_1.pathToFileURL)(ENTRY).href).catch((err) => {
-    const msg = err instanceof Error ? err.message : String(err);
+    const d = describeFatal(err);
     exitEmitted = true;
-    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${msg}`)}`, "error");
+    writeFatalStack("import", d.stack);
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${d.message}`)}`, "error");
     process.exit(127);
 });
 //# sourceMappingURL=index.js.map

package/payload/platform/plugins/scheduling/PLUGIN.md

@@ -296,7 +296,7 @@ Choosing a dispatch mode is **two questions, not one**: should this fire run *at
 
 1. **`action`** — nothing here needs a model. One pre-encoded MCP tool, no reasoning, no spawn.
 2. **`agentDispatch` with a `gate`** — a model is needed to compose or to judge, but only when there is something to act on. **This is the default for anything conditional.** The dispatcher calls the gate tool headlessly before spawning; `hasWork:false` skips the fire entirely.
-3. **`agentDispatch` with no gate** — judgement applies on *every* fire, whatever the state of the world: a daily briefing, a weekly digest. This is the exception, and it is stated as one. A recurring `agentDispatch` with no `gate` is refused unless it carries `gateWaived` naming why.
+3. There is no third shape. A recurring `agentDispatch` with no `gate` is refused. A routine that reaches the model on a fire with nothing to report is a routine that can send with nothing to report, so "judgement applies on every fire" is not an exception the write accepts. Express the trigger as a gate instead: the gate decides whether the fire happens, the prompt decides what to say once it does.
 
 When an agent-bearing event fires, the heartbeat hands the prompt to the destination's native channel: the channel spawns or resumes the deterministic admin session for that phone or chat, the agent runs the prompt with full admin tools, and its answer is delivered back over the account's paired socket. No operator session need be open.
 
@@ -325,8 +325,7 @@ Written as one model turn instead — "check whether it is signed yet and, if it
 - `channel` — `whatsapp` or `telegram`.
 - `destination` — the E.164 phone (WhatsApp) or chat id (Telegram) to run the turn for and reply to. It **must already be a registered admin or account-manager** on that channel; a destination that is not is rejected when the event is created. For WhatsApp the authoritative admin/manager lists are read from the socket-owning **house** account (never the event's own account), and the destination's registered account must match the account that created the schedule: an admin belongs to the house, a manager to its bound sub-account. The house/owner account may target any registered admin or manager; a sub-account is locked to its own manager(s). A refusal names the true reason — `not-registered` (in no house list) or `cross-account` (registered to a different account, naming both accounts).
 - `prompt` — the instruction the agent runs. Write it for the case where there **is** work: the gate has already decided that.
-- `gate` — `{ plugin, tool, args }`. The precondition, evaluated headlessly between the `nextRun` advance and the spawn. It must return `structuredContent {hasWork:boolean}`; the dispatcher reads that boolean and nothing else. A gate that errors, times out or returns no boolean **dispatches anyway**, so a broken check never silently mutes a routine. Requires a complete `agentDispatch`, is refused on an action-mode event, and is refused when any check names a type `scheduling-gate` does not probe.
-- `gateWaived` — a string reason, and the only way to create a recurring `agentDispatch` with no gate. Give the reason this routine has judgement to apply on every fire ("the morning briefing composes from scratch each day"). It is stored on the event and counted by the standing gate-classification check, so a deliberate exception stays readable and the fleet's drift back to ungated is a number someone can look at. A conditional sweep is not an exception; gate it.
+- `gate` — `{ plugin, tool, args }`. The precondition, evaluated headlessly between the `nextRun` advance and the spawn. It must return `structuredContent {hasWork:boolean}`; the dispatcher reads that boolean and nothing else. A gate that errors, times out or returns no boolean **refuses the fire**: it has not shown there is anything to report, and nothing reaches the model until something to report is proven. The refused fire is recorded as `gate-unavailable` rather than `gated`, and `op=gate-census … gateUnavailable=<n>` plus one `op=gate-unavailable` line per routine is what stops a permanently broken gate reading as a routine that is merely quiet. Requires a complete `agentDispatch`, is refused on an action-mode event, and is refused when any check names a type `scheduling-gate` does not probe.
 
 **Gate check vocabulary.** A **`mail`** check answers whether a UID strictly above the stored watermark exists in the folder, optionally narrowed by `subjectPrefixes`. It is not "is there mail" — an empty answer on a full mailbox is the normal quiet state. The IMAP range `UID <n+1>:*` still yields the folder's last message when `n` is at or above the highest assigned UID (RFC 3501 §6.4.8), so the probe drops anything at or below the watermark before deciding; `[scheduling-gate] op=mail-probe … returned=<n> aboveWatermark=<n>` reports both counts, and `returned` exceeding `aboveWatermark` by exactly one is the steady state. A UIDVALIDITY change reports work, because the stored UID then names a different message. The watermark is keyed `<mailbox>|<folder>` with the folder lower-cased, because `INBOX` is case-insensitive by RFC 3501 §5.1: a binding that writes `"folder": "inbox"` and one that writes `"INBOX"` address one entry, so changing the case of an existing binding does not reset the position. The mailbox segment keeps its case, because a local part is case-sensitive. Keys already stored in mixed case fold on read, highest `uid` winning, and `[scheduling-gate] op=watermark-fold … kept=<key> droppedUid=<n>` names what the repair discarded.
 
@@ -359,7 +358,7 @@ Three lines record it. `[schedule-gate] op=mark-advanced eventId=… advanced=
 
 **Recurring only.** A one-time agent event is never gated — its row is already `due` by the time the dispatcher sees it, so a skip there would drop the routine for good — and it is therefore outside the refusal. `schedule-update` takes no waiver either: an existing routine keeps what it has until it is edited.
 
-An event carries **either** an `action` **or** an `agentDispatch`, never both — setting one clears the other. Agent dispatch is stored as `agentChannel`, `agentDestination`, `agentPrompt`; the gate as `gatePlugin`, `gateTool`, `gateArgs`; the waiver as `gateWaived`. Use `schedule-update` with `agentDispatch` to modify or `agentDispatch: null` to clear. On WhatsApp, a destination bound as an account-manager scopes the spawned session to its sub-account — unless that same phone is also on the house `adminPhones` list, in which case it scopes to the channel account, because the dispatch rides the house socket and so arrives from the house number. On Telegram the session runs on the house account.
+An event carries **either** an `action` **or** an `agentDispatch`, never both — setting one clears the other. Agent dispatch is stored as `agentChannel`, `agentDestination`, `agentPrompt`; the gate as `gatePlugin`, `gateTool`, `gateArgs`. Older rows may also carry a legacy `gateWaived` reason; it is read by the standing census and can no longer be written. Use `schedule-update` with `agentDispatch` to modify or `agentDispatch: null` to clear. On WhatsApp, a destination bound as an account-manager scopes the spawned session to its sub-account — unless that same phone is also on the house `adminPhones` list, in which case it scopes to the channel account, because the dispatch rides the house socket and so arrives from the house number. On Telegram the session runs on the house account.
 
 A WhatsApp `agentDispatch` destination may therefore be an account manager, not only an admin phone — this is the supported way to send a manager a proactive or scheduled WhatsApp message. The reply is delivered over the house's paired line regardless of which sub-account the session is scoped to; socket ownership never restricts which number the dispatch can reach.
 

package/payload/platform/plugins/scheduling/lib/mcp-spawn-tee/index.js

@@ -25,10 +25,13 @@
  *   - `server.log` via the loopback log-ingest route — best-effort mirror of
  *     the [mcp-helper] lifecycle lines.
  *
- * Lifecycle lines, correlation key `session=<id8> server=<name>` — unchanged:
+ * Lifecycle lines, correlation key `session=<id8> server=<name>`:
  *   [mcp-helper] op=spawn ... pid= entry=
  *   [mcp-helper] op=boot  ... head=<first stderr bytes>
  *   [mcp-helper] op=exit  ... code= signal= lifetimeMs= stderr-tail=
+ *   [mcp-helper] op=fatal ... kind=uncaught|rejection deferred=yes|no
+ *                              disposition=survived|exit error=
+ *     preceded by an `op=fatal-stack` block carrying the full stack (Task 2787).
  *
  * Process model (Task 989): the shim IS the server's process. op=exit fires
  * from process.on("exit"), so it covers a normal exit, a non-zero exit, an
@@ -37,6 +40,17 @@
  * and leaves no op=exit line — the per-session stderr tail already on disk and
  * Claude Code's own transport-drop are the evidence for that death mode.
  *
+ * op=exit records THAT a fatal killed the process; it never records WHICH one,
+ * because Node's fatal printer writes beneath the tee (Task 2787). The op=fatal
+ * pair is what names the error.
+ *
+ * Task 2788 — a fatal no longer always kills. `disposition=` says what the guard
+ * did: the shim exits 1 only when it is the sole listener for the event AND no
+ * stdio transport is connected. A fatal on a connected transport is recorded
+ * and survived, because Claude Code's policy after a helper dies is one
+ * reconnect then stop, so killing a live server removes its whole tool surface
+ * for the rest of the session.
+ *
  * The shim never writes to fd 1 (stdout) — that is the JSON-RPC channel.
  */
 Object.defineProperty(exports, "__esModule", { value: true });
@@ -114,14 +128,22 @@ function postToServerLog(suffix, level) {
 // Claude Code visibility, never re-teed), and a best-effort server.log mirror.
 // `suffix` is the line body after the tag and carries no newline (the
 // log-ingest route rejects newlines).
-function emitLifecycle(suffix, level) {
+//
+// Task 2787 — `mirror` is false for op=exit and op=fatal. Both fire while the
+// loop is stopping, so the async fetch cannot flush: server.log held 2 op=exit
+// lines against 160 op=spawn and 135 op=boot. The sync raw sink is the
+// authoritative carrier for those two; posting them was a near-total loss
+// dressed as a mirror. op=spawn/op=boot/op=error keep it — they fire while the
+// loop is live and land.
+function emitLifecycle(suffix, level, mirror = true) {
     const line = `[mcp-helper] ${suffix}\n`;
     appendSafe(rawSinkPath, line);
     try {
         rawStderrWrite(line);
     }
     catch { /* stderr closed */ }
-    postToServerLog(suffix, level);
+    if (mirror)
+        postToServerLog(suffix, level);
 }
 if (!ENTRY) {
     emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason="no entry given (argv[2] missing)"`, "error");
@@ -165,6 +187,97 @@ function onSignal(sig, code) {
 process.on("SIGTERM", onSignal("SIGTERM", 143));
 process.on("SIGINT", onSignal("SIGINT", 130));
 process.on("SIGHUP", onSignal("SIGHUP", 129));
+// Task 2787 — the fatal guard. Three measured facts drove it here rather than
+// into the 26 plugin entries: Node's default fatal printer writes to fd 2
+// BENEATH the JS `process.stderr.write` the tee replaces, so on both 18 Aug
+// deaths the stack reached neither the raw sink nor Claude Code's own
+// `Server stderr:` capture; the shim is the single seam every entry already
+// loads through; and 26 copies would have to stay in step for ever.
+//
+// The stack is written through appendSafe and rawStderrWrite directly, never
+// through teeWrite — the tee is the thing that was blind to it.
+/** The three fields a fatal contributes. A rejection reason need not be an
+ *  Error, in which case there is no stack and the stringified reason stands in
+ *  for all three. */
+function describeFatal(err) {
+    if (err instanceof Error) {
+        return { name: err.name, message: err.message, stack: err.stack ?? `${err.name}: ${err.message}` };
+    }
+    const s = String(err);
+    return { name: typeof err, message: s, stack: s };
+}
+/** Write a fatal's full stack as its own block, before the lifecycle line that
+ *  summarises it. Multi-line by nature, which is why it is not a field on that
+ *  line. Goes through appendSafe and the RAW writer — never teeWrite, which is
+ *  the thing Node's own fatal printer writes beneath. */
+function writeFatalStack(kind, stack) {
+    const block = `[mcp-helper] op=fatal-stack session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind}\n${stack}\n`;
+    appendSafe(rawSinkPath, block);
+    try {
+        rawStderrWrite(block);
+    }
+    catch { /* stderr closed */ }
+}
+/** Task 2788 — has a stdio transport connected in this process?
+ *
+ *  `server.connect(transport)` calls `StdioServerTransport.start()`, whose body
+ *  is `this._stdin.on("data", …)`. So a stdin `data` listener exists if and only
+ *  if a stdio transport has started, and `close()` removes it again — a fatal
+ *  after the transport closed correctly reads as not connected.
+ *
+ *  Read at the moment of the fatal rather than latched at first connect, so a
+ *  transport that has since closed is not remembered as live. Nothing is
+ *  patched: all 26 plugin entries construct a StdioServerTransport and none
+ *  reads stdin itself, so this listener has exactly one source. The three
+ *  channel services carry no stdio transport, so every fatal in them still
+ *  exits — unchanged from before this task. */
+function transportConnected() {
+    return process.stdin.listenerCount("data") > 0;
+}
+// Task 2788 — the disposition. `disposition=` names what THIS guard did with
+// the process: `exit` means it called process.exit(1); `survived` means it
+// returned and left the process running.
+//
+// Claude Code owns the spawn (Task 706: no ChildProcess handle; Task 989: the
+// shim IS the server process) and its post-failure policy is one reconnect then
+// stop — measured on 18 Aug, when the retry died the same way 2.6s in and the
+// CLI never spawned again, leaving that session with `No such tool available`
+// for the rest of its life. Nothing in this tree can change that policy, so not
+// dying is the only mechanism available.
+//
+// The boundary is the connect, not a time window, because that is the fact that
+// separates "a live server hit a bad request" from "this server never came up".
+// Masking the second as the first would replace a visible outage with a silent
+// one.
+//
+//   * another listener present -> record and STAND DOWN, exactly as before. The
+//     email plugin installs its own pair (plugins/email/mcp/src/lib/setup-probe.ts)
+//     and deliberately survives errors it attributes to imapflow/nodemailer.
+//     The guard does not exit, so disposition=survived; if that handler then
+//     exits, the op=exit line that follows is the death record, and the census
+//     reads it as dark on its own terms.
+//   * sole listener, transport connected -> record and keep serving.
+//   * sole listener, no transport -> exit 1, which is Node's own default for an
+//     uncaught throw and (Node >= 15) for an unhandled rejection.
+//
+// The stack is written either way: surviving must not cost the diagnosis, which
+// is what Task 2787 exists to preserve.
+function onFatal(event, kind) {
+    return (err) => {
+        const sole = process.listenerCount(event) === 1;
+        const exiting = sole && !transportConnected();
+        const d = describeFatal(err);
+        // The stack first, so it is on disk before anything else can fail.
+        writeFatalStack(kind, d.stack);
+        emitLifecycle(`op=fatal session=${SESSION_ID8} server=${SERVER_NAME} kind=${kind} ` +
+            `deferred=${sole ? "no" : "yes"} disposition=${exiting ? "exit" : "survived"} ` +
+            `error=${JSON.stringify(JSON.stringify({ name: d.name, message: d.message }))}`, "error", false);
+        if (exiting)
+            process.exit(1);
+    };
+}
+process.on("uncaughtException", onFatal("uncaughtException", "uncaught"));
+process.on("unhandledRejection", onFatal("unhandledRejection", "rejection"));
 // op=exit, emitted once from the process "exit" event. Sync-only — the loop is
 // stopping. When a catchable signal caused the exit, report code=— signal=<sig>
 // to match the prior wrapper's format; otherwise code=<exit code> signal=—.
@@ -177,7 +290,7 @@ process.on("exit", (code) => {
     const codeField = exitSignal ? "—" : String(code);
     const level = exitSignal || code !== 0 ? "error" : "info";
     emitLifecycle(`op=exit session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} ` +
-        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
+        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level, false);
 });
 emitLifecycle(`op=spawn session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} entry=${ENTRY}`, "info");
 // Task 2356 — present argv as a direct `node <entry>` invocation before the
@@ -194,11 +307,20 @@ process.argv = [process.argv[0], ENTRY, ...process.argv.slice(3)];
 // Run the real MCP server in THIS process. Dynamic import() (not top-level
 // await — this file compiles to CommonJS) loads the ESM entry; a load-time
 // failure mirrors the old child spawn-error path (op=error, exit 127). The
-// op=exit handler is suppressed on this path so op=error stays the sole record.
+// op=exit handler is suppressed on this path so op=error stays the sole
+// lifecycle record.
+//
+// Task 2787 — this .catch() settles the rejection, so a throw during the
+// entry's module EVALUATION never reaches the uncaughtException guard above.
+// The stack is written here explicitly; without it a boot-time death leaves
+// its message on the op=error line and nothing else — no type, no frames. The
+// op=error line itself is unchanged: `describeFatal().message` is the same
+// value the old inline expression produced.
 import((0, node_url_1.pathToFileURL)(ENTRY).href).catch((err) => {
-    const msg = err instanceof Error ? err.message : String(err);
+    const d = describeFatal(err);
     exitEmitted = true;
-    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${msg}`)}`, "error");
+    writeFatalStack("import", d.stack);
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${d.message}`)}`, "error");
     process.exit(127);
 });
 //# sourceMappingURL=index.js.map

package/payload/platform/plugins/scheduling/mcp/dist/index.js

@@ -73,9 +73,6 @@ const gateShape = {
     args: z.record(z.unknown()).optional().describe("Arguments passed to the gate tool verbatim"),
 };
 const GATE_DESCRIPTION = "Precondition: before this routine spawns an agent turn, the dispatcher calls this tool headlessly and reads structuredContent.hasWork. False skips the turn entirely; true dispatches as normal. A gate that errors, times out or returns no boolean dispatches anyway, so a broken gate never silently mutes the routine. Requires a complete agentDispatch and is refused on an action-mode event.";
-// Task 2383 — the declared exception, on the create path only. `schedule-update`
-// takes no waiver: an existing routine keeps what it has until it is edited.
-const GATE_WAIVED_DESCRIPTION = "The declared reason this recurring routine runs a model on every fire with no gate. A daily briefing or a weekly digest composes from scratch each time and has judgement to apply whether or not anything changed; a conditional sweep does not, and belongs behind a gate. Required when a recurring agentDispatch carries no gate — the write is refused without one. Stored on the event and counted by the standing gate-classification check, so every deliberate exception stays readable.";
 // ---------------------------------------------------------------------------
 // schedule-event
 // ---------------------------------------------------------------------------
@@ -105,7 +102,6 @@ eagerTool(server, "schedule-event", "Create a scheduled event or appointment. A
         botId: z.string().optional().describe("Telegram only — the bot that carries this routine. Omit to let the fire-time resolver pick whichever admin bot lists the chat id, which is correct for a single-admin-bot account. Name one to pin the carrier, so the routine cannot silently change bot when another bot's role changes."),
     }).optional().describe("Agent-bearing dispatch: when the event fires, spawns or resumes the admin channel session for `destination` and runs `prompt` with full admin tools, delivering the answer back over the channel. Mutually exclusive with `action`. Always records an event, never a meeting."),
     gate: z.object(gateShape).optional().describe(GATE_DESCRIPTION),
-    gateWaived: z.string().optional().describe(GATE_WAIVED_DESCRIPTION),
 }, async (params) => {
     if (!accountId)
         return refuseNoAccount("schedule-event");
@@ -146,8 +142,6 @@ eagerTool(server, "schedule-event", "Create a scheduled event or appointment. A
             parts.push(`agent dispatch: ${params.agentDispatch.channel} → ${params.agentDispatch.destination}`);
         if (params.gate)
             parts.push(`gate: ${params.gate.plugin}/${params.gate.tool}`);
-        if (params.gateWaived)
-            parts.push(`gate waived: ${params.gateWaived}`);
         return { content: [{ type: "text", text: parts.join(", ") }] };
     }
     catch (err) {