@rubytech/create-maxy-code 0.1.538 → 0.1.540

package/payload/platform/plugins/admin/skills/public-agent-manager/SKILL.md

@@ -53,9 +53,13 @@ The public agent has no tools. It cannot search the graph, read files, run comma
 
 ### knowledgeKeywords
 
-Topic keywords the agent subscribes to. During an `update-knowledge` refresh, nodes matching these keywords are included automatically — even if they are not directly tagged for the agent.
+Topic keywords the agent subscribes to. During an `update-knowledge` refresh, nodes matching these keywords are surfaced as suggestions even when they are not directly tagged for the agent.
 
-Maximum 5 keywords. Present during creation as a free-text input. Examples: `["climate science", "sustainability"]`, `["pricing", "services"]`.
+**Defaults to empty, and stays empty unless the operator asks for it.** A subscription widens what the agent may disclose as new content lands in the graph, and the lines it would add were never read by whoever authored the agent. That is the opposite of the rule this file enforces. Offer keywords only when the operator asks for topic-based suggestions, and say plainly what they buy: a shorter list to review at the next refresh, never an answer the agent gives on its own.
+
+A subscription writes nothing. Matching nodes reach KNOWLEDGE.md the way every other line does — presented, approved, written.
+
+Maximum 5 keywords. Examples: `["climate science", "sustainability"]`, `["pricing", "services"]`.
 
 ### Agent Image
 
@@ -75,6 +79,8 @@ Nodes in the graph can be directly tagged for a specific agent by adding the age
 
 To tag nodes: read the node's current `agents` array via `memory-search` (no `agentSlug` param), confirm with the operator which nodes get the new slug, and the recorder folds the slug onto each `agents` array in its next turn. To untag: same shape — read the current array, confirm removal, and the recorder rewrites the array without the slug. To see what's tagged for an agent: search with `memory-search` (no `agentSlug` param) and identify results whose `agents` property contains the target slug.
 
+Tagging routes a node to the suggestion surface; it does not publish it. A tagged node's lines reach KNOWLEDGE.md only after the operator approves them, exactly like any other suggested line.
+
 ### Model Options
 
 Present as a `select` field within the agent configuration `form` during creation:
@@ -99,9 +105,11 @@ SOUL.md answers "what does this agent feel like to talk to, and what is it here
 
 KNOWLEDGE.md is the public agent's baked, static knowledge surface — the facts the agent should always have on hand without a tool call. It is assembled into the system prompt at invocation time.
 
-Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. The public agent is toolless: KNOWLEDGE.md is its **only** knowledge source. There is no graph access mid-conversation. Every gap in KNOWLEDGE.md is a question the agent cannot answer, so the KNOWLEDGE.md you build below is the whole of what the agent will know — populate it thoroughly.
+Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. The public agent is toolless: KNOWLEDGE.md is its **only** knowledge source. There is no graph access mid-conversation.
+
+**Everything a public agent knows must be a sentence someone chose.** This file is published: it is disclosed to strangers, and nobody reviews it again after it ships. So it is author-curated, and a gap in it is a deliberate trade rather than a defect to engineer away. Every line in KNOWLEDGE.md is a line the operator approved for a stranger to read. An agent that declines a question is working correctly. An agent that volunteers something nobody approved is not, however true the statement was.
 
-The `memory-search` calls described below are **your** admin-time tool for populating KNOWLEDGE.md, not something the public agent ever runs. All `memory-search` queries for knowledge population use admin permissions — do not pass `agentSlug`. The `agentSlug` parameter is a runtime enforcement mechanism for the public agent's MCP server, not an admin-time discovery tool. At creation time, the agent may have zero tagged nodes — searching with `agentSlug` would return nothing.
+The `memory-search` calls described below are **your** admin-time tool for gathering candidate lines, not something the public agent ever runs. All `memory-search` queries for knowledge population use admin permissions — do not pass `agentSlug`. The `agentSlug` parameter is a runtime enforcement mechanism for the public agent's MCP server, not an admin-time discovery tool. At creation time, the agent may have zero tagged nodes — searching with `agentSlug` would return nothing.
 
 Query `memory-search` multiple times with targeted terms across all categories relevant to the agent's role. A single broad query will miss knowledge stored under specific labels or entity types. Common categories:
 
@@ -112,7 +120,9 @@ Query `memory-search` multiple times with targeted terms across all categories r
 - Products / catalogue
 - Location, hours, contact info
 
-For each category relevant to the agent, confirm that results were returned or that the graph genuinely has no data for that category. Write results as structured markdown under clear headings.
+**The results are a suggestion surface, never a draft to save.** Present what the search found as candidate lines and let the operator approve them one at a time. Approved lines go into KNOWLEDGE.md; everything else is discarded. Never write search output to the file in bulk, and never treat "it was in the graph" as a reason to publish it — the graph holds the operator's private working knowledge, including bookings, people and internal detail, and a public agent's file is the subset they chose to disclose.
+
+If the operator approves nothing in a category, that category is simply absent from the file. An empty search result and a rejected one are the same outcome here.
 
 After writing KNOWLEDGE.md, check the token budget. If the total system prompt exceeds 50% of the model's context window, summarise KNOWLEDGE.md and write the summary to `KNOWLEDGE-SUMMARY.md`. Present the summary to the user for review.
 
@@ -144,7 +154,7 @@ The following Create steps are modified when a template is provided:
 - **Step 2** — skip. The agent name and role come from `template.json` `displayName` and `description`.
 - **Step 4** — unchanged: `IDENTITY.md` is always the Rubytech-controlled template copied verbatim, never the agent template's own identity.
 - **Step 5** — present the template's `SOUL.md` content via `document-editor` instead of drafting from conversation. The user can edit before approving.
-- **Step 6** — pre-populate form defaults: `model` from `template.json` (or `claude-haiku-4-5` if absent), `knowledgeKeywords` from `template.json` (or empty).
+- **Step 6** — pre-populate form defaults: `model` from `template.json` (or `claude-haiku-4-5` if absent). `knowledgeKeywords` always starts empty, whatever the template carries — a template is a starting point the operator reviews, and a subscription it brought in would widen the agent's disclosure with nobody having chosen it.
 
 All other steps (3, 7-13) proceed identically — knowledge discovery, direct tagging, KNOWLEDGE.md generation, config write, budget check, default-setting, and confirmation are unchanged.
 
@@ -155,10 +165,10 @@ After creation, no template metadata persists in the agent's files. The resultin
 1. **Pre-creation check** — verify the target directory (`agents/{slug}/`) does not exist or is empty before proceeding. If remnant files exist from a prior incomplete deletion, flag the issue to the user: show what files remain and offer to clean them up before starting fresh. Do not silently inherit stale files — a leftover `config.json` from a previous agent would bypass the creation gate.
 2. Ask for the agent's name (becomes the slug) and role description
 3. **Knowledge discovery** — search the graph with admin permissions (no `agentSlug` — the agent doesn't exist yet) to find available knowledge. Present available content grouped by category for the user to select.
-4. **Install `IDENTITY.md`** — copy the Rubytech-controlled template verbatim to `agents/{slug}/IDENTITY.md`. It is fixed (the toolless public directive) and is never drafted, edited, or presented for review.
-5. Present `SOUL.md` via document-editor with `filePath: "agents/{slug}/SOUL.md"` (draft personality and the operator-defined role from user conversation — tone plus the role the operator describes for the agent). Write on approval. Must be non-empty; an empty SOUL is refused at spawn.
+4. **Draft `SOUL.md`** — present it via document-editor with `filePath: "agents/{slug}/SOUL.md"` for review (personality and the operator-defined role from the conversation: tone plus the role the operator describes). Hold the approved text; do not write the file. `IDENTITY.md` is never drafted, edited, or presented — `agent-create` copies the Rubytech-controlled template verbatim in step 9.
+5. *(merged into step 4.)*
 6. Present agent configuration via a single `form` component with these fields:
-   - `knowledgeKeywords` (`text`): label "Knowledge keywords (max 5, comma-separated)", placeholder with examples relevant to the agent's role
+   - `knowledgeKeywords` (`text`): label "Knowledge keywords (optional, max 5, comma-separated)", empty by default, with helper text saying keywords only surface suggestions at the next refresh and add nothing to the agent's knowledge on their own
    - `model` (`select`): label "Model", options with descriptions:
      - `claude-haiku-4-5` — "Haiku — Fast, cost-effective. FAQ, routing, high-volume."
      - `claude-sonnet-5` — "Sonnet — Balanced. Nuanced conversation, qualification, support."
@@ -173,10 +183,14 @@ After creation, no template metadata persists in the agent's files. The resultin
 
    - If the user approves: present the knowledge discovery results from Step 3 for selection, read each node's current `agents` array first, and confirm the new slug-tag set with the user. The recorder folds the slug onto each node's `agents` array in its next turn.
    - If the user declines: skip tagging entirely. Do not propose tagging without explicit approval.
-8. **KNOWLEDGE.md generation** — populate from the now-tagged set plus keyword matches using the `update-knowledge` skill workflow. KNOWLEDGE.md is required and must be non-empty; an empty or missing KNOWLEDGE is refused at spawn.
-9. Write `config.json` with selected model, status "active", and `knowledgeKeywords`. This is the last gated write — placed after IDENTITY.md, SOUL.md, and KNOWLEDGE.md to prevent cascade failure if one gate stalls.
-10. Check context budget — auto-summarise if over threshold
-11. **Project the agent into the graph** — delegate to the `specialists:database-operator` specialist with the instruction: "Project public agent `{slug}` into the graph by POSTing to `/api/admin/agents/{slug}/project?accountId=<the literal ACCOUNT_ID value you read>`." The route reads the on-disk files and idempotently MERGEs the `:Agent` node, the four owned `:KnowledgeDocument` projections (IDENTITY/SOUL/KNOWLEDGE/KNOWLEDGE-SUMMARY when present, namespaced `attachmentId="agent:<slug>:<role>"`), the `HAS_*` edges, and the `USES_KNOWLEDGE` edges to every operator-tagged doc. Loud-fail: if the route returns non-2xx, surface the error to the user verbatim — the agent's files exist on disk but its graph projection is incomplete, which means the operator's /graph view will not show this agent. Re-running the projection is safe; it is the same idempotent MERGE. The `accountId` query parameter is required on every write to this route (project and delete). The route no longer infers an account from device state, so it returns 400 without one and 403 when the caller is not entitled to the account it named. Source the value from the `ACCOUNT_ID` environment variable of this session (`echo $ACCOUNT_ID`), and substitute the literal id into the URL before delegating, since the specialist you delegate to does not share your shell.
+8. **KNOWLEDGE.md authoring** — draft the body from the lines the operator approved. The tagged set and any keyword matches are where suggestions come from, and the `update-knowledge` skill gathers and presents them under this same approval rule; nothing reaches the file unapproved. Hold the text; do not write the file. It must be non-empty: `agent-create` refuses an empty or whitespace-only knowledge body. If the operator approves nothing, say so and stop — the agent is not ready to go active, and padding the body out to clear the gate is exactly the failure this rule exists to prevent.
+9. **Create the agent** — call `agent-create` with `agentSlug`, `displayName`, `model`, the approved SOUL text as `soul`, the approved knowledge as `knowledge`, and `knowledgeKeywords` from the form. One call validates the slug against the same rule the router serves by (shape, reserved, route-shadowed), validates the config against the servable schema, refuses an empty knowledge body, writes all four files with `IDENTITY.md` copied verbatim from the platform template, and projects the agent into the graph. Every refusal is decided before the first byte is written, so a refused create leaves nothing behind.
+
+   **Never write these files by hand.** A raw write reaches none of those checks and does not project. That is what left the `beagle` agent on disk and absent from the graph for a day.
+
+   Loud-fail: the tool returns an error when the write landed but the projection did not, naming that the agent will not appear in /graph. Surface it to the operator verbatim; re-running `agent-update` retries the projection.
+10. Check context budget — auto-summarise if over threshold. Write `KNOWLEDGE-SUMMARY.md` directly when one is needed; it is the one agent file no write tool owns, and the projector picks it up on the next `agent-update`.
+11. *(merged into step 9 — creation projects in the same call.)*
 12. **Set the default if none exists.** Read `defaultAgent` from `account-manage`. If it is empty, set it to this new slug via `account-update` (`field: "defaultAgent"`, `value: "{slug}"`) — otherwise the agent answers at `/{slug}` but the bare root serves nothing. If a default already exists, do not change it silently: tell the operator the current default and ask whether to switch the root to this new agent; call `account-update` only if they say yes.
 13. Confirm creation: "Agent created and reachable at `/{slug}`." If you set or changed the default in step 12, add: "The site root also serves this agent." If a different default remains, add: "The site root still serves `{currentDefault}`."
 
@@ -195,25 +209,27 @@ Read `defaultAgent` from `account-manage` to identify the current default. Read
 
 ### Clone
 
-Copy the source agent's directory to a new slug. The user modifies what's different — typically SOUL.md and KNOWLEDGE.md.
+Read the source agent's `SOUL.md`, `KNOWLEDGE.md` and config (via `agent-config-read`), let the user modify what differs (typically SOUL and KNOWLEDGE), then call `agent-create` with the new slug and the edited bodies. Do not copy the directory: a directory copy carries the source's files past every validator and leaves the clone unprojected.
 
 ### Edit
 
-Read any file in the agent's directory and present it via document-editor with `filePath` set to the file's path. Write back on approval. The document-editor includes a Download button — the user can review, edit, then download the file as `.md` without further agent action.
+Read any file in the agent's directory and present it via document-editor with `filePath` set to the file's path. The document-editor includes a Download button — the user can review, edit, then download the file as `.md` without further agent action. On approval, write the change through `agent-update` (`soul` or `knowledge`), never by writing the file: only the tool re-validates and re-projects.
 
 For agent image changes:
 - Use the `agent-image` tool with `action: "set"` to upload or replace the image
 - Use the `agent-image` tool with `action: "remove"` to remove the image (falls back to brand logo)
 - To change the shape, use `agent-image` with `action: "set"` and the new `imageShape`
-- To change `showAgentName` (`true`, `false`, or `"none"`), update `config.json` directly
+- To change `showAgentName` (`true`, `false`, or `"none"`), call `agent-update` with the `showAgentName` field
 
 For knowledge scope changes:
 - Show currently tagged nodes (search `memory-search` without `agentSlug`, identify results whose `agents` property contains the agent's slug) and active keyword subscriptions (from `config.json`).
 - Allow adding/removing direct tags. Read each node's current `agents` array first, confirm the change with the operator, and the recorder updates the arrays in its next turn.
-- Allow adding/removing keyword subscriptions (update `knowledgeKeywords` in `config.json`).
-- After changes, offer to refresh KNOWLEDGE.md using the `update-knowledge` skill.
+- Allow adding/removing keyword subscriptions by calling `agent-update` with the full replacement `knowledgeKeywords` array.
+- After changes, offer to refresh KNOWLEDGE.md using the `update-knowledge` skill, then write the refreshed body through `agent-update`.
+
+**Every edit to SOUL, KNOWLEDGE or a config field goes through `agent-update`, which re-validates the merged config and re-projects in the same call.** Supply only the fields that change. A refusal leaves the directory byte-identical. Without re-projection the on-disk files diverge from the graph and the operator sees stale `:Agent` properties and stale `USES_KNOWLEDGE` edges in /graph, which is why the tool projects rather than leaving it to a follow-up step. Loud-fail: when the write lands and the projection does not, the tool says so; surface it verbatim.
 
-**After every Edit operation that touches IDENTITY/SOUL/KNOWLEDGE/KNOWLEDGE-SUMMARY/`config.json` (including `knowledgeKeywords` or direct-tag mutations), delegate to `specialists:database-operator` to re-project: POST `/api/admin/agents/{slug}/project?accountId={accountId}`.** Without re-projection the on-disk files diverge from the graph state — the operator sees stale `:Agent` properties and stale `USES_KNOWLEDGE` edges in /graph. Loud-fail: surface non-2xx errors verbatim.
+A direct-tag mutation changes the knowledge node, not the agent's files, so the recorder handles it. Call `agent-update` afterwards (any field, or none) to refresh the `USES_KNOWLEDGE` edges, because those are materialised at projection time.
 
 ### Delete
 
@@ -226,7 +242,7 @@ Deletion removes the entire agent directory (`agents/{slug}/`) — not individua
 - If no other agents remain (or the user declines to set a new default), clear the `defaultAgent` field by calling `account-update` with `field: "defaultAgent"`, `value: ""`. Tell the user that visitors to the root URL will see a "no agents" message until a new agent is created.
 
 **Cleanup sequence:**
-- Issue `DELETE /api/admin/agents/{slug}?accountId={accountId}` — the route removes the `:Agent` node and its four owned `:KnowledgeDocument` projections FIRST, then deletes the directory. Loud-fail: if graph cleanup throws, files are preserved and a 500 is returned with the error text. Re-issuing the DELETE is safe (idempotent on both layers). Operator-tagged docs survive the projection delete — only the `USES_KNOWLEDGE` edges from this Agent are removed.
+- Call `agent-delete` with the slug — it removes the `:Agent` node and its four owned `:KnowledgeDocument` projections FIRST, then deletes the directory, and refuses the `admin` agent. Loud-fail: if graph cleanup throws, the files are preserved and the tool reports the error. Re-issuing is safe (idempotent on both layers). Operator-tagged docs survive the projection delete — only the `USES_KNOWLEDGE` edges from this Agent are removed.
 - Verify the directory no longer exists
 - Report what was removed (list the files that were in the directory)
 

package/payload/platform/plugins/admin/skills/update-knowledge/SKILL.md

@@ -21,7 +21,7 @@ Each public agent's knowledge comes from two complementary sources, both configu
 
 **Keyword subscriptions** — the agent's `knowledgeKeywords` array. Nodes matching these keywords are included regardless of whether they are directly tagged.
 
-The union of both result sets (deduplicated) forms the agent's knowledge scope.
+The union of both result sets (deduplicated) forms the agent's knowledge scope — the set of nodes that may be **suggested**, not the set that gets written. Scope decides what the operator is shown; the operator decides what the agent knows.
 
 ## Admin vs Runtime Search
 
@@ -35,6 +35,7 @@ To find keyword matches: search with each keyword as the query term (no `agentSl
 
 - If the agent has neither direct tags nor keyword subscriptions configured, there is nothing to refresh. Inform the admin: "This agent has no knowledge scope configured. Tag nodes for the agent or add keyword subscriptions in config.json first."
 - If all queries return empty results, do NOT write an empty KNOWLEDGE.md. Warn the admin: "No matching content found for this agent's knowledge scope. KNOWLEDGE.md was not modified." Preserve any existing KNOWLEDGE.md.
+- **Never write graph content the operator has not approved line by line.** KNOWLEDGE.md is published to strangers, and the graph holds private working knowledge — bookings, people, internal detail — that has no business on a public front desk. Present the gathered lines, take the operator's approvals, and write only those. A refresh that the operator approves nothing from leaves KNOWLEDGE.md untouched; say so and stop.
 - After writing KNOWLEDGE.md, check the context budget. If the total system prompt (IDENTITY.md + SOUL.md + plugins + KNOWLEDGE.md) exceeds 50% of the model's context window, auto-generate KNOWLEDGE-SUMMARY.md and present it via `document-editor` with `filePath: "agents/{slug}/KNOWLEDGE-SUMMARY.md"` for review.
 - Present the generated KNOWLEDGE.md via `document-editor` with `filePath: "agents/{slug}/KNOWLEDGE.md"` for admin review before finalising.
 - Log the refresh: write a note at the top of KNOWLEDGE.md with the refresh timestamp.
@@ -45,10 +46,10 @@ Run `memory-search` multiple times with targeted queries to build comprehensive
 
 1. Search with the agent's role or topic as the query term. In the results, identify nodes whose `agents` property contains the target agent's slug — these are the directly-tagged nodes.
 2. For each keyword in the agent's `knowledgeKeywords`, search with that keyword as the query term. These capture content by topic regardless of tagging.
-3. Merge all results, deduplicate by node content, and organise under clear markdown headings by topic.
+3. Merge all results, deduplicate by node content, and organise under clear markdown headings by topic. That organised set is what you present for approval — it is a proposal, not the next version of the file.
 
 Categories to cover (where relevant to the agent's role): services, pricing, FAQs, team, policies, products, location/hours, contact info. Skip categories where no matching content exists.
 
 ## Bulk Refresh
 
-When asked to refresh all agents, iterate over each public agent directory under `agents/`, read its `config.json`, and run the refresh for each. Present a summary of results.
+When asked to refresh all agents, iterate over each public agent directory under `agents/`, read its `config.json`, and gather for each. Approval is still per agent and per line — "refresh everything" asks you to do the gathering in one pass, not to write in one pass. Present each agent's proposed lines, take the operator's approvals, then write. Finish with a summary naming, per agent, how many lines were approved and how many were dropped.

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

@@ -9,6 +9,20 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-31 (0.1.540)
+
+- A registered party can now be set to notify you without the assistant replying to them, so you see the message and decide yourself.
+- The assistant can now create, update and delete agents for you, and every one of its tools is checked at build time against what it declares.
+- Each incoming message from outside your team now carries one reference through every step, so a message can be followed end to end when something goes wrong.
+- WhatsApp conversations are now tracked per account, with a standing check that reports a phone number appearing under two accounts.
+
+## 2026-07-31 (0.1.539)
+
+- You can now reply to a specific message in chat, and the assistant sees which one you meant.
+- The calendar now shows times in the account's own timezone rather than the browser's, and shows and keeps the meeting description, which is also carried into the exported calendar file.
+- Narrow phone screens no longer overflow sideways, with a standing check that reports it if the layout regresses.
+- When a live location cannot be followed, the reply from WhatsApp is now recorded so the reason is visible.
+
 ## 2026-07-31 (0.1.538)
 
 - A message from someone outside your team now also reaches the account's manager in their own chat, written in plain English, and each account can turn the separate raw notification off.

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

@@ -69,6 +69,8 @@ either is a regression.
 
 **`/chat` empty-state starter chips.** While the admin webchat has no conversation JSONL yet (`GET /api/webchat/session` → `projectDir:null`), `app/chat/page.tsx` renders a "What's up next, {givenName}?" greeting (given name = first whitespace token of the admin session's `userName`; degrades to "What's up next?" without one) above three one-tap starter chips (replacing the earlier read-only lists): **Catch me up** (`Inbox`), **My day** (`CalendarClock`), **To-do** (`ListTodo`). `GreetingPanel` no longer fetches `GET /api/webchat/greeting` — the headline reads from the `userName` prop alone. A tap dispatches the chip's verbatim prompt through the existing `send()` with zero typing, via the same arm/fire path as the `?q=` handoff seed: `dispatchChip` logs `[admin-ui] op=chip-tap id=<catch-up|my-day|to-do> chars=<n>`, sets the composer text, and arms a one-shot effect that fires `send()` once the text matches. Chips gate to `variant` admin/operator; the public surface shows the headline alone. The first journaled turn replaces the panel with the transcript. The `/api/webchat/greeting` route (`server/routes/webchat-greeting.ts`) and `specialist-roster.ts` are now unconsumed by this surface — slimming them is a separate follow-up. The full webchat architecture lives in `.docs/admin-webchat-native-channel.md`.
 
+**`/chat` reply to a specific message.** Each of your own messages and each of the assistant's replies carries a reply control beside its copy button. Clicking it puts a strip above the composer naming who you are replying to and quoting the message; the X on that strip cancels. Sending delivers the quote to the agent as the first line of its context, so "redo that one" resolves to the message you pointed at, and the sent message keeps the quote visible above it when you reload. Two limits are deliberate: a message that arrived while the assistant was mid-turn cannot be quoted (the transcript records that arrival without an id to target), and tool runs, thinking runs and error banners are not reply targets. The quoted text is capped at 500 characters and is read from the conversation's own transcript server-side, never from the browser. The public visitor surface has no reply control. The full path is in `.docs/admin-webchat-native-channel.md`.
+
 **`/chat` composer transport button.** The button at the end of the input shows a **microphone** while the box is empty — tap it to record a voice note. Type a character, or attach a file, and the same button becomes the **send** arrow; while the agent is replying it becomes a **stop** square. So an empty composer offers voice, a composer with something to send offers send, and a running turn offers stop — one button, three states. The microphone-device chooser (which input to record from) stays in the row of icons below the box. This is the same on the admin `/chat`, the public chat, and the maxy-lite webchat.
 
 **`/chat` Conversations flyout + zero-sessions splash.** The admin `/chat` `HeaderMenu` carries a **Conversations** item (rendered only when `onOpenConversations` is wired, which scopes it to `/chat`) that opens an in-chat session-management pane (`app/chat/SessionList.tsx`) hosted by `chat/page.tsx` — distinct from, and sharing endpoints with, the `Sidebar` Sessions list (which stays hidden on narrow viewports). It enumerates the admin's own webchat sessions via `GET /api/admin/sidebar-sessions` (carries the per-row `live` marker and `archived` flag, install-wide), **filtering out `channel:'whatsapp'`/`'telegram'` rows** (those are channel-bound, cannot be chatted in webchat, and live in the WhatsApp/Telegram reader panels; the same endpoint now also feeds the sidebar Sessions list, which does show them), lists the remainder newest-first with the live one marked and archived rows folded under a collapsible subsection, and offers per-row resume (`/chat?session=<id>`), rename, archive/unarchive, two-tap delete, an **End** control on the live row (`session-stop`), plus a New-session control (`session-rc-spawn`) and a copyable full id. The pane header carries the title and a top-right close (X) control that dismisses the flyout (no back-chevron/"Chat" label); the New-session control floats at the pane's bottom-left. When the canonical pointer is `known:false` (`canonical-empty`) and enumeration returns zero rows, the surface renders a splash (brand logo + New session) instead of a dead bootstrap thread; a freshly-spawned New session is `known:true`, so its greeting is preserved. Client breadcrumbs: `[chat-conversations] op=enumerate owned=<n>` and `op=action name=<open|rename|archive|delete|stop> sessionId=<id8>` (`op=action-failed … status=…` on a non-2xx). Detail lives in `.docs/admin-webchat-native-channel.md` ("Conversations flyout + zero-sessions splash").
@@ -560,6 +562,40 @@ explicit `?plugin=` parameter, not inferred from `--` in the slug.
 | `DELETE /api/admin/agents/:slug?accountId=` | Public agents only, on the named validated account. Removes the dir after `deleteAgentProjection`; refuses the `admin` slug (403) and a missing/unknown `accountId` (400) with no write. Loud-fail: a graph-cleanup throw aborts the file removal. |
 | `POST /api/admin/agents/:slug/project?accountId=` | Re-projects the named account's on-disk agent into the graph. Same `accountId` contract as delete. |
 
+### Agent write tools (admin MCP)
+
+Public-agent CRUD is tool-only. There is no create or update HTTP route: the three
+admin MCP tools own the write path, and raw file writes reach none of their checks.
+That is what left the `beagle` agent on disk and absent from the graph for a day.
+
+| Tool | Refuses | On success |
+|---|---|---|
+| `agent-create` | `slug-unsafe` (shape, reserved or route-shadowed, by the same rule the router serves by), `exists` (the directory is occupied), `knowledge-empty`, `config-invalid` (naming the field), `not-found` (the platform IDENTITY template is missing). Every check runs before the first write, so a refusal leaves no directory. | Writes `IDENTITY.md` (copied verbatim from `templates/agents/public/`), `SOUL.md`, `KNOWLEDGE.md` and `config.json`, then projects. Returns an error when the write landed but the projection did not. |
+| `agent-update` | `slug-unsafe`, `not-found`, `knowledge-empty` when `knowledge` is supplied, `config-invalid` on the merged config. A refusal leaves the directory byte-identical. | Writes only the fields supplied, merges config fields into the existing file, then re-projects. Called with the slug alone it re-projects and nothing else. |
+| `agent-delete` | The `admin` slug, at the tool boundary as well as at the route. | Calls `DELETE /api/admin/agents/:slug`, which removes the graph projection before the directory and preserves the files if the graph write throws. |
+
+The config schema (`plugins/admin/mcp/src/tools/agent-config-schema.ts`) requires a
+non-blank `displayName`, a `model` passing `isSelectableModel`, and a `status` of
+`active` or `inactive`; it constrains `imageShape`, `accessMode` and
+`knowledgeKeywords` when present, and passes unknown keys so a field written by an
+unreleased feature is not blocked. `KNOWLEDGE-SUMMARY.md` is the one agent file no
+write tool owns; write it directly and the next `agent-update` projects it.
+
+Every call emits one line:
+
+    [admin/agents] op=agent-write action=<create|update|delete> slug=<slug> accountId=<8>
+      outcome=<ok|refused> reason=<slug-unsafe|config-invalid|knowledge-empty|exists|not-found|projection-failed|delete-failed|write-failed|none>
+      detail=<shape|reserved|shadowed|field|error text|-> projected=<n>
+
+`projected` is read from the projection response, never assumed. The
+disk-without-graph signature is `action=create|update outcome=ok projected=0` —
+the action matters, because a successful delete also logs `projected=0`, having
+removed the projection on purpose.
+
+`reason=write-failed` covers an unresolvable account directory or an I/O error.
+It exists because `getAccountDir` throws and the lifeline wrapper re-throws, so
+without a catch in the handler those failures would emit no line at all.
+
 Observability rides `[admin/agents]`, and **every line names the account it acted
 on** (`accountId=<id8>`) — a well-formed answer about the wrong account is
 otherwise indistinguishable from a correct one, which is exactly how an empty
@@ -580,6 +616,19 @@ Agents page survived undiagnosed on a multi-account install.
 - `op=<delete|project> rejected reason=<missing-accountId|unknown-accountId>` —
   a caller that did not name its account. A skill that was not updated produces
   this on its first call instead of writing to the wrong account.
+- `op=project rejected reason=agent-not-on-disk accountId=<id8> slug=<…>
+  probed=<agentDir>` — the projection 404. `probed` names the directory that
+  actually resolved, so a "the route says not found, the files are plainly
+  there" report is refutable without reproducing the call; before it existed the
+  route returned that 404 silently and such a report could be neither confirmed
+  nor refuted. Its two siblings are `op=project ok accountId=<id8> slug=<…>
+  nodesWritten=<n>` and `op=project failed accountId=<id8> slug=<…>
+  error="<msg>"` on a projector throw. `nodesWritten` counts nodes MERGEd — the
+  Agent node plus one KnowledgeDocument per present body file — so it stays
+  non-zero on an idempotent re-projection, and **`nodesWritten=0` on an `ok` is
+  the defect signature**: `projectAgent` returns early without throwing on an
+  unsafe slug, a missing `config.json` or a body-file read error, and the route
+  answers `200 {"ok":true}` in all three cases.
 - `op=delete accountId=<id8> slug=<…> outcome=<ok|failed>` with
   `reason=<graph-cleanup-failed|rm-error>` on failure (files preserved on a
   graph-cleanup throw).
@@ -983,6 +1032,30 @@ The companion `/api/admin/version` and `/api/admin/actions` routes are
 served by `maxy-edge.service`, not this aggregator. The edge process
 keeps the upgrade view alive while the brand service restarts.
 
+### Phone-width layout overflow
+
+If any part of an admin screen is cut off at the right edge on a phone —
+a header pill, a message bubble — the dashboard now reports it by itself
+rather than waiting for a screenshot. Every admin page measures its own
+width after it settles, and posts a record when something sticks out past
+the edge.
+
+Read the reports with:
+
+```
+grep 'op=layout-overflow' ~/.<brand>/logs/client-errors.log
+```
+
+Each line names the page it happened on (`route`) and the element that
+stuck out (`offender`), so the cause is identifiable without reproducing
+it on a handset. A line with a `delta` but an empty `offender` means the
+measurement ran too early, which is a different fault from a cut-off
+page. No lines at all is the healthy state.
+
+These reports share the client-error log, so they also count towards the
+24-hour client-error figure shown on the upgrade view. A rise there with
+`op=layout-overflow` lines behind it is a layout problem, not a crash.
+
 ## System-stats widget
 
 Source:

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

@@ -28,7 +28,9 @@ Every turn carries a `source`. Three values exist:
 | `schedule` | The scheduler wrote this turn. The named destination did not send it. |
 | `public-relay` | The platform wrote this turn because a public visitor messaged the account. The named sender is a manager being told, not someone who wrote to you. |
 
-A `public-relay` turn also says so in its own first two lines. If a turn claims a manager wrote something they plainly would not have written, check the source before answering them.
+A `public-relay` turn also says so in its own first two lines, and states which handset its reply tool reaches. That handset is the manager's, never the visitor's: the turn runs in the manager's own admin session, so a reply written to the visitor is delivered to the manager. If a turn claims a manager wrote something they plainly would not have written, check the source before answering them.
+
+**On a `public-relay` turn the reply tool is the only way to reach anyone.** On an ordinary turn the platform forwards your closing text to the sender when you called no reply tool. On a relay-woken turn it does not, because the relay carries its own reply path. So whatever you decide the manager should receive has to go through the reply tool; text you merely write at the end of the turn reaches nobody, and a decision not to reply is silence rather than a message.
 
 ## Which files compose the prompt
 
@@ -45,7 +47,7 @@ A public agent's directory also carries `KNOWLEDGE.md` and `config.json`. An acc
 
 ## The switches, and what each one stops
 
-Four settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
+Five settings sit on this path. They are not interchangeable, and reaching for the wrong one is how an operator ends up silencing more than they meant.
 
 | Setting | What it stops | What it leaves running |
 |---|---|---|
@@ -53,6 +55,7 @@ Four settings sit on this path. They are not interchangeable, and reaching for t
 | `publicAgentEnabled: false` | The visitor gets no reply. | The manager notification and the relay. |
 | `managerNotifyEnabled: false` | The verbatim copy of the visitor's message. | The relay, and any reply the woken turn sends. |
 | `dispatchInbound: false` | Every agent turn on that account's socket. | Storage: messages are still stored and readable. |
+| `dispatch: false` on one registered party | The public-agent turn for that one phone. | Everything else: storage, the label, the manager notification, the relay, and every other sender on the line. |
 
 `managerNotifyEnabled` is the fine-grained one, and the one to reach for when the notifications are unwanted but the work is not. Unbinding a manager is not a substitute: the manager registry is shared by the notification, the relay and `whatsapp-notify-manager`, so unbinding silences all three.
 
@@ -60,16 +63,34 @@ Read the current value with `whatsapp-config {action:'get-manager-notify-enabled
 
 ## When the answer is not here
 
-`logs-read --tail server` and filter on the tags. One public inbound writes this chain, in order, with `account=` and `sender=` on each line:
+`logs-read --tail server` and filter on the tags. One public inbound writes this chain, in order:
 
 ```
-[whatsapp:wire]         op=stanza
-[wa-notify]             op=eligible        reason=<how the sender was admitted>
-[whatsapp:route]        op=routed          agentType=public
-[whatsapp:notify]       op=public-inbound  enabled=0|1 outcome=sent|failed|no-recipients|disabled
-[whatsapp:relay]        op=dispatch        outcome=sent|failed|no-recipients
-[whatsapp:public-agent] op=route           enabled=… slug=… spawned=0|1
-[whatsapp:public-agent] op=spawn-ok | op=spawn-failed
+[whatsapp:wire]         op=stanza          msgId=<id>
+[wa-notify]             op=eligible        msgId=<id> reason=<how the sender was admitted>
+[whatsapp:route]        op=routed          inboundId=<id> msgIds=<the stanzas this payload covers>
+[whatsapp:notify]       op=public-inbound  inboundId=<id> enabled=0|1 outcome=sent|failed|no-recipients|disabled
+[whatsapp:relay]        op=dispatch        inboundId=<id> outcome=sent|failed|no-recipients
+[whatsapp:party]        op=dispatch-decision  inboundId=<id> party=… dispatch=true|false spawned=0|1   (labelled senders only)
+[whatsapp:public-agent] op=route           inboundId=<id> enabled=… slug=… spawned=0|1
+[whatsapp:public-agent] op=spawn-ok | op=spawn-failed   inboundId=<id>
 ```
 
-Three standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `gap`, `relayGap` and `englishGap`, each of which counts a step that a routed inbound reached and the next one did not. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.
+Follow one inbound by its `inboundId`. That selects the last five lines and nothing else, however many visitors messaged in the same window. For the first two, read `msgIds=` off the `op=routed` line and grep one of those ids. Two greps rather than one, because the debouncer merges stanzas into a single routed payload and the two halves are keyed either side of that merge.
+
+Anything that failed carries the same id: the drop lines, `op=public-inbound-rejected`, `op=dispatch-rejected` and `op=spawn-failed`. Fewer lines than expected, with none of them a failure, means a step emitted nothing at all — which is what the standing audits below are for.
+
+Do not try to follow an inbound by its sender. `sender=` appears on two of these lines, and the same visitor is a LID on `op=stanza` and an E.164 on `op=routed`, so no sender-based filter spans the merge.
+
+`op=spawn-failed` there is the WhatsApp side reporting a 500. What the spawn itself did is in the manager's own lines, correlated by `pid`:
+
+```
+op=startup-watch                  state=armed
+op=public-dev-channel-confirmed   channel=<kind> bufferCleared=<bool> bytesDropped=<n>
+op=startup-watch                  state=reset
+op=startup-watch                  state=disposed
+```
+
+The first-run dialog is answered for the session, and the watcher that guards against an *unanswered* one drops what it saw before that answer. `bufferCleared=false` means the confirm fired and the drop did not, which is the shape that killed a resumed spawn on 2026-08-01: the answered dialog's own footer stayed in the buffer, the replayed transcript slid past it, and the spawn was blocked by a line the agent itself had written the day before.
+
+Three standing audits reconcile that chain rather than waiting for someone to notice. `op=public-notify-reconcile` reports `gap`, `relayGap` and `answerGap`, each of which counts a step that a routed inbound reached and the next one did not. `op=spawn-census` reports attempts against successes. A non-zero gap, or attempts with no successes, is a fault even when nothing has been reported.

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

@@ -293,7 +293,7 @@ A `Service` node matched by vector search will have its `PriceSpecification`, `R
 
 ## Keyword Subscriptions — Reactive Per-Agent Knowledge
 
-Each public agent can subscribe to up to 5 keywords via `knowledgeKeywords` in its `config.json`. These subscriptions make the agent reactive to new graph content matching its topics — content added after the agent was created becomes discoverable without manual tag updates.
+Each public agent can subscribe to up to 5 keywords via `knowledgeKeywords` in its `config.json`. Subscriptions default to empty and are opt-in: the operator asks for them or the agent has none. A subscription makes new graph content matching its topics **discoverable at the next refresh** — it surfaces candidate lines for the operator to approve, and never adds anything to a public agent's knowledge on its own. Whatever a public agent can say is a line the operator approved for a stranger to read.
 
 ### Dual search per keyword
 
@@ -311,7 +311,7 @@ Results from keyword subscription searches are merged into the same scored map a
 
 ### Lifecycle
 
-Keywords are consumed by the `update-knowledge` admin skill when regenerating KNOWLEDGE.md — the regeneration query broadens the operator-tagged set with keyword matches so newly-added graph content that shares a subscribed topic lands in the next baked snapshot. There is no runtime keyword-injection path on the public PTY surface.
+Keywords are consumed by the `update-knowledge` admin skill when regenerating KNOWLEDGE.md — the regeneration query broadens the operator-tagged set with keyword matches, so newly-added graph content sharing a subscribed topic is *proposed* for the next baked snapshot. It is proposed, not baked: the skill presents the gathered lines and writes only the ones the operator approves. There is no runtime keyword-injection path on the public PTY surface.
 
 ---
 

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

@@ -118,7 +118,7 @@ Backfilling already-written `:Event` appointments into `:Meeting` is a separate
 
 Both labels are readable. `schedule-list` returns meetings and events together and tags each row `kind`; a meeting renders as `MEETING — <title> (<start>) → <end> (<uid>)`. `status` filters **events only**, because a `:Meeting` carries no `eventStatus`; `from`, `to` and `upcoming` apply to meetings on `startsAt`.
 
-A meeting's handle is its `uid`. `schedule-event` returns it on creation, and `schedule-get`, `schedule-update` and `schedule-cancel` accept it wherever they accept an event id — they resolve an event first, then a meeting, so a caller never has to say which kind it holds. Updating a meeting sets `title`, `startsAt`, `endsAt` and `location` and never rewrites the `uid` (the same contract as the admin Calendar edit); `description`, `eventStatus`, `recurrence`, `note`, `action` and `agentDispatch` have no meeting equivalent and do not cross over. Cancelling a meeting **deletes** it and its attendee edges, the same as deleting it on the Calendar page — a `:Meeting` has no status to set to cancelled. A booking-sourced meeting that is deleted is rewritten by the next reconcile run.
+A meeting's handle is its `uid`. `schedule-event` returns it on creation, and `schedule-get`, `schedule-update` and `schedule-cancel` accept it wherever they accept an event id — they resolve an event first, then a meeting, so a caller never has to say which kind it holds. Updating a meeting sets `title`, `startsAt`, `endsAt` and `location` and never rewrites the `uid`; `eventStatus`, `recurrence`, `note`, `action` and `agentDispatch` have no meeting equivalent and do not cross over. A meeting DOES carry a `description`: `schedule-event` writes one, `schedule-get` returns it, and the admin Calendar edits it. `schedule-update` does not write it, so this tool's field set is narrower than the admin Calendar edit's. Cancelling a meeting **deletes** it and its attendee edges, the same as deleting it on the Calendar page — a `:Meeting` has no status to set to cancelled. A booking-sourced meeting that is deleted is rewritten by the next reconcile run.
 
 Until this landed, `schedule-list` matched `:Event` alone while `schedule-event` wrote `:Meeting`, so an agent could not see its own writes: a calendar-sync turn read back an empty list, re-applied the same three meetings, and told the operator over WhatsApp that they had not saved. Observability is therefore two-part. Every list call logs `[schedule-list] op=result meetings=<n> events=<n>`. The standing check is `[schedule-audit] account=<id> meetings=<n> listable=<n> invisible=<n>`, emitted per account on every `reconcile-bookings` run (every 120 s) **before** that script's Cloudflare gates, so it also reports on installs with no booking site. `listable` is what the real `scheduleList` returns, not a re-implementation of its query — that is the whole point, since a copy would agree with a broken original. `invisible=0` is the success signal; `invisible>0` means a calendar entry exists that the agent cannot see.
 

package/payload/platform/plugins/scheduling/mcp/dist/tools/__tests__/schedule-get-description.test.d.ts

@@ -0,0 +1,2 @@
+export {};
+//# sourceMappingURL=schedule-get-description.test.d.ts.map

package/payload/platform/plugins/scheduling/mcp/dist/tools/__tests__/schedule-get-description.test.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"schedule-get-description.test.d.ts","sourceRoot":"","sources":["../../../src/tools/__tests__/schedule-get-description.test.ts"],"names":[],"mappings":""}

package/payload/platform/plugins/scheduling/mcp/dist/tools/__tests__/schedule-get-description.test.js

@@ -0,0 +1,59 @@
+// Task 2280. "Reading the meeting returns only title, times, location and
+// timezone" was the operator's report, and it was exactly what the projection
+// selected: `m.description` is written by meeting-write and was read by nothing.
+import { describe, it, expect, vi } from "vitest";
+const MEETING = {
+    uid: "sched-bgl0004",
+    title: "BGL-0004 — Zanzibar airport to My Blue Hotel",
+    startsAt: "2026-08-01T13:40:00+03:00",
+    endsAt: "2026-08-01T16:15:00+03:00",
+    location: "Zanzibar airport",
+    timezone: "Africa/Dar_es_Salaam",
+    description: "Driver Mcha. $40 cash with an ATM stop on the way.",
+    createdAt: "2026-07-31T18:02:11.000Z",
+    updatedAt: "2026-07-31T18:02:11.000Z",
+};
+let lastCypher = "";
+vi.mock("../../lib/neo4j.js", () => ({
+    getSession: () => ({
+        run: vi.fn(async (cypher) => {
+            lastCypher = cypher;
+            if (cypher.includes("MATCH (m:Meeting")) {
+                return {
+                    records: [
+                        {
+                            get: (k) => k === "rels" ? [] : MEETING[k],
+                        },
+                    ],
+                };
+            }
+            return { records: [] };
+        }),
+        close: vi.fn(async () => { }),
+    }),
+}));
+import { scheduleGet } from "../schedule-get.js";
+describe("scheduleGet — the meeting body comes back (Task 2280)", () => {
+    it("returns the description", async () => {
+        const detail = await scheduleGet("sched-bgl0004", "acct-1");
+        expect(detail.description).toBe("Driver Mcha. $40 cash with an ATM stop on the way.");
+    });
+    it("still returns the fields it always did", async () => {
+        const detail = await scheduleGet("sched-bgl0004", "acct-1");
+        expect(detail.name).toBe("BGL-0004 — Zanzibar airport to My Blue Hotel");
+        expect(detail.location).toBe("Zanzibar airport");
+        expect(detail.timezone).toBe("Africa/Dar_es_Salaam");
+        expect(detail.startDate).toBe("2026-08-01T13:40:00+03:00");
+    });
+    it("selects the column, which is where the field was missing", async () => {
+        await scheduleGet("sched-bgl0004", "acct-1");
+        expect(lastCypher).toContain("m.description AS description");
+    });
+    it("omits the key rather than returning an empty string when there is no body", async () => {
+        const detail = await scheduleGet("sched-bgl0004", "acct-1");
+        // Same mock, description blanked for this assertion only.
+        const blank = { ...detail, description: undefined };
+        expect("description" in blank && blank.description === "").toBe(false);
+    });
+});
+//# sourceMappingURL=schedule-get-description.test.js.map

package/payload/platform/plugins/scheduling/mcp/dist/tools/__tests__/schedule-get-description.test.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"schedule-get-description.test.js","sourceRoot":"","sources":["../../../src/tools/__tests__/schedule-get-description.test.ts"],"names":[],"mappings":"AAAA,0EAA0E;AAC1E,8EAA8E;AAC9E,iFAAiF;AACjF,OAAO,EAAE,QAAQ,EAAE,EAAE,EAAE,MAAM,EAAE,EAAE,EAAE,MAAM,QAAQ,CAAC;AAElD,MAAM,OAAO,GAAG;IACd,GAAG,EAAE,eAAe;IACpB,KAAK,EAAE,8CAA8C;IACrD,QAAQ,EAAE,2BAA2B;IACrC,MAAM,EAAE,2BAA2B;IACnC,QAAQ,EAAE,kBAAkB;IAC5B,QAAQ,EAAE,sBAAsB;IAChC,WAAW,EAAE,oDAAoD;IACjE,SAAS,EAAE,0BAA0B;IACrC,SAAS,EAAE,0BAA0B;CACtC,CAAC;AAEF,IAAI,UAAU,GAAG,EAAE,CAAC;AAEpB,EAAE,CAAC,IAAI,CAAC,oBAAoB,EAAE,GAAG,EAAE,CAAC,CAAC;IACnC,UAAU,EAAE,GAAG,EAAE,CAAC,CAAC;QACjB,GAAG,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,EAAE,MAAc,EAAE,EAAE;YAClC,UAAU,GAAG,MAAM,CAAC;YACpB,IAAI,MAAM,CAAC,QAAQ,CAAC,kBAAkB,CAAC,EAAE,CAAC;gBACxC,OAAO;oBACL,OAAO,EAAE;wBACP;4BACE,GAAG,EAAE,CAAC,CAAS,EAAE,EAAE,CACjB,CAAC,KAAK,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAE,OAAmC,CAAC,CAAC,CAAC;yBAC9D;qBACF;iBACF,CAAC;YACJ,CAAC;YACD,OAAO,EAAE,OAAO,EAAE,EAAE,EAAE,CAAC;QACzB,CAAC,CAAC;QACF,KAAK,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,IAAI,EAAE,GAAE,CAAC,CAAC;KAC7B,CAAC;CACH,CAAC,CAAC,CAAC;AAEJ,OAAO,EAAE,WAAW,EAAE,MAAM,oBAAoB,CAAC;AAEjD,QAAQ,CAAC,uDAAuD,EAAE,GAAG,EAAE;IACrE,EAAE,CAAC,yBAAyB,EAAE,KAAK,IAAI,EAAE;QACvC,MAAM,MAAM,GAAG,MAAM,WAAW,CAAC,eAAe,EAAE,QAAQ,CAAC,CAAC;QAC5D,MAAM,CAAC,MAAO,CAAC,WAAW,CAAC,CAAC,IAAI,CAAC,oDAAoD,CAAC,CAAC;IACzF,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,wCAAwC,EAAE,KAAK,IAAI,EAAE;QACtD,MAAM,MAAM,GAAG,MAAM,WAAW,CAAC,eAAe,EAAE,QAAQ,CAAC,CAAC;QAC5D,MAAM,CAAC,MAAO,CAAC,IAAI,CAAC,CAAC,IAAI,CAAC,8CAA8C,CAAC,CAAC;QAC1E,MAAM,CAAC,MAAO,CAAC,QAAQ,CAAC,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;QAClD,MAAM,CAAC,MAAO,CAAC,QAAQ,CAAC,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC;QACtD,MAAM,CAAC,MAAO,CAAC,SAAS,CAAC,CAAC,IAAI,CAAC,2BAA2B,CAAC,CAAC;IAC9D,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,0DAA0D,EAAE,KAAK,IAAI,EAAE;QACxE,MAAM,WAAW,CAAC,eAAe,EAAE,QAAQ,CAAC,CAAC;QAC7C,MAAM,CAAC,UAAU,CAAC,CAAC,SAAS,CAAC,8BAA8B,CAAC,CAAC;IAC/D,CAAC,CAAC,CAAC;IAEH,EAAE,CAAC,2EAA2E,EAAE,KAAK,IAAI,EAAE;QACzF,MAAM,MAAM,GAAG,MAAM,WAAW,CAAC,eAAe,EAAE,QAAQ,CAAC,CAAC;QAC5D,0DAA0D;QAC1D,MAAM,KAAK,GAAG,EAAE,GAAG,MAAM,EAAE,WAAW,EAAE,SAAS,EAAE,CAAC;QACpD,MAAM,CAAC,aAAa,IAAI,KAAK,IAAI,KAAK,CAAC,WAAW,KAAK,EAAE,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC;IACzE,CAAC,CAAC,CAAC;AACL,CAAC,CAAC,CAAC"}

package/payload/platform/plugins/scheduling/mcp/dist/tools/schedule-get.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"schedule-get.d.ts","sourceRoot":"","sources":["../../src/tools/schedule-get.ts"],"names":[],"mappings":"AAEA,OAAO,EAAa,KAAK,MAAM,EAAE,MAAM,oBAAoB,CAAC;AAE5D,MAAM,WAAW,WAAW;IAC1B,wEAAwE;IACxE,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,SAAS,GAAG,OAAO,CAAC;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,uDAAuD;IACvD,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,kFAAkF;IAClF,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,mFAAmF;IACnF,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,kFAAkF;IAClF,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;IAClB,aAAa,EAAE,KAAK,CAAC;QACnB,IAAI,EAAE,MAAM,CAAC;QACb,WAAW,EAAE,MAAM,CAAC;QACpB,UAAU,CAAC,EAAE,MAAM,CAAC;QACpB,QAAQ,EAAE,MAAM,CAAC;KAClB,CAAC,CAAC;CACJ;AAED,wBAAsB,WAAW,CAAC,OAAO,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,WAAW,GAAG,IAAI,CAAC,CAqHjG"}
+{"version":3,"file":"schedule-get.d.ts","sourceRoot":"","sources":["../../src/tools/schedule-get.ts"],"names":[],"mappings":"AAEA,OAAO,EAAa,KAAK,MAAM,EAAE,MAAM,oBAAoB,CAAC;AAE5D,MAAM,WAAW,WAAW;IAC1B,wEAAwE;IACxE,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,EAAE,SAAS,GAAG,OAAO,CAAC;IAC1B,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,uDAAuD;IACvD,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,aAAa,CAAC,EAAE,MAAM,CAAC;IACvB,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,kFAAkF;IAClF,YAAY,CAAC,EAAE,MAAM,CAAC;IACtB,gBAAgB,CAAC,EAAE,MAAM,CAAC;IAC1B,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,mFAAmF;IACnF,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,kFAAkF;IAClF,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;IAClB,SAAS,EAAE,MAAM,CAAC;IAClB,aAAa,EAAE,KAAK,CAAC;QACnB,IAAI,EAAE,MAAM,CAAC;QACb,WAAW,EAAE,MAAM,CAAC;QACpB,UAAU,CAAC,EAAE,MAAM,CAAC;QACpB,QAAQ,EAAE,MAAM,CAAC;KAClB,CAAC,CAAC;CACJ;AAED,wBAAsB,WAAW,CAAC,OAAO,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAAC,WAAW,GAAG,IAAI,CAAC,CA0HjG"}

package/payload/platform/plugins/scheduling/mcp/dist/tools/schedule-get.js

@@ -15,6 +15,7 @@ export async function scheduleGet(eventId, accountId) {
          OPTIONAL MATCH (p:Person)-[r:ATTENDED]->(m)
          RETURN m.uid AS uid, m.title AS title, toString(m.startsAt) AS startsAt,
                 toString(m.endsAt) AS endsAt, m.location AS location, m.timezone AS timezone,
+                m.description AS description,
                 toString(m.createdAt) AS createdAt, toString(m.updatedAt) AS updatedAt,
                 collect({type: type(r), targetLabel: 'Person', targetName: coalesce(p.displayName, p.email), targetId: elementId(p)}) AS rels`, { id: eventId, accountId });
             if (meetingResult.records.length === 0)
@@ -41,6 +42,11 @@ export async function scheduleGet(eventId, accountId) {
                 meeting.endDate = m.get("endsAt");
             if (m.get("location"))
                 meeting.location = m.get("location");
+            // Task 2280 — the meeting's own body. Written by meeting-write since the
+            // beginning and selected by nothing, so "read the meeting" answered with a
+            // title, times, a location and a timezone and nothing else.
+            if (m.get("description"))
+                meeting.description = m.get("description");
             if (m.get("timezone"))
                 meeting.timezone = m.get("timezone");
             return meeting;

package/payload/platform/plugins/scheduling/mcp/dist/tools/schedule-get.js.map

@@ -1 +1 @@
-{"version":3,"file":"schedule-get.js","sourceRoot":"","sources":["../../src/tools/schedule-get.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,iBAAiB,CAAC;AAC7C,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AACjD,OAAO,EAAE,SAAS,EAAe,MAAM,oBAAoB,CAAC;AAqC5D,MAAM,CAAC,KAAK,UAAU,WAAW,CAAC,OAAe,EAAE,SAAiB;IAClE,MAAM,YAAY,GAAG,UAAU,EAAE,CAAC;IAClC,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,YAAY,CAAC,GAAG,CACnC;;wIAEkI,EAClI,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QAEF,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAChC,uEAAuE;YACvE,sEAAsE;YACtE,wCAAwC;YACxC,MAAM,aAAa,GAAG,MAAM,YAAY,CAAC,GAAG,CAC1C;;;;;8IAKsI,EACtI,EAAE,EAAE,EAAE,OAAO,EAAE,SAAS,EAAE,CAC3B,CAAC;YACF,IAAI,aAAa,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC;gBAAE,OAAO,IAAI,CAAC;YAEpD,MAAM,CAAC,GAAG,aAAa,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;YACnC,MAAM,KAAK,GAAG,CAAC,CAAC,GAAG,CAAC,MAAM,CAKxB,CAAC;YACH,MAAM,OAAO,GAAgB;gBAC3B,OAAO,EAAE,CAAC,CAAC,GAAG,CAAC,KAAK,CAAC;gBACrB,IAAI,EAAE,SAAS;gBACf,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC;gBACpB,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAC5B,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,WAAW,CAAC;gBAC7B,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,WAAW,CAAC;gBAC7B,aAAa,EAAE,KAAK;qBACjB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC;qBAC9B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;oBACX,IAAI,EAAE,CAAC,CAAC,IAAK;oBACb,WAAW,EAAE,CAAC,CAAC,WAAW,IAAI,QAAQ;oBACtC,UAAU,EAAE,CAAC,CAAC,UAAU,IAAI,SAAS;oBACrC,QAAQ,EAAE,CAAC,CAAC,QAAS;iBACtB,CAAC,CAAC;aACN,CAAC;YACF,IAAI,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC;gBAAE,OAAO,CAAC,OAAO,GAAG,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;YACvD,IAAI,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAAE,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC;YAC5D,IAAI,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAAE,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC;YAC5D,OAAO,OAAO,CAAC;QACjB,CAAC;QAED,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;QACjC,MAAM,CAAC,GAAG,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,UAAU,CAAC;QACrC,MAAM,IAAI,GAAG,MAAM,CAAC,GAAG,CAAC,MAAM,CAK5B,CAAC;QAEH,MAAM,MAAM,GAAgB;YAC1B,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,IAAI,EAAE,OAAO;YACb,IAAI,EAAE,CAAC,CAAC,IAAI;YACZ,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,WAAW,EAAE,CAAC,CAAC,WAAW;YAC1B,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,aAAa,EAAE,IAAI;iBAChB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC;iBAC9B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;gBACX,IAAI,EAAE,CAAC,CAAC,IAAK;gBACb,WAAW,EAAE,CAAC,CAAC,WAAW,IAAI,SAAS;gBACvC,UAAU,EAAE,CAAC,CAAC,UAAU,IAAI,SAAS;gBACrC,QAAQ,EAAE,CAAC,CAAC,QAAS;aACtB,CAAC,CAAC;SACN,CAAC;QAEF,IAAI,CAAC,CAAC,WAAW;YAAE,MAAM,CAAC,WAAW,GAAG,CAAC,CAAC,WAAW,CAAC;QACtD,IAAI,CAAC,CAAC,OAAO;YAAE,MAAM,CAAC,OAAO,GAAG,CAAC,CAAC,OAAO,CAAC;QAC1C,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,UAAU;YAAE,MAAM,CAAC,UAAU,GAAG,CAAC,CAAC,UAAU,CAAC;QACnD,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,OAAO;YAAE,MAAM,CAAC,OAAO,GAAG,CAAC,CAAC,OAAO,CAAC;QAC1C,IAAI,CAAC,CAAC,aAAa;YAAE,MAAM,CAAC,aAAa,GAAG,CAAC,CAAC,aAAa,CAAC;QAC5D,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,KAAK;YAAE,MAAM,CAAC,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC;QACpC,IAAI,CAAC,CAAC,YAAY;YAAE,MAAM,CAAC,YAAY,GAAG,CAAC,CAAC,YAAY,CAAC;QACzD,IAAI,CAAC,CAAC,gBAAgB;YAAE,MAAM,CAAC,gBAAgB,GAAG,CAAC,CAAC,gBAAgB,CAAC;QACrE,IAAI,CAAC,CAAC,WAAW;YAAE,MAAM,CAAC,WAAW,GAAG,CAAC,CAAC,WAAW,CAAC;QAEtD,0EAA0E;QAC1E,2EAA2E;QAC3E,oDAAoD;QACpD,MAAM,MAAM,GAAG,MAAM,YAAY,CAAC,GAAG,CACnC;kDAC4C,EAC5C,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QACF,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YAC9B,MAAM,CAAC,OAAO,GAAG,SAAS,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,UAAU,CAAC,CAAC;QACpE,CAAC;QAED,MAAM,QAAQ,GAAG,MAAM,YAAY,CAAC,GAAG,CACrC;4BACsB,EACtB,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QACF,MAAM,CAAC,QAAQ,GAAG,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC;QAE/D,OAAO,MAAM,CAAC;IAChB,CAAC;YAAS,CAAC;QACT,MAAM,YAAY,CAAC,KAAK,EAAE,CAAC;IAC7B,CAAC;AACH,CAAC"}
+{"version":3,"file":"schedule-get.js","sourceRoot":"","sources":["../../src/tools/schedule-get.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,iBAAiB,CAAC;AAC7C,OAAO,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AACjD,OAAO,EAAE,SAAS,EAAe,MAAM,oBAAoB,CAAC;AAqC5D,MAAM,CAAC,KAAK,UAAU,WAAW,CAAC,OAAe,EAAE,SAAiB;IAClE,MAAM,YAAY,GAAG,UAAU,EAAE,CAAC;IAClC,IAAI,CAAC;QACH,MAAM,MAAM,GAAG,MAAM,YAAY,CAAC,GAAG,CACnC;;wIAEkI,EAClI,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QAEF,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC,EAAE,CAAC;YAChC,uEAAuE;YACvE,sEAAsE;YACtE,wCAAwC;YACxC,MAAM,aAAa,GAAG,MAAM,YAAY,CAAC,GAAG,CAC1C;;;;;;8IAMsI,EACtI,EAAE,EAAE,EAAE,OAAO,EAAE,SAAS,EAAE,CAC3B,CAAC;YACF,IAAI,aAAa,CAAC,OAAO,CAAC,MAAM,KAAK,CAAC;gBAAE,OAAO,IAAI,CAAC;YAEpD,MAAM,CAAC,GAAG,aAAa,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;YACnC,MAAM,KAAK,GAAG,CAAC,CAAC,GAAG,CAAC,MAAM,CAKxB,CAAC;YACH,MAAM,OAAO,GAAgB;gBAC3B,OAAO,EAAE,CAAC,CAAC,GAAG,CAAC,KAAK,CAAC;gBACrB,IAAI,EAAE,SAAS;gBACf,IAAI,EAAE,CAAC,CAAC,GAAG,CAAC,OAAO,CAAC;gBACpB,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAC5B,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,WAAW,CAAC;gBAC7B,SAAS,EAAE,CAAC,CAAC,GAAG,CAAC,WAAW,CAAC;gBAC7B,aAAa,EAAE,KAAK;qBACjB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC;qBAC9B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;oBACX,IAAI,EAAE,CAAC,CAAC,IAAK;oBACb,WAAW,EAAE,CAAC,CAAC,WAAW,IAAI,QAAQ;oBACtC,UAAU,EAAE,CAAC,CAAC,UAAU,IAAI,SAAS;oBACrC,QAAQ,EAAE,CAAC,CAAC,QAAS;iBACtB,CAAC,CAAC;aACN,CAAC;YACF,IAAI,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC;gBAAE,OAAO,CAAC,OAAO,GAAG,CAAC,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAC;YACvD,IAAI,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAAE,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC;YAC5D,yEAAyE;YACzE,2EAA2E;YAC3E,4DAA4D;YAC5D,IAAI,CAAC,CAAC,GAAG,CAAC,aAAa,CAAC;gBAAE,OAAO,CAAC,WAAW,GAAG,CAAC,CAAC,GAAG,CAAC,aAAa,CAAC,CAAC;YACrE,IAAI,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC;gBAAE,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC,GAAG,CAAC,UAAU,CAAC,CAAC;YAC5D,OAAO,OAAO,CAAC;QACjB,CAAC;QAED,MAAM,MAAM,GAAG,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC;QACjC,MAAM,CAAC,GAAG,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,UAAU,CAAC;QACrC,MAAM,IAAI,GAAG,MAAM,CAAC,GAAG,CAAC,MAAM,CAK5B,CAAC;QAEH,MAAM,MAAM,GAAgB;YAC1B,OAAO,EAAE,CAAC,CAAC,OAAO;YAClB,IAAI,EAAE,OAAO;YACb,IAAI,EAAE,CAAC,CAAC,IAAI;YACZ,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,WAAW,EAAE,CAAC,CAAC,WAAW;YAC1B,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,SAAS,EAAE,CAAC,CAAC,SAAS;YACtB,aAAa,EAAE,IAAI;iBAChB,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC;iBAC9B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;gBACX,IAAI,EAAE,CAAC,CAAC,IAAK;gBACb,WAAW,EAAE,CAAC,CAAC,WAAW,IAAI,SAAS;gBACvC,UAAU,EAAE,CAAC,CAAC,UAAU,IAAI,SAAS;gBACrC,QAAQ,EAAE,CAAC,CAAC,QAAS;aACtB,CAAC,CAAC;SACN,CAAC;QAEF,IAAI,CAAC,CAAC,WAAW;YAAE,MAAM,CAAC,WAAW,GAAG,CAAC,CAAC,WAAW,CAAC;QACtD,IAAI,CAAC,CAAC,OAAO;YAAE,MAAM,CAAC,OAAO,GAAG,CAAC,CAAC,OAAO,CAAC;QAC1C,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,UAAU;YAAE,MAAM,CAAC,UAAU,GAAG,CAAC,CAAC,UAAU,CAAC;QACnD,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,OAAO;YAAE,MAAM,CAAC,OAAO,GAAG,CAAC,CAAC,OAAO,CAAC;QAC1C,IAAI,CAAC,CAAC,aAAa;YAAE,MAAM,CAAC,aAAa,GAAG,CAAC,CAAC,aAAa,CAAC;QAC5D,IAAI,CAAC,CAAC,QAAQ;YAAE,MAAM,CAAC,QAAQ,GAAG,CAAC,CAAC,QAAQ,CAAC;QAC7C,IAAI,CAAC,CAAC,KAAK;YAAE,MAAM,CAAC,KAAK,GAAG,CAAC,CAAC,KAAK,CAAC;QACpC,IAAI,CAAC,CAAC,YAAY;YAAE,MAAM,CAAC,YAAY,GAAG,CAAC,CAAC,YAAY,CAAC;QACzD,IAAI,CAAC,CAAC,gBAAgB;YAAE,MAAM,CAAC,gBAAgB,GAAG,CAAC,CAAC,gBAAgB,CAAC;QACrE,IAAI,CAAC,CAAC,WAAW;YAAE,MAAM,CAAC,WAAW,GAAG,CAAC,CAAC,WAAW,CAAC;QAEtD,0EAA0E;QAC1E,2EAA2E;QAC3E,oDAAoD;QACpD,MAAM,MAAM,GAAG,MAAM,YAAY,CAAC,GAAG,CACnC;kDAC4C,EAC5C,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QACF,IAAI,MAAM,CAAC,OAAO,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YAC9B,MAAM,CAAC,OAAO,GAAG,SAAS,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,UAAU,CAAC,CAAC;QACpE,CAAC;QAED,MAAM,QAAQ,GAAG,MAAM,YAAY,CAAC,GAAG,CACrC;4BACsB,EACtB,EAAE,OAAO,EAAE,SAAS,EAAE,CACvB,CAAC;QACF,MAAM,CAAC,QAAQ,GAAG,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,GAAG,CAAC,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC;QAE/D,OAAO,MAAM,CAAC;IAChB,CAAC;YAAS,CAAC;QACT,MAAM,YAAY,CAAC,KAAK,EAAE,CAAC;IAC7B,CAAC;AACH,CAAC"}

package/payload/platform/plugins/scheduling/mcp/dist/tools/schedule-update.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"schedule-update.d.ts","sourceRoot":"","sources":["../../src/tools/schedule-update.ts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAE,WAAW,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAGtE;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,cAAc,sEAAuE,CAAC;AAEnG,MAAM,MAAM,WAAW,GAAG,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,CAAC,CAAC;AAE1D,MAAM,WAAW,oBAAoB;IACnC,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,WAAW,CAAC,EAAE,WAAW,CAAC;IAC1B,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,WAAW,GAAG,IAAI,CAAC;IAC5B,aAAa,CAAC,EAAE,aAAa,GAAG,IAAI,CAAC;CACtC;AAED;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,UAAU,GAClB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,GACpC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,eAAe,GAAG,cAAc,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAE7E,wBAAgB,UAAU,CACxB,GAAG,EAAE;IAAE,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,EACrF,GAAG,EAAE,IAAI,GACR,UAAU,CAmCZ;AAED,wBAAsB,cAAc,CAAC,MAAM,EAAE,oBAAoB,GAAG,OAAO,CAAC,IAAI,CAAC,CAkahF"}
+{"version":3,"file":"schedule-update.d.ts","sourceRoot":"","sources":["../../src/tools/schedule-update.ts"],"names":[],"mappings":"AASA,OAAO,KAAK,EAAE,WAAW,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAGtE;;;;;;;;;;;;;;;GAeG;AACH,eAAO,MAAM,cAAc,sEAAuE,CAAC;AAEnG,MAAM,MAAM,WAAW,GAAG,CAAC,OAAO,cAAc,CAAC,CAAC,MAAM,CAAC,CAAC;AAE1D,MAAM,WAAW,oBAAoB;IACnC,SAAS,EAAE,MAAM,CAAC;IAClB,OAAO,EAAE,MAAM,CAAC;IAChB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,SAAS,CAAC,EAAE,MAAM,CAAC;IACnB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,WAAW,CAAC,EAAE,WAAW,CAAC;IAC1B,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,QAAQ,CAAC,EAAE,MAAM,CAAC;IAClB,QAAQ,CAAC,EAAE,OAAO,CAAC;IACnB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,WAAW,GAAG,IAAI,CAAC;IAC5B,aAAa,CAAC,EAAE,aAAa,GAAG,IAAI,CAAC;CACtC;AAED;;;;;;;;;;;;;GAaG;AACH,MAAM,MAAM,UAAU,GAClB;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,OAAO,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,GACpC;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,eAAe,GAAG,cAAc,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,CAAC;AAE7E,wBAAgB,UAAU,CACxB,GAAG,EAAE;IAAE,UAAU,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,QAAQ,EAAE,MAAM,GAAG,IAAI,CAAC;IAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAAE,EACrF,GAAG,EAAE,IAAI,GACR,UAAU,CAmCZ;AAED,wBAAsB,cAAc,CAAC,MAAM,EAAE,oBAAoB,GAAG,OAAO,CAAC,IAAI,CAAC,CAsahF"}

package/payload/platform/plugins/scheduling/mcp/dist/tools/schedule-update.js

@@ -381,12 +381,16 @@ export async function scheduleUpdate(params) {
             }
         }
         if (result.records.length === 0) {
-            // Task 2100 — the id may be a meeting uid. A :Meeting carries only
-            // title/startsAt/endsAt/location as editable fields, and its uid is the
-            // (accountId, uid) idempotency key, never rewritten by an edit — the same
-            // contract as the admin Calendar PATCH (calendar.ts:284-296). description,
-            // eventStatus, recurrence, note, action and agentDispatch have no meeting
-            // equivalent and do not cross over.
+            // Task 2100 — the id may be a meeting uid. This branch edits
+            // title/startsAt/endsAt/location, and the uid is the (accountId, uid)
+            // idempotency key, never rewritten by an edit.
+            //
+            // Task 2280 corrected what follows. A :Meeting DOES carry a description:
+            // meeting-write stores one, schedule-get returns it, and the admin
+            // Calendar PATCH now edits it. This tool still does not write it, so it is
+            // no longer the same field set as that PATCH — the remaining gap is Task
+            // 2296. eventStatus, recurrence, note, action and agentDispatch genuinely
+            // have no meeting equivalent and do not cross over.
             const meetingSets = [];
             const meetingParams = { id: eventId, accountId };
             if (updates.name !== undefined) {