@rubytech/create-sitedesk-code 0.1.518 → 0.1.520

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

@@ -48,7 +48,7 @@ export async function processUpload(
   // printed a hardcoded ms=0, which an operator reads as "took no time" rather
   // than "was never measured".
   const startedMs = now()
-  const session = await resolveSession(env.DB, sessionId, startedMs)
+  const session = await resolveSession(env.DB, sessionId, env.PORTAL_ACCOUNT_ID, startedMs)
   if (!session) {
     log('[data-portal] op=upload owner=none result=denied')
     return { status: 401, payload: { ok: false, error: 'denied' } }
@@ -63,7 +63,7 @@ export async function processUpload(
 
   // The target is resolved BEFORE any R2 call, the same ordering rule the owner
   // gate follows: a denied caller must never be able to cause a store write.
-  const target = await checkTarget(env.DB, session.accountId, session.folders, targetPath)
+  const target = await checkTarget(env.DB, env.PORTAL_ACCOUNT_ID, session.folders, targetPath)
   if (!target.ok) {
     log(
       `[data-portal] op=target-check uploadId=${uploadId} owner=${q(owner)} ` +
@@ -76,10 +76,11 @@ export async function processUpload(
       `targetPath=${q(targetPath)} result=allowed`,
   )
 
-  const key = uploadKey(owner, targetPath, filename)
-  // The key is derived from the session owner, then re-checked through the same
-  // gate the other routes use — a filename carrying '..' must not escape.
-  if (!authorizeKey(owner, key)) {
+  const key = uploadKey(env.PORTAL_ACCOUNT_ID, owner, targetPath, filename)
+  // The key is derived from this portal's account and the session owner, then
+  // re-checked through the same gate the other routes use — a filename carrying
+  // '..' must not escape.
+  if (!authorizeKey(env.PORTAL_ACCOUNT_ID, owner, key)) {
     log(`[data-portal] op=request uploadId=${uploadId} owner=${q(owner)} result=bad-filename`)
     return { status: 400, payload: { ok: false, error: 'invalid filename' } }
   }
@@ -143,8 +144,9 @@ export async function processUpload(
   // request time, which is why this line exists.
   const objectPresent = (await env.BUCKET.head(key)) !== null
   const rowPresent =
-    (await env.DB.prepare('SELECT fileId FROM manifest WHERE objectKey = ?').bind(key).first()) !==
-    null
+    (await env.DB.prepare('SELECT fileId FROM manifest WHERE objectKey = ? AND accountId = ?')
+      .bind(key, env.PORTAL_ACCOUNT_ID)
+      .first()) !== null
   log(
     `[data-portal] op=complete uploadId=${uploadId} ms=${now() - startedMs} objectPresent=${objectPresent} rowPresent=${rowPresent}`,
   )
@@ -158,10 +160,14 @@ async function writeManifestRow(
   env: PortalEnv,
   row: { fileId: string; owner: string; filename: string; key: string; size: number; at: string; targetPath: string },
 ): Promise<void> {
+  // The row carries its account and the upsert conflicts on (accountId,
+  // objectKey). Conflicting on objectKey alone would be a takeover on the
+  // shared store: another client's upload at the same key would seize the
+  // existing row, reset its ingested flag, and redirect the file.
   await env.DB.prepare(
-    `INSERT INTO manifest (fileId, ownerId, filename, objectKey, size, uploadedAt, ingested, targetPath)
-       VALUES (?, ?, ?, ?, ?, ?, ?, ?)
-       ON CONFLICT (objectKey) DO UPDATE SET
+    `INSERT INTO manifest (fileId, accountId, ownerId, filename, objectKey, size, uploadedAt, ingested, targetPath)
+       VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
+       ON CONFLICT (accountId, objectKey) DO UPDATE SET
          fileId = excluded.fileId,
          size = excluded.size,
          uploadedAt = excluded.uploadedAt,
@@ -170,7 +176,17 @@ async function writeManifestRow(
          devicePath = '',
          deleted = 0`,
   )
-    .bind(row.fileId, row.owner, row.filename, row.key, row.size, row.at, 0, row.targetPath)
+    .bind(
+      row.fileId,
+      env.PORTAL_ACCOUNT_ID,
+      row.owner,
+      row.filename,
+      row.key,
+      row.size,
+      row.at,
+      0,
+      row.targetPath,
+    )
     .run()
 }
 
@@ -192,7 +208,7 @@ export async function processMultipartCreate(
   now: () => number,
 ): Promise<Handler> {
   const startedMs = now()
-  const session = await resolveSession(env.DB, sessionId, startedMs)
+  const session = await resolveSession(env.DB, sessionId, env.PORTAL_ACCOUNT_ID, startedMs)
   if (!session) {
     log('[data-portal] op=mp-create owner=none result=denied')
     return { status: 401, payload: { ok: false, error: 'denied' } }
@@ -215,7 +231,7 @@ export async function processMultipartCreate(
     }
   }
 
-  const target = await checkTarget(env.DB, session.accountId, session.folders, targetPath)
+  const target = await checkTarget(env.DB, env.PORTAL_ACCOUNT_ID, session.folders, targetPath)
   if (!target.ok) {
     log(
       `[data-portal] op=target-check uploadId=${uploadId} owner=${q(owner)} ` +
@@ -224,8 +240,8 @@ export async function processMultipartCreate(
     return { status: 403, payload: { ok: false, error: 'target not allowed' } }
   }
 
-  const key = uploadKey(owner, targetPath, filename)
-  if (!authorizeKey(owner, key)) {
+  const key = uploadKey(env.PORTAL_ACCOUNT_ID, owner, targetPath, filename)
+  if (!authorizeKey(env.PORTAL_ACCOUNT_ID, owner, key)) {
     log(`[data-portal] op=mp-create uploadId=${uploadId} owner=${q(owner)} result=bad-filename`)
     return { status: 400, payload: { ok: false, error: 'invalid filename' } }
   }
@@ -250,12 +266,15 @@ export async function processMultipartPart(
   env: PortalEnv,
   log: Logger,
 ): Promise<Handler> {
-  const session = await resolveSession(env.DB, sessionId, Date.now())
+  const session = await resolveSession(env.DB, sessionId, env.PORTAL_ACCOUNT_ID, Date.now())
   if (!session) {
     log('[data-portal] op=r2-put owner=none result=denied')
     return { status: 401, payload: { ok: false, error: 'denied' } }
   }
-  if (!authorizeKey(session.ownerId, key)) {
+  // The part key round-trips through the client on every call, so the full
+  // account and owner prefix is re-checked here rather than trusted from the
+  // create step that minted it.
+  if (!authorizeKey(env.PORTAL_ACCOUNT_ID, session.ownerId, key)) {
     log(`[data-portal] op=r2-put owner=${q(session.ownerId)} result=denied reason=not-owner`)
     return { status: 403, payload: { ok: false, error: 'denied' } }
   }
@@ -311,14 +330,14 @@ export async function processMultipartComplete(
   now: () => number,
 ): Promise<Handler> {
   const startedMs = now()
-  const session = await resolveSession(env.DB, sessionId, startedMs)
+  const session = await resolveSession(env.DB, sessionId, env.PORTAL_ACCOUNT_ID, startedMs)
   if (!session) {
     log('[data-portal] op=mp-complete owner=none result=denied')
     return { status: 401, payload: { ok: false, error: 'denied' } }
   }
   const owner = session.ownerId
   const uploadId = newId()
-  if (!authorizeKey(owner, key)) {
+  if (!authorizeKey(env.PORTAL_ACCOUNT_ID, owner, key)) {
     log(`[data-portal] op=mp-complete uploadId=${uploadId} owner=${q(owner)} result=denied reason=not-owner`)
     return { status: 403, payload: { ok: false, error: 'denied' } }
   }
@@ -366,8 +385,9 @@ export async function processMultipartComplete(
 
   const objectPresent = (await env.BUCKET.head(key)) !== null
   const rowPresent =
-    (await env.DB.prepare('SELECT fileId FROM manifest WHERE objectKey = ?').bind(key).first()) !==
-    null
+    (await env.DB.prepare('SELECT fileId FROM manifest WHERE objectKey = ? AND accountId = ?')
+      .bind(key, env.PORTAL_ACCOUNT_ID)
+      .first()) !== null
   log(
     `[data-portal] op=complete uploadId=${uploadId} ms=${now() - startedMs} ` +
       `objectPresent=${objectPresent} rowPresent=${rowPresent}`,

package/payload/platform/plugins/cloudflare/skills/data-portal/template/wrangler.toml

@@ -1,10 +1,18 @@
 # Cloudflare Pages config for the data portal (data-portal skill).
-# The skill fills the placeholders at assemble time:
+#
+# `bin/portal-assemble.mjs` fills these, and nothing else may: hand-filling them
+# is what shipped a portal whose bucket name and config disagreed (Task 2099).
 #   __PROJECT_NAME__     the Pages project name
-#   __D1_DATABASE_NAME__ the D1 database name  (<accountId>-<purpose>)
-#   __D1_DATABASE_ID__   the id printed by `wrangler d1 create`
-#   __R2_BUCKET_NAME__   the R2 bucket name    (<accountId>-<purpose>)
+#   __D1_DATABASE_NAME__ the ONE shared house database   (DATA_PORTAL_DB_NAME)
+#   __D1_DATABASE_ID__   its id                          (DATA_PORTAL_DB_ID)
+#   __R2_BUCKET_NAME__   the ONE shared house bucket     (DATA_PORTAL_BUCKET)
+#   __PORTAL_ACCOUNT_ID__ this portal's own account id
 #   __PORTAL_INSTALL_ORIGIN__ the install's PUBLIC origin (https://<public-tunnel-hostname>), NOT the admin/operator host
+#
+# The first three come from platform/config/cloudflare-house.env and are
+# IDENTICAL in every portal: one store backs all of them. __PORTAL_ACCOUNT_ID__
+# is what differs, and it is the only thing separating this client's rows and
+# objects from another client's.
 name = "__PROJECT_NAME__"
 pages_build_output_dir = "."
 compatibility_date = "2024-01-01"
@@ -31,4 +39,9 @@ bucket_name = "__R2_BUCKET_NAME__"
 # directory it is handed, so a secret in it is a secret in a repo and one deploy
 # from being served. Set it with `wrangler pages secret put`.
 [vars]
+# The tenant scope for every query and every object key. A var, not a secret:
+# it is this client's own account id, not a credential, and the worker needs it
+# on every request. Its partner PORTAL_FETCH_SECRET stays out of this file for
+# the reason given above.
+PORTAL_ACCOUNT_ID = "__PORTAL_ACCOUNT_ID__"
 PORTAL_INSTALL_ORIGIN = "__PORTAL_INSTALL_ORIGIN__"

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

@@ -79,7 +79,7 @@ either is a regression.
 
 **`/chat` Claude-desktop transcript presentation.** The admin webchat keeps the shared `Transcript` shell (stream, follow-tail) but injects a /chat-only item renderer via the component's optional `renderItems` prop: `renderChatTimeline` in `app/chat/transcript-render.tsx`. Presentation: operator turns render as a right-aligned grey bubble showing the message text and, beneath it, a subtle always-visible time-of-day stamp (no label); delivered agent replies render as plain prose with the same time-of-day stamp beneath (the reply-document filename line stays, as prose); the stamp is HH:MM from the turn's `ts` (locale-formatted, right-aligned inside the operator bubble, left-aligned under agent prose), and a turn whose `ts` is null/unparseable shows no stamp, never an empty line — so only delivered operator and agent-reply turns are stamped, while tool runs, the collapsed "Thinking" block, and the agent-error banner stay time-free; a maximal consecutive run of `tool-call`/`tool-result` turns renders as one collapsed grey one-liner ("Used N tools ›") whose expansion shows every call and result payload — a lone call still gets the one-liner, and prose or a directive row ends a run. The WhatsApp/operator reader (`/whatsapp`, `OperatorConversations`) omits the prop and keeps the default `renderTimeline`, so its bubble/DM chrome is unchanged — except that since the attachment-render extraction the default renderer draws inbound `operator-inbound` uploads and `agent-file` deliveries inline (image thumbnail / pdf.js preview / voice-note player / download chip) via the attachment renderer shared with `/chat`, extracted to `app/chat/attachment-render.tsx` to break the cycle with `transcript-render.tsx`; `renderChatTimeline` is untouched. Both presentations are test-pinned (`app/whatsapp/__tests__/Transcript-*.test.tsx`, `app/chat/__tests__/transcript-render.test.tsx`, `app/chat/__tests__/pdf-preview.test.tsx`). **Day-divider:** both renderers insert a centered `.day-divider` row between two consecutive timeline items on different local calendar days (label `Today`/`Yesterday`, else `Sat 14 Jun 2026`), so a thread spanning midnight is never an ambiguous run of HH:MM; the first dated item gets a leading divider, a null/unparseable `ts` marks no boundary, dividers are computed over the filtered `visibleItems`, and in `/chat` a day crossover flushes any open tool/think run first so a collapsed run never spans it. Per-bubble HH:MM stamps are unchanged. Shared helpers `dayKey`/`dayLabel`/`itemTs`/`DayDivider` live in `app/whatsapp/Transcript.tsx`.
 
-**One delivered bubble per turn when the agent replied.** On the admin `/chat`, a turn that used the reply tool shows exactly one delivered bubble — the reply. A trailing sign-off or recap the agent writes after the reply is treated as narration and is not shown as a second bubble (it collapses like any mid-turn prose). Only a turn that ends **without** using the reply tool has its final text promoted to a delivered bubble, so a genuine no-reply answer is never lost. The tradeoff, accepted by the operator: a turn that acknowledges on the reply tool and then writes the real answer as trailing text will not show that trailing answer — the agent is steered to put the answer on the reply tool so this stays rare.
+**One delivered bubble per turn on the admin `/chat`.** The admin webchat has no outbound transport, so the agent has no reply tool there: the text its turn ends with **is** the delivered answer, and it renders as the one prominent prose bubble. Mid-turn prose collapses into the folded run as before, so a turn shows exactly one delivered bubble. A turn that reaches its end with no trailing text delivers nothing and is logged as `op=turn-answer-absent`. Public webchat, WhatsApp and Telegram keep their reply tool, and every historical admin transcript still renders its recorded reply-tool bubbles unchanged.
 
 **WhatsApp reader is read/write (WhatsApp-Web surface).** A WhatsApp store conversation in the operator Conversations reader (`OperatorConversations`) and the admin root channel viewer (`app/page.tsx`) no longer opens the plain read-only DM chrome — it opens `app/whatsapp/WhatsappWebConversation.tsx`, a WhatsApp-Web-styled surface: a conversation header, the delivered-only store transcript reskinned green/white under a `.wa-web` root class, and a reply composer (`app/whatsapp/ReplyComposer.tsx`). The operator can type text, insert emoji (a codepoint-data picker — no OS input, so the `check-no-emoji-in-jsx` gate stays green), record a voice note (MediaRecorder → the existing audio send path), attach a file **from device storage** (a modal browsing the DATA_ROOT tree via `GET /api/admin/files`, sent by reference — the OS file dialog is no longer the reader's picker), reply to a specific message (a per-bubble affordance that quotes the original in the composer and threads natively on WhatsApp), and search the loaded transcript (a header control that filters to matching turns and highlights the match). The header carries only that Search control — the former Video / Phone / menu icons are gone, because no call or presence data exists behind them. Sent files honour the webchat allowlist (`SUPPORTED_MIME_SET` / 50 MB / 5 files); a device-file reference is authorised server-side (`authorizeReplyFileRef`) against the send's own account (the conversation owner) **or** the session's pinned account (`getAccountIdForSession` — the exact scope the DeviceFilePicker used to offer it), so a house/managing-admin session can attach a managed-client file the picker listed. Because a reply sends bytes OUT to an external WhatsApp recipient, any other account, a `public` partition, and any install-wide / non-account path are refused fail-closed; the cross-account admission's authority is the session's pinned account, never the caller-supplied body `accountId` (the own-account admission matches the body `accountId`, which the route already trusts via `isValidAccountId` and the existing-conversation guard). A scope refusal returns a distinct HTTP 403 reason (`file-ref-cross-account` / `file-ref-public` / `file-ref-foreign`) and copy, never "device file not found" (reserved for a genuine resolve/stat miss). Per-ref `[wa-manual-send] op=reply-file-ref … via=own|session|deny reason=<…> ok=<bool>` logs the decision before any send; `via=deny ok=true` is the exfiltration signature that must never appear. **Send is reply-only and DM-only:** `POST /api/whatsapp-reader/reply` (`requireAdminSession`) refuses any target with no existing stored conversation (`reason=no-existing-conversation`, HTTP 403) — a cold first-contact send bans the account, so the composer is never a cold-contact path, enforced server-side — and refuses `@g.us` groups (`reason=group-send-blocked`), matching the agent's observe-only group invariant; a group thread shows a read-only note in place of the composer. The endpoint is the sole store writer for a manual send: right after each send resolves it appends the record itself, stamped `origin:'operator-manual'` (attributed "You", distinct from an assistant reply), because the Baileys echo that normally persists the store is gated on message text (`manager.ts:906`) and would leave an uncaptioned media send delivered-but-invisible. The record's `messageId` matches the echo's derivation so the async text echo's own persist dedups to a no-op; the send is confirmed by re-read (`op=recorded present=<bool>`). A sent send does not spawn an assistant turn (echo dispatch stays suppressed). Attachments deliver as WhatsApp media/documents and render **inline** in the store reader (image thumbnail / pdf preview / audio player / download chip), because the manual-send path records the message with the servable `attachmentId`. The `.wa-web` skin is scoped to WhatsApp store threads only, so `/chat`, the admin agent session view, and the public visitor webchat are unchanged; the visitor webchat gains no send capability. The in-bubble delivered-tick is cosmetic (no read-receipt data is stored); inbound bubbles keep their sender name so group threads stay attributable, and both directions carry a WhatsApp callout tail (`.wa-web`-scoped only). Non-WhatsApp reader rows (Telegram/webchat session JSONLs) keep the plain read-only `Transcript`. Observability rides `[wa-manual-send]` lines correlated by a per-request `sendId`. **Composer sizing matches the webchat composer:** the reply textarea auto-grows to fit multi-line content (measured from `scrollHeight`, clamped to a one-row minimum and a `viewport/3` maximum, scrollable past the cap with the scrollbar hidden), and a top-border grab handle drags (pointer) or nudges (ArrowUp/ArrowDown, keyboard-focusable) to an explicit height in the same clamp; a manual drag pins the height and overrides auto-grow until the field is cleared, which releases it back to auto-grow. A completed manual resize logs `[operator-ui] op=wa-composer-resize mode=drag|key h=<px>`; a bare click on the handle (no drag) logs nothing.
 
@@ -757,7 +757,7 @@ authoritative. This section names the surfaces and what backs each.
 > a read-only reader. The item gates on the flyout handler being wired, exactly
 > like the admin and lite items. The read-only inbound-channel **Conversations**
 > reader (WhatsApp, Telegram, public webchat, via the admin-gated
-> `/api/whatsapp-reader/conversations` route) remains on `/data`'s Conversations
+> `/api/operator-conversations/conversations` route) remains on `/data`'s Conversations
 > item and in the admin Sidebar; it is no longer reachable from the operator chat
 > surface. The operator surface is documented in full in the internal doc
 > `maxy-code/.docs/operator-dashboard.md`.
@@ -799,7 +799,7 @@ authoritative. This section names the surfaces and what backs each.
 > count. On the operator **chat** surface the handler is always wired, so the
 > item is always present and opens the live session switcher (above). On `/data`
 > the handler is wired only when ≥1 reviewable inbound conversation exists
-> (fetched from `/whatsapp-reader/conversations` with the operator's session
+> (fetched from `/operator-conversations/conversations` with the operator's session
 > key), and selecting it renders the read-only reader in place (the file browser
 > is swapped for it; Back returns) — so `/data` keeps its hide-when-empty
 > behaviour. The flyout-open signal `[operator-ui] op=conversations-menu
@@ -813,8 +813,8 @@ authoritative. This section names the surfaces and what backs each.
 | Nav rows (Chat / People / Agents / Projects / Tasks / Artefacts) | People, Agents, Tasks open the artefact-pane Graph filtered to the matching label. Chat selects the active conversation. Artefacts swaps the list to editable documents. **The "Projects" row is brand-aware:** its visible term and the graph label it filters to both come from the injected `window.__BRAND__.primaryContainer` (`brand.json` → `server/index.ts` inject → `brand.ts` `brandPrimaryContainer()`), so SiteDesk reads "Projects" → `:Project`, SiteDesk "Jobs" → `:Job`, Real Agent "Properties" → `:Property`. A brand JSON missing `primaryContainer` falls back to Project/Projects (server logs `[brand] op=primaryContainer-default reason=absent brand=<hostname>`; the populated case logs `[brand] op=inject primaryContainer=<label>/<term>`). | `graph-search.ts`, `graph-subgraph.ts`, `sidebar-artefacts.ts` |
 | Sessions list (Active / Archived / All) | Live row store driven by SSE; manual reconcile button on the segmented control re-fetches the full id set. Every listed row carries two launch actions: the claude.ai/code resume (`ExternalLink`) and a chat-launch (`MessageSquare`) that opens `/chat?session=<full sessionId>` — the admin webchat pointed at that exact session; sending there resumes a stopped session with the webchat channel bound to that id (see `admin-webchat-native-channel.md`, "Session-targeted mode"). **Clicking the row's body** (live-dot, title, id, or timestamp) opens that same `/chat?session=<id>` as the chat-launch action. The main area stays a `<div>` (it wraps the inline rename input, which a `<button>` may not contain) carrying `role="button"`, `tabIndex`, an "Open <title> in webchat" aria-label, and Enter/Space activation, styled with `conv-main-clickable` for pointer + hover parity with the channel-row button. The click and keyboard handlers no-op while the row is being renamed, so an in-progress edit is preserved; the action icons and the `⋯` overflow menu are a sibling cluster running their own handlers, so activating them never triggers the row-body open. At the ≤720 px drawer breakpoint each row stacks into two lines — dot + title + id/stamp, then the action icons — with a divider between rows and actions at full opacity (the desktop hover-gated 0.5 opacity never resolves on touch). Below a 400 px list width each row's action icons collapse to a single `MoreHorizontal` ellipsis trigger; its popover menu lists the same actions as the inline icons but labels them with concise verbs (`Resume in claude.ai/code`, `Open in webchat`, `Stop`, `Archive` / `Unarchive`, `Rename`, `Delete`, `Re-seat`) rather than the inline icon buttons' verbose per-session aria-labels — the inline buttons keep those verbose labels because an icon-only control needs the full descriptive accessible name. **Re-seat:** Re-seat is a member action of the one `SessionRowActions` cluster, not a separate sibling control — wide it is the sliders icon inline with the other icons (sharing the cluster geometry and alignment); collapsed it is the `Re-seat` menu item, which expands the model/mode/effort form inline inside the overflow menu. The form (`SessionReseatControl`) forks the session via `/api/admin/session-reseat` and navigates to the fork (the same fork mechanism `/chat`'s pickers drive); its model picker defaults to the row's current model (a `model` field on each row, read from the JSONL tail), and mode and effort each carry a "Keep" option that omits the field. The overflow menu and the Re-seat form render through a `document.body` portal, fixed-positioned from the trigger's rect (right-aligned, flipped above the trigger when there is no room below), so neither is clipped by `.side-list`'s `overflow-y:auto`; Escape, a pointerdown outside the trigger/popover, and any scroll or resize dismiss them. | `/claude-sessions/events`, `/claude-sessions`, `/session-reseat` |
 | Data pane | A "Data" nav row beside Artefacts/Sessions. Uses the same `activeNav` toggle, but its content — the headless `DataFileBrowser` (graph search + `{installDir}/data/` file browser) — renders in the shell's **main column** via `DataPaneSurface`, like the WhatsApp Transcript, not in the side-list; there is no side-list block under `activeNav==='data'`. `AdminShell` owns a `dataOpen` main-column state (mutually exclusive with the WhatsApp selection); the row lifts the choice through `onSelectData`. On `/` it opens in place; from any other route (`/graph`, `/chat`, `/browser`) it navigates to `/?data=1`, which the root shell hydrates on mount (`hydrateDataFromUrl`, then strips the query). The admin burger no longer carries a Data item (the operator surface, which has no Sidebar, keeps the burger → `/data` route). Client breadcrumbs: `[admin-ui] sidebar-nav surface=data …`, `[admin-ui] data-open route=… via=<in-place\|navigate>`, `[admin-ui] data-hydrate route=/`. | `sidebar-artefacts.ts`, `files.ts`, `graph-search.ts` |
-| Channel reader nav rows (WhatsApp / Telegram) | One conditional nav row per channel that has ≥1 conversation. Each row carries its brand glyph (WhatsApp `#25D366`, Telegram `#229ED9`); a channel with no conversations shows no row, and no install ever shows an always-empty "No conversations" row. The channel list loads **once on sidebar mount**, so a failed load shows one muted, non-clickable line instead of channel rows. **WhatsApp rows are sourced from the on-disk message store** (`readAllConversations`), one row per stored conversation keyed by `remoteJid`, independent of whether any session JSONL exists — a blocked non-admin DM or a group-observed thread that never produced a session is listed here. **Telegram rows are session-sourced** (one per admin Telegram session), unchanged. Each conversation row shows a **display name**: for WhatsApp, the store record's `senderName` (else the `senderTelephone`, else the `remoteJid`); for Telegram, the precedence `operatorName ?? senderId ?? title` where `operatorName` is the bound `Person givenName familyName`. Under the name each row shows a **last-message-time breadcrumb** (`conv-timestamp`) from `lastMessageAt`, never "Invalid Date". **Scope colour (WhatsApp):** each WhatsApp row is coloured by its conversation's scope — a thin left accent bar, green for `admin`, orange for `public`, taken from the conversation's most-recent stored record (this replaces the former "Public" text pill). **Re-seat:** only session-sourced rows (Telegram, and webchat in the Sessions panel) carry a `SessionRowActions` Re-seat cluster; a WhatsApp store row has no session, so it carries no Re-seat. A click on a conversation **opens its transcript on the home surface**: on `/` it selects in place, and from any other route it navigates to `/?wa=<remoteJid>&acct=<accountId>`, which the root shell hydrates on mount (then strips the query). **Account-scoped** exactly as the sidebar Sessions list: both row sources (WhatsApp store rows and Telegram/public-webchat session rows) are scoped to the caller's pinned account (`getAccountIdForSession(cacheKey)`), multi-account-gated (`listValidAccounts().length > 1`). On a multi-account install a subaccount view shows only its own conversations; the house account's WhatsApp appears only under the house view; an untagged session sidecar is excluded and counted; an unresolvable scope fails closed to an empty list (logs `op=list-scope-unresolved`). A single-account install filters nothing, byte-identical to before. Server logs `[wa-reader] op=list pinnedAccount=<id8> resolvedAccount=<id8> multiAccount=<bool> conversations=<n> sessionRows=<m> storeRows=<k> adminScope=<n> publicScope=<n> sessionRowsExcludedUntagged=<n>` per list build (`pinnedAccount === resolvedAccount` is the post-fix invariant when `multiAccount=true`; `conversations=0` on an account with a non-empty store dir is the over-filtering drift signal); the client logs `[admin-ui] wa-open route=… via=<in-place\|navigate> …` and `[admin-ui] wa-hydrate route=/ remoteJid=…`. | `/whatsapp-reader/conversations` |
-| Channel transcript (`<Transcript>`) | **WhatsApp** reads its conversation verbatim from the message store file (`<remoteJid>.jsonl`) over SSE (`/whatsapp-reader/store-stream`): both directions, `dateSent`-ordered, backlog on connect then a live tail so a newly stored message appears without reload — no session JSONL is read. **Telegram** still reads one session's JSONL over SSE (`/whatsapp-reader/stream`) and renders both sides plus tool calls — the turns claude.ai/code hides because channel inbound is stamped `isMeta`. Every turn shows its time-of-day (HH:MM from the turn's `ts`; a null/unparseable `ts` shows no time, never "Invalid Date"). On the Telegram session stream, `tool-call`/`tool-result` turns render as **collapsed cards** so the human↔agent text is not buried in JSON. The thread **follows the tail**: it opens at the newest turn and pins to the bottom on each live append **only while the operator is already within 32 px of the bottom**; while scrolled up a **jump-to-bottom control** (`.wa-jump`) appears. Both streams send a 20 s heartbeat so an idle Cloudflare tunnel does not idle-drop, tag each frame with a byte-offset `id:`, and resume from the client's `Last-Event-ID` on reconnect (no duplicate backlog); the client clears the "Stream disconnected" banner on reopen and latches it only on a terminal CLOSED state. The Telegram session stream also interleaves a collapsed `⚙ directive injected (N B)` row per turn (listed by `GET /whatsapp-reader/directives?sessionId=`, bytes served by `GET /whatsapp-reader/directive?sessionId=&name=`); a WhatsApp store conversation has no session, so it has no directives. A centered day-divider row (`.day-divider`) marks each local calendar-day crossover. This viewer renders **delivered messages only** (both WhatsApp store rows and Telegram session rows, via `forceDeliveredOnly`) with **no per-viewer toggle** — the former "Messages only" pill is retired; the admin `/chat` composer's own messages-only control is unaffected. The panel — wallpaper included — is **bounded to `--chat-measure` and centred** (`.platform > .wa-reader`), so it reads as a column the same width as `/data`, not an edge-to-edge beige surface. The store stream open logs `[wa-reader] op=open remoteJid=<jid> scope=<admin\|public> messages=<n> source=store`. | `/whatsapp-reader/store-stream`, `/whatsapp-reader/stream`, `/whatsapp-reader/directives`, `/whatsapp-reader/directive` |
+| Channel reader nav rows (WhatsApp / Telegram) | One conditional nav row per channel that has ≥1 conversation. Each row carries its brand glyph (WhatsApp `#25D366`, Telegram `#229ED9`); a channel with no conversations shows no row, and no install ever shows an always-empty "No conversations" row. The channel list loads **once on sidebar mount**, so a failed load shows one muted, non-clickable line instead of channel rows. **WhatsApp rows are sourced from the on-disk message store** (`readAllConversations`), one row per stored conversation keyed by `remoteJid`, independent of whether any session JSONL exists — a blocked non-admin DM or a group-observed thread that never produced a session is listed here. **Telegram rows are session-sourced** (one per admin Telegram session), unchanged. Each conversation row shows a **display name**: for WhatsApp, the store record's `senderName` (else the `senderTelephone`, else the `remoteJid`); for Telegram, the precedence `operatorName ?? senderId ?? title` where `operatorName` is the bound `Person givenName familyName`. Under the name each row shows a **last-message-time breadcrumb** (`conv-timestamp`) from `lastMessageAt`, never "Invalid Date". **Scope colour (WhatsApp):** each WhatsApp row is coloured by its conversation's scope — a thin left accent bar, green for `admin`, orange for `public`, taken from the conversation's most-recent stored record (this replaces the former "Public" text pill). **Re-seat:** only session-sourced rows (Telegram, and webchat in the Sessions panel) carry a `SessionRowActions` Re-seat cluster; a WhatsApp store row has no session, so it carries no Re-seat. A click on a conversation **opens its transcript on the home surface**: on `/` it selects in place, and from any other route it navigates to `/?wa=<remoteJid>&acct=<accountId>`, which the root shell hydrates on mount (then strips the query). **Account-scoped** exactly as the sidebar Sessions list: both row sources (WhatsApp store rows and Telegram/public-webchat session rows) are scoped to the caller's pinned account (`getAccountIdForSession(cacheKey)`), multi-account-gated (`listValidAccounts().length > 1`). On a multi-account install a subaccount view shows only its own conversations; the house account's WhatsApp appears only under the house view; an untagged session sidecar is excluded and counted; an unresolvable scope fails closed to an empty list (logs `op=list-scope-unresolved`). A single-account install filters nothing, byte-identical to before. Server logs `[wa-reader] op=list pinnedAccount=<id8> resolvedAccount=<id8> multiAccount=<bool> conversations=<n> sessionRows=<m> storeRows=<k> adminScope=<n> publicScope=<n> sessionRowsExcludedUntagged=<n>` per list build (`pinnedAccount === resolvedAccount` is the post-fix invariant when `multiAccount=true`; `conversations=0` on an account with a non-empty store dir is the over-filtering drift signal); the client logs `[admin-ui] wa-open route=… via=<in-place\|navigate> …` and `[admin-ui] wa-hydrate route=/ remoteJid=…`. | `/operator-conversations/conversations` |
+| Channel transcript (`<Transcript>`) | **WhatsApp** reads its conversation verbatim from the message store file (`<remoteJid>.jsonl`) over SSE (`/whatsapp-reader/store-stream`): both directions, `dateSent`-ordered, backlog on connect then a live tail so a newly stored message appears without reload — no session JSONL is read. **Telegram** still reads one session's JSONL over SSE (`/session-reader/stream`) and renders both sides plus tool calls — the turns claude.ai/code hides because channel inbound is stamped `isMeta`. Every turn shows its time-of-day (HH:MM from the turn's `ts`; a null/unparseable `ts` shows no time, never "Invalid Date"). On the Telegram session stream, `tool-call`/`tool-result` turns render as **collapsed cards** so the human↔agent text is not buried in JSON. The thread **follows the tail**: it opens at the newest turn and pins to the bottom on each live append **only while the operator is already within 32 px of the bottom**; while scrolled up a **jump-to-bottom control** (`.wa-jump`) appears. Both streams send a 20 s heartbeat so an idle Cloudflare tunnel does not idle-drop, tag each frame with a byte-offset `id:`, and resume from the client's `Last-Event-ID` on reconnect (no duplicate backlog); the client clears the "Stream disconnected" banner on reopen and latches it only on a terminal CLOSED state. The Telegram session stream also interleaves a collapsed `⚙ directive injected (N B)` row per turn (listed by `GET /session-reader/directives?sessionId=`, bytes served by `GET /session-reader/directive?sessionId=&name=`); a WhatsApp store conversation has no session, so it has no directives. A centered day-divider row (`.day-divider`) marks each local calendar-day crossover. This viewer renders **delivered messages only** (both WhatsApp store rows and Telegram session rows, via `forceDeliveredOnly`) with **no per-viewer toggle** — the former "Messages only" pill is retired; the admin `/chat` composer's own messages-only control is unaffected. The panel — wallpaper included — is **bounded to `--chat-measure` and centred** (`.platform > .wa-reader`), so it reads as a column the same width as `/data`, not an edge-to-edge beige surface. The store stream open logs `[wa-reader] op=open remoteJid=<jid> scope=<admin\|public> messages=<n> source=store`. | `/whatsapp-reader/store-stream`, `/session-reader/stream`, `/session-reader/directives`, `/session-reader/directive` |
 | Conversations row hover actions | Inline rename, archive, delete, JSONL view / download per row. The historical `.conversations-modal` CSS block exists in `globals.css` but is no longer mounted from any TSX — Sidebar.tsx now owns every per-row affordance directly. | `claude-sessions.ts` |
 | Artefacts list | Lists every `:FileArtifact` under this account's tree (`relativePath STARTS WITH 'accounts/'`, all file types, excluding the `uploads/<id>/` subtree) plus this account's IDENTITY / SOUL / KNOWLEDGE / specialist templates. Click downloads the row's backing file (`downloadPath` → `GET /api/admin/files/download`) so the operator opens it in their local app; rows whose file is outside `DATA_ROOT` (bundled-fallback templates) show a "can't be downloaded" pill. The in-app artefact pane is dead pending removal. | `sidebar-artefacts.ts`, `files.ts` |
 | System-stats widget | CPU / RAM widget at the foot of the sidebar. | `system-stats.ts` (see above) |
@@ -916,6 +916,44 @@ equivalent wording: the reader reply path and the `/send-admin` route.
 Consolidating them is tracked separately; do not copy their strings into
 new callers.
 
+## WhatsApp inbound notifications
+
+An inbound WhatsApp message raises a WhatsApp-green card at the **top right** of
+every admin surface within about a second of arrival. The card shows the
+sub-account it arrived on, the sender (their WhatsApp profile name, or their
+number when they have none), and the first two lines of the message, with an
+ellipsis when there was more. A media message with no caption shows its media
+type instead.
+
+The card disappears within five seconds and is **stored nowhere** — there is no
+history, no unread count, and nothing to click. It exists to tell the operator a
+message landed; the reader is where the message itself is read.
+
+**Bursts drain rather than pile up.** One card alone lasts five seconds. As more
+arrive, every card on screen speeds up: two share 2.5 seconds each, three 1.7,
+four 1.25, and five or more sit on a 1.2 second floor. A card's dwell only ever
+shortens, so it does not linger once the stack empties. There is no cap on how
+many cards can appear at once.
+
+**Four sender types, one icon each:**
+
+| Icon | Sender |
+|---|---|
+| Shield | **Admin** — the operator's own number, or a bound admin |
+| Two-way arrows | **Account manager (active)** — a manager whose messages drive an agent turn |
+| Eye | **Account manager (passive)** — a passive bind, which files work but never replies |
+| Person | **Public** — a member of the public |
+
+Cards from **every** sub-account appear regardless of which account the tab is
+currently pinned to, and each is labelled with that sub-account's name. That is
+deliberate: seeing another account's message is what tells the operator to
+switch to it.
+
+Messages that raise no card, by design: anything the operator sent, group
+messages (groups are observation-only), history catch-up during a re-sync, and
+any sender the access rules decline. A blocked or unrecognised contact is
+silent.
+
 ## Related references
 
 - [`platform.md`](platform.md) — UI layout, session reconcile model,

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

@@ -68,6 +68,8 @@ So:
 
   The share is reachable solely from the box itself. Operators reach it by forwarding loopback over SSH — `ssh -L 4445:localhost:445 admin@<tunnel-host>` and then mounting `smb://localhost:4445` — or by joining the box to a private network and re-installing, which makes the private interface the chosen LAN bind.
 
+  That second remedy applies to SMB only. The admin edge uses a different rule: it binds loopback whenever the host carries a public IPv4, whether or not a private interface exists alongside it, so joining a private network does not make the edge LAN-reachable on a cloud box.
+
 If the device has no non-loopback IPv4 interface at all, the installer refuses to provision and exits — there is nothing safe to bind to. This is distinct from the public-only case, which still provisions a working (host-local) share.
 
 This classification is the structural guarantee that SMB never leaves the box (loopback-only) or the LAN (LAN-only), even if upstream firewall rules are misconfigured. The Cloudflare tunnel that fronts the admin UI carries HTTPS only; it does not route SMB.

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). 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-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 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-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). 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-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 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-status, email-otp-extract."
 tools:
   - name: email-provider-info
     publicAllowlist: false
@@ -10,6 +10,10 @@ tools:
     publicAllowlist: false
     adminAllowlist: false
     riskClass: write_local
+  - name: email-signature-set
+    publicAllowlist: false
+    adminAllowlist: false
+    riskClass: write_local
   - name: email-read
     publicAllowlist: false
     adminAllowlist: false
@@ -42,6 +46,13 @@ tools:
     publicAllowlist: false
     adminAllowlist: false
     riskClass: external
+  # adminAllowlist is true here and false on every sibling: this tool exists to
+  # be run AGAINST the other email tools' claims, so it is useless if only their
+  # callers can reach it. It is a pure read and writes nothing.
+  - name: email-draft-list
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: read
   - name: email-search
     publicAllowlist: false
     adminAllowlist: false
@@ -101,6 +112,7 @@ Manages the agent's own dedicated email account — IMAP for reading, SMTP for s
 
 - **Provider lookup:** `email-provider-info` — given just an email address, returns the inferred IMAP/SMTP hosts and the provider's app-password / trusted-application / IMAP-enable requirement, deterministically from the provider map. Call this BEFORE soliciting a password so the requirement is relayed first; most providers reject the normal login password. Returns "unknown" (operator supplies hosts) or "unsupported" (provider blocks IMAP/SMTP, e.g. Tuta).
 - **Setup:** `email-setup` — collect credentials in plain chat and connect IMAP/SMTP. Hosts are auto-inferred for known providers; supports alias addresses (`agentAddress`). For hosts where the client-visible Drafts folder is not the one flagged `\Drafts`, pass `draftsFolder` to name it explicitly (e.g. `INBOX.Drafts`).
+- **Signature:** `email-signature-set` — install the account's signature into the three files `email-draft` already reads at the account root (`email-signature.txt`, `.html`, `.font`). Plain text and HTML are stored and appended byte-for-byte; `font` is one CSS font-family value that wraps the HTML body and has no plain-text effect. **A part you omit is removed**, so a text-only call clears a stale HTML signature rather than leaving it to keep being appended; pass every part you want to keep on each call. A call with no parts at all is refused rather than treated as "erase everything". Because the append is deterministic and happens on every draft, a signature must never be written into a draft body by hand — that duplicates the stored one and drifts from it. Pass the operator's real signature read from its source of truth; reconstructing markup from memory or from stripped graph text is what put a dead logo URL into a client draft. Account-scoped, no `mailbox` selector: one signature per account.
 - **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.
@@ -110,6 +122,12 @@ Manages the agent's own dedicated email account — IMAP for reading, SMTP for s
 - **Reply:** `email-reply` — threaded reply to an existing email by `messageId`. Resolves the original envelope via IMAP `SEARCH HEADER Message-ID` (INBOX then `\Sent`), so threading works for any message still present on the server even if the graph never ingested it. Supports `replyAll`, `cc`/`bcc`, and `attachments` (same path rules as `email-send`). Explicit `cc`/`bcc` are added in addition to whatever `replyAll` places in `To`, passed through as given (no overlap de-duplication against `To`).
 - **Compose to Drafts:** `email-draft` — builds the same MIME message as `email-send` (same `cc`/`bcc`/`attachments` rules; unlike a dispatched send, the stored draft keeps its `Bcc:` header, because the draft bytes are the only recipient carrier) but APPENDs it to the mailbox's `\Drafts` special-use folder with the `\Draft` flag instead of dispatching it. Nothing is sent. Pass `messageId` to compose a threaded draft-reply: the parent is resolved via IMAP and the draft carries `In-Reply-To`/`References` plus a `Re:` subject from the parent, exactly like `email-reply` (the `subject` argument is then optional and ignored). The success message names the Drafts folder, the APPEND UID, and the draft's own `Message-ID` (`draft id`) so a saved draft is never indistinguishable from a silent no-op and a later edit has a stable handle. Fails naming the mailbox when the server advertises no `\Drafts` special-use folder — no fallback folder is picked, unless a per-account `draftsFolder` override is configured (via `email-setup`), which is honoured before special-use discovery for hosts whose client-visible Drafts is a differently-named mailbox. Use when the operator wants to review and send by hand.
 - **Revise a draft:** `email-draft-edit` — replace a stored draft. The `targetUid` is a fast-path hint; the draft's own `Message-ID` (`draftMessageId`) is the stable identity, because Gmail renumbers a draft's UID when it is touched. The tool tries the UID first, then relocates by a `Message-ID` header search, then composes the replacement from the parameters (same shape as `email-draft`, plus `targetUid`, optional `draftMessageId`, and an optional `messageId` for a threaded revision), APPENDs it with `\Draft`, and deletes the resolved old copy — the replacement is always appended before the old copy is expunged, so a mid-cycle failure never leaves zero copies. When neither identity resolves a live draft, the prior draft is gone: the replacement is saved as a fresh draft (`created`) rather than failing. A single transient transport drop is retried on a fresh connection; auth and other permanent errors surface immediately. Nothing is sent. The confirmation names the folder, the new UID, and the new draft id.
+- **Verify a draft:** `email-draft-list` — read the Drafts folder back and report what is in it. This is the only tool that can confirm a draft's presence: `email-status` reports connectivity and an inbox count, and `email-read`/`email-search` are inbox/sent only. Optional `uid` or `draftMessageId` narrows to one draft, but the plain listing is preferred, because neither handle is stable — Gmail renumbers a draft's Drafts UID when it is touched, and `email-draft-edit` mints a **new** draft `Message-ID` for every revision, so a handle from earlier in the conversation can miss a draft that is present. A narrowing miss therefore never returns bare: it names the miss, says why a stale handle misses, and lists the drafts that *are* in the folder, so "that handle is not here" can never be read as "no draft is here". Lists every message in the resolved folder, not only `\Draft`-flagged ones, because that is what the operator's own mail client shows and a `draftsFolder` override may point at a folder this plugin did not write. A draft id matching two rows is reported as two rows, not collapsed — the edit path leaves a second copy when an expunge is not confirmed. Nothing is written, sent or deleted.
+
+  **Confirm before asserting.** After `email-draft` or `email-draft-edit`, and whenever anyone reports a draft they cannot see, read the folder with `email-draft-list` before saying the draft is there. The save confirmation is evidence that the write succeeded, not evidence that the draft is in the folder now.
+
+  **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.
 - **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`.
@@ -136,6 +154,7 @@ Email ingestion is **operator-initiated and human-in-the-loop**. There is no bac
 
 | Skill | Purpose |
 |-------|---------|
+| [email-signature](skills/email-signature/SKILL.md) | Setting or changing the account's email signature. Carries the loader convention (three files at the account root, verbatim text/html, trimmed font), the rule that a signature is installed only via `email-signature-set`, and the rule that the agent never hand-builds one inside a draft body. |
 | [email-ingest](skills/email-ingest/SKILL.md) | Operator-initiated ingestion. Drives "check my emails" → list via `email-fetch` → summarise → ask the operator per message → write the approved subset via `email-ingest`. |
 | [email-composition](skills/email-composition/SKILL.md) | Conversational wrapper for drafting replies, new emails, and inbox triage. Orchestrates the sending `email-*` tools with human-in-the-loop approval on every send; draft intent ("leave it in drafts", "don't send yet") routes to `email-draft`, threaded drafts pass `messageId`, and a stored draft is revised via `email-draft-edit` or sent via `email-draft-send`. |
 

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list-tool.test.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=email-draft-list-tool.test.d.ts.map

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list-tool.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"email-draft-list-tool.test.d.ts","sourceRoot":"","sources":["../../src/__tests__/email-draft-list-tool.test.ts"],"names":[],"mappings":""}

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list-tool.test.js

@@ -0,0 +1,142 @@
+import { describe, it, expect, vi, beforeEach } from "vitest";
+// The tool's rendering is the unit under test, so the reader is stubbed at the
+// module boundary. A wholesale vi.mock replaces the WHOLE module, so the factory
+// must name every symbol email-draft-list.ts imports from it — MAX_LIMIT as well
+// as listDrafts — or the import lands undefined.
+const { listMock } = vi.hoisted(() => ({ listMock: vi.fn() }));
+vi.mock("../lib/imap.js", () => ({
+    listDrafts: listMock,
+    MAX_LIMIT: 50,
+}));
+vi.mock("../lib/credentials.js", () => ({
+    loadCredentials: vi.fn(async () => ({
+        credentials: { config: { email: "m@x.com" }, password: "pw" },
+    })),
+}));
+const { emailDraftList } = await import("../tools/email-draft-list.js");
+const run = (params = {}) => emailDraftList({ accountId: "acc-1", ...params });
+const listing = (over) => ({
+    folder: "[Gmail]/Drafts",
+    mode: "census",
+    resolved: true,
+    rows: [],
+    total: 0,
+    ...over,
+});
+const quote = {
+    uid: 28316,
+    subject: "Quote",
+    to: ["jonathan@apexgrange.com"],
+    messageId: "<id-283@x>",
+    date: new Date("2026-07-28T09:00:00Z"),
+};
+describe("emailDraftList rendering", () => {
+    beforeEach(() => vi.clearAllMocks());
+    it("renders a census with the folder and every row", async () => {
+        listMock.mockResolvedValue(listing({
+            total: 2,
+            rows: [
+                quote,
+                { uid: 10, subject: "Older", to: ["a@x.com"], messageId: "<id-10@x>", date: null },
+            ],
+        }));
+        const text = await run();
+        expect(text).toContain("[Gmail]/Drafts");
+        expect(text).toContain("UID: 28316");
+        expect(text).toContain("jonathan@apexgrange.com");
+        expect(text).toContain("<id-283@x>");
+        expect(text).toContain("UID: 10");
+    });
+    it("an empty folder says so and is not an error", async () => {
+        listMock.mockResolvedValue(listing({ total: 0, rows: [] }));
+        const text = await run();
+        expect(text).toMatch(/No drafts in \[Gmail\]\/Drafts/);
+    });
+    it("a missed handle names the miss AND lists what is present", async () => {
+        listMock.mockResolvedValue(listing({ mode: "message-id", resolved: false, total: 1, rows: [quote] }));
+        const text = await run({ draftMessageId: "stale@x" });
+        expect(text).toContain("not found");
+        expect(text).toContain("UID: 28316");
+        expect(text).toMatch(/change when the draft is edited/);
+    });
+    it("a missed handle on a genuinely empty folder does not claim drafts exist", async () => {
+        listMock.mockResolvedValue(listing({ mode: "uid", resolved: false, total: 0, rows: [] }));
+        const text = await run({ uid: 999 });
+        expect(text).toContain("not found");
+        expect(text).toMatch(/no drafts at all/);
+    });
+    it("a confirmed hit reports the folder total alongside the draft", async () => {
+        listMock.mockResolvedValue(listing({ mode: "uid", resolved: true, total: 3, rows: [quote] }));
+        const text = await run({ uid: 28316 });
+        expect(text).toMatch(/Confirmed in \[Gmail\]\/Drafts/);
+        expect(text).toContain("3 drafts");
+        expect(text).toContain("UID: 28316");
+    });
+    it("names the duplicate-copy state when one draft id matches twice", async () => {
+        listMock.mockResolvedValue(listing({
+            mode: "message-id",
+            resolved: true,
+            total: 2,
+            rows: [quote, { ...quote, uid: 28317 }],
+        }));
+        const text = await run({ draftMessageId: "id-283@x" });
+        expect(text).toMatch(/2 copies match/);
+        expect(text).toMatch(/expunge is not confirmed/);
+    });
+    it("a miss over a truncated census states its window too", async () => {
+        listMock.mockResolvedValue(listing({
+            mode: "uid",
+            resolved: false,
+            total: 90,
+            rows: Array.from({ length: 20 }, (_, i) => ({
+                uid: i + 1,
+                subject: "s",
+                to: [],
+                messageId: null,
+                date: null,
+            })),
+        }));
+        const text = await run({ uid: 999 });
+        expect(text).toMatch(/holds 90 drafts; showing the newest 20/);
+    });
+    it("names both handles when both were tried", async () => {
+        listMock.mockResolvedValue(listing({ mode: "uid", resolved: false, total: 1, rows: [quote] }));
+        const text = await run({ uid: 999, draftMessageId: "gone@x" });
+        expect(text).toContain("UID 999");
+        expect(text).toContain("draft id gone@x");
+    });
+    it("truncation is stated and never mentions next_before_uid", async () => {
+        listMock.mockResolvedValue(listing({
+            folder: "Drafts",
+            total: 90,
+            rows: Array.from({ length: 50 }, (_, i) => ({
+                uid: i + 1,
+                subject: "s",
+                to: [],
+                messageId: null,
+                date: null,
+            })),
+        }));
+        const text = await run({ limit: 500 });
+        expect(text).toMatch(/newest 50 of 90/);
+        expect(text).not.toContain("next_before_uid");
+    });
+    it("clamps limit to MAX_LIMIT and floors it at 1", async () => {
+        listMock.mockResolvedValue(listing({}));
+        await run({ limit: 500 });
+        expect(listMock).toHaveBeenCalledWith(expect.anything(), "pw", expect.objectContaining({ limit: 50 }));
+        await run({ limit: 0 });
+        expect(listMock).toHaveBeenLastCalledWith(expect.anything(), "pw", expect.objectContaining({ limit: 1 }));
+    });
+    it("defaults the limit to 20 when none is given", async () => {
+        listMock.mockResolvedValue(listing({}));
+        await run();
+        expect(listMock).toHaveBeenCalledWith(expect.anything(), "pw", expect.objectContaining({ limit: 20 }));
+    });
+    it("says the listing is flag-agnostic so an operator can reconcile against their client", async () => {
+        listMock.mockResolvedValue(listing({ total: 1, rows: [quote] }));
+        const text = await run();
+        expect(text).toMatch(/not only \\Draft-flagged/);
+    });
+});
+//# sourceMappingURL=email-draft-list-tool.test.js.map

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list-tool.test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"email-draft-list-tool.test.js","sourceRoot":"","sources":["../../src/__tests__/email-draft-list-tool.test.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,MAAM,EAAE,EAAE,EAAE,UAAU,EAAE,MAAM,QAAQ,CAAC;AAG9D,+EAA+E;AAC/E,iFAAiF;AACjF,iFAAiF;AACjF,iDAAiD;AACjD,MAAM,EAAE,QAAQ,EAAE,GAAG,EAAE,CAAC,OAAO,CAAC,GAAG,EAAE,CAAC,CAAC,EAAE,QAAQ,EAAE,EAAE,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC;AAE/D,EAAE,CAAC,IAAI,CAAC,gBAAgB,EAAE,GAAG,EAAE,CAAC,CAAC;IAC/B,UAAU,EAAE,QAAQ;IACpB,SAAS,EAAE,EAAE;CACd,CAAC,CAAC,CAAC;AAEJ,EAAE,CAAC,IAAI,CAAC,uBAAuB,EAAE,GAAG,EAAE,CAAC,CAAC;IACtC,eAAe,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC;QAClC,WAAW,EAAE,EAAE,MAAM,EAAE,EAAE,KAAK,EAAE,SAAS,EAAE,EAAE,QAAQ,EAAE,IAAI,EAAE;KAC9D,CAAC,CAAC;CACJ,CAAC,CAAC,CAAC;AAEJ,MAAM,EAAE,cAAc,EAAE,GAAG,MAAM,MAAM,CAAC,8BAA8B,CAAC,CAAC;AAExE,MAAM,GAAG,GAAG,CAAC,SAAkC,EAAE,EAAE,EAAE,CACnD,cAAc,CAAC,EAAE,SAAS,EAAE,OAAO,EAAE,GAAG,MAAM,EAAW,CAAC,CAAC;AAE7D,MAAM,OAAO,GAAG,CAAC,IAA4B,EAAiB,EAAE,CAAC,CAAC;IAChE,MAAM,EAAE,gBAAgB;IACxB,IAAI,EAAE,QAAQ;IACd,QAAQ,EAAE,IAAI;IACd,IAAI,EAAE,EAAE;IACR,KAAK,EAAE,CAAC;IACR,GAAG,IAAI;CACR,CAAC,CAAC;AAEH,MAAM,KAAK,GAAG;IACZ,GAAG,EAAE,KAAK;IACV,OAAO,EAAE,OAAO;IAChB,EAAE,EAAE,CAAC,yBAAyB,CAAC;IAC/B,SAAS,EAAE,YAAY;IACvB,IAAI,EAAE,IAAI,IAAI,CAAC,sBAAsB,CAAC;CACvC,CAAC;AAEF,QAAQ,CAAC,0BAA0B,EAAE,GAAG,EAAE;IACxC,UAAU,CAAC,GAAG,EAAE,CAAC,EAAE,CAAC,aAAa,EAAE,CAAC,CAAC;IAErC,EAAE,CAAC,gDAAgD,EAAE,KAAK,IAAI,EAAE;QAC9D,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC;YACN,KAAK,EAAE,CAAC;YACR,IAAI,EAAE;gBACJ,KAAK;gBACL,EAAE,GAAG,EAAE,EAAE,EAAE,OAAO,EAAE,OAAO,EAAE,EAAE,EAAE,CAAC,SAAS,CAAC,EAAE,SAAS,EAAE,WAAW,EAAE,IAAI,EAAE,IAAI,EAAE;aACnF;SACF,CAAC,CACH,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,EAAE,CAAC;QACzB,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,gBAAgB,CAAC,CAAC;QACzC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,YAAY,CAAC,CAAC;QACrC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,yBAAyB,CAAC,CAAC;QAClD,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,YAAY,CAAC,CAAC;QACrC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,SAAS,CAAC,CAAC;IACpC,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,6CAA6C,EAAE,KAAK,IAAI,EAAE;QAC3D,QAAQ,CAAC,iBAAiB,CAAC,OAAO,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC;QAC5D,MAAM,IAAI,GAAG,MAAM,GAAG,EAAE,CAAC;QACzB,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,gCAAgC,CAAC,CAAC;IACzD,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,0DAA0D,EAAE,KAAK,IAAI,EAAE;QACxE,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC,EAAE,IAAI,EAAE,YAAY,EAAE,QAAQ,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAC1E,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,cAAc,EAAE,SAAS,EAAE,CAAC,CAAC;QACtD,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,WAAW,CAAC,CAAC;QACpC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,YAAY,CAAC,CAAC;QACrC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,iCAAiC,CAAC,CAAC;IAC1D,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,yEAAyE,EAAE,KAAK,IAAI,EAAE;QACvF,QAAQ,CAAC,iBAAiB,CAAC,OAAO,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,QAAQ,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,EAAE,EAAE,CAAC,CAAC,CAAC;QAC1F,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,GAAG,EAAE,GAAG,EAAE,CAAC,CAAC;QACrC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,WAAW,CAAC,CAAC;QACpC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,kBAAkB,CAAC,CAAC;IAC3C,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,8DAA8D,EAAE,KAAK,IAAI,EAAE;QAC5E,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,QAAQ,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAClE,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,GAAG,EAAE,KAAK,EAAE,CAAC,CAAC;QACvC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,gCAAgC,CAAC,CAAC;QACvD,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,UAAU,CAAC,CAAC;QACnC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,YAAY,CAAC,CAAC;IACvC,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,gEAAgE,EAAE,KAAK,IAAI,EAAE;QAC9E,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC;YACN,IAAI,EAAE,YAAY;YAClB,QAAQ,EAAE,IAAI;YACd,KAAK,EAAE,CAAC;YACR,IAAI,EAAE,CAAC,KAAK,EAAE,EAAE,GAAG,KAAK,EAAE,GAAG,EAAE,KAAK,EAAE,CAAC;SACxC,CAAC,CACH,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,cAAc,EAAE,UAAU,EAAE,CAAC,CAAC;QACvD,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,gBAAgB,CAAC,CAAC;QACvC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,0BAA0B,CAAC,CAAC;IACnD,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,sDAAsD,EAAE,KAAK,IAAI,EAAE;QACpE,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC;YACN,IAAI,EAAE,KAAK;YACX,QAAQ,EAAE,KAAK;YACf,KAAK,EAAE,EAAE;YACT,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC;gBAC1C,GAAG,EAAE,CAAC,GAAG,CAAC;gBACV,OAAO,EAAE,GAAG;gBACZ,EAAE,EAAE,EAAE;gBACN,SAAS,EAAE,IAAI;gBACf,IAAI,EAAE,IAAI;aACX,CAAC,CAAC;SACJ,CAAC,CACH,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,GAAG,EAAE,GAAG,EAAE,CAAC,CAAC;QACrC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,wCAAwC,CAAC,CAAC;IACjE,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,yCAAyC,EAAE,KAAK,IAAI,EAAE;QACvD,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC,EAAE,IAAI,EAAE,KAAK,EAAE,QAAQ,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CACnE,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,GAAG,EAAE,GAAG,EAAE,cAAc,EAAE,QAAQ,EAAE,CAAC,CAAC;QAC/D,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,SAAS,CAAC,CAAC;QAClC,MAAM,CAAC,IAAI,CAAC,CAAC,SAAS,CAAC,iBAAiB,CAAC,CAAC;IAC5C,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,yDAAyD,EAAE,KAAK,IAAI,EAAE;QACvE,QAAQ,CAAC,iBAAiB,CACxB,OAAO,CAAC;YACN,MAAM,EAAE,QAAQ;YAChB,KAAK,EAAE,EAAE;YACT,IAAI,EAAE,KAAK,CAAC,IAAI,CAAC,EAAE,MAAM,EAAE,EAAE,EAAE,EAAE,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,CAAC;gBAC1C,GAAG,EAAE,CAAC,GAAG,CAAC;gBACV,OAAO,EAAE,GAAG;gBACZ,EAAE,EAAE,EAAE;gBACN,SAAS,EAAE,IAAI;gBACf,IAAI,EAAE,IAAI;aACX,CAAC,CAAC;SACJ,CAAC,CACH,CAAC;QACF,MAAM,IAAI,GAAG,MAAM,GAAG,CAAC,EAAE,KAAK,EAAE,GAAG,EAAE,CAAC,CAAC;QACvC,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,iBAAiB,CAAC,CAAC;QACxC,MAAM,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,SAAS,CAAC,iBAAiB,CAAC,CAAC;IAChD,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,8CAA8C,EAAE,KAAK,IAAI,EAAE;QAC5D,QAAQ,CAAC,iBAAiB,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC,CAAC;QACxC,MAAM,GAAG,CAAC,EAAE,KAAK,EAAE,GAAG,EAAE,CAAC,CAAC;QAC1B,MAAM,CAAC,QAAQ,CAAC,CAAC,oBAAoB,CACnC,MAAM,CAAC,QAAQ,EAAE,EACjB,IAAI,EACJ,MAAM,CAAC,gBAAgB,CAAC,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CACvC,CAAC;QACF,MAAM,GAAG,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,CAAC,CAAC;QACxB,MAAM,CAAC,QAAQ,CAAC,CAAC,wBAAwB,CACvC,MAAM,CAAC,QAAQ,EAAE,EACjB,IAAI,EACJ,MAAM,CAAC,gBAAgB,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,CAAC,CACtC,CAAC;IACJ,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,6CAA6C,EAAE,KAAK,IAAI,EAAE;QAC3D,QAAQ,CAAC,iBAAiB,CAAC,OAAO,CAAC,EAAE,CAAC,CAAC,CAAC;QACxC,MAAM,GAAG,EAAE,CAAC;QACZ,MAAM,CAAC,QAAQ,CAAC,CAAC,oBAAoB,CACnC,MAAM,CAAC,QAAQ,EAAE,EACjB,IAAI,EACJ,MAAM,CAAC,gBAAgB,CAAC,EAAE,KAAK,EAAE,EAAE,EAAE,CAAC,CACvC,CAAC;IACJ,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,qFAAqF,EAAE,KAAK,IAAI,EAAE;QACnG,QAAQ,CAAC,iBAAiB,CAAC,OAAO,CAAC,EAAE,KAAK,EAAE,CAAC,EAAE,IAAI,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,CAAC;QACjE,MAAM,IAAI,GAAG,MAAM,GAAG,EAAE,CAAC;QACzB,MAAM,CAAC,IAAI,CAAC,CAAC,OAAO,CAAC,0BAA0B,CAAC,CAAC;IACnD,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list.test.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=email-draft-list.test.d.ts.map

package/payload/platform/plugins/email/mcp/dist/__tests__/email-draft-list.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"email-draft-list.test.d.ts","sourceRoot":"","sources":["../../src/__tests__/email-draft-list.test.ts"],"names":[],"mappings":""}