@rubytech/create-maxy-code 0.1.571 → 0.1.573

package/payload/platform/plugins/dispatch/mcp/dist/tools/reads.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"reads.js","sourceRoot":"","sources":["../../src/tools/reads.ts"],"names":[],"mappings":"AASA,OAAO,EAAE,UAAU,EAAE,MAAM,qBAAqB,CAAC;AACjD,OAAO,EACL,OAAO,EACP,QAAQ,EACR,eAAe,EACf,gBAAgB,EAChB,kBAAkB,GAEnB,MAAM,gBAAgB,CAAC;AACxB,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAmB,MAAM,aAAa,CAAC;AAEnE,MAAM,CAAC,KAAK,UAAU,MAAM,CAAC,CAK5B;IACC,MAAM,GAAG,GAAG,MAAM,OAAO,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC;IAC3D,IAAI,CAAC,GAAG;QAAE,OAAO,SAAS,CAAC,MAAM,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,GAAG,KAAK,CAAC,CAAC,KAAK,oBAAoB,CAAC,CAAC;IACvF,MAAM,MAAM,GAAG,MAAM,gBAAgB,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC;IACvE,OAAO,QAAQ,CACb,IAAI,CAAC,SAAS,CACZ,EAAE,UAAU,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU,EAAE,GAAG,EAAE,MAAM,EAAE,UAAU,EAAE,MAAM,CAAC,MAAM,EAAE,EACxE,IAAI,EACJ,CAAC,CACF,CACF,CAAC;AACJ,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,OAAO,CAAC,CAM7B;IACC,IAAI,CAAC,CAAC,MAAM,CAAC,MAAM,IAAI,CAAC,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,CAAC,CAAC,MAAM,CAAC,MAAM,CAAC,EAAE,CAAC;QACnF,OAAO,SAAS,CACd,IAAI,CAAC,CAAC,MAAM,CAAC,MAAM,cAAc,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,GAAG,sCAAsC,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,GAAG,CAC/I,CAAC;IACJ,CAAC;IACD,MAAM,IAAI,GAAG,MAAM,QAAQ,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC;IAC9D,MAAM,MAAM,GAAG,IAAI,IAAI,CAAC,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC,WAAW,EAAE,CAAC;IAC/C,OAAO,QAAQ,CACb,IAAI,CAAC,SAAS,CACZ;QACE,UAAU,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU;QAC5B,KAAK,EAAE,IAAI,CAAC,MAAM;QAClB,IAAI,EAAE,IAAI,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;YACrB,GAAG,CAAC;YACJ,sEAAsE;YACtE,+DAA+D;YAC/D,OAAO,EACL,CAAC,CAAC,WAAW,KAAK,IAAI;gBACtB,CAAC,CAAC,WAAW,GAAG,MAAM;gBACtB,CAAC,UAAU,CAAC,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,GAAG,CAAC;SACtC,CAAC,CAAC;KACJ,EACD,IAAI,EACJ,CAAC,CACF,CACF,CAAC;AACJ,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,WAAW,CAAC,CAMjC;IACC,MAAM,IAAI,GAAG,MAAM,eAAe,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC;IACpF,OAAO,QAAQ,CACb,IAAI,CAAC,SAAS,CACZ,EAAE,UAAU,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU,EAAE,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,KAAK,EAAE,IAAI,CAAC,MAAM,EAAE,MAAM,EAAE,IAAI,EAAE,EACpF,IAAI,EACJ,CAAC,CACF,CACF,CAAC;AACJ,CAAC;AAED,MAAM,CAAC,KAAK,UAAU,GAAG,CAAC,CAKzB;IACC,MAAM,IAAI,GAAG,GAAG,CAAC,CAAC,IAAI,gBAAgB,CAAC;IACvC,MAAM,EAAE,GAAG,GAAG,CAAC,CAAC,IAAI,gBAAgB,CAAC;IACrC,MAAM,MAAM,GAAG,MAAM,kBAAkB,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE,IAAI,EAAE,EAAE,CAAC,CAAC;IAC1E,MAAM,WAAW,GAAG,MAAM,QAAQ,CAAC,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC,SAAS,EAAE;QACzD,eAAe,EAAE,IAAI;QACrB,KAAK,EAAE,GAAG;KACX,CAAC,CAAC;IAEH,8EAA8E;IAC9E,4EAA4E;IAC5E,6CAA6C;IAC7C,MAAM,OAAO,GAAG,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;QACxC,QAAQ,EAAE,CAAC,CAAC,QAAQ;QACpB,IAAI,EAAE,CAAC,CAAC,IAAI;QACZ,YAAY,EAAE,CAAC,CAAC,YAAY;QAC5B,MAAM,EAAE,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,KAAK,CAAC,CAAC,QAAQ,CAAC;KACxD,CAAC,CAAC,CAAC;IAEJ,OAAO,QAAQ,CACb,IAAI,CAAC,SAAS,CACZ;QACE,IAAI,EAAE,CAAC,CAAC,IAAI;QACZ,UAAU,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU;QAC5B,OAAO;QACP,WAAW,EAAE,WAAW,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;YACnC,KAAK,EAAE,CAAC,CAAC,KAAK;YACd,IAAI,EAAE,CAAC,CAAC,OAAO;YACf,WAAW,EAAE,CAAC,CAAC,WAAW;SAC3B,CAAC,CAAC;QACH,gBAAgB,EAAE,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,QAAQ,KAAK,IAAI,CAAC;KAC5D,EACD,IAAI,EACJ,CAAC,CACF,CACF,CAAC;AACJ,CAAC"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/result.d.ts

@@ -0,0 +1,17 @@
+/**
+ * The MCP tool-result shape, in one place.
+ *
+ * A refusal is `isError: true` with text naming what to do about it, never a
+ * throw: a thrown error inside a tool handler reaches the agent as a stack
+ * trace with no instruction in it.
+ */
+export interface ToolResult {
+    content: Array<{
+        type: "text";
+        text: string;
+    }>;
+    isError?: true;
+}
+export declare function toolText(text: string): ToolResult;
+export declare function toolError(text: string): ToolResult;
+//# sourceMappingURL=result.d.ts.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/result.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"result.d.ts","sourceRoot":"","sources":["../../src/tools/result.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AACH,MAAM,WAAW,UAAU;IACzB,OAAO,EAAE,KAAK,CAAC;QAAE,IAAI,EAAE,MAAM,CAAC;QAAC,IAAI,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC/C,OAAO,CAAC,EAAE,IAAI,CAAC;CAChB;AAED,wBAAgB,QAAQ,CAAC,IAAI,EAAE,MAAM,GAAG,UAAU,CAEjD;AAED,wBAAgB,SAAS,CAAC,IAAI,EAAE,MAAM,GAAG,UAAU,CAElD"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/result.js

@@ -0,0 +1,7 @@
+export function toolText(text) {
+    return { content: [{ type: "text", text }] };
+}
+export function toolError(text) {
+    return { content: [{ type: "text", text }], isError: true };
+}
+//# sourceMappingURL=result.js.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/result.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"result.js","sourceRoot":"","sources":["../../src/tools/result.ts"],"names":[],"mappings":"AAYA,MAAM,UAAU,QAAQ,CAAC,IAAY;IACnC,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,CAAC;AAC/C,CAAC;AAED,MAAM,UAAU,SAAS,CAAC,IAAY;IACpC,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AAC9D,CAAC"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-record.d.ts

@@ -0,0 +1,13 @@
+/**
+ * The MCP adapter for `dispatch-visit-record`.
+ *
+ * The write itself moved to `platform/lib/dispatch-write` so the field job
+ * sheet can call it without a second implementation. This file's only job is
+ * the shape: a domain outcome becomes a `ToolResult`, with the refusal text
+ * unchanged so the agent-facing wording does not drift.
+ */
+import { type VisitRecordParams } from "../../../../../lib/dispatch-write/dist/index.js";
+import { type ToolResult } from "./result.js";
+export type { VisitRecordParams } from "../../../../../lib/dispatch-write/dist/index.js";
+export declare function visitRecord(p: VisitRecordParams): Promise<ToolResult>;
+//# sourceMappingURL=visit-record.d.ts.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-record.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visit-record.d.ts","sourceRoot":"","sources":["../../src/tools/visit-record.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,EAEL,KAAK,iBAAiB,EACvB,MAAM,iDAAiD,CAAC;AACzD,OAAO,EAAuB,KAAK,UAAU,EAAE,MAAM,aAAa,CAAC;AAEnE,YAAY,EAAE,iBAAiB,EAAE,MAAM,iDAAiD,CAAC;AAEzF,wBAAsB,WAAW,CAAC,CAAC,EAAE,iBAAiB,GAAG,OAAO,CAAC,UAAU,CAAC,CAG3E"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-record.js

@@ -0,0 +1,15 @@
+/**
+ * The MCP adapter for `dispatch-visit-record`.
+ *
+ * The write itself moved to `platform/lib/dispatch-write` so the field job
+ * sheet can call it without a second implementation. This file's only job is
+ * the shape: a domain outcome becomes a `ToolResult`, with the refusal text
+ * unchanged so the agent-facing wording does not drift.
+ */
+import { visitRecord as visitRecordWrite, } from "../../../../../lib/dispatch-write/dist/index.js";
+import { toolError, toolText } from "./result.js";
+export async function visitRecord(p) {
+    const out = await visitRecordWrite(p);
+    return out.ok ? toolText(JSON.stringify(out.value, null, 2)) : toolError(out.message);
+}
+//# sourceMappingURL=visit-record.js.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-record.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"visit-record.js","sourceRoot":"","sources":["../../src/tools/visit-record.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,EACL,WAAW,IAAI,gBAAgB,GAEhC,MAAM,iDAAiD,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAmB,MAAM,aAAa,CAAC;AAInE,MAAM,CAAC,KAAK,UAAU,WAAW,CAAC,CAAoB;IACpD,MAAM,GAAG,GAAG,MAAM,gBAAgB,CAAC,CAAC,CAAC,CAAC;IACtC,OAAO,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC;AACxF,CAAC"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-status-set.d.ts

@@ -0,0 +1,13 @@
+/**
+ * The MCP adapter for `dispatch-visit-status-set`.
+ *
+ * The write itself moved to `platform/lib/dispatch-write` so the field job
+ * sheet can call it without a second implementation. This file's only job is
+ * the shape: a domain outcome becomes a `ToolResult`, with the refusal text
+ * unchanged so the agent-facing wording does not drift.
+ */
+import { type VisitStatusSetParams } from "../../../../../lib/dispatch-write/dist/index.js";
+import { type ToolResult } from "./result.js";
+export type { StatusSource, VisitStatusSetParams, } from "../../../../../lib/dispatch-write/dist/index.js";
+export declare function visitStatusSet(p: VisitStatusSetParams): Promise<ToolResult>;
+//# sourceMappingURL=visit-status-set.d.ts.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-status-set.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"visit-status-set.d.ts","sourceRoot":"","sources":["../../src/tools/visit-status-set.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,EAEL,KAAK,oBAAoB,EAC1B,MAAM,iDAAiD,CAAC;AACzD,OAAO,EAAuB,KAAK,UAAU,EAAE,MAAM,aAAa,CAAC;AAEnE,YAAY,EACV,YAAY,EACZ,oBAAoB,GACrB,MAAM,iDAAiD,CAAC;AAEzD,wBAAsB,cAAc,CAAC,CAAC,EAAE,oBAAoB,GAAG,OAAO,CAAC,UAAU,CAAC,CAGjF"}

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-status-set.js

@@ -0,0 +1,15 @@
+/**
+ * The MCP adapter for `dispatch-visit-status-set`.
+ *
+ * The write itself moved to `platform/lib/dispatch-write` so the field job
+ * sheet can call it without a second implementation. This file's only job is
+ * the shape: a domain outcome becomes a `ToolResult`, with the refusal text
+ * unchanged so the agent-facing wording does not drift.
+ */
+import { visitStatusSet as visitStatusSetWrite, } from "../../../../../lib/dispatch-write/dist/index.js";
+import { toolError, toolText } from "./result.js";
+export async function visitStatusSet(p) {
+    const out = await visitStatusSetWrite(p);
+    return out.ok ? toolText(JSON.stringify(out.value, null, 2)) : toolError(out.message);
+}
+//# sourceMappingURL=visit-status-set.js.map

package/payload/platform/plugins/dispatch/mcp/dist/tools/visit-status-set.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"visit-status-set.js","sourceRoot":"","sources":["../../src/tools/visit-status-set.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AACH,OAAO,EACL,cAAc,IAAI,mBAAmB,GAEtC,MAAM,iDAAiD,CAAC;AACzD,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAmB,MAAM,aAAa,CAAC;AAOnE,MAAM,CAAC,KAAK,UAAU,cAAc,CAAC,CAAuB;IAC1D,MAAM,GAAG,GAAG,MAAM,mBAAmB,CAAC,CAAC,CAAC,CAAC;IACzC,OAAO,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC,QAAQ,CAAC,IAAI,CAAC,SAAS,CAAC,GAAG,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC,GAAG,CAAC,OAAO,CAAC,CAAC;AACxF,CAAC"}

package/payload/platform/plugins/dispatch/mcp/package.json

@@ -0,0 +1,21 @@
+{
+  "name": "@maxy/dispatch",
+  "version": "0.1.0",
+  "private": true,
+  "type": "module",
+  "main": "dist/index.js",
+  "scripts": {
+    "build": "tsc",
+    "start": "node dist/index.js",
+    "test": "vitest run"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.12.1",
+    "neo4j-driver": "^5.28.1"
+  },
+  "devDependencies": {
+    "typescript": "^5.7.0",
+    "@types/node": "^22.0.0",
+    "vitest": "^4.1.2"
+  }
+}

package/payload/platform/plugins/dispatch/skills/dispatch-setup/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: dispatch-setup
+description: "Use when an account is switching on dispatch and needs its config.json authored, or when its statuses, job types, worker roster, checklists or vocabulary need changing. Triggers include 'set up dispatch', 'add a job status', 'add an engineer to the roster', 'we call them drivers not engineers', 'why is nobody offered for this job type', and any dispatch tool refusing with reason=no-config."
+---
+
+# Dispatch setup
+
+Author `$ACCOUNT_DIR/dispatch/config.json`. Until it exists and validates, every dispatch tool
+registers and refuses with `reason=no-config`.
+
+## What success looks like
+
+A file that `dispatch-config-get` reads back without complaint, describing **this** operator's work
+in **this** operator's words. Six keys:
+
+| Key | What it holds |
+|---|---|
+| `statuses` | `job[]` and `visit[]`, each `{name, terminal}`; `jobTransitions[]` and `visitTransitions[]` as explicit `[from, to]` pairs |
+| `jobTypes` | `{name, requiredQualification, defaultDurationMin, slaTargetHours?}` |
+| `workers` | `{workerId, name, qualifications[], workingHours}` |
+| `records` | `checklists` keyed by job type; `requiredBeforeTerminal` keyed by terminal visit status, values from `notes`, `media`, `parts`, `checklist`, `signature` |
+| `vocabulary` | the operator's own noun for `job`, `visit`, `worker` |
+| `vehicles` | `{enabled, defaultGeofenceRadiusM?}` |
+
+## Two constraints the file must satisfy before it is written
+
+**Every status is reachable.** A status that is not the first of its kind and is not the `to` of any
+transition can never be entered. Nothing fails when this is wrong — no transition ever fires, and
+that is indistinguishable from a status nobody happens to use. `dispatch-config-get` reports it as
+`unreachable`.
+
+**Every job type has at least one qualified worker.** A type whose `requiredQualification` no worker
+holds offers nobody, for ever, with no error. `dispatch-config-get` reports it as
+`typesWithNoQualifiedWorker`.
+
+Both are reported rather than blocked, because an operator mid-way through hiring legitimately has a
+type nobody covers yet. Say so plainly rather than writing the file silently.
+
+## How to elicit it
+
+Ask what the operator already says, not what the schema wants. "What do you call the thing you send
+someone out to do?" gives you `vocabulary.job`. "Walk me through one from the phone ringing to the
+invoice" gives you the statuses in order, and the order gives you the transitions. "Who could do
+that one, and who couldn't?" gives you the qualification, which is usually a certificate or a
+licence they will name unprompted.
+
+Do not offer a default status set. A borrowed status list is how an operator ends up with statuses
+they never use and no status for the one thing they do daily.
+
+`workingHours` is `{ "mon": ["08:00", "17:00"] }` per day worked; an absent day means not working.
+A worker with no qualification recorded is accepted and reported, because a new starter is real.
+
+## Changing an existing config
+
+Read the current file first and change only what was asked. Removing a status that live jobs are
+sitting in strands them: nothing can move them, because no transition names a status that no longer
+exists. Check with `dispatch-job-list` before removing any status, and say what you found.
+
+## What this skill does not do
+
+It creates no `:Site`, `:Customer`, `:Person:Engineer` or `:Vehicle` node. A `workerId` in the
+roster must have a matching `:Person:Engineer` on the account before `dispatch-allocate` will use
+it, created with `memory-update`. Say this at the end of setup rather than letting the first
+allocation discover it.

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

@@ -111,59 +111,27 @@ JSONL and the real follower.
 | `whatsapp-channel/src/server.ts:620` | `consumedInbounds <= 0` (2nd follower) | `no-consumed-inbound` |
 
 ```
-[<door>-channel]     op=turn-drop sessionId=… messageId=… finalBytes=… reason=…
-[<door>-turn-census] op=census sessionId=… pending=… held=<0|1> heldMessageId=… heldAgeMs=… lastMessageId=…
+[channel-fanout] op=fan-out reached=… notReached=… segments=… messageId=… sessionId=…
+[channel-parity] op=parity-census sessionId=… rendered=… sent=… missing=… missingIds=…
 ```
 
-Any `op=turn-drop` with `finalBytes>0` is a lost answer. The census runs every
-60 s per follower; `held=1` with `heldAgeMs` rising across ticks is a hold that
-never resolved, and `pending` not returning to 0 with no inbound in flight is
-credit drift.
+`missing` above zero is a lost answer, and `missingIds` names each one. The
+census prints every cycle, including when the counts agree: an absent line means
+the census stopped, never that delivery is healthy.
 
-**Read them in the right file.** Both lines are emitted by the *channel MCP
-server*, whose stderr is teed to `${LOG_DIR}/mcp-<serverName>-<sessionId>.log`
-(`claude-session-manager/src/channel-spawn-tee.ts`). They are **never** in
-`server.log`, which carries the gateway-side half only — `op=turn-end`,
-`op=turn-answer-absent`, `delivered=`. Grepping `server.log` for a drop returns
-nothing and means nothing.
+**Read them in `server.log`.** Both are emitted by the ui-server, which now owns
+the one emitter between the session JSONL and every channel. The per-door
+`op=turn-drop` and `op=census` lines that used to sit in
+`${LOG_DIR}/mcp-<serverName>-<sessionId>.log` are gone with the per-channel
+followers that were removed, and so is `delivered=fallback`, which no code
+emits.
 
 ```bash
-# the discard and the hold, per session
-grep -E 'op=(turn-drop|census)' ~/.<brand>/logs/mcp-telegram-channel-*.log | tail -20
-# the gateway's view of the same turn
-grep -E 'op=(turn-end|turn-answer-absent)' ~/.<brand>/logs/server.log | grep <sessionId>
+# every answer and where it went
+grep -E 'op=(fan-out|parity-census)' ~/.<brand>/logs/server.log | tail -20
+# one session
+grep 'op=fan-out' ~/.<brand>/logs/server.log | grep <sessionId>
 ```
-
-**A seventh discard site, and the one nothing was reading.** An answer that
-survived every guard above could still be produced and thrown away at the last
-step, because the gateway resolved its destination from admin identity rather
-than from the channel it came in on. A public visitor has no admin identity, so
-the resolver returned no target: nothing was attempted, no transport failed, and
-the line read `reached=none notReached=none`.
-
-The turn-end body now carries the channel server's own spawn `role`, and that is
-the only thing that decides the destination:
-
-| `role=` | Where the answer goes | `op=fan-out` |
-|---|---|---|
-| `public` | every segment through the posting key's own transport; no identity resolver, no registry read | never emitted |
-| `admin` | every live door the person is reachable on, via `fanTargetsFor` | emitted |
-| absent or unrecognised | nowhere. 400, plus one `op=turn-role-absent … evicted=<yes\|no>` | never emitted |
-
-`op=turn-end` and `op=turn-strand-anomaly` both name the role, so no outcome is
-unattributable.
-
-A roleless POST has one cause: a channel server from a build predating the field,
-still attached to a session that outlived the platform restart. It reconnects its
-stream, so nothing respawns it, and left alone it would post roleless turn-ends for
-the life of that session. `evicted=yes` says the gateway dropped its subscriber, so
-the next inbound spawns a server on the current build: one turn is lost per session
-rather than all of them. That turn's answer is deliberately not delivered to the
-posting key, because doing so would restore the very fallback whose reachability hid
-the original defect. The standing check is one line per door per minute, over a
-rolling hour:
-
-```bash
 # the standing read; any undeliveredPublic>0 is a failure
 grep -E 'op=census' ~/.<brand>/logs/server.log | grep delivery-census | tail -5
 # a visitor's answer that reached nobody, or a turn-end that named no role

package/payload/platform/plugins/docs/references/dispatch.md

@@ -0,0 +1,159 @@
+# Dispatch
+
+Field-work dispatch: create a job, allocate it to a qualified worker, move it through the account's
+own statuses, record what happened on site. Admin agent only, ten tools, ships inert.
+
+## Enabling it
+
+`dispatch` is in `plugins.available` on all four brands and in `defaultEnabled` on none. An account
+adds it to `enabledPlugins`, then runs the `dispatch-setup` skill to author
+`$ACCOUNT_DIR/dispatch/config.json`. Until that file exists and validates, every tool registers and
+refuses per call with `reason=no-config`.
+
+Enabling it also puts `schema-dispatch.md` in the account's resolved verticals, beside
+`schema-base` and the account's own businessType vertical. That is what makes `:Job`, `:Visit`,
+`:Site`, `:Customer`, `:Asset`, `:Part`, `:JobCost`, `:Contact`, job `:Note` and `:Engineer`
+writable from any businessType rather than from construction alone.
+
+## The config is the vocabulary and the rules
+
+Six keys in `$ACCOUNT_DIR/dispatch/config.json`: `statuses` (job and visit lists, each entry
+`{name, terminal}`, plus `jobTransitions` and `visitTransitions` as explicit `[from, to]` pairs),
+`jobTypes` (`{name, requiredQualification, defaultDurationMin, slaTargetHours?}`), `workers`
+(`{workerId, name, qualifications[], workingHours}`), `records` (`checklists` per job type,
+`requiredBeforeTerminal` per terminal visit status), `vocabulary` (`job`, `visit`, `worker`), and
+`vehicles` (`{enabled, defaultGeofenceRadiusM?}`).
+
+No status, job type, qualification, checklist, SLA target or operator noun appears in plugin source.
+A test walks every source file and fails if any string from either shipped fixture config appears in
+it.
+
+## The ten tools
+
+| Tool | Does | Refuses when |
+|---|---|---|
+| `dispatch-config-get` | Returns the vocabulary, statuses, transitions, job types, roster, checklists and the config audit | no config |
+| `dispatch-job-create` | Raises a job at a site for a customer, in the account's first job status, with `slaTargetAt` computed from the type | unknown job type; site or customer does not exist |
+| `dispatch-job-get` | One job with every visit, its times, who attended and what was recorded | job not on this account |
+| `dispatch-job-list` | Jobs filtered by status, type, worker, date window, or narrowed to never-allocated. `overdue` computed on every read | status not declared |
+| `dispatch-allocate-candidates` | Who could take this job in this window, with clashes shown and exclusions named | job unknown, untyped, or typed to something no longer declared |
+| `dispatch-allocate` | Creates the visit, attends it, moves the job along its own edge, attaches a vehicle | worker not on the roster; worker lacks the qualification; vehicle passed while `vehicles.enabled` is false; no `:Person:Engineer` node for the workerId |
+| `dispatch-visit-status-set` | Moves a visit; closes the job when its last visit reaches a terminal status | status not declared; transition not in the edge list; a required record missing |
+| `dispatch-visit-record` | Note, media reference, fitted part, checklist item, signature, arrival | visit unknown; nothing supplied to record |
+| `dispatch-site-history` | Every visit at one site, newest first, with notes | — |
+| `dispatch-day` | One day: every worker with the visits they hold, plus jobs nobody has been sent to | — |
+
+All ten are `adminAllowlist: true`, `publicAllowlist: false`.
+
+## Legality is data
+
+A move is legal when the account's own transition list contains that `[from, to]` pair. There is no
+state machine in the code. A refusal names both ends:
+`op=transition-refused … from=X to=Y reason=not-in-config`.
+
+A move into a terminal status is refused a second way when the visit is missing a field
+`records.requiredBeforeTerminal` demands there, and that refusal names the field:
+`reason=missing-required-field:notes`.
+
+Neither refusal is swallowed. A status that quietly failed to change cannot be told apart from one
+nobody tried to change.
+
+## A busy worker is offered, not hidden
+
+Only a missing qualification excludes a worker, and every exclusion is named:
+`exclusions=w1:missing-qualification`. A qualified worker already committed in the window is offered
+with the clash shown. Double-booking is the office's decision, and a tool that drops the busy option
+makes that decision for them with no trace.
+
+There is no travel-time estimate.
+
+## Arrival is two properties
+
+`arrivedPressedAt` and `arrivedObservedAt` are written by separate `SET` clauses, so recording
+either never clears the other. An observation with no press is stored and flagged. A pressed arrival
+is what somebody said; an observed one is what was measured, and a single `arrivedAt` cannot show
+them disagreeing.
+
+## The standing checks
+
+Six failure modes emit no event, because no action occurs: a job created and never allocated, a job
+past its SLA target, a status no transition reaches, a job type no worker is qualified for, a worker
+with no qualification, and visits closing hours after the work ended.
+
+- `[dispatch-census]`, per account, every 15 minutes: `jobs= unallocated= oldestUnallocatedAgeH=
+  overdue= visitsOpen= visitsOpenOver24h=`
+- `[dispatch-config-audit]`, on config load and each tick: `statuses= unreachable= terminal=
+  jobTypes= typesWithNoQualifiedWorker= workersWithNoQualification=`
+- `[dispatch-record-census]`, daily: `closedVisits= withNote= withMedia= medianRecordLagS=
+  p90RecordLagS=`
+
+They run in the UI server, not in the plugin, because a plugin only runs when somebody calls it.
+Accounts without a dispatch config are skipped silently.
+
+`overdue` is the count a typical incumbent system reports as zero because response-time targets were
+never configured. A non-zero, believable number is the feature working.
+
+The absence of `[dispatch-census]` is itself the signal: the check died, and every count is stale
+rather than zero.
+
+## The office planner
+
+`/dispatch` is an admin surface that renders a dispatch day: worker rows against days over a
+selectable range, a job list with true counts, and each visit's status with its pressed and
+observed arrival side by side. It reads; it does not yet re-time or re-allocate.
+
+It does not call these tools. Both it and this plugin read through `platform/lib/dispatch-read`,
+which owns its Neo4j session, so the planner's route holds no graph credentials and issues no
+Cypher — asserted by a test rather than trusted. This plugin's `mcp/src/lib/read.ts` is a
+re-export of that lib, so the tools and the planner cannot disagree about what a filter means.
+
+Two things the planner computes for itself. `dispatch-day` bounds a day in UTC, which misplaces a
+Europe/London visit near local midnight for the whole of British Summer Time, so the planner
+derives boundaries in the account's own timezone. And `dispatch-job-list` caps its rows, so the
+planner takes its counts from an aggregate instead of counting what it was given.
+
+It also names a defect it cannot fix. `dispatch-allocate` stores `startDate` exactly as the caller
+passed it (`allocate.ts:186`) while normalising `endDate` (`allocate.ts:51`). The window compare is
+lexical, so a start carrying a non-UTC offset reads correctly under GMT and an hour out under
+British Summer Time. The planner logs `op=nonzulu-start` with the offending visit ids; correcting
+it belongs at the writer.
+
+Full detail: [`.docs/dispatch-planner.md`](../../../.docs/dispatch-planner.md).
+
+## The field job sheet
+
+The engineer's surface is his phone, so the detailed record is made in a Telegram Mini App: the sheet
+opens inside the chat he is already in, with nothing installed and no second login.
+
+Set it up once per bot:
+
+1. Run `telegram-menu-button` with the bot's token and the account's public https origin. Give the
+   origin only — the tool appends `/field` and stamps the bot id on itself.
+2. Give each worker in `dispatch/config.json` a `telegramUserId` matching their numeric Telegram id.
+   Without one the sheet refuses them with "Ask the office to add you as an engineer."
+
+The worker then taps the menu button and sees today's visits, in the order they will be done, each
+card carrying the site, the customer, the contact and what was reported. Opening one shows the
+site's previous visits with their notes and photograph counts, then the checklist for that job type,
+parts, both signatures and a free note. Completion is refused, naming the one missing field, when
+the account's `requiredBeforeTerminal` is not satisfied.
+
+Every refusal is named and none of them shows a login form. `unbound-user` is the office's to fix;
+`bad-hash` and `duplicate-bot` mean something is wrong rather than missing.
+
+Two limits worth knowing before you deploy it. There is no offline queue yet, so an edit made out of
+signal is refused rather than held; the sheet says so rather than appearing to save it. And a site
+carries no address, because the ontology has none to carry, so a card names the site but cannot give
+a street. `sitesVisitedTodayWithoutAddress=` on the census counts what that costs each day. Both are
+tracked work, not permanent limits.
+
+Full detail: [`.docs/dispatch-field-app.md`](../../../.docs/dispatch-field-app.md).
+
+## Diagnostic path
+
+```
+journalctl --user -u <brand>-* | grep -E '\[dispatch\]|\[dispatch-census\]|\[dispatch-config-audit\]|\[dispatch-record-census\]|\[dispatch-field\]|\[dispatch-field-census\]'
+```
+
+Then filter by `jobId=` for one job's lifeline, `op=transition-refused` to audit rejected writes, or
+`exclusions=` to see why allocation offered whom.

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

@@ -75,3 +75,26 @@ Two things to know:
 
 Text only for now. Photos, files and voice notes are not available on Telegram
 from the dashboard.
+
+## Building your own Telegram functionality
+
+Telegram is a core plugin, so it is on every install and cannot be switched off.
+
+Beyond sending and reading messages, {{productName}} can reach every one of the
+185 things Telegram's Bot API can do: buttons under a message, changing a
+message after you sent it, uploading a photo or a document, pinning, polls, chat
+administration, and opening a small web page inside the Telegram chat itself.
+
+Just ask for what you want. "Send the team a message with Yes and No buttons",
+"update that job card to say he's on site", "pin the rota to the group".
+{{productName}} loads its Telegram build skill, which lists every available
+method and how to call it.
+
+Five of the 185 are deliberately refused, because they would break your own
+inbound messages: setting or deleting the webhook by hand, polling Telegram for
+updates instead, and the two that move the bot off Telegram's cloud servers.
+Setting up or repointing a webhook is what the Telegram setup skill is for.
+
+If Telegram publishes a new capability it works here immediately, with nothing
+released first. A scheduled check reconciles what {{productName}} knows about
+against Telegram's live documentation and reports anything that changed.

package/payload/platform/plugins/email/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "email",
-  "description": "Email — one or more dedicated email mailboxes per account, each addressable by a `mailbox` selector. Retrieval: email-graph-query for stored email-thread history as :ConversationArchive {source:'email'} with :Section chunks (recall, search, 'threads about X', 'what did Y send?'); email-read / email-search for live IMAP inbox previews (with best-effort per-archive section hints from the graph); email-fetch-body for the COMPLETE decoded body of one message (by uid or message_id) when a preview is not enough; email-fetch-attachment for the extracted TEXT of one attachment (PDF via pdftotext, text/* by decode) when data sits inside a file rather than the body. Ingestion (operator-initiated, human-in-the-loop): email-fetch lists new messages, email-ingest writes the operator-approved subset via the conversation-archive pipeline. Sending: email-send (new), email-reply (threaded — resolves the original via IMAP Message-ID search), email-draft (compose to the mailbox Drafts folder, unsent, for operator review; pass messageId for a threaded draft-reply), email-draft-edit (revise a stored draft, located by its Drafts UID or, when Gmail has renumbered it, its draft Message-ID), email-draft-send (dispatch a stored draft by Drafts UID, then remove it), email-draft-list (read the Drafts folder back and confirm what is actually in it — the only tool that can verify a draft's presence). Deleting: email-delete (move named UIDs from email-read/email-search to the mailbox Trash — recoverable, never an expunge). Config: email-provider-info (pre-password host + app-password lookup from an address alone), email-setup, email-signature-set (install the signature every email-draft then appends automatically — never hand-write a signature into a draft body), email-sending-identity-set (designate which attached mailbox this account sends from, so a send or draft that names no mailbox resolves it from the account instead of being refused), email-status, email-otp-extract.",
+  "description": "Email — one or more dedicated email mailboxes per account, each addressable by a `mailbox` selector. Retrieval: email-graph-query for stored email-thread history as :ConversationArchive {source:'email'} with :Section chunks (recall, search, 'threads about X', 'what did Y send?'); email-read / email-search for live IMAP inbox previews (with best-effort per-archive section hints from the graph); email-fetch-body for the COMPLETE decoded body of one message (by uid or message_id) when a preview is not enough; email-fetch-attachment for the extracted TEXT of one attachment (PDF via pdftotext, text/* by decode) when data sits inside a file rather than the body. Ingestion (operator-initiated, human-in-the-loop): email-fetch lists new messages, email-ingest writes the operator-approved subset via the conversation-archive pipeline. Sending: email-send (new), email-reply (threaded — resolves the original via IMAP Message-ID search), email-draft (compose to the mailbox Drafts folder, unsent, for operator review; pass messageId for a threaded draft-reply), email-draft-edit (revise a stored draft, located by its Drafts UID or, when Gmail has renumbered it, its draft Message-ID), email-draft-send (dispatch a stored draft by Drafts UID, then remove it), email-draft-list (read the Drafts folder back and confirm what is actually in it — the only tool that can verify a draft's presence). Deleting: email-delete (move named UIDs to the mailbox Trash — recoverable, never an expunge; folder inbox/sent take UIDs from email-read/email-search, folder drafts takes them from email-draft-list and accepts a draftMessageId because a draft is renumbered on every edit). Config: email-provider-info (pre-password host + app-password lookup from an address alone), email-setup, email-signature-set (install the signature every email-draft then appends automatically — never hand-write a signature into a draft body), email-sending-identity-set (designate which attached mailbox this account sends from, so a send or draft that names no mailbox resolves it from the account instead of being refused), email-status, email-otp-extract.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

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

@@ -1,6 +1,6 @@
 ---
 name: email
-description: "Email — one or more dedicated email mailboxes per account, each addressable by a `mailbox` selector. Retrieval: email-graph-query for stored email-thread history as :ConversationArchive {source:'email'} with :Section chunks (recall, search, 'threads about X', 'what did Y send?'); email-read / email-search for live IMAP inbox previews (with best-effort per-archive section hints from the graph); email-fetch-body for the COMPLETE decoded body of one message (by uid or message_id) when a preview is not enough; email-fetch-attachment for the extracted TEXT of one attachment (PDF via pdftotext, text/* by decode) when data sits inside a file rather than the body. Ingestion (operator-initiated, human-in-the-loop): email-fetch lists new messages, email-ingest writes the operator-approved subset via the conversation-archive pipeline. Sending: email-send (new), email-reply (threaded — resolves the original via IMAP Message-ID search), email-draft (compose to the mailbox Drafts folder, unsent, for operator review; pass messageId for a threaded draft-reply), email-draft-edit (revise a stored draft, located by its Drafts UID or, when Gmail has renumbered it, its draft Message-ID), email-draft-send (dispatch a stored draft by Drafts UID, then remove it), email-draft-list (read the Drafts folder back and confirm what is actually in it — the only tool that can verify a draft's presence). Deleting: email-delete (move named UIDs from email-read/email-search to the mailbox Trash — recoverable, never an expunge). Config: email-provider-info (pre-password host + app-password lookup from an address alone), email-setup, email-signature-set (install the signature every email-draft then appends automatically — never hand-write a signature into a draft body), email-sending-identity-set (designate which attached mailbox this account sends from, so a send or draft that names no mailbox resolves it from the account instead of being refused), email-status, email-otp-extract."
+description: "Email — one or more dedicated email mailboxes per account, each addressable by a `mailbox` selector. Retrieval: email-graph-query for stored email-thread history as :ConversationArchive {source:'email'} with :Section chunks (recall, search, 'threads about X', 'what did Y send?'); email-read / email-search for live IMAP inbox previews (with best-effort per-archive section hints from the graph); email-fetch-body for the COMPLETE decoded body of one message (by uid or message_id) when a preview is not enough; email-fetch-attachment for the extracted TEXT of one attachment (PDF via pdftotext, text/* by decode) when data sits inside a file rather than the body. Ingestion (operator-initiated, human-in-the-loop): email-fetch lists new messages, email-ingest writes the operator-approved subset via the conversation-archive pipeline. Sending: email-send (new), email-reply (threaded — resolves the original via IMAP Message-ID search), email-draft (compose to the mailbox Drafts folder, unsent, for operator review; pass messageId for a threaded draft-reply), email-draft-edit (revise a stored draft, located by its Drafts UID or, when Gmail has renumbered it, its draft Message-ID), email-draft-send (dispatch a stored draft by Drafts UID, then remove it), email-draft-list (read the Drafts folder back and confirm what is actually in it — the only tool that can verify a draft's presence). Deleting: email-delete (move named UIDs to the mailbox Trash — recoverable, never an expunge; folder inbox/sent take UIDs from email-read/email-search, folder drafts takes them from email-draft-list and accepts a draftMessageId because a draft is renumbered on every edit). Config: email-provider-info (pre-password host + app-password lookup from an address alone), email-setup, email-signature-set (install the signature every email-draft then appends automatically — never hand-write a signature into a draft body), email-sending-identity-set (designate which attached mailbox this account sends from, so a send or draft that names no mailbox resolves it from the account instead of being refused), email-status, email-otp-extract."
 tools:
   - name: email-provider-info
     publicAllowlist: false
@@ -120,7 +120,7 @@ Manages the agent's own dedicated email account — IMAP for reading, SMTP for s
 - **Sending identity:** `email-sending-identity-set` — designate which attached mailbox is the account's own outbound address. Afterwards an `email-draft`, `email-send` or `email-reply` that names no `mailbox` composes from it, instead of being refused with a list of addresses. Exactly one mailbox carries the designation: the call clears it from every sibling in the same write, so uniqueness is a property of the write rather than of a later check. The address comes from the operator, never from inference — a routing rule, a signature or an inbound trigger names an address for a different purpose, and reading one of those as the sending address is what put a mailbox the operator never sends from into a draft brief. Re-running `email-setup` on a designated mailbox preserves the designation. `email-status` reports which mailbox holds it, and says so when a multi-mailbox account has none.
 - **Read inbox:** `email-read` — metadata only (UID, sender, subject, date), plus a best-effort `Archive`/`Archive-Section` hint when the IMAP message's `receivedAt` falls inside a stored `:ConversationArchive {source:'email'}` section, plus an `Attachments (N): filename (mime, size); …` footer when the message carries enclosures. Supports pagination (`before_uid`), folders (`inbox`/`sent`), filtering by sender/date/subject. Metadata is derived from IMAP `bodyStructure` — no bytes downloaded.
 - **Search inbox:** `email-search` — live IMAP search by sender, subject, body keyword, date range. Same per-archive hint and attachment footer as `email-read`.
-- **Delete (move to Trash):** `email-delete` — move the messages named by `uids` (from a prior `email-read`/`email-search`, scoped to a source `folder` of `inbox` or `sent`) into the mailbox's Trash folder. **Recoverable, never an expunge** — the message leaves the inbox and permanent removal is left to the operator's own mail client or the provider's Trash auto-purge; this tool never permanently deletes. Trash is resolved per provider: the `\Trash` special-use folder if advertised, else the first existing of `Trash`, `[Gmail]/Trash`, `Deleted Items`, `Deleted Messages`. `Junk` is never treated as Trash. A mailbox with no resolvable Trash yields a typed error and moves nothing — there is no silent expunge fallback. A `uid` that is already gone is counted not-moved without failing the rest; the result reports `Moved N of M message(s) to <Trash>`. It deletes only the UIDs you name, never by search criteria.
+- **Delete (move to Trash):** `email-delete` — move the messages named by `uids` (from a prior `email-read`/`email-search`, scoped to a source `folder` of `inbox`, `sent`, or `drafts`) into the mailbox's Trash folder. **Recoverable, never an expunge** — the message leaves the inbox and permanent removal is left to the operator's own mail client or the provider's Trash auto-purge; this tool never permanently deletes. Trash is resolved per provider: the `\Trash` special-use folder if advertised, else the first existing of `Trash`, `[Gmail]/Trash`, `Deleted Items`, `Deleted Messages`. `Junk` is never treated as Trash. A mailbox with no resolvable Trash yields a typed error and moves nothing — there is no silent expunge fallback. A `uid` that is already gone is counted not-moved without failing the rest; the result reports `Moved N of M message(s) to <Trash>`. It deletes only the UIDs you name, never by search criteria. Deleting a draft uses `folder: "drafts"` with a UID from `email-draft-list`; because a draft is renumbered every time it is edited, pass `draftMessageId` as well and the tool relocates by the draft's own Message-ID when the UID no longer resolves. The Drafts folder is resolved by the account's configured `draftsFolder` override when set, else by the `\Drafts` special-use flag.
 - **Read one attachment's text:** `email-fetch-attachment` — the extracted text of a single inbox attachment, addressed by `uid` plus an optional `index` (1-based, matching the `Attachments (N): …` footer order) or `filename`. With one attachment and no selector, that attachment is read; with more than one and no selector, or an ambiguous filename, the call is refused with a numbered listing. `application/pdf` is extracted via `pdftotext`, `text/*` by decode; any other type reports that it cannot be extracted, and a PDF with no text layer reports it is a scanned image (no OCR), so "no data in the attachment" never reads the same as "the attachment could not be read". Bytes are downloaded once through the 25 MB-capped fetch path; inbox only. A `text/calendar` part counts as an attachment whatever its disposition and whatever its name — a named one keeps its name, an unnamed one is listed as `invite-<part>.ics` — so a meeting invite whose message body is empty is still readable. A calendar part inside a forwarded `message/rfc822` wrapper is not listed (IMAP gives it the wrapper's part number, which fetches the whole encapsulated message). Use this when actionable data (a meeting date, an amount) may sit inside a file rather than the email body.
 - **Read one whole message:** `email-fetch-body` — the COMPLETE decoded body of a single message addressed by `uid` (with optional `folder`) or `message_id` (resolved across inbox and sent). No 500-char preview cap. Downloads the full RFC822 source and decodes it with `mailparser`, so every MIME shape — flat text, single-part HTML, `multipart/alternative`, and nested `multipart/related`/`multipart/mixed` (Outlook's inline-image house style) — yields a body; the preview tools above intentionally stay preview-only. Use this when the operator wants to read or act on a message's actual content.
 - **Send:** `email-send` — new outbound email. Pass `cc`/`bcc` (each an array of email addresses) to copy or blind-copy recipients — CC appears in the message header, BCC recipients receive the message without appearing in any header. Pass `attachments` (absolute file paths under the account directory, ≤25 MB each) to attach files as SMTP attachments; an invalid path fails the send with no email dispatched. The success message names the CC recipients and reports the BCC count without naming them.
@@ -133,7 +133,7 @@ Manages the agent's own dedicated email account — IMAP for reading, SMTP for s
 
   **Never state an unverified cause.** When the draft is confirmed present and the customer's client still does not show it, the honest report is exactly that: the draft is on the server, and the client-side reason is unknown. Do not offer a mail-app setting, a sync toggle or a provider option as the cause unless it has been verified. A successful IMAP write to and read of the Drafts folder proves the folder is exposed over IMAP, so provider "show in IMAP" settings are excluded by the evidence rather than being candidates for it.
 
-- **Send a draft:** `email-draft-send` — dispatch a stored draft addressed by its Drafts UID via SMTP, then relocate it into `\Sent`. Recipients come from the draft's own To/Cc/Bcc headers (the `\Drafts` copy keeps its `Bcc:`), deduped, sent from the agent alias with an explicit SMTP envelope. The draft is relocated only after SMTP accepts; an SMTP failure leaves it in place and surfaces verbatim. A draft with no recipients is refused before sending. Operator-approved sends only.
+- **Send a draft:** `email-draft-send` — dispatch a stored draft addressed by its Drafts UID via SMTP, then relocate it into `\Sent`. Recipients come from the draft's own To/Cc/Bcc headers (the `\Drafts` copy keeps its `Bcc:`), deduped, sent from the agent alias with an explicit SMTP envelope. The draft is relocated only after SMTP accepts; an SMTP failure leaves it in place and surfaces verbatim. A draft with no recipients is refused before sending. On Gmail the draft is deleted *before* SMTP instead, because Gmail suppresses Sent-filing against a duplicate Message-ID. A delete the server refuses stops the send there, before SMTP, naming the UID and folder. Operator-approved sends only.
 - **The Sent copy is verified, not assumed.** All three send paths read `\Sent` back after SMTP acceptance and search it by Message-ID, then state what is actually there as a fact separate from the send. A folder and UID are named only when they were read back; "no copy was found", "this server advertises no `\Sent` folder", and "the Sent folder could not be checked" are reported as three distinct outcomes, never collapsed. A send whose copy cannot be located is still a successful send. Each send also appends its observed outcome to `config/email-sent-ledger.jsonl`, and the install heartbeat spawns `dist/scripts/sent-copy-sweep.js` hourly to ask `\Sent`, per mailbox, whether each Message-ID sent in the trailing 24 h is actually present (`[email-sent-sweep] op=reconcile …`). Presence is asked per Message-ID rather than by comparing folder totals, because `\Sent` also holds everything the owner sends from other clients. See [`references/email-reference.md`](references/email-reference.md).
 - **Ingestion — fetch:** `email-fetch` — list new IMAP messages since the stored high-water mark. Metadata + body preview only — including attachment names, mimetypes, and sizes so the operator sees what's attached before approving. No bytes downloaded, no graph writes. Stages the batch in-memory for `email-ingest`.
 - **Ingestion — apply:** `email-ingest` — apply the operator's per-message decisions to the staged batch. Each Message-ID must carry a disposition (`ingest` or `discard`). Approved messages land on `:ConversationArchive {source:'email'}` via the source-agnostic conversation-archive pipeline (one archive per thread, sessionised into `:Section` chunks). Attachment bytes are fetched, archived to `{accountDir}/archive/email/<uidValidity>-<uid>/<sha256>-<filename>` (0o600, 25 MB cap), and each attachment lands as a content-addressed `:DigitalDocument` keyed on `attachmentId = sha256(bytes)`; the `:HAS_ENCLOSURE` edge from the parent `:ConversationArchive` is wired by `memory-ingest` on its next pass via the `pendingArchiveEdges` queue. Advances the inbox high-water mark only after a successful write.