@rubytech/create-maxy-code 0.1.546 → 0.1.548

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:db7c14326a115e7d05b687b72bef0ba3892f1614ee46484e0e90414bf2c16f27
 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
@@ -3494,13 +3484,27 @@ The Routines surface (`/routines`) is the admin view of the account's
 automation `:Event` nodes — the device's scheduled agent turns and tool
 dispatches, which the Calendar surface deliberately excludes (`calendar.ts`
 unions only appointment events, `actionPlugin IS NULL`). It renders one card per
-routine (title, the roster's one-sentence description where the routine has one,
-human-readable schedule, next run, channel/destination or tool, status); a card
-opens a detail modal modeled on the calendar `EventDetailModal`. The description
-is roster-owned: the seed is its only writer, `GET /api/admin/routines` projects
-it read-only, and the PATCH route refuses it, so an operator-created routine has
-none and its card renders with no line and no placeholder.
-The modal edits the prose instruction (`agentPrompt`), the dispatch binding
+routine (title, its one-line description where it has one, human-readable
+schedule, next run, channel/destination or tool, status); a card opens a detail
+modal modeled on the calendar `EventDetailModal`. A shipped routine is seeded with
+a description and the operator can rewrite it from the modal; a routine nobody has
+captioned renders with no line and no placeholder. Editing it stamps the row
+operator-owned, so the next roster refresh leaves the operator's wording alone,
+and recomputes the row's search vector, which is built from the name and the
+description. A description is never dispatched: `agentPrompt` is the only text a
+fire sends.
+The read-only view shows two prose blocks, each under its own heading, in the
+order **Description** then **Instruction sent to the agent**. Both use the same
+header-above-prose shape, so neither reads as a different kind of thing from the
+other. Before this the modal showed one unheaded block, so the caption and the
+multi-KB prompt that actually fires were indistinguishable. The instruction
+heading never reads the bare word "Instruction", in either mode: that collides
+with the `## Instruction` block the platform appends to every dispatched channel
+turn, and an agent read the two as the same field. The Description block renders
+on every kind of routine, including a tool-action routine and a bare trigger,
+because both already show it on the card; the instruction block belongs to an
+agent routine, the only kind that has one. The modal edits the description, the
+prose instruction (`agentPrompt`), the dispatch binding
 (`agentChannel` and `agentDestination`, chosen from a server-supplied roster
 rather than typed), and the schedule via a friendly builder (frequency
 daily/weekly/monthly, day-of-week, day-of-month, time) that falls back to a
@@ -3521,6 +3525,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
@@ -3538,7 +3565,7 @@ The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.t
 | `GET /api/admin/routines/:eventId` | One routine, same automation+account guard. |
 | `GET /api/admin/routines/:eventId/runs` | One routine's `:RoutineRun` history, newest first. `limit` clamps to 1..500 and defaults to 50, so a caller that wants the full page must ask for it. |
 | `GET /api/admin/routines/:eventId/runs.csv` | The same projection as a `text/csv` attachment with `Content-Disposition`, and **no** limit, so it is not the same row set as a clamped `/runs` call. Re-parses its own output and returns 500 rather than serving a document with fewer rows than the query returned. Zero rows is 404, not a header-only file: the query cannot tell a routine with no runs from an `eventId` on another account. |
-| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `recurrence`, and the `agentChannel`/`agentDestination` pair. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `description`, `recurrence`, and the `agentChannel`/`agentDestination` pair. A `description` write stamps `operatorEdited` and recomputes the row's `embedding` from `Event: <name>` plus the new text, reading the name from the row rather than the request body; the embedder returning nothing leaves the previous vector in place and the save still succeeds. A whitespace-only `description` is stored as null, so "no caption" is one state in the graph. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
 | `GET /api/admin/dispatch-destinations` | Every destination the session's account may bind a routine to, across both channels, each labelled by the authoritative list it came from (`House admin`, `Account manager`, `Telegram admin`), plus an optional `name`: a display-only person name resolved from `:Person` in the row's own account scope — the house for a `House admin` row, the managed sub-account for an `Account manager` row, and never for Telegram, whose destinations are chat ids. Computed from the same lists the validator reads and filtered by the same rule, so the picker cannot offer what the save refuses; `name` is never part of what Save posts, and a graph outage returns an unnamed roster rather than an error. |
 | `POST /api/admin/routines/:eventId/suspend` | Writes `eventStatus = 'suspended'` on a routine currently `'scheduled'`. 404s otherwise, so a second suspend is not a silent no-op. |
 | `POST /api/admin/routines/:eventId/resume` | Returns a suspended routine to `'scheduled'`. 404s if it is not suspended, 409s if it cannot be resumed. |
@@ -3619,6 +3646,24 @@ would say so. `completed` gets its own bucket even though no code path writes it
 today, because it remains part of the shipped enum and one row carrying it would
 otherwise pin `other` above zero forever and kill the alarm.
 
+`[schedule-audit] op=description-coverage acct=<8> routines=<n>
+withDescription=<n> withInstruction=<n> toolActions=<n>` is the pair behind the
+two prose blocks the modal shows. A routine carrying an instruction and no
+description is a card whose title is all the operator gets; one carrying a
+description and no instruction is worse, because it looks explained, fires on
+schedule and sends nothing. Neither state writes an event of its own, so only a
+periodic count reveals them, and the counts sit on one line beside the total
+because any one of them alone answers the wrong question. `toolActions` is on the
+line because `withInstruction` is otherwise comparable to nothing: a tool-action
+routine has no instruction and is not silent, it runs a tool, so an account
+holding one would sit at `routines > withInstruction` for ever and the alarm
+would be dead from that point on. The genuinely silent count is `routines -
+toolActions - withInstruction`, the same reconciliation `other` performs in the
+suspension census. Emitted per account on every sweep tick including a healthy
+one, over the same automation set the routes list. The roster seed's own
+`descNull` counter is its narrow twin, scoped to seeded rows and so blind to
+exactly the operator-created ones most likely to carry no caption.
+
 **The shipped roster.** Every account starts with eleven routines —
 `start-of-day`, `inbound-check`, `end-of-day`, `appointment-reminder`,
 `commitment-chase`, `calendar-reconcile`, `contact-reconcile`, `crm-reconcile`,

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

@@ -9,6 +9,17 @@ 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.548)
+
+- Telegram now works per account: each bot has its own address and secret, a scheduled message goes to the right account, and a check reports any bot that is set up but never delivers.
+- Every WhatsApp reply and document send now names the account it belongs to, and a send whose account does not match its conversation is refused.
+- Each turn now records how much the assistant actually had to work with, so a turn that came back thin can be told apart from one that failed.
+
+## 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.

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

@@ -99,13 +99,27 @@ The Routines surface (`/routines`) is the admin view of the account's
 automation `:Event` nodes — the device's scheduled agent turns and tool
 dispatches, which the Calendar surface deliberately excludes (`calendar.ts`
 unions only appointment events, `actionPlugin IS NULL`). It renders one card per
-routine (title, the roster's one-sentence description where the routine has one,
-human-readable schedule, next run, channel/destination or tool, status); a card
-opens a detail modal modeled on the calendar `EventDetailModal`. The description
-is roster-owned: the seed is its only writer, `GET /api/admin/routines` projects
-it read-only, and the PATCH route refuses it, so an operator-created routine has
-none and its card renders with no line and no placeholder.
-The modal edits the prose instruction (`agentPrompt`), the dispatch binding
+routine (title, its one-line description where it has one, human-readable
+schedule, next run, channel/destination or tool, status); a card opens a detail
+modal modeled on the calendar `EventDetailModal`. A shipped routine is seeded with
+a description and the operator can rewrite it from the modal; a routine nobody has
+captioned renders with no line and no placeholder. Editing it stamps the row
+operator-owned, so the next roster refresh leaves the operator's wording alone,
+and recomputes the row's search vector, which is built from the name and the
+description. A description is never dispatched: `agentPrompt` is the only text a
+fire sends.
+The read-only view shows two prose blocks, each under its own heading, in the
+order **Description** then **Instruction sent to the agent**. Both use the same
+header-above-prose shape, so neither reads as a different kind of thing from the
+other. Before this the modal showed one unheaded block, so the caption and the
+multi-KB prompt that actually fires were indistinguishable. The instruction
+heading never reads the bare word "Instruction", in either mode: that collides
+with the `## Instruction` block the platform appends to every dispatched channel
+turn, and an agent read the two as the same field. The Description block renders
+on every kind of routine, including a tool-action routine and a bare trigger,
+because both already show it on the card; the instruction block belongs to an
+agent routine, the only kind that has one. The modal edits the description, the
+prose instruction (`agentPrompt`), the dispatch binding
 (`agentChannel` and `agentDestination`, chosen from a server-supplied roster
 rather than typed), and the schedule via a friendly builder (frequency
 daily/weekly/monthly, day-of-week, day-of-month, time) that falls back to a
@@ -126,6 +140,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
@@ -143,7 +180,7 @@ The route (`server/routes/admin/routines.ts`) is account-scoped like `calendar.t
 | `GET /api/admin/routines/:eventId` | One routine, same automation+account guard. |
 | `GET /api/admin/routines/:eventId/runs` | One routine's `:RoutineRun` history, newest first. `limit` clamps to 1..500 and defaults to 50, so a caller that wants the full page must ask for it. |
 | `GET /api/admin/routines/:eventId/runs.csv` | The same projection as a `text/csv` attachment with `Content-Disposition`, and **no** limit, so it is not the same row set as a clamped `/runs` call. Re-parses its own output and returns 500 rather than serving a document with fewer rows than the query returned. Zero rows is 404, not a header-only file: the query cannot tell a routine with no runs from an `eventId` on another account. |
-| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `recurrence`, and the `agentChannel`/`agentDestination` pair. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
+| `PATCH /api/admin/routines/:eventId` | Edits `agentPrompt`, `description`, `recurrence`, and the `agentChannel`/`agentDestination` pair. A `description` write stamps `operatorEdited` and recomputes the row's `embedding` from `Event: <name>` plus the new text, reading the name from the row rather than the request body; the embedder returning nothing leaves the previous vector in place and the save still succeeds. A whitespace-only `description` is stored as null, so "no caption" is one state in the graph. Cron validation and the timezone-aware `nextRun` recompute copy the scheduling plugin's `schedule-update` tool. The binding is revalidated against the same house-authority rule, shared as `platform/lib/agent-dispatch-rule`; it is refused `partial-binding`, `invalid-channel`, `no-prompt`, `not-registered`, `cross-account`, `action-routine` (a routine that runs a tool keeps it — an agent binding outranks the action at fire time) or `clear-would-orphan` (clearing the only field holding a one-time routine inside the automation filter would hide it from every routines surface), and no refusal writes. Both fields as `null` clears the binding. An invalid cron is rejected 400 with no write. Only creation and deletion stay agent-only (`schedule-event`/`schedule-cancel`). |
 | `GET /api/admin/dispatch-destinations` | Every destination the session's account may bind a routine to, across both channels, each labelled by the authoritative list it came from (`House admin`, `Account manager`, `Telegram admin`), plus an optional `name`: a display-only person name resolved from `:Person` in the row's own account scope — the house for a `House admin` row, the managed sub-account for an `Account manager` row, and never for Telegram, whose destinations are chat ids. Computed from the same lists the validator reads and filtered by the same rule, so the picker cannot offer what the save refuses; `name` is never part of what Save posts, and a graph outage returns an unnamed roster rather than an error. |
 | `POST /api/admin/routines/:eventId/suspend` | Writes `eventStatus = 'suspended'` on a routine currently `'scheduled'`. 404s otherwise, so a second suspend is not a silent no-op. |
 | `POST /api/admin/routines/:eventId/resume` | Returns a suspended routine to `'scheduled'`. 404s if it is not suspended, 409s if it cannot be resumed. |
@@ -224,6 +261,24 @@ would say so. `completed` gets its own bucket even though no code path writes it
 today, because it remains part of the shipped enum and one row carrying it would
 otherwise pin `other` above zero forever and kill the alarm.
 
+`[schedule-audit] op=description-coverage acct=<8> routines=<n>
+withDescription=<n> withInstruction=<n> toolActions=<n>` is the pair behind the
+two prose blocks the modal shows. A routine carrying an instruction and no
+description is a card whose title is all the operator gets; one carrying a
+description and no instruction is worse, because it looks explained, fires on
+schedule and sends nothing. Neither state writes an event of its own, so only a
+periodic count reveals them, and the counts sit on one line beside the total
+because any one of them alone answers the wrong question. `toolActions` is on the
+line because `withInstruction` is otherwise comparable to nothing: a tool-action
+routine has no instruction and is not silent, it runs a tool, so an account
+holding one would sit at `routines > withInstruction` for ever and the alarm
+would be dead from that point on. The genuinely silent count is `routines -
+toolActions - withInstruction`, the same reconciliation `other` performs in the
+suspension census. Emitted per account on every sweep tick including a healthy
+one, over the same automation set the routes list. The roster seed's own
+`descNull` counter is its narrow twin, scoped to seeded rows and so blind to
+exactly the operator-created ones most likely to carry no caption.
+
 **The shipped roster.** Every account starts with eleven routines —
 `start-of-day`, `inbound-check`, `end-of-day`, `appointment-reminder`,
 `commitment-chase`, `calendar-reconcile`, `contact-reconcile`, `crm-reconcile`,

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/scheduling/PLUGIN.md

@@ -204,6 +204,12 @@ Use standard 5-field cron syntax: `minute hour day-of-month month day-of-week`.
 | `0 0 1 * *` | First of each month at midnight |
 | `*/30 * * * *` | Every 30 minutes |
 
+## What an update confirms
+
+`schedule-update` returns the properties it wrote: `Event updated: <id> — fields: description, recurrence`. Companions count — changing `recurrence` also writes `nextRun`, changing `eventStatus` also writes `suspendedInBulk`, and setting an `agentDispatch` also clears `actionPlugin`, `actionTool` and `actionArgs`. Four properties are never named: `updatedAt` and `operatorEdited` are stamps, `embedding` is a derived search vector, and `notes` is reported as `note appended` instead, and only when the caller supplied one that was not empty.
+
+When `agentPrompt` is not among the fields, the line ends `(the instruction sent to the agent was not changed)`. That clause is the answer to "did my prompt rewrite land" — a confirmation without it means the dispatch prompt was written. Editing a meeting opens `Meeting updated:` and names the caller's own field names, not the stored `title`/`startsAt`/`endsAt`.
+
 ## Skip next
 
 For recurring events, `schedule-update` with `skipNext: true` advances `nextRun` by one cycle without triggering. Use when the user says "skip tomorrow's briefing" or similar.

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

@@ -7,6 +7,7 @@ import { scheduleList } from "./tools/schedule-list.js";
 import { scheduleGet } from "./tools/schedule-get.js";
 import { scheduleRuns } from "./tools/schedule-runs.js";
 import { scheduleUpdate, EVENT_STATUSES } from "./tools/schedule-update.js";
+import { describeUpdate } from "./lib/update-summary.js";
 import { scheduleCancel } from "./tools/schedule-cancel.js";
 import { scheduleExportIcs } from "./tools/schedule-export-ics.js";
 import { scheduleImportIcs } from "./tools/schedule-import-ics.js";
@@ -328,11 +329,14 @@ eagerTool(server, "schedule-update", "Update an event's properties or append a n
     if (!accountId)
         return refuseNoAccount("schedule-update");
     try {
-        await scheduleUpdate({ ...params, accountId });
+        const written = await scheduleUpdate({ ...params, accountId });
         if (params.skipNext) {
             return { content: [{ type: "text", text: `Skipped next occurrence of event: ${params.eventId}` }] };
         }
-        return { content: [{ type: "text", text: `Event updated: ${params.eventId}` }] };
+        // Task 2362 — name the properties written. The flat `Event updated: <id>` this replaced read
+        // identically for a description edit and for a dispatch-prompt rewrite, and an agent read it
+        // as proof its own successful rewrite had not landed.
+        return { content: [{ type: "text", text: describeUpdate(params.eventId, written) }] };
     }
     catch (err) {
         return {