@rubytech/create-maxy-code 0.1.545 → 0.1.547

package/payload/platform/plugins/admin/mcp/dist/tools/account-default-agent.d.ts

@@ -0,0 +1,16 @@
+export type DefaultAgentRefusal = "shape" | "not-found";
+export type DefaultAgentVerdict = {
+    ok: true;
+    slug: string;
+} | {
+    ok: false;
+    reason: DefaultAgentRefusal;
+};
+/**
+ * Decide whether a submitted `defaultAgent` value may be stored. An empty or
+ * whitespace-only value is the clear operation and is accepted as `slug: ""`.
+ * Shape is decided before existence, so a traversal value is refused as
+ * `shape` however many real files sit at the end of it.
+ */
+export declare function checkDefaultAgent(accountDir: string, value: string): DefaultAgentVerdict;
+//# sourceMappingURL=account-default-agent.d.ts.map

package/payload/platform/plugins/admin/mcp/dist/tools/account-default-agent.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"account-default-agent.d.ts","sourceRoot":"","sources":["../../src/tools/account-default-agent.ts"],"names":[],"mappings":"AAiBA,MAAM,MAAM,mBAAmB,GAAG,OAAO,GAAG,WAAW,CAAC;AAExD,MAAM,MAAM,mBAAmB,GAC3B;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAC1B;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,mBAAmB,CAAA;CAAE,CAAC;AAE/C;;;;;GAKG;AACH,wBAAgB,iBAAiB,CAAC,UAAU,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,mBAAmB,CAQxF"}

package/payload/platform/plugins/admin/mcp/dist/tools/account-default-agent.js

@@ -0,0 +1,21 @@
+import { existsSync } from "node:fs";
+import { join } from "node:path";
+import { AGENT_SLUG_PATTERN } from "../../../../../lib/agent-slug/dist/index.js";
+/**
+ * Decide whether a submitted `defaultAgent` value may be stored. An empty or
+ * whitespace-only value is the clear operation and is accepted as `slug: ""`.
+ * Shape is decided before existence, so a traversal value is refused as
+ * `shape` however many real files sit at the end of it.
+ */
+export function checkDefaultAgent(accountDir, value) {
+    const slug = value.trim();
+    if (!slug)
+        return { ok: true, slug: "" };
+    if (!AGENT_SLUG_PATTERN.test(slug))
+        return { ok: false, reason: "shape" };
+    if (!existsSync(join(accountDir, "agents", slug, "config.json"))) {
+        return { ok: false, reason: "not-found" };
+    }
+    return { ok: true, slug };
+}
+//# sourceMappingURL=account-default-agent.js.map

package/payload/platform/plugins/admin/mcp/dist/tools/account-default-agent.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"account-default-agent.js","sourceRoot":"","sources":["../../src/tools/account-default-agent.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACrC,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AACjC,OAAO,EAAE,kBAAkB,EAAE,MAAM,6CAA6C,CAAC;AAqBjF;;;;;GAKG;AACH,MAAM,UAAU,iBAAiB,CAAC,UAAkB,EAAE,KAAa;IACjE,MAAM,IAAI,GAAG,KAAK,CAAC,IAAI,EAAE,CAAC;IAC1B,IAAI,CAAC,IAAI;QAAE,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,IAAI,EAAE,EAAE,EAAE,CAAC;IACzC,IAAI,CAAC,kBAAkB,CAAC,IAAI,CAAC,IAAI,CAAC;QAAE,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC;IAC1E,IAAI,CAAC,UAAU,CAAC,IAAI,CAAC,UAAU,EAAE,QAAQ,EAAE,IAAI,EAAE,aAAa,CAAC,CAAC,EAAE,CAAC;QACjE,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,WAAW,EAAE,CAAC;IAC5C,CAAC;IACD,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,IAAI,EAAE,CAAC;AAC5B,CAAC"}

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:4566431caa948d080401758fc742c6b3f6340a0a1d17129ff51c9887836aaf87
+content-hash: sha256:27883a95ee231fb265b37617f71dfdf1a71e28fccf76d09f9e75c0726c777f48
 brand: maxy-code
 product-name: Maxy
 ---
@@ -1686,15 +1686,13 @@ Two questions an agent cannot answer from inside itself, and both have caused re
 
 ## What wakes a session
 
-Five things start or resume a WhatsApp session. They are distinguishable, and the distinction matters, because two of them are written by the platform rather than by the person named as the sender.
+Four things start or resume a WhatsApp session. They are distinguishable, and the distinction matters, because one of them is written by the platform rather than by the person named as the sender.
 
 **An admin phone or an account manager messages the line.** This resumes that person's own admin session. There is no per-account admin session: the session id is a hash of the account plus the person, so one person messaging from two channels resumes one thread, and two managers on one account have two threads.
 
-**A public sender messages the line.** Three things follow, in this order, and each is independent of the ones after it.
+**A public sender messages the line.** One thing follows: the account's public agent answers the visitor, if the account has one and has enabled it. If not, the message is stored and labelled and the visitor receives nothing at all.
 
-1. The account's registered managers are notified, verbatim, unless the account has turned that off. This fires before any agent starts, so it survives a spawn that fails.
-2. Every bound manager's own admin session is woken with a `public-relay` turn carrying the sender's message as fenced content. This is the carrier for anything the account needs to do about the visitor: translate, put a request to a registered counterparty, carry the answer back.
-3. The account's public agent answers the visitor, if the account has one and has enabled it. If not, the visitor receives nothing at all, and steps 1 and 2 have already happened regardless.
+Nobody is told the visitor wrote. The platform used to notify the registered managers and to wake each of them with a relay turn; both were retired, because telling the operator a stranger wrote in is a scheduled routine's job. A routine chooses its own recipient, its own wording and its own transport, and an account that wants no such message simply does not run one.
 
 **The scheduler fires a due event.** This raises a `schedule` turn on the destination's own session, carrying the event's prompt.
 
@@ -1702,19 +1700,16 @@ Five things start or resume a WhatsApp session. They are distinguishable, and th
 
 ## Reading why you woke
 
-Every turn carries a `source`. Three values exist:
+Every turn carries a `source`. Two values exist:
 
 | `source` | Meaning |
 |---|---|
 | `user` | A real person sent this message to the line. Also the value when the field is absent. |
 | `schedule` | The scheduler wrote this turn. The named destination did not send it. |
-| `public-relay` | The platform wrote this turn because a public visitor messaged the account. The named sender is a manager being told, not someone who wrote to you. |
 
-**A `public-relay` turn is the one turn whose `## Instruction` block is the account's own.** Its body is `agents/admin/INSTRUCTION.md`, written by the account owner, and it is the only instruction that turn carries: no standing-rules block rides with it. Every other turn on this line, including one the owner sent from their own handset and one the scheduler wrote, takes the platform's own directive and never reads that file. If the file is empty the relay turn is refused outright, so the message is dropped and nobody is told. A public visitor's own turn reads its agent's file at `agents/<slug>/INSTRUCTION.md`, never the admin's.
+**A public visitor's turn is the one turn whose `## Instruction` block is the account's own.** Its body is `agents/<slug>/INSTRUCTION.md`, written by the account owner, where `<slug>` is the public agent answering. If that file is missing the turn is refused outright, so the visitor is not answered rather than being handed platform prose the account cannot edit. Every turn you authored, from your own handset or through the scheduler, takes the platform's own directive and never reads that file, so it can never be refused over a file it does not use.
 
-A `public-relay` turn also says so in its own first two lines, and states which handset its reply tool reaches. That handset is the manager's, never the visitor's: the turn runs in the manager's own admin session, so a reply written to the visitor is delivered to the manager. If a turn claims a manager wrote something they plainly would not have written, check the source before answering them.
-
-**On a `public-relay` turn the reply tool is the only way to reach anyone.** On an ordinary turn the platform forwards your closing text to the sender when you called no reply tool. On a relay-woken turn it does not, because the relay carries its own reply path. So whatever you decide the manager should receive has to go through the reply tool; text you merely write at the end of the turn reaches nobody, and a decision not to reply is silence rather than a message.
+On every turn on this line the platform forwards your closing text to the sender when you called no reply tool, so a turn that ends with an answer written but no tool called still reaches the person waiting.
 
 ## Which files compose the prompt
 
@@ -1725,25 +1720,22 @@ The system prompt is assembled per spawn from one agent directory, and **which d
 
 From that one directory it takes `IDENTITY.md` and `SOUL.md`, verbatim.
 
-The consequence catches people out: **an instruction written into `agents/admin/SOUL.md` is never read by a public spawn**, and an instruction written into a public agent's `SOUL.md` is never read by an admin turn. Before writing an instruction into a role file, decide which role will actually be running when it needs to apply. If the answer is "the admin agent, woken by a stranger's message", the file is `agents/admin/SOUL.md` and the trigger is the `public-relay` dispatch above.
+The consequence catches people out: **an instruction written into `agents/admin/SOUL.md` is never read by a public spawn**, and an instruction written into a public agent's `SOUL.md` is never read by an admin turn. Before writing an instruction into a role file, decide which role will actually be running when it needs to apply. A stranger's message wakes the public agent and nothing else, so an instruction meant to govern what happens when a stranger writes belongs in that agent's own files, never in `agents/admin/`.
 
 A public agent's directory also carries `KNOWLEDGE.md` and `config.json`. An account can hold as many public agents as it likes; only one is bound to WhatsApp at a time, and that binding is per account.
 
 ## The switches, and what each one stops
 
-Five settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
+Four settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
 
 | Setting | What it stops | What it leaves running |
 |---|---|---|
 | `dmPolicy: disabled` | Public senders are refused at the gate. | Admin and manager inbound. |
-| `publicAgentEnabled: false` | The visitor gets no reply. | The manager notification and the relay. |
-| `managerNotifyEnabled: false` | The verbatim copy of the visitor's message. | The relay, and any reply the woken turn sends. |
+| `publicAgentEnabled: false` | The visitor gets no reply. | Storage and labelling of what the visitor sent. |
 | `dispatchInbound: false` | Every agent turn on that account's socket. | Storage: messages are still stored and readable. |
-| `dispatch: false` on one registered party | The public-agent turn for that one phone. | Everything else: storage, the label, the manager notification, the relay, and every other sender on the line. |
-
-`managerNotifyEnabled` is the fine-grained one, and the one to reach for when the notifications are unwanted but the work is not. Unbinding a manager is not a substitute: the manager registry is shared by the notification, the relay and `whatsapp-notify-manager`, so unbinding silences all three.
+| `dispatch: false` on one registered party | The public-agent turn for that one phone. | Everything else: storage, the label, and every other sender on the line. |
 
-Read the current value with `whatsapp-config {action:'get-manager-notify-enabled'}` and set it with `set-manager-notify-enabled`. Both are scoped to the calling session's own account.
+None of these governs whether the operator hears about a visitor, because no setting does: that is a scheduled routine's job, and the way to stop it is to stop the routine. The manager registry is read by nothing on this path at all, so unbinding a manager changes nothing a visitor's message does.
 
 ## When the answer is not here
 
@@ -1753,16 +1745,14 @@ Read the current value with `whatsapp-config {action:'get-manager-notify-enabled
 [whatsapp:wire]         op=stanza          msgId=<id>
 [wa-notify]             op=eligible        msgId=<id> reason=<how the sender was admitted>
 [whatsapp:route]        op=routed          inboundId=<id> msgIds=<the stanzas this payload covers>
-[whatsapp:notify]       op=public-inbound  inboundId=<id> enabled=0|1 outcome=sent|failed|no-recipients|disabled
-[whatsapp:relay]        op=dispatch        inboundId=<id> outcome=sent|failed|no-recipients
 [whatsapp:party]        op=dispatch-decision  inboundId=<id> party=… dispatch=true|false spawned=0|1   (labelled senders only)
 [whatsapp:public-agent] op=route           inboundId=<id> enabled=… slug=… spawned=0|1
 [whatsapp:public-agent] op=spawn-ok | op=spawn-failed   inboundId=<id>
 ```
 
-Follow one inbound by its `inboundId`. That selects the last five lines and nothing else, however many visitors messaged in the same window. For the first two, read `msgIds=` off the `op=routed` line and grep one of those ids. Two greps rather than one, because the debouncer merges stanzas into a single routed payload and the two halves are keyed either side of that merge.
+Follow one inbound by its `inboundId`. That selects the last four lines and nothing else, however many visitors messaged in the same window. For the first two, read `msgIds=` off the `op=routed` line and grep one of those ids. Two greps rather than one, because the debouncer merges stanzas into a single routed payload and the two halves are keyed either side of that merge.
 
-Anything that failed carries the same id: the drop lines, `op=public-inbound-rejected`, `op=dispatch-rejected` and `op=spawn-failed`. Fewer lines than expected, with none of them a failure, means a step emitted nothing at all — which is what the standing audits below are for.
+Anything that failed carries the same id: the drop lines and `op=spawn-failed`. Fewer lines than expected, with none of them a failure, means a step emitted nothing at all — which is what the standing audits below are for.
 
 Do not try to follow an inbound by its sender. `sender=` appears on two of these lines, and the same visitor is a LID on `op=stanza` and an E.164 on `op=routed`, so no sender-based filter spans the merge.
 
@@ -1777,7 +1767,7 @@ op=startup-watch                  state=disposed
 
 The first-run dialog is answered for the session, and the watcher that guards against an *unanswered* one drops what it saw before that answer. `bufferCleared=false` means the confirm fired and the drop did not, which is the shape that killed a resumed spawn on 2026-08-01: the answered dialog's own footer stayed in the buffer, the replayed transcript slid past it, and the spawn was blocked by a line the agent itself had written the day before.
 
-Three standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `gap`, `relayGap` and `answerGap`, each of which counts a step that a routed inbound reached and the next one did not. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.
+Two standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `routed` against `answered`, so a visitor routed to an agent that never replied shows as `answerGap`. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.
 
 ---
 # Settings
@@ -3521,6 +3511,29 @@ render it through one `RoutineStatusDot`, which is what stops them drifting:
 | `cancelled`, `completed` | solid grey (`--text-tertiary`) | deliberately stopped or finished |
 | anything else, and `null` | grey ring, no fill | no reading taken |
 
+**The run recap.** Each card carries a history icon that opens that routine's
+run history; the detail modal's **Runs** button reaches the same view. A run
+shows what it sent — the message text itself, on the row and in full in the run
+dialog — and a run that finished having sent nothing says so, which is a
+different statement from a run whose outcome is not yet known. Both the routine
+list and the run list have a Refresh control, because a run is promoted from
+"accepted" to "finished" by a background sweep a couple of minutes later. The
+**Download all runs** file carries the message text as its last column, so an
+export of a customer-facing routine contains what was said to customers.
+
+The run's own dot answers a different question from the routine's:
+
+| run status | dot | meaning |
+|---|---|---|
+| `finished` | green (`--session-live`) | it ran and its output was seen |
+| `open`, `accepted`, `started` | activity (`--color-alias-status-activity`) | in flight, or accepted with nothing yet known |
+| `no-destination` | amber (`--color-alias-status-warning-solid`) | it had nowhere to send |
+| `failed` | red (`--color-alias-status-error-solid`) | the dispatch failed |
+| anything else, and `null` | grey ring, no fill | no reading taken |
+
+`app/routines/types.ts` holds both mappings and `RunStatusDot` is the only thing
+that paints the run one, so the row and the dialog cannot drift.
+
 The unrecognised case is a state of its own, never a fallback into green: `GET
 /api/admin/routines` projects `eventStatus` verbatim, so a value outside the set
 can reach the card at any time, and a stood-down routine showing green is a

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,15 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-08-02 (0.1.547)
+
+- A routine's past runs now read as cards showing status, channel and the message actually sent, with a refresh and a way back in. Runs with no captured output are flagged.
+- The separate notification and relay that fired when someone outside your team messaged you have been retired. The public agent's own reply is now the record, and the count of routed and answered messages comes from it.
+
+## 2026-08-02 (0.1.546)
+
+- When the assistant notifies you on a channel, the outcome of that notification is now recorded, so a message that never arrived can be traced rather than guessed at.
+
 ## 2026-08-02 (0.1.545)
 
 - The assistant is now instructed differently depending on whether you messaged it directly or the turn was relayed from someone outside your team, so your own standing rules no longer ride along on a relayed turn.

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

package/payload/platform/plugins/docs/references/admin-ui.md

@@ -126,6 +126,29 @@ render it through one `RoutineStatusDot`, which is what stops them drifting:
 | `cancelled`, `completed` | solid grey (`--text-tertiary`) | deliberately stopped or finished |
 | anything else, and `null` | grey ring, no fill | no reading taken |
 
+**The run recap.** Each card carries a history icon that opens that routine's
+run history; the detail modal's **Runs** button reaches the same view. A run
+shows what it sent — the message text itself, on the row and in full in the run
+dialog — and a run that finished having sent nothing says so, which is a
+different statement from a run whose outcome is not yet known. Both the routine
+list and the run list have a Refresh control, because a run is promoted from
+"accepted" to "finished" by a background sweep a couple of minutes later. The
+**Download all runs** file carries the message text as its last column, so an
+export of a customer-facing routine contains what was said to customers.
+
+The run's own dot answers a different question from the routine's:
+
+| run status | dot | meaning |
+|---|---|---|
+| `finished` | green (`--session-live`) | it ran and its output was seen |
+| `open`, `accepted`, `started` | activity (`--color-alias-status-activity`) | in flight, or accepted with nothing yet known |
+| `no-destination` | amber (`--color-alias-status-warning-solid`) | it had nowhere to send |
+| `failed` | red (`--color-alias-status-error-solid`) | the dispatch failed |
+| anything else, and `null` | grey ring, no fill | no reading taken |
+
+`app/routines/types.ts` holds both mappings and `RunStatusDot` is the only thing
+that paints the run one, so the row and the dialog cannot drift.
+
 The unrecognised case is a state of its own, never a fallback into green: `GET
 /api/admin/routines` projects `eventStatus` verbatim, so a value outside the set
 can reach the card at any time, and a stood-down routine showing green is a

package/payload/platform/plugins/docs/references/channel-wake-and-prompt.md

@@ -4,15 +4,13 @@ Two questions an agent cannot answer from inside itself, and both have caused re
 
 ## What wakes a session
 
-Five things start or resume a WhatsApp session. They are distinguishable, and the distinction matters, because two of them are written by the platform rather than by the person named as the sender.
+Four things start or resume a WhatsApp session. They are distinguishable, and the distinction matters, because one of them is written by the platform rather than by the person named as the sender.
 
 **An admin phone or an account manager messages the line.** This resumes that person's own admin session. There is no per-account admin session: the session id is a hash of the account plus the person, so one person messaging from two channels resumes one thread, and two managers on one account have two threads.
 
-**A public sender messages the line.** Three things follow, in this order, and each is independent of the ones after it.
+**A public sender messages the line.** One thing follows: the account's public agent answers the visitor, if the account has one and has enabled it. If not, the message is stored and labelled and the visitor receives nothing at all.
 
-1. The account's registered managers are notified, verbatim, unless the account has turned that off. This fires before any agent starts, so it survives a spawn that fails.
-2. Every bound manager's own admin session is woken with a `public-relay` turn carrying the sender's message as fenced content. This is the carrier for anything the account needs to do about the visitor: translate, put a request to a registered counterparty, carry the answer back.
-3. The account's public agent answers the visitor, if the account has one and has enabled it. If not, the visitor receives nothing at all, and steps 1 and 2 have already happened regardless.
+Nobody is told the visitor wrote. The platform used to notify the registered managers and to wake each of them with a relay turn; both were retired, because telling the operator a stranger wrote in is a scheduled routine's job. A routine chooses its own recipient, its own wording and its own transport, and an account that wants no such message simply does not run one.
 
 **The scheduler fires a due event.** This raises a `schedule` turn on the destination's own session, carrying the event's prompt.
 
@@ -20,19 +18,16 @@ Five things start or resume a WhatsApp session. They are distinguishable, and th
 
 ## Reading why you woke
 
-Every turn carries a `source`. Three values exist:
+Every turn carries a `source`. Two values exist:
 
 | `source` | Meaning |
 |---|---|
 | `user` | A real person sent this message to the line. Also the value when the field is absent. |
 | `schedule` | The scheduler wrote this turn. The named destination did not send it. |
-| `public-relay` | The platform wrote this turn because a public visitor messaged the account. The named sender is a manager being told, not someone who wrote to you. |
 
-**A `public-relay` turn is the one turn whose `## Instruction` block is the account's own.** Its body is `agents/admin/INSTRUCTION.md`, written by the account owner, and it is the only instruction that turn carries: no standing-rules block rides with it. Every other turn on this line, including one the owner sent from their own handset and one the scheduler wrote, takes the platform's own directive and never reads that file. If the file is empty the relay turn is refused outright, so the message is dropped and nobody is told. A public visitor's own turn reads its agent's file at `agents/<slug>/INSTRUCTION.md`, never the admin's.
+**A public visitor's turn is the one turn whose `## Instruction` block is the account's own.** Its body is `agents/<slug>/INSTRUCTION.md`, written by the account owner, where `<slug>` is the public agent answering. If that file is missing the turn is refused outright, so the visitor is not answered rather than being handed platform prose the account cannot edit. Every turn you authored, from your own handset or through the scheduler, takes the platform's own directive and never reads that file, so it can never be refused over a file it does not use.
 
-A `public-relay` turn also says so in its own first two lines, and states which handset its reply tool reaches. That handset is the manager's, never the visitor's: the turn runs in the manager's own admin session, so a reply written to the visitor is delivered to the manager. If a turn claims a manager wrote something they plainly would not have written, check the source before answering them.
-
-**On a `public-relay` turn the reply tool is the only way to reach anyone.** On an ordinary turn the platform forwards your closing text to the sender when you called no reply tool. On a relay-woken turn it does not, because the relay carries its own reply path. So whatever you decide the manager should receive has to go through the reply tool; text you merely write at the end of the turn reaches nobody, and a decision not to reply is silence rather than a message.
+On every turn on this line the platform forwards your closing text to the sender when you called no reply tool, so a turn that ends with an answer written but no tool called still reaches the person waiting.
 
 ## Which files compose the prompt
 
@@ -43,25 +38,22 @@ The system prompt is assembled per spawn from one agent directory, and **which d
 
 From that one directory it takes `IDENTITY.md` and `SOUL.md`, verbatim.
 
-The consequence catches people out: **an instruction written into `agents/admin/SOUL.md` is never read by a public spawn**, and an instruction written into a public agent's `SOUL.md` is never read by an admin turn. Before writing an instruction into a role file, decide which role will actually be running when it needs to apply. If the answer is "the admin agent, woken by a stranger's message", the file is `agents/admin/SOUL.md` and the trigger is the `public-relay` dispatch above.
+The consequence catches people out: **an instruction written into `agents/admin/SOUL.md` is never read by a public spawn**, and an instruction written into a public agent's `SOUL.md` is never read by an admin turn. Before writing an instruction into a role file, decide which role will actually be running when it needs to apply. A stranger's message wakes the public agent and nothing else, so an instruction meant to govern what happens when a stranger writes belongs in that agent's own files, never in `agents/admin/`.
 
 A public agent's directory also carries `KNOWLEDGE.md` and `config.json`. An account can hold as many public agents as it likes; only one is bound to WhatsApp at a time, and that binding is per account.
 
 ## The switches, and what each one stops
 
-Five settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
+Four settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
 
 | Setting | What it stops | What it leaves running |
 |---|---|---|
 | `dmPolicy: disabled` | Public senders are refused at the gate. | Admin and manager inbound. |
-| `publicAgentEnabled: false` | The visitor gets no reply. | The manager notification and the relay. |
-| `managerNotifyEnabled: false` | The verbatim copy of the visitor's message. | The relay, and any reply the woken turn sends. |
+| `publicAgentEnabled: false` | The visitor gets no reply. | Storage and labelling of what the visitor sent. |
 | `dispatchInbound: false` | Every agent turn on that account's socket. | Storage: messages are still stored and readable. |
-| `dispatch: false` on one registered party | The public-agent turn for that one phone. | Everything else: storage, the label, the manager notification, the relay, and every other sender on the line. |
-
-`managerNotifyEnabled` is the fine-grained one, and the one to reach for when the notifications are unwanted but the work is not. Unbinding a manager is not a substitute: the manager registry is shared by the notification, the relay and `whatsapp-notify-manager`, so unbinding silences all three.
+| `dispatch: false` on one registered party | The public-agent turn for that one phone. | Everything else: storage, the label, and every other sender on the line. |
 
-Read the current value with `whatsapp-config {action:'get-manager-notify-enabled'}` and set it with `set-manager-notify-enabled`. Both are scoped to the calling session's own account.
+None of these governs whether the operator hears about a visitor, because no setting does: that is a scheduled routine's job, and the way to stop it is to stop the routine. The manager registry is read by nothing on this path at all, so unbinding a manager changes nothing a visitor's message does.
 
 ## When the answer is not here
 
@@ -71,16 +63,14 @@ Read the current value with `whatsapp-config {action:'get-manager-notify-enabled
 [whatsapp:wire]         op=stanza          msgId=<id>
 [wa-notify]             op=eligible        msgId=<id> reason=<how the sender was admitted>
 [whatsapp:route]        op=routed          inboundId=<id> msgIds=<the stanzas this payload covers>
-[whatsapp:notify]       op=public-inbound  inboundId=<id> enabled=0|1 outcome=sent|failed|no-recipients|disabled
-[whatsapp:relay]        op=dispatch        inboundId=<id> outcome=sent|failed|no-recipients
 [whatsapp:party]        op=dispatch-decision  inboundId=<id> party=… dispatch=true|false spawned=0|1   (labelled senders only)
 [whatsapp:public-agent] op=route           inboundId=<id> enabled=… slug=… spawned=0|1
 [whatsapp:public-agent] op=spawn-ok | op=spawn-failed   inboundId=<id>
 ```
 
-Follow one inbound by its `inboundId`. That selects the last five lines and nothing else, however many visitors messaged in the same window. For the first two, read `msgIds=` off the `op=routed` line and grep one of those ids. Two greps rather than one, because the debouncer merges stanzas into a single routed payload and the two halves are keyed either side of that merge.
+Follow one inbound by its `inboundId`. That selects the last four lines and nothing else, however many visitors messaged in the same window. For the first two, read `msgIds=` off the `op=routed` line and grep one of those ids. Two greps rather than one, because the debouncer merges stanzas into a single routed payload and the two halves are keyed either side of that merge.
 
-Anything that failed carries the same id: the drop lines, `op=public-inbound-rejected`, `op=dispatch-rejected` and `op=spawn-failed`. Fewer lines than expected, with none of them a failure, means a step emitted nothing at all — which is what the standing audits below are for.
+Anything that failed carries the same id: the drop lines and `op=spawn-failed`. Fewer lines than expected, with none of them a failure, means a step emitted nothing at all — which is what the standing audits below are for.
 
 Do not try to follow an inbound by its sender. `sender=` appears on two of these lines, and the same visitor is a LID on `op=stanza` and an E.164 on `op=routed`, so no sender-based filter spans the merge.
 
@@ -95,4 +85,4 @@ op=startup-watch                  state=disposed
 
 The first-run dialog is answered for the session, and the watcher that guards against an *unanswered* one drops what it saw before that answer. `bufferCleared=false` means the confirm fired and the drop did not, which is the shape that killed a resumed spawn on 2026-08-01: the answered dialog's own footer stayed in the buffer, the replayed transcript slid past it, and the spawn was blocked by a line the agent itself had written the day before.
 
-Three standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `gap`, `relayGap` and `answerGap`, each of which counts a step that a routed inbound reached and the next one did not. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.
+Two standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `routed` against `answered`, so a visitor routed to an agent that never replied shows as `answerGap`. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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

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

@@ -180,6 +180,17 @@ process.on("exit", (code) => {
         `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
 });
 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
+// entry loads. The shim is meant to be transparent: an entry that asks the
+// standard "am I the entry module?" question
+// (`import.meta.url === pathToFileURL(realpathSync(process.argv[1])).href`)
+// must get the same answer it gets when Claude Code runs it without the shim.
+// With the shim's own path left in argv[1] the answer is no, so such an entry
+// loads, starts nothing, and exits 0 — measured on the three channel servers,
+// which all gate main() that way. Plugin MCPs connect at module top level and
+// never read argv, so this is inert for them. ENTRY was captured above, before
+// the rewrite. Extra CLI args keep their positions after the entry slot.
+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