@rubytech/create-maxy-code 0.1.563 → 0.1.565

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.563",
+  "version": "0.1.565",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

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

@@ -274,8 +274,8 @@ Tools are available via the `admin` MCP server.
 - `hooks/quote-render-pdf-conformance.sh` — **PostToolUse matcher=`mcp__plugin_browser_browser__browser-pdf-save`.** The PDF-time companion to the PreToolUse `quote-render-gate`: the HTML gates run inside `quote-render` before the receipt, but the two PDF-only conformance checks cannot, because the PDF does not exist until `browser-pdf-save` runs. For a gated client-quote PDF (`memory/users/<phone>/documents/quote-<jobId>.pdf` or `…-breakdown.pdf`) whose render receipt names the source HTML, it blocks (exit 2) when the printed PDF's `/URI` annotation count is below the source HTML's absolute-link count (a rasterised or flattened print that dropped links) or when an embedded `https://` link does not answer 200 (a Sign-Online link a pending redeploy would 404). The offline `/URI`-count check runs first and short-circuits, so a link-loss regression never depends on the network. **Block message:** `Blocked: the printed quote PDF is missing links the document declared, or an embedded link is not live (…). Do not send it. If a Sign-Online link is not live yet, deploy the signing page first; then re-render and re-print so the PDF carries every link the document declares.` **Log line** (stderr, on a block): `[quote-render] op=bypass jobId=<jobId> reason=pdf-link-conformance detail=<uri-count …|link <url> -> <code>>`. Every non-quote PDF, and any call with no receipt (the PreToolUse gate owns that block), passes at exit 0. **Fail-open** on an uninspectable call (tty / empty stdin / no `python3` / receipt or PDF absent). **Reach on upgrade:** `provision-account-dir.sh` writes this PostToolUse matcher only at account-provision time, so accounts provisioned before it landed keep a stale matcher and need a settings backfill (tracked as a follow-up task), the same reach limit the AskUserQuestion carrier gate hit.
 - `hooks/webfetch-preflight.mjs` — short-circuits WebFetch on JS-SPA shells with a structured `WEBFETCH_CANNOT_READ_JS_SPA` error so the agent surfaces a loud failure to the owner instead of paying the 60s extraction timeout. Fail-open on any internal error.
 - `hooks/askuserquestion-investigate-gate.sh` — PreToolUse matcher=`AskUserQuestion`. Blocks the question (exit 2) when no read-only investigation tool has fired since the latest real user turn in the session JSONL. The structural fix for the failure class where the agent fabricates a menu before evidence-gathering (session `c085ec2c-46fb-4b73-8865-68cf85866ea8` 2026-05-22 — "change remote access password" → invented options "Admin PIN / Cloudflare tunnel / WiFi password" with zero prior tool_use; post-correction the agent immediately fired `remote-auth-status` → `ToolSearch` → `remote-auth-set-password`, proving it knew the moves). **Allowlist** (exact, with trailing `__<tool>` suffix-match for namespaced `mcp__plugin_<plugin>_<server>__<tool>` aliases): `ToolSearch`, `Grep`, `Glob`, `Read`, `LS`, `NotebookRead`, `Bash`, `WebFetch`, `WebSearch`, plus the read-only admin / memory MCP tools (`*-status`, `*-list`, `*-read`, `skill-find`, `memory-find-candidates`, `profile-read`, `conversation-list`, `memory-list-attachments`, `memory-read-attachment`). **Block message:** `Blocked: AskUserQuestion requires at least one investigation tool (ToolSearch, Grep, Read, *-list, *-status, *-read, skill-find, ...) earlier in this turn. Search the operator's literal phrase first.` **Log line** (stderr, one per call): `[ask-gate] decision=<allow|block> sessionId=<id8> seen=<csv|-> reason=<allowlist-hit|no-investigation|fail-open-no-transcript|fail-open-parse-error>`. **Fail-open** on missing transcript or parse error — nudges, never bricks the UI.
-- `hooks/askuserquestion-channel-carrier-gate.sh` — PreToolUse matcher=`AskUserQuestion`, registered as a **second command on the same matcher** as the investigate-gate (either exit 2 blocks; the two guard different conditions). Blocks the question (exit 2) when the session has a native channel attached, because the Claude Code channel protocol carries only the two permission methods — there is no carrier for the `AskUserQuestion` elicitation, so on an rc-spawn channel (webchat/WhatsApp/Telegram) session the harness would block the turn awaiting a selection that can never arrive and the reader renders only delivered replies, wedging the turn (live SiteDesk incident session `1a085718` 2026-07-11: `/chat` stalled on the delivered "On it…" ack with no card). **Signal:** the rc-spawn writes the channel MCP registration as a config file in `os.tmpdir()` keyed by session id (`maxy-channel-<sid>.json` / `maxy-webchat-channel-<sid>.json` / `maxy-wa-channel-<sid>.json` / `maxy-telegram-channel-<sid>.json`, `sid` sanitized `[^A-Za-z0-9_-]→_` exactly as the writers do); its presence at tool-call time is the authoritative "channel attached to this session" marker. The hook resolves the tmpdir the way Node's `os.tmpdir()` does (`${TMPDIR:-/tmp}`, trailing slash stripped). Correct in both readings of the claude.ai/code scoping question: a Pi channel process sees the tmpfile (block); a claude.ai/code process on another host never sees the Pi tmpfile (fail-open → allow, that surface can answer the card). **Block message:** `Blocked: this is a native-channel session and AskUserQuestion cannot be delivered over a channel (the channel protocol carries no elicitation card, so the turn would wedge). Ask the same question as prose in your channel reply tool and wait for the operator's next message.` **Log line** (stderr, one per decisive call): `[ask-channel] decision=<allow|block> sessionId=<id8> channel=<attached|none> reason=<channel-attached|no-channel|fail-open-no-envelope|fail-open-no-session>`. **Fail-open** on no envelope, blank session id, or absent channel file — nudges, never bricks the UI. The complementary standing check (`interactive-wedge` in the session manager) catches any un-carried interactive tool_use that slips past this hook; it scans every account's project-slug (not just the boot slug), so a client sub-account channel wedge is covered too. **Reach on upgrade:** `provision-account-dir.sh` writes this matcher only at account-provision time, and the upgrade path re-provisions only the house account — so an account provisioned before this gate landed keeps a stale matcher and re-wedges (live SiteDesk recurrence session `d39a22b0`, account `2078cb54`, 2026-07-15). `setup-account.sh` runs `reconcile_all_accounts_askgate` (`platform/scripts/lib/account-settings-askgate.sh`) on every install to retrofit the carrier gate onto every existing account's `settings.json` — idempotent surgical jq patch of the `AskUserQuestion` matcher, one `[backfill-1683] file=<f> status=<absent|no-hooks|already-set|updated|rewrite-failed>` line per account, contents never echoed.
-- `hooks/public-tool-surface.sh` — **PreToolUse matcher-less (every tool) + UserPromptSubmit + Stop.** Records the tool surface a `role='public'` spawn REALISES, which nothing recorded before: `tool-allowlist` records the surface a spawn was given, and `[public-surface] op=audit` reconciles MCP server names from spawn-tee filenames, so it is blind to `Read`, `Bash`, `Skill` and `ToolSearch` (no MCP child, no tee file). On 2026-08-01 five such tools ran in a session spawned with `--allowed-tools mcp__whatsapp-channel__reply --strict-mcp-config --permission-mode dontAsk` and produced no line. **Input:** `MAXY_PUBLIC_ALLOWED_TOOLS`, stamped by both spawn paths (`http-server.ts` rc-spawn, `pty-spawner.ts`) for `role='public'` only, carrying that spawn's final `--allowed-tools` argv set comma-joined. Absent means not a public spawn: the hook exits 0 in silence. **Log lines** (server.log only — a visitor's PTY gains no output): `[public-surface] op=tool-realised sessionId=<id8> tool=<name> allowed=<y|n>` per call, `allowed` being exact membership of the stamped set; `[public-surface] op=realised-census sessionId=<id8> calls=<n> disallowed=<n>` at Stop, emitted including zero so a session with no disallowed call is distinguishable from one the hook never saw. Per-call tallies are appends to `<logdir>/public-surface/<sanitised-session-id>`, removed by the census, so no counter mutex is needed. The `UserPromptSubmit` registration is the turn-start reset and emits nothing: the stuck-turn recycler kills a wedged PTY and resumes the SAME session id, so that turn's `Stop` never fires and its tally would otherwise be counted into the next turn's census (measured: three calls in a killed turn plus one call in the next reported `calls=4 disallowed=3`). **Never blocks:** exit 0 on every path, including unparseable stdin, absent `session_id`, missing `python3` and an unwritable log. **Reach on upgrade:** `provision-account-dir.sh` writes both entries only at account-provision time, so `setup-account.sh` runs `reconcile_all_accounts_public_surface` (`platform/scripts/lib/account-settings-public-surface.sh`) on every install to retrofit them onto every existing account, one `[backfill-2339] file=<f> status=<absent|no-hooks|already-set|updated|rewrite-failed>` line per account, contents never echoed.
+- `hooks/askuserquestion-channel-carrier-gate.sh` — PreToolUse matcher=`AskUserQuestion`, registered as a **second command on the same matcher** as the investigate-gate (either exit 2 blocks; the two guard different conditions). Blocks the question (exit 2) when the session has a native channel attached, because the Claude Code channel protocol carries only the two permission methods — there is no carrier for the `AskUserQuestion` elicitation, so on an rc-spawn channel (webchat/WhatsApp/Telegram) session the harness would block the turn awaiting a selection that can never arrive and the reader renders only delivered replies, wedging the turn (live SiteDesk incident session `1a085718` 2026-07-11: `/chat` stalled on the delivered "On it…" ack with no card). **Signal:** the rc-spawn writes the channel MCP registration as a config file in `os.tmpdir()` keyed by session id (`maxy-channel-<sid>.json` / `maxy-webchat-channel-<sid>.json` / `maxy-wa-channel-<sid>.json` / `maxy-telegram-channel-<sid>.json`, `sid` sanitized `[^A-Za-z0-9_-]→_` exactly as the writers do); its presence at tool-call time is the authoritative "channel attached to this session" marker. The hook resolves the tmpdir the way Node's `os.tmpdir()` does (`${TMPDIR:-/tmp}`, trailing slash stripped). Correct in both readings of the claude.ai/code scoping question: a Pi channel process sees the tmpfile (block); a claude.ai/code process on another host never sees the Pi tmpfile (fail-open → allow, that surface can answer the card). **Block message:** `Blocked: this is a native-channel session and AskUserQuestion cannot be delivered over a channel (the channel protocol carries no elicitation card, so the turn would wedge). Ask the same question as prose in your answer and wait for the operator's next message.` **Log line** (stderr, one per decisive call): `[ask-channel] decision=<allow|block> sessionId=<id8> channel=<attached|none> reason=<channel-attached|no-channel|fail-open-no-envelope|fail-open-no-session>`. **Fail-open** on no envelope, blank session id, or absent channel file — nudges, never bricks the UI. The complementary standing check (`interactive-wedge` in the session manager) catches any un-carried interactive tool_use that slips past this hook; it scans every account's project-slug (not just the boot slug), so a client sub-account channel wedge is covered too. **Reach on upgrade:** `provision-account-dir.sh` writes this matcher only at account-provision time, and the upgrade path re-provisions only the house account — so an account provisioned before this gate landed keeps a stale matcher and re-wedges (live SiteDesk recurrence session `d39a22b0`, account `2078cb54`, 2026-07-15). `setup-account.sh` runs `reconcile_all_accounts_askgate` (`platform/scripts/lib/account-settings-askgate.sh`) on every install to retrofit the carrier gate onto every existing account's `settings.json` — idempotent surgical jq patch of the `AskUserQuestion` matcher, one `[backfill-1683] file=<f> status=<absent|no-hooks|already-set|updated|rewrite-failed>` line per account, contents never echoed.
+- `hooks/public-tool-surface.sh` — **PreToolUse matcher-less (every tool) + UserPromptSubmit + Stop.** Records the tool surface a `role='public'` spawn REALISES, which nothing recorded before: `tool-allowlist` records the surface a spawn was given, and `[public-surface] op=audit` reconciles MCP server names from spawn-tee filenames, so it is blind to `Read`, `Bash`, `Skill` and `ToolSearch` (no MCP child, no tee file). On 2026-08-01 five such tools ran in a session spawned with `--allowed-tools mcp__whatsapp-channel__reply --strict-mcp-config --permission-mode dontAsk` (that reply tool is now retired; a public spawn's allowlist is the deny-basis anchor alone) and produced no line. **Input:** `MAXY_PUBLIC_ALLOWED_TOOLS`, stamped by both spawn paths (`http-server.ts` rc-spawn, `pty-spawner.ts`) for `role='public'` only, carrying that spawn's final `--allowed-tools` argv set comma-joined. Absent means not a public spawn: the hook exits 0 in silence. **Log lines** (server.log only — a visitor's PTY gains no output): `[public-surface] op=tool-realised sessionId=<id8> tool=<name> allowed=<y|n>` per call, `allowed` being exact membership of the stamped set; `[public-surface] op=realised-census sessionId=<id8> calls=<n> disallowed=<n>` at Stop, emitted including zero so a session with no disallowed call is distinguishable from one the hook never saw. Per-call tallies are appends to `<logdir>/public-surface/<sanitised-session-id>`, removed by the census, so no counter mutex is needed. The `UserPromptSubmit` registration is the turn-start reset and emits nothing: the stuck-turn recycler kills a wedged PTY and resumes the SAME session id, so that turn's `Stop` never fires and its tally would otherwise be counted into the next turn's census (measured: three calls in a killed turn plus one call in the next reported `calls=4 disallowed=3`). **Never blocks:** exit 0 on every path, including unparseable stdin, absent `session_id`, missing `python3` and an unwritable log. **Reach on upgrade:** `provision-account-dir.sh` writes both entries only at account-provision time, so `setup-account.sh` runs `reconcile_all_accounts_public_surface` (`platform/scripts/lib/account-settings-public-surface.sh`) on every install to retrofit them onto every existing account, one `[backfill-2339] file=<f> status=<absent|no-hooks|already-set|updated|rewrite-failed>` line per account, contents never echoed.
 - `hooks/mcp-tool-missing.sh` — **PostToolUse hook on `mcp__.*` (directive 3).** Defence-in-depth for the `No such tool available: mcp__…` failure class that the name-binding is built to eliminate. Fires on any MCP tool call; no-op unless the `tool_response` carries `No such tool available` AND the qualified name resolves to a maxy plugin (read from the generated `hooks/lib/maxy-mcp-plugins.txt`). On a maxy match it logs one deterministic `[mcp-tool-missing] server=<server> tool=<tool>` line and exits 2 with a fixed envelope on stderr, so the agent relays a named server-unavailable failure instead of narrating "warming up" or blind-retrying. A missing non-maxy bridge tool (Playwright etc., upstream-owned) passes through (exit 0). The maxy-plugin list is regenerated and gate-diffed by `platform/scripts/check-canonical-tool-names.mjs`.
 - `hooks/post-tool-use-agent.sh` — **PostToolUse hook on `Agent`.** Drains any subagent hook-decision buffers under `~/.maxy-code/logs/hook-decisions/` modified since this parent's previous PostToolUse-Agent fire (cursor file keyed by parent session id), prints one `[hook-propagate]` line per record to stdout — Claude Code attaches the stdout as a `hook_success` attachment on the parent JSONL, making the records grep-queryable from the parent session alone. Rotates consumed buffers to `consumed/`. Emits one `[hook-propagate-census] parentSession=<…> subagentHooksObserved=<N> attachmentsEmitted=<M>` line per fire to stdout and server.log; `N != M` is the propagation regression signal. The companion emitter library `hooks/lib/hook-emit.sh` is sourced by `post-tool-use-agent.sh` and any other hook that records a block decision (4 KB stderr truncation, `truncated=true` set on the record).
 - `hooks/admin-authoring-observer.sh` — **PostToolUse hook on Write and Edit.** Observation only — never blocks; exits 0 on every path. Fires when the admin agent (not a specialist subagent — gated by `MAXY_SPECIALIST` env) writes or edits a file under `<accountDir>/output/`. Walks the session transcript from the latest real-user turn forward to detect any prior `Task` `tool_use` whose `subagent_type` starts with `specialists:`. Emits one stderr line `[admin-authoring] inline-write path=<rel> priorSpecialistSpawnInTurn=<true|false|unknown>`. A `false` value on a long-form prose file is the regression signal this hook was designed to make visible — the BioSymm proposal session (admin authored a customer-facing proposal inline despite content-producer being installed) is the failure mode this surfaces mechanically. Mechanical enforcement (refuse the write, force a re-spawn) is deferred per the task spec.

package/payload/platform/plugins/admin/hooks/__tests__/askuserquestion-channel-carrier-gate.test.sh

@@ -4,7 +4,7 @@
 # The hook blocks AskUserQuestion when the session has a native channel
 # attached — signalled by a channel MCP config file for this session id in
 # tmpdir. A channel carries no elicitation card, so the turn would wedge; the
-# hook steers the agent to ask in prose via its channel reply tool instead.
+# hook steers the agent to ask in prose in its own answer instead.
 #
 # Covers (per .tasks/1552):
 #   1. Channel attached (webchat config file present) + AskUserQuestion  → BLOCK channel-attached

package/payload/platform/plugins/admin/hooks/askuserquestion-channel-carrier-gate.sh

@@ -10,8 +10,9 @@
 # wedges — the operator sees the last delivered reply and a live-looking but
 # dead composer (see .tasks/1552, live SiteDesk incident session 1a085718
 # 2026-07-11). This hook removes that wedge deterministically by steering the
-# agent to ask the same question as prose via its channel reply tool, which
-# rides the ordinary delivered-reply path that works on every surface.
+# agent to ask the same question as prose in its answer, which rides the ordinary
+# delivery path that works on every surface. Task 2078 — that path is the turn's
+# own final text now; before it, the channel reply tool.
 #
 # This is a SEPARATE concern from askuserquestion-investigate-gate.sh (which
 # blocks a fabricated menu raised before any investigation). Both are registered
@@ -129,7 +130,7 @@ done
 
 if [ "$CHANNEL_ATTACHED" -eq 1 ]; then
   echo "[ask-channel] decision=block sessionId=${SESSION_ID8} channel=attached reason=channel-attached" >&2
-  echo "Blocked: this is a native-channel session and AskUserQuestion cannot be delivered over a channel (the channel protocol carries no elicitation card, so the turn would wedge). Ask the same question as prose in your channel reply tool and wait for the operator's next message." >&2
+  echo "Blocked: this is a native-channel session and AskUserQuestion cannot be delivered over a channel (the channel protocol carries no elicitation card, so the turn would wedge). Ask the same question as prose in your answer and wait for the operator's next message." >&2
   exit 2
 fi
 

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:5b93e9b58f687c920da46bec1137f326c5c00d5f2b1d4a460a5f5248eaee0c15
+content-hash: sha256:c0d108d50a5c5109da65ad22f4838284c614aed9161d4b5ab70c6db7c30904c2
 brand: maxy-code
 product-name: Maxy
 ---
@@ -2544,6 +2544,25 @@ Ask Maxy: "What messages has the bot received?" or "Show recent Telegram activit
 
 **Messages not arriving:** Make sure the bot hasn't been blocked. Try sending `/start` to the bot directly.
 
+## Sending from the dashboard
+
+Open a Telegram conversation in the dashboard and you can type a reply straight
+into it, the same way you already can with WhatsApp. The message goes out from
+your bot.
+
+Two things to know:
+
+- **Direct messages only.** Group and supergroup chats show no message box. A
+  Telegram conversation is filed under the person who spoke, so a message sent
+  from a group thread would reach that one person privately rather than the
+  group — the box is hidden rather than doing something you did not intend.
+- **History starts now.** Messages are only shown from the point this feature
+  was installed onward. A conversation that was already running looks empty
+  until the next message arrives, and then fills up from there.
+
+Text only for now. Photos, files and voice notes are not available on Telegram
+from the dashboard.
+
 ---
 # Outlook
 Source: https://docs.getmaxy.com/outlook-guide.md
@@ -2570,7 +2589,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-mail-search` | Microsoft Graph `$search` (KQL) over the mailbox. Preview-only, like `outlook-mail-list`, and pages the same way via `nextCursor`/`cursor`. Put sender/subject/recipient/date filters in the query: `from:`, `to:`, `subject:`, `received>=`. Graph forbids `$search`+`$filter`, so a strict date window is on `outlook-mail-list`. |
 | `outlook-mail-fetch-body` | Complete body of one message by id (`GET /me/messages/{id}?$select=body`). HTML decoded to text, no preview cap. The full-read path — list/search return Microsoft's ~255-char preview only. Returns the envelope plus the whole body. |
 | `outlook-mail-attachment` | List or download any message's attachments — received or draft. With `messageId` alone, LISTS them (`id`, `name`, `contentType`, `size`, `isInline`, and a `kind` of file/item/reference) via `GET /me/messages/{id}/attachments` and `$select` (no bytes). A draft is a message in the same collection, so passing a draftId lists what that draft carries; the returned `name`/`id` is what `outlook-draft-edit`'s `removeAttachments` takes. With `messageId`+`attachmentId`, DOWNLOADS one file attachment: its bytes are written to `{accountDir}/uploads/outlook/<messageHash>/<bytesHash>-<name>` at `0o600` and the saved path is returned, ready for the Read tool, `SendUserFile`, or an `outlook-mail-reply` attachment. Only file attachments download — item/reference kinds, empty payloads, and anything over 25 MB are refused with nothing written. `outlook-mail-list` / `outlook-mail-search` / `outlook-mail-fetch-body` report `hasAttachments` so the agent knows when to call this. Needs `Mail.Read`. |
-| `outlook-mail-reply` | Reply in-thread (`createReply` / `createReplyAll` + send). Threads natively via conversationId. `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file; files over Graph's ~3 MB inline limit use a chunked upload session). Body is plain text, prepended above the quote. Needs `Mail.ReadWrite` + `Mail.Send`. |
+| `outlook-mail-reply` | Reply in-thread (`createReply` / `createReplyAll` + send). Threads natively via conversationId. `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file; files over Graph's ~3 MB inline limit use a chunked upload session). Body is plain text, prepended above the quote. A reply whose recipients resolve **only** to the sending mailbox is **refused** before the send and its draft deleted: Graph addresses a reply to the original message's sender, so replying to your own sent message addresses it to yourself. An explicit `cc` does not exempt it — use `outlook-mail-send` with an explicit `to`. The resolved recipients are logged as `to=`. Needs `Mail.ReadWrite` + `Mail.Send`. |
 | `outlook-mail-delete` | Move messages to Deleted Items (`POST /me/messages/{id}/move`). Recoverable — never hard-deletes. An id already gone is counted not-moved. Needs `Mail.ReadWrite`. |
 | `outlook-mail-ingest` | Write operator-reviewed messages into the business graph as `:ConversationArchive {source:'email'}` threads (the analogue of the IMAP `email-ingest`). Input `decisions`: one `{messageId, disposition:'ingest'\|'discard'}` per listed message. Each `ingest` message's full body + envelope is fetched, threads group by Graph `conversationId`, and participants resolve closed-set against Neo4j (`:Person`/`:AdminUser` by `accountId`); an unresolved From/To/Cc address skips its whole thread and is returned to the operator (no `:Person` auto-create). Resolvable threads dispatch through the shared `conversation-archive-ingest.sh --source email`. Human-in-the-loop: nothing lands without an explicit per-message decision. The plugin's only Neo4j coupling. Needs `Mail.Read`. |
 | `outlook-mail-otp-extract` | Poll the inbox for a one-time code from a sender (domain). Reads full bodies to extract it; optional subject regex and timeout (default 60 s). |
@@ -2587,7 +2606,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-shared-mailbox-add` | Attach a shared mailbox (no sign-in, no licence) through the Full Access of a mailbox that is already connected. `address` is the shared mailbox; `via` names the connected mailbox when more than one is attached. Proves the access before storing anything, so a refusal is the real answer. |
 | `outlook-shared-mailbox-remove` | Detach a shared mailbox. Drops the pointer only; no credential is touched. |
 | `outlook-mail-send` | Send a message. No attachments → `POST /me/sendMail`; with attachments → draft, attach, send (`/me/sendMail` carries attachments inline and cannot fit a large file). to/cc/bcc arrays, subject, body, isHtml, attachments (account-dir paths, 25 MB/file). Success asserted on Graph 202; no message id on either route. Needs `Mail.Send` (+ `Mail.ReadWrite` to attach). |
-| `outlook-draft` | Create a draft in Drafts, either a new message or a threaded reply. Returns the draft id; never sends. Attachments are attached before the id is returned, so the draft is ready to send. Needs `Mail.ReadWrite`. **New message** (no `replyToMessageId`): `POST /me/messages`, requires `to` + `subject`, same body model as `outlook-mail-send`, threads under nothing. **Threaded reply** (`replyToMessageId` = the id of the message being answered): `POST /me/messages/{id}/createReply` — the draft carries the parent's conversationId, so it lands under the original. This is the only way to draft a reply without sending it: `outlook-mail-reply` threads but always sends. Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote, matching what `outlook-mail-reply` sends, so the threaded path is **plain text only** — `to`, `subject`, and `isHtml: true` are **refused** (not ignored) when replying. `replyAll` includes everyone on the original; `cc`/`bcc` add recipients. |
+| `outlook-draft` | Create a draft in Drafts, either a new message or a threaded reply. Returns the draft id; never sends. Attachments are attached before the id is returned, so the draft is ready to send. Needs `Mail.ReadWrite`. **New message** (no `replyToMessageId`): `POST /me/messages`, requires `to` + `subject`, same body model as `outlook-mail-send`, threads under nothing. **Threaded reply** (`replyToMessageId` = the id of the message being answered): `POST /me/messages/{id}/createReply` — the draft carries the parent's conversationId, so it lands under the original. This is the only way to draft a reply without sending it: `outlook-mail-reply` threads but always sends. Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote, matching what `outlook-mail-reply` sends, so the threaded path is **plain text only** — `to`, `subject`, and `isHtml: true` are **refused** (not ignored) when replying. `replyAll` includes everyone on the original; `cc`/`bcc` add recipients. The result carries `to`, the recipients the draft holds, so the self-addressed case above is visible without fetching the draft back; on this path it is reported rather than refused, because a draft is not sent and `outlook-draft-edit` can re-address it. |
 | `outlook-draft-edit` | Update an existing draft in place (`PATCH /me/messages/{draftId}`) and/or add and remove attachments. Graph drafts are mutable — pass draftId plus the fields to change (to/cc/bcc/subject/body/isHtml/attachments/removeAttachments). `attachments` adds; `removeAttachments` takes files off by name or attachment id; both together replace a file in one call. Sent messages cannot be edited. Needs `Mail.ReadWrite`. |
 | `outlook-draft-send` | Send an existing draft by id (`POST /me/messages/{id}/send`). Graph consumes the draft, returns 202. Needs `Mail.Send`. |
 
@@ -2657,8 +2676,12 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Send args | `send-args account=<id> recipients=<N> hasBody=<bool>` |
 | Sent | `sent account=<id> status=202 messageId=<id-or-null>` |
 | Send failed | `send-failed account=<id> error=<msg>` |
+| Reply sent | `mail-reply op=reply account=<id> id=<parentId> convId=<id\|null> replyAll=<bool> attachments=<N> to=<csv>` — `to=` is the recipients Graph resolved; before it, who a sent reply actually went to existed nowhere on disk |
+| Reply refused (self-addressed) | `mail-reply op=self-reply-refused account=<id> id=<parentId> to=<csv>` — terminal, nothing sent, draft deleted |
+| Self-reply guard could not run | `mail-reply op=self-reply-guard state=no-address account=<id> id=<parentId>` — the config carries no mailbox address, so the comparison is impossible and the send proceeds. Distinguishes "guard passed" from "guard absent", which a missing line cannot |
+| Refused, draft not cleaned up | `mail-reply op=self-reply-cleanup-failed account=<id> draftId=<id> error=<msg>` — followed by the refusal; the orphan is visible in Drafts |
 | Draft request | `draft-request account=<id> threaded=<bool>` |
-| Draft created | `draft-created account=<id> id=<draftId> threaded=<bool> convId=<id\|null>` |
+| Draft created | `draft-created account=<id> id=<draftId> threaded=<bool> convId=<id\|null> to=<csv>` |
 | Draft failed | `draft-failed account=<id> threaded=<bool> error=<msg>` |
 | Draft-send request | `draft-send-request account=<id> id=<draftId>` |
 | Draft sent | `draft-sent account=<id> id=<draftId> status=202` |

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

@@ -9,6 +9,18 @@ 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-05 (0.1.565)
+
+- Every channel now delivers the assistant's answer the same way the admin webchat does: the answer is taken from the conversation record and sent. Previously WhatsApp, Telegram and the public webchat asked the assistant to call a send tool, so an answer was suppressed when it called and lost entirely when it did not. Long answers arrive as ordered segments, and an answer meant for you fans out to every channel you have live, naming any that could not be reached.
+- A sub-account conversation no longer sees the main account's specialists. It was being given the house list while dispatch used its own, so the two disagreed.
+- Replying to a message your own mailbox sent no longer emails you instead of the intended recipient, and the reply reports who it is going to before it is sent rather than after.
+
+## 2026-08-05 (0.1.564)
+
+- You can now reply to a Telegram conversation from the dashboard. Telegram was read-only, so a conversation you could watch was one you could not answer; it now has a composer like WhatsApp. Sending is restricted to private chats.
+- An arriving Telegram message now raises a card and a desktop notification, the same as WhatsApp. Until now it arrived silently on every admin surface.
+- A portal job sheet now records time, so a day's labour reaches the timesheet. Field work could be marked done but carried no hours and wrote no labour cost at either end.
+
 ## 2026-08-05 (0.1.563)
 
 - You can now update from the dashboard. The installed version sits in the sidebar header rather than buried in the footer menu, and when a newer one is available the control there starts the update and shows its progress live. Previously the only route was asking the assistant in chat, and an available update was invisible until you opened the menu.

package/payload/platform/plugins/cloudflare/mcp/__tests__/portal-visit-status-write.test.ts

@@ -1,6 +1,8 @@
 import { describe, it, expect } from 'vitest'
 import {
+  MAX_NOTE_LENGTH,
   MAX_STATUS_LENGTH,
+  WORK_DATE_RE,
   processVisitStatus,
 } from '../../skills/data-portal/template/functions/api/visit-status'
 import type {
@@ -174,3 +176,119 @@ describe('the visit-status write gate', () => {
     expect(joined).not.toContain('granary')
   })
 })
+
+describe('the working day a status edit may carry', () => {
+  const day = (extra: Record<string, unknown>) => ({ visitId: 'v1', status: 'done', ...extra })
+
+  it('inserts the day, the date and the note when the claim is well formed', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      day({ dayHundredths: 100, workDate: '2026-08-05', workNote: 'second fix' }),
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(200)
+    expect(inserted[0]).toContain(100)
+    expect(inserted[0]).toContain('2026-08-05')
+    expect(inserted[0]).toContain('second fix')
+  })
+
+  it('defaults to no claim when the body carries no day', async () => {
+    // A status-only edit is the common case and must stay a one-field write.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(day({}), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(200)
+    expect(inserted[0]).toContain(0)
+    expect(inserted[0]).toContain('')
+  })
+
+  it('refuses a day outside 0..100 rather than writing it into the graph', async () => {
+    // A value above a full day is described by no shipped surface. Refused at
+    // the door, exactly as an over-long status is.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const e = env(database)
+    for (const d of [101, -1, 50.5, '100']) {
+      const h = await processVisitStatus(
+        day({ dayHundredths: d, workDate: '2026-08-05' }),
+        'sess',
+        e,
+        () => {},
+        1,
+      )
+      expect(h.status).toBe(400)
+    }
+    expect(inserted).toEqual([])
+  })
+
+  it('refuses a claim whose date is missing or malformed', async () => {
+    // The date becomes part of the cost key. A claim the roll-up cannot date is
+    // told to the person now, not left sitting in the queue.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const e = env(database)
+    for (const wd of [undefined, '', '5th Aug', '2026-8-5']) {
+      const h = await processVisitStatus(
+        day({ dayHundredths: 100, workDate: wd }),
+        'sess',
+        e,
+        () => {},
+        1,
+      )
+      expect(h.status).toBe(400)
+    }
+    expect(inserted).toEqual([])
+  })
+
+  it('accepts a date only in the shape the pull will key on', () => {
+    expect(WORK_DATE_RE.test('2026-08-05')).toBe(true)
+    expect(WORK_DATE_RE.test('2026-08-05T09:00:00Z')).toBe(false)
+  })
+
+  it('refuses a note longer than the cap rather than truncating it', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      day({
+        dayHundredths: 100,
+        workDate: '2026-08-05',
+        workNote: 'x'.repeat(MAX_NOTE_LENGTH + 1),
+      }),
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(400)
+    expect(inserted).toEqual([])
+  })
+
+  it('logs whether the edit carried a day, and never the note', async () => {
+    const lines: string[] = []
+    const { database } = db(ROWS, person('alice', 'own'))
+    await processVisitStatus(
+      day({ dayHundredths: 100, workDate: '2026-08-05', workNote: 'granary court rewire' }),
+      'sess',
+      env(database),
+      (l) => lines.push(l),
+      1,
+    )
+    const joined = lines.join('\n')
+    expect(joined).toContain('labour=true')
+    expect(joined).not.toContain('granary')
+    expect(joined).not.toContain('2026-08-05')
+  })
+
+  it('still refuses another person visit when the edit carries a day', async () => {
+    // The gate is the SELECT and the new fields must not have moved it.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      { visitId: 'v2', status: 'done', dayHundredths: 100, workDate: '2026-08-05' },
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(404)
+    expect(inserted).toEqual([])
+  })
+})

package/payload/platform/plugins/cloudflare/skills/data-portal/SKILL.md

@@ -147,6 +147,21 @@ ALTER TABLE people ADD COLUMN recordScope TEXT NOT NULL DEFAULT 'own';
 No backfill follows it. Everyone already enrolled lands on the narrow scope, which is the intended
 outcome, and widening one person is a re-run of enrolment for that person.
 
+**A status edit may also carry a working day, and a store that predates those three columns needs
+them added once too.** `dayHundredths` is integer hundredths of a day, which is what the timesheet
+engine consumes: 100 is a full day, and 0 means the edit claims no labour. `workDate` is the day
+worked, and the pull refuses a claim without one rather than dating it from when the sheet was filed.
+`workNote` is what the worker did. The same `IF NOT EXISTS` rule applies, so run all three:
+
+```sql
+ALTER TABLE visit_status ADD COLUMN dayHundredths INTEGER NOT NULL DEFAULT 0;
+ALTER TABLE visit_status ADD COLUMN workDate TEXT NOT NULL DEFAULT '';
+ALTER TABLE visit_status ADD COLUMN workNote TEXT NOT NULL DEFAULT '';
+```
+
+Until they exist the endpoint's INSERT names columns the table lacks and fails loudly, which is the
+intended outcome: a status edit silently losing its hours is the failure worth avoiding.
+
 **A passcode is never stored in plaintext** — not in `data-portal.json`, not in a log line, nowhere
 on the device. The operator conveys it to the person out of band. Rotating a passcode is a re-run of
 the script for that person; there is no separate editor.

package/payload/platform/plugins/cloudflare/skills/data-portal/schema.sql

@@ -309,14 +309,32 @@ CREATE TABLE IF NOT EXISTS visits_state (
 -- is counted by the audit. It is never written under another id and never
 -- dropped: a dropped edit is a promise broken to the person who made it, and it
 -- emits nothing at the time it happens.
+-- `dayHundredths`, `workDate` and `workNote` are the working day the edit
+-- carries (Task 2432). `dayHundredths` is integer hundredths of a day, which is
+-- exactly what the timesheet engine consumes: 100 is a full day. 0 means this
+-- edit carries no labour claim, the same absent-sentinel convention `ownerId`
+-- uses above for unbound. The pull writes a labour :JobCost only when it is
+-- above 0, and refuses a claim carrying no `workDate` rather than dating it
+-- from anything else: `statusAt` would record the wrong day for a sheet filed
+-- the next morning, and a visit's scheduled date is not evidence of when it was
+-- attended.
+--
+-- IF NOT EXISTS adds none of the three to a table that predates them. Add them
+-- by hand in that case, in this order:
+--   ALTER TABLE visit_status ADD COLUMN dayHundredths INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visit_status ADD COLUMN workDate TEXT NOT NULL DEFAULT '';
+--   ALTER TABLE visit_status ADD COLUMN workNote TEXT NOT NULL DEFAULT '';
 CREATE TABLE IF NOT EXISTS visit_status (
-  id        INTEGER PRIMARY KEY AUTOINCREMENT,
-  accountId TEXT NOT NULL,
-  visitId   TEXT NOT NULL,
-  ownerId   TEXT NOT NULL,
-  status    TEXT NOT NULL,
-  statusAt  TEXT NOT NULL,
-  claimed   INTEGER NOT NULL DEFAULT 0
+  id            INTEGER PRIMARY KEY AUTOINCREMENT,
+  accountId     TEXT NOT NULL,
+  visitId       TEXT NOT NULL,
+  ownerId       TEXT NOT NULL,
+  status        TEXT NOT NULL,
+  statusAt      TEXT NOT NULL,
+  dayHundredths INTEGER NOT NULL DEFAULT 0,
+  workDate      TEXT NOT NULL DEFAULT '',
+  workNote      TEXT NOT NULL DEFAULT '',
+  claimed       INTEGER NOT NULL DEFAULT 0
 );
 
 -- The pull selects unclaimed rows for one account every sixty seconds, so the

package/payload/platform/plugins/cloudflare/skills/data-portal/template/functions/api/visit-status.ts

@@ -12,6 +12,27 @@ import { q } from './_lib/log'
  */
 export const MAX_STATUS_LENGTH = 64
 
+/**
+ * The longest work note a person may attach to a day.
+ *
+ * The note reaches `:JobCost.description` through the device-side pull, so it
+ * is graph content arriving from the open web and gets the same treatment the
+ * status gets: refused at the door, never truncated. The size is chosen for a
+ * description cell on the A4 timesheet row, not derived from anything.
+ */
+export const MAX_NOTE_LENGTH = 500
+
+/**
+ * The only date shape a claim may carry.
+ *
+ * The date becomes part of the cost key the pull merges on, so a free-form
+ * string would produce a key nobody can reproduce. A COPY of this check lives
+ * in `platform/ui/server/portal-visits-pull.ts` as the invariant at the writer;
+ * the two cannot share a constant because this file ships to Cloudflare Pages
+ * and cannot import from the platform tree.
+ */
+export const WORK_DATE_RE = /^\d{4}-\d{2}-\d{2}$/
+
 /**
  * Record a status a person set against one of their visits.
  *
@@ -56,10 +77,39 @@ export async function processVisitStatus(
     return { status: 400, payload: { ok: false, error: 'status too long' } }
   }
 
+  // The working day the edit carries, if any. Absent means a status-only edit,
+  // which is the common case and stays a zero-claim write.
+  const dayHundredths = b.dayHundredths === undefined ? 0 : b.dayHundredths
+  if (
+    typeof dayHundredths !== 'number' ||
+    !Number.isInteger(dayHundredths) ||
+    dayHundredths < 0 ||
+    dayHundredths > 100
+  ) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=bad-day`)
+    return { status: 400, payload: { ok: false, error: 'dayHundredths must be an integer 0..100' } }
+  }
+  const workDate = typeof b.workDate === 'string' ? b.workDate : ''
+  const workNote = typeof b.workNote === 'string' ? b.workNote : ''
+  // A claim the roll-up could not date is refused now rather than queued. The
+  // pull holds the same invariant, so a row reaching the table another way is
+  // still never written under a guessed date.
+  if (dayHundredths > 0 && !WORK_DATE_RE.test(workDate)) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=undated-claim`)
+    return {
+      status: 400,
+      payload: { ok: false, error: 'a day claim requires workDate as YYYY-MM-DD' },
+    }
+  }
+  if (workNote.length > MAX_NOTE_LENGTH) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=note-too-long`)
+    return { status: 400, payload: { ok: false, error: 'note too long' } }
+  }
+
   const scoped = session.recordScope === 'own'
   const sql =
-    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, claimed, visitId)
-     SELECT ?, ?, ?, ?, 0, v.visitId
+    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, dayHundredths, workDate, workNote, claimed, visitId)
+     SELECT ?, ?, ?, ?, ?, ?, ?, 0, v.visitId
        FROM visits v
        JOIN visits_state s
          ON s.accountId = v.accountId AND s.currentGeneration = v.generation
@@ -74,6 +124,9 @@ export async function processVisitStatus(
         session.ownerId,
         status,
         statusAt,
+        dayHundredths,
+        workDate,
+        workNote,
         env.PORTAL_ACCOUNT_ID,
         session.ownerId,
         visitId,
@@ -83,6 +136,9 @@ export async function processVisitStatus(
         session.ownerId,
         status,
         statusAt,
+        dayHundredths,
+        workDate,
+        workNote,
         env.PORTAL_ACCOUNT_ID,
         visitId,
       )
@@ -100,11 +156,12 @@ export async function processVisitStatus(
     return { status: 404, payload: { ok: false, error: 'not found' } }
   }
 
-  // Counts, the scope and the outcome. Never the status text: it describes what
-  // a real person was doing.
+  // Counts, the scope, whether a day was claimed, and the outcome. Never the
+  // status text, the date or the note: they describe what a real person was
+  // doing and when.
   log(
     `[data-portal] op=visit-status owner=${q(session.ownerId)} account=${q(session.accountId)} ` +
-      `scope=${session.recordScope} queued=${changes} result=ok`,
+      `scope=${session.recordScope} labour=${dayHundredths > 0} queued=${changes} result=ok`,
   )
   return { status: 200, payload: { ok: true, queued: changes } }
 }

package/payload/platform/plugins/docs/references/outlook-guide.md

@@ -20,7 +20,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-mail-search` | Microsoft Graph `$search` (KQL) over the mailbox. Preview-only, like `outlook-mail-list`, and pages the same way via `nextCursor`/`cursor`. Put sender/subject/recipient/date filters in the query: `from:`, `to:`, `subject:`, `received>=`. Graph forbids `$search`+`$filter`, so a strict date window is on `outlook-mail-list`. |
 | `outlook-mail-fetch-body` | Complete body of one message by id (`GET /me/messages/{id}?$select=body`). HTML decoded to text, no preview cap. The full-read path — list/search return Microsoft's ~255-char preview only. Returns the envelope plus the whole body. |
 | `outlook-mail-attachment` | List or download any message's attachments — received or draft. With `messageId` alone, LISTS them (`id`, `name`, `contentType`, `size`, `isInline`, and a `kind` of file/item/reference) via `GET /me/messages/{id}/attachments` and `$select` (no bytes). A draft is a message in the same collection, so passing a draftId lists what that draft carries; the returned `name`/`id` is what `outlook-draft-edit`'s `removeAttachments` takes. With `messageId`+`attachmentId`, DOWNLOADS one file attachment: its bytes are written to `{accountDir}/uploads/outlook/<messageHash>/<bytesHash>-<name>` at `0o600` and the saved path is returned, ready for the Read tool, `SendUserFile`, or an `outlook-mail-reply` attachment. Only file attachments download — item/reference kinds, empty payloads, and anything over 25 MB are refused with nothing written. `outlook-mail-list` / `outlook-mail-search` / `outlook-mail-fetch-body` report `hasAttachments` so the agent knows when to call this. Needs `Mail.Read`. |
-| `outlook-mail-reply` | Reply in-thread (`createReply` / `createReplyAll` + send). Threads natively via conversationId. `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file; files over Graph's ~3 MB inline limit use a chunked upload session). Body is plain text, prepended above the quote. Needs `Mail.ReadWrite` + `Mail.Send`. |
+| `outlook-mail-reply` | Reply in-thread (`createReply` / `createReplyAll` + send). Threads natively via conversationId. `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file; files over Graph's ~3 MB inline limit use a chunked upload session). Body is plain text, prepended above the quote. A reply whose recipients resolve **only** to the sending mailbox is **refused** before the send and its draft deleted: Graph addresses a reply to the original message's sender, so replying to your own sent message addresses it to yourself. An explicit `cc` does not exempt it — use `outlook-mail-send` with an explicit `to`. The resolved recipients are logged as `to=`. Needs `Mail.ReadWrite` + `Mail.Send`. |
 | `outlook-mail-delete` | Move messages to Deleted Items (`POST /me/messages/{id}/move`). Recoverable — never hard-deletes. An id already gone is counted not-moved. Needs `Mail.ReadWrite`. |
 | `outlook-mail-ingest` | Write operator-reviewed messages into the business graph as `:ConversationArchive {source:'email'}` threads (the analogue of the IMAP `email-ingest`). Input `decisions`: one `{messageId, disposition:'ingest'\|'discard'}` per listed message. Each `ingest` message's full body + envelope is fetched, threads group by Graph `conversationId`, and participants resolve closed-set against Neo4j (`:Person`/`:AdminUser` by `accountId`); an unresolved From/To/Cc address skips its whole thread and is returned to the operator (no `:Person` auto-create). Resolvable threads dispatch through the shared `conversation-archive-ingest.sh --source email`. Human-in-the-loop: nothing lands without an explicit per-message decision. The plugin's only Neo4j coupling. Needs `Mail.Read`. |
 | `outlook-mail-otp-extract` | Poll the inbox for a one-time code from a sender (domain). Reads full bodies to extract it; optional subject regex and timeout (default 60 s). |
@@ -37,7 +37,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-shared-mailbox-add` | Attach a shared mailbox (no sign-in, no licence) through the Full Access of a mailbox that is already connected. `address` is the shared mailbox; `via` names the connected mailbox when more than one is attached. Proves the access before storing anything, so a refusal is the real answer. |
 | `outlook-shared-mailbox-remove` | Detach a shared mailbox. Drops the pointer only; no credential is touched. |
 | `outlook-mail-send` | Send a message. No attachments → `POST /me/sendMail`; with attachments → draft, attach, send (`/me/sendMail` carries attachments inline and cannot fit a large file). to/cc/bcc arrays, subject, body, isHtml, attachments (account-dir paths, 25 MB/file). Success asserted on Graph 202; no message id on either route. Needs `Mail.Send` (+ `Mail.ReadWrite` to attach). |
-| `outlook-draft` | Create a draft in Drafts, either a new message or a threaded reply. Returns the draft id; never sends. Attachments are attached before the id is returned, so the draft is ready to send. Needs `Mail.ReadWrite`. **New message** (no `replyToMessageId`): `POST /me/messages`, requires `to` + `subject`, same body model as `outlook-mail-send`, threads under nothing. **Threaded reply** (`replyToMessageId` = the id of the message being answered): `POST /me/messages/{id}/createReply` — the draft carries the parent's conversationId, so it lands under the original. This is the only way to draft a reply without sending it: `outlook-mail-reply` threads but always sends. Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote, matching what `outlook-mail-reply` sends, so the threaded path is **plain text only** — `to`, `subject`, and `isHtml: true` are **refused** (not ignored) when replying. `replyAll` includes everyone on the original; `cc`/`bcc` add recipients. |
+| `outlook-draft` | Create a draft in Drafts, either a new message or a threaded reply. Returns the draft id; never sends. Attachments are attached before the id is returned, so the draft is ready to send. Needs `Mail.ReadWrite`. **New message** (no `replyToMessageId`): `POST /me/messages`, requires `to` + `subject`, same body model as `outlook-mail-send`, threads under nothing. **Threaded reply** (`replyToMessageId` = the id of the message being answered): `POST /me/messages/{id}/createReply` — the draft carries the parent's conversationId, so it lands under the original. This is the only way to draft a reply without sending it: `outlook-mail-reply` threads but always sends. Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote, matching what `outlook-mail-reply` sends, so the threaded path is **plain text only** — `to`, `subject`, and `isHtml: true` are **refused** (not ignored) when replying. `replyAll` includes everyone on the original; `cc`/`bcc` add recipients. The result carries `to`, the recipients the draft holds, so the self-addressed case above is visible without fetching the draft back; on this path it is reported rather than refused, because a draft is not sent and `outlook-draft-edit` can re-address it. |
 | `outlook-draft-edit` | Update an existing draft in place (`PATCH /me/messages/{draftId}`) and/or add and remove attachments. Graph drafts are mutable — pass draftId plus the fields to change (to/cc/bcc/subject/body/isHtml/attachments/removeAttachments). `attachments` adds; `removeAttachments` takes files off by name or attachment id; both together replace a file in one call. Sent messages cannot be edited. Needs `Mail.ReadWrite`. |
 | `outlook-draft-send` | Send an existing draft by id (`POST /me/messages/{id}/send`). Graph consumes the draft, returns 202. Needs `Mail.Send`. |
 
@@ -107,8 +107,12 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Send args | `send-args account=<id> recipients=<N> hasBody=<bool>` |
 | Sent | `sent account=<id> status=202 messageId=<id-or-null>` |
 | Send failed | `send-failed account=<id> error=<msg>` |
+| Reply sent | `mail-reply op=reply account=<id> id=<parentId> convId=<id\|null> replyAll=<bool> attachments=<N> to=<csv>` — `to=` is the recipients Graph resolved; before it, who a sent reply actually went to existed nowhere on disk |
+| Reply refused (self-addressed) | `mail-reply op=self-reply-refused account=<id> id=<parentId> to=<csv>` — terminal, nothing sent, draft deleted |
+| Self-reply guard could not run | `mail-reply op=self-reply-guard state=no-address account=<id> id=<parentId>` — the config carries no mailbox address, so the comparison is impossible and the send proceeds. Distinguishes "guard passed" from "guard absent", which a missing line cannot |
+| Refused, draft not cleaned up | `mail-reply op=self-reply-cleanup-failed account=<id> draftId=<id> error=<msg>` — followed by the refusal; the orphan is visible in Drafts |
 | Draft request | `draft-request account=<id> threaded=<bool>` |
-| Draft created | `draft-created account=<id> id=<draftId> threaded=<bool> convId=<id\|null>` |
+| Draft created | `draft-created account=<id> id=<draftId> threaded=<bool> convId=<id\|null> to=<csv>` |
 | Draft failed | `draft-failed account=<id> threaded=<bool> error=<msg>` |
 | Draft-send request | `draft-send-request account=<id> id=<draftId>` |
 | Draft sent | `draft-sent account=<id> id=<draftId> status=202` |

package/payload/platform/plugins/docs/references/telegram-guide.md

@@ -56,3 +56,22 @@ Ask {{productName}}: "What messages has the bot received?" or "Show recent Teleg
 **Can't send to a group:** The bot must be a member of the group. Add it via the group settings in Telegram, then try again.
 
 **Messages not arriving:** Make sure the bot hasn't been blocked. Try sending `/start` to the bot directly.
+
+## Sending from the dashboard
+
+Open a Telegram conversation in the dashboard and you can type a reply straight
+into it, the same way you already can with WhatsApp. The message goes out from
+your bot.
+
+Two things to know:
+
+- **Direct messages only.** Group and supergroup chats show no message box. A
+  Telegram conversation is filed under the person who spoke, so a message sent
+  from a group thread would reach that one person privately rather than the
+  group — the box is hidden rather than doing something you did not intend.
+- **History starts now.** Messages are only shown from the point this feature
+  was installed onward. A conversation that was already running looks empty
+  until the next message arrives, and then fills up from there.
+
+Text only for now. Photos, files and voice notes are not available on Telegram
+from the dashboard.

package/payload/platform/plugins/memory/references/schema-construction.md

@@ -116,7 +116,7 @@ MERGE keys per label:
 - `:Contact` — `(accountId, contactId)` — write-time MERGE
 - `:PurchaseOrderLine` — `(accountId, poNumber, lineId)` — child of `:PurchaseOrder`
 - `:Note` — `(accountId, noteId)` — child of `:Job` via `(:Note)-[:ABOUT]->(:Job)`, append-only CREATE (a fresh `noteId` per note, not a content MERGE), so a second note never overwrites the first
-- `:Engineer` — `(accountId, personId)` — additional label on `:Person`, set via `memory-update`
+- `:Engineer` — `(accountId, engineerId)` — additional label on `:Person`, set via `memory-update`
 - `:Supplier` — `(accountId, organizationId)` — additional label on `:Organization`
 
 ---

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

@@ -133,10 +133,10 @@ Microsoft Graph access for Outlook.com / Microsoft 365 mailboxes. Mail is read (
 - **Multiple mailboxes:** one account can hold several mailboxes. Every operational tool takes an optional `mailbox` argument (email or graphUserId). With one mailbox, omit it. With two or more, name it — omitting it returns a refusal listing the connected mailboxes. `outlook-mailbox-list` shows them all.
 - **Mail (read):** `outlook-mail-list` returns messages newest-first with an optional `since`/`before` date window, and `outlook-mail-search` runs a Graph `$search` (KQL) query where `from:`/`to:`/`subject:`/`received>=` filters live — both return Microsoft's short `bodyPreview` (~255 chars) for cheap triage and a `nextCursor` for paging beyond the 250-per-page window (the cursor is an opaque `@odata.nextLink`; pass it back as `cursor`). Graph forbids `$search`+`$filter`, so the strict date window is on the list tool and sender/subject filtering is on the search tool. `outlook-mail-fetch-body` reads the COMPLETE body of one message by id (HTML decoded to text, no preview cap) — the full-read path. All three read tools report `hasAttachments` per message, so the agent knows to reach for the attachment tool.
 - **Mail (attachments):** `outlook-mail-attachment` lists or downloads any message's attachments — received or draft. Called with `messageId` alone it LISTS them (`id`, `name`, `contentType`, `size`, `isInline`, and a `kind` of `file`/`item`/`reference`) via `GET /me/messages/{id}/attachments` with `$select` (no bytes); a draft is a message in the same collection, so passing a draftId lists what that draft carries, and the returned `name`/`id` is the handle `outlook-draft-edit`'s `removeAttachments` takes. Called with `messageId`+`attachmentId` it DOWNLOADS one file attachment: the bytes are written to `{accountDir}/uploads/outlook/<messageHash>/<bytesHash>-<name>` at `0o600` and the saved absolute path is returned, ready for the Read tool, `SendUserFile`, or an `outlook-mail-reply` attachment. Only file attachments download — `item` (embedded message/event) and `reference` (cloud-drive link) kinds are refused, as are empty payloads and anything over the 25 MB cap; in each case nothing is written. Requires `Mail.Read`.
-- **Mail (reply / delete):** `outlook-mail-reply` replies in-thread (native `conversationId` threading) with `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file — files over Graph's ~3 MB inline limit stream through a chunked upload session); the body is prepended above the quoted original. `outlook-mail-delete` moves messages to Deleted Items (recoverable — never hard-deletes). Both require `Mail.ReadWrite` (reply also needs `Mail.Send`).
+- **Mail (reply / delete):** `outlook-mail-reply` replies in-thread (native `conversationId` threading) with `replyAll`, added cc/bcc, and account-scoped file attachments (up to 25 MB per file — files over Graph's ~3 MB inline limit stream through a chunked upload session); the body is prepended above the quoted original. A reply whose recipients resolve **only** to the sending mailbox is refused before the send and its draft deleted: Graph addresses a reply to the original message's sender, so replying to your own sent message addresses it to yourself. An explicit `cc` does not exempt it — use `outlook-mail-send` with an explicit `to` instead. Both `outlook-mail-reply` and `outlook-draft` log the resolved recipients as `to=`. `outlook-mail-delete` moves messages to Deleted Items (recoverable — never hard-deletes). Both require `Mail.ReadWrite` (reply also needs `Mail.Send`).
 - **Mail (ingest to graph):** `outlook-mail-ingest` writes operator-reviewed messages into the business graph as `:ConversationArchive {source:'email'}` threads, the analogue of the IMAP `email-ingest`. Input is `decisions`: one `{messageId, disposition:'ingest'|'discard'}` per listed message. Each `ingest` message's full body + envelope is fetched via `runMailFetchBody`, threads are grouped by Graph `conversationId`, and participant resolution is closed-set — every From/To/Cc address must already resolve to a `:Person.email` or `:AdminUser.email` for the `accountId`, or its thread is skipped and the address is returned to the operator (no `:Person` auto-create). Resolvable threads dispatch one at a time through the shared `plugins/memory/bin/conversation-archive-ingest.sh --source email` (same RFC822 thread-JSON shape the `email` normaliser consumes). This is the plugin's only Neo4j coupling (`neo4j-driver`). Human-in-the-loop: nothing enters the graph without an explicit per-message decision; the `outlook-mail-ingest` skill drives the list → summarise → ask → ingest loop. Requires `Mail.Read`.
 - **Mail (OTP):** `outlook-mail-otp-extract` polls the inbox for a one-time verification code from a named sender, reading full bodies to extract it — used during service authentication.
-- **Mail (send / draft):** `outlook-mail-send` sends a new message — via `POST /me/sendMail` with no attachments, or composed as a draft, attached, and sent when `attachments` is present (`/me/sendMail` carries attachments inline and cannot fit a large file); `outlook-draft` creates a draft, attaches any files, and returns its id — either a new message (`to` + `subject` required) or, with `replyToMessageId`, a threaded reply created via `POST /me/messages/{id}/createReply` that lands under the original conversation (the only way to draft a reply without sending it; `outlook-mail-reply` threads but always sends). On the threaded path Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote — the same email `outlook-mail-reply` sends — so that path is plain text only and `to`, `subject`, and `isHtml: true` are refused rather than silently dropped; `replyAll` and `cc`/`bcc` work as on reply. `outlook-draft-edit` updates an existing draft in place (Graph drafts are mutable) and edits its attachments — `attachments` adds files, `removeAttachments` takes them off by name or attachment id, and both together replace a file in one call; `outlook-draft-send` sends an existing draft by id. Recipients are to/cc/bcc arrays; body is HTML or plain text via `isHtml`; `attachments` are file paths inside the account directory, capped at 25 MB per file and validated before any Graph write. Success asserted on Graph 202. Requires `Mail.Send` + `Mail.ReadWrite`; a mailbox on the old read-only consent returns an actionable "re-register to grant send" signal.
+- **Mail (send / draft):** `outlook-mail-send` sends a new message — via `POST /me/sendMail` with no attachments, or composed as a draft, attached, and sent when `attachments` is present (`/me/sendMail` carries attachments inline and cannot fit a large file); `outlook-draft` creates a draft, attaches any files, and returns its id — either a new message (`to` + `subject` required) or, with `replyToMessageId`, a threaded reply created via `POST /me/messages/{id}/createReply` that lands under the original conversation (the only way to draft a reply without sending it; `outlook-mail-reply` threads but always sends). On the threaded path Graph sets the recipients and `RE:` subject from the original and composes the body above its own quote — the same email `outlook-mail-reply` sends — so that path is plain text only and `to`, `subject`, and `isHtml: true` are refused rather than silently dropped; `replyAll` and `cc`/`bcc` work as on reply. The draft result carries `to`, the recipients the draft holds, so the self-addressed case above is visible without fetching the draft back; on this path it is reported rather than refused, because a draft is not sent. `outlook-draft-edit` updates an existing draft in place (Graph drafts are mutable) and edits its attachments — `attachments` adds files, `removeAttachments` takes them off by name or attachment id, and both together replace a file in one call; `outlook-draft-send` sends an existing draft by id. Recipients are to/cc/bcc arrays; body is HTML or plain text via `isHtml`; `attachments` are file paths inside the account directory, capped at 25 MB per file and validated before any Graph write. Success asserted on Graph 202. Requires `Mail.Send` + `Mail.ReadWrite`; a mailbox on the old read-only consent returns an actionable "re-register to grant send" signal.
 - **Calendar (read + control):** `outlook-calendar-list` and `outlook-calendar-event` read events; `outlook-calendar-create` books an event; `outlook-calendar-update` reschedules or edits one; `outlook-calendar-cancel` cancels a meeting (notifying attendees when the account organises it) or deletes a personal appointment; `outlook-calendar-respond` accepts, declines, or tentatively accepts an invite; `outlook-calendar-freebusy` reports availability for one or more addresses over a window. Writes require the `Calendars.ReadWrite` consent; a mailbox on stale read-only consent returns a distinct signal naming the scope and `outlook-account-register`.
 - **Contacts (read-only):** `outlook-contacts-list` returns contacts.
 - **Health:** `outlook-mailbox-info` reports auth state, refresh-window status, and top-level folder count for one mailbox (name it with `mailbox` when several are attached). `outlook-mailbox-list` lists every attached mailbox with its email, scopes, and token health, reading local stores only, never the network. It reports an `addressable` count and a per-mailbox `status` (`ok` / `blank-email` / `refresh-expired` / `unreadable`) so an authenticated, addressable mailbox is distinguishable from one that is merely present: a bare `count` of 1 is not "connected" unless that mailbox is `status:ok`. Use these to answer "did mailbox X auth?" without grepping logs.

package/payload/platform/plugins/outlook/mcp/dist/__tests__/attach.test.js

@@ -10,7 +10,7 @@ function configWithToken(accountId) {
     const dir = mkdtempSync(join(tmpdir(), "outlook-attach-"));
     const tokenStore = new TokenStore(accountId, dir);
     tokenStore.store("access-token", "refresh-token", 3600, { scopes: ["Mail.ReadWrite", "Mail.Send"] });
-    return { clientId: "test-client", tenantId: "common", accountId, tokenStore };
+    return { clientId: "test-client", tenantId: "common", accountId, tokenStore, mailboxAddress: null };
 }
 const UPLOAD_URL = "https://upload.example.com/session/attach";
 function mockRouted() {