@rubytech/create-maxy-code 0.1.438 → 0.1.440

package/package.json

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

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:359dfc8bdd471d36f84a6cf223c8a1621dd66f00245f5e8f8e2674642036601b
+content-hash: sha256:81b544b4ce131682cab873b1c561b196496d3f57fade3f76245646e3fc16aacc
 brand: maxy-code
 product-name: Maxy
 ---
@@ -424,6 +424,8 @@ Some premium plugins are **bundles** — multiple sub-plugins shipped under one
 
 A bundle's sub-plugins carry the skills, so each must be registered as its own Claude Code plugin for its skills to load — the installer does this at install time for every bundle the brand ships. When a sub-plugin's skills are missing (a specialist dispatches but its skill answers *Unknown skill*), the manager names the gap at boot: grep `server.log` for `[skill-registration] op=drift` — each line gives the account, the sub-plugin, and which registration surface is missing. The fix is to re-run the installer for this brand; a clean boot instead logs `startup-self-test skill-registration=ok`.
 
+The same split applies to a premium plugin's **tools**: its MCP server mounts only when the generated plugin manifest carries an `mcpServers` block (set by `mcp-manifest: auto` in the plugin's `PLUGIN.md`). When a tool-plugin is enabled but its server never mounts — its tools are listed but every call finds an empty toolbox — the manager names it at boot: grep `server.log` for `[tool-registration] op=drift`, which gives the account, the plugin, and the reason (`no-mcpServers-manifest`, `dist-missing`, or `not-installed`). A clean boot instead logs `startup-self-test tool-registration=ok`.
+
 If you ask Maxy about a tool from a plugin your brand does not ship (for example, a Maxy install asking about a Real Agent Loop CRM tool), Maxy responds with a structured `<tool-surface-error>` envelope naming the missing plugin and the remedy, rather than improvising with a generic alternative.
 
 **Public agent embedding:** Premium plugins marked as public-eligible have their full content (skills and reference knowledge) embedded in public agent prompts. This means a public agent for a Real Agent member can handle buyer enquiries, book viewings, deliver coaching content, and onboard new applicants — all powered by the premium plugin's domain knowledge. Plugins marked admin-only (listings, vendors, leads, business) are only available to the account owner's admin agent.
@@ -2036,7 +2038,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 |------|---------|
 | `outlook-account-register` | Start the device-code flow for this account. Returns a user code + `microsoft.com/devicelogin` URL immediately; does not block. |
 | `outlook-account-register-poll` | Finish the device-code flow. One check per call: returns pending, registered, expired, or denied. |
-| `outlook-mail-list` | Recent mail. Default top=25, folder=Inbox. |
+| `outlook-mail-list` | Recent mail. Default top=25, folder=Inbox. `folder` takes a well-known name or alias (case/space-insensitive): Inbox, Sent Items/sent, Drafts, Deleted Items/trash, Junk Email/junk/spam, Archive, Outbox — or a raw folder id. Custom folder names are not resolved. |
 | `outlook-mail-search` | Microsoft Graph `$search` over the mailbox. |
 | `outlook-calendar-list` | Calendar events in next rangeDays days (default 7, max 365). |
 | `outlook-calendar-event` | Full detail of a single event by id. |
@@ -2067,7 +2069,7 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Auth ok | `auth-ok account=<id> graphUserId=<id> scopes=<csv> tokenExpSec=<N>` |
 | Token refreshed | `token-refreshed account=<id> oldExpSec=<N> newExpSec=<N>` |
 | Refresh failed | `token-refresh-failed account=<id> reason=<err>` (terminal) |
-| Mail list | `mail-list account=<id> folder=<id-or-Inbox> count=<N> elapsedMs=<N>` |
+| Mail list | `mail-list op=resolve account=<id> folderIn=<name> folderResolved=<token> asRawId=<bool> count=<N> elapsedMs=<N>` (on error, `error=<msg>` replaces `count`) |
 | Mail search | `mail-search account=<id> query=<trunc-32> count=<N> elapsedMs=<N>` |
 | Calendar list | `calendar-list account=<id> rangeDays=<N> count=<N> elapsedMs=<N>` |
 | Calendar event | `calendar-event account=<id> eventId=<trunc-12> elapsedMs=<N>` |
@@ -2737,7 +2739,7 @@ either is a regression.
 |---|---|---|
 | `/session` | Admin cookie session: PIN-gated mint, validate, rotate. | `GET /`, `POST /` |
 | `/sessions` | Legacy admin-server conversation routes. No UI consumer remains after the ConversationsModal was retired; the surviving handlers are deletion candidates and not described here. | (legacy, no live caller) |
-| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> unknownChannel=<n> excludedPublicWebchat=<n>`. | `GET /` |
+| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. The name comes from the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line so a persistent `channelNamesResolved` shortfall is never silent. | `GET /` |
 | `/session-delete` | POST `{ sessionId }`. Thin proxy over the manager: POST `/:id/stop` (idempotent) then DELETE `/:id`. Sends **no** accountId. The manager resolves the session by scanning every slug under `projects/` for its JSONL (`slugForExistingJsonl`, covering `archive/`), exactly as the sidebar list enumerates rows, and gates on file existence alone — so any session the operator can see is deletable. This replaces the earlier accountId-derived slug and the `!row` term, which narrowed resolution below the list and left a session under a non-house slug with no watcher row (e.g. a legacy `-home-admin` session on a single-account install) listed yet un-deletable. Account scope is a view filter, not a delete gate — admin access is install-wide, so there is nothing to scope against. The sibling `/session-stop` (the standalone End control) resolves identically and also forwards no accountId. | `POST /` |
 | `/session-rc-spawn` | POST `{ sessionId?, name? }`. Fire-and-forget `claude --remote-control [name] [--session-id <sid>]`. Present `sessionId` resumes; absent starts a fresh session (also used by the sidebar's "New session" button — it no longer opens claude.ai/code directly). Proxies to the manager's `/rc-spawn`, which waits up to **60 s** (raised from 12 s) for the spawned PTY to bind and returns `{ spawnedPid, sessionId, bridgeSessionId, slug, outcome, reason }`. For a webchat-bound spawn (every admin-gated host's "New session", returning a same-origin `/chat?session=<id>` target — `resolveRcSpawnOutcome` → `sameOrigin:true`) the Sidebar navigates the **current** tab via `window.location.assign`, replacing the dashboard in place (back returns to it); only a claude.ai/code slug (`sameOrigin:false`, the bare-admin resume bridge, never a new-session outcome) navigates a separately-opened tab. On `timeout` or `spawn-failed` it shows an error modal (reason + sessionId) and **never** opens a bare claude.ai/code tab. The new process registers itself as its own Remote Control entry in claude.ai/code. | `POST /` |
 | `/claude-sessions` | **Spawn surface only**. `POST /` is the Sidebar new-session-with-prompt path, cookie-auth only (the recorder loopback caller was removed; LinkedIn ingest moved to `/rc-spawn`). The former UI-facing handlers (SSE row feed, list, resume, stop, rename, archive, delete, `/:id/meta`, `/:id/input`, `/:id/log`) were removed — the maxy dashboard no longer manages or displays sessions. | `POST /` |
@@ -3960,6 +3962,8 @@ For subagents, the same spawn pushes `--add-dir` for every bundled plugin agents
 
 A boot gate refuses to start the manager when any admin-allowlisted tool `mcp__<plugin>__*` lacks a registered server. The signal is `boot-failed reason=mcp-allowlist-without-server plugin=<p> tool=<t>` followed by `process.exit(1)`. The remediation is a one-line edit to the named `PLUGIN.md`: add the `mcp:` block. The complementary observability emit `mcp-config-allowlist-coverage admin-tools=A admin-registered=R` (where `A === R`) confirms the invariant per boot.
 
+**Whether a plugin's server mounts is decided by the generated manifest, not the `mcp:` block.** A plugin ships its MCP as `mcp/`; the manifest generator ([`scripts/generate-plugin-manifests.mjs`](../../../../scripts/generate-plugin-manifests.mjs), run at bundle time over the payload) reads the plugin's `mcp-manifest:` frontmatter. `auto` emits an `mcpServers` block into the generated `.claude-plugin/plugin.json` — routed through `lib/mcp-spawn-tee`, carrying no per-session env (`LOG_DIR`/`SESSION_ID`/`ACCOUNT_ID`/`NEO4J_*`/`PLATFORM_ROOT` ride the PTY env block described above) — and copies the tee into the plugin's `lib/`; `skip` emits nothing, so Claude Code never spawns the server. The generator recognises two server shapes. A plugin-local `mcp/` (its `hasMcp` check: `mcp/dist/index.js` or `mcp/package.json`) uses `auto` or `skip`. A tool-plugin whose `mcp:` server is a shared `platform/lib/<name>` binary rather than a plugin-local `mcp/` (e.g. `graph`, served by `platform/lib/graph-mcp`) is annotated `mcp-manifest: shared-lib`: the generator emits that plugin's `mcp:` block verbatim into `mcpServers` — command, args (anchored on `${PLATFORM_ROOT}`, routed through the shared `lib/mcp-spawn-tee`), and env — which Claude Code expands at spawn from the PTY env block. No tee copy is made into the plugin, because both the tee and the server resolve from `${PLATFORM_ROOT}` outside the per-plugin cache. `graph` is the one shared-lib tool-plugin; every other tool-plugin ships a plugin-local `mcp/` and uses `auto`. A plugin with an `mcp:` block, no plugin-local `mcp/`, and no `mcp-manifest: shared-lib` annotation is a FATAL at generation time. Premium plugins import platform libs (`mcp-lifeline`, etc.) via a source-tree relative path; the bundler's premium-lib shipper (`packages/create-maxy-code/scripts/bundle.js`) rewrites that path and vendors each referenced `platform/lib/<name>` into `premium-plugins/<bundle>/lib/<name>/`, so the auto-mounted dist resolves its imports. The `mcp-allowlist-without-server` gate above proves only that a plugin's PLUGIN.md `mcp:` block matches its allowlist — it reads source, not the generated manifest — so a plugin left on `skip` passes that gate while its server silently never mounts (its tools are listed but not live). The `tool-registration` gate below closes that blind spot.
+
 A second boot gate walks every specialist `.md` under `platform/templates/specialists/agents/`, every bundled `<plugin>/agents/` directory, and the per-account `<accountDir>/specialists/agents/` directory, parses each file's `tools:` frontmatter line (canonical long-prefix names), and classifies every tool name as one of: CC-native (Read, Bash, …), a tool the loaded `PLUGIN.md` set actually serves (matched as the long canonical name in `toolSurface.all`), a third-party MCP bridge (a `mcp__plugin_*` name whose plugin segment is NOT a maxy platform plugin — Playwright etc., upstream-owned, passes unconditionally), `unknown-tool-in-plugin` (maxy plugin namespace served but tool name absent), `unknown-plugin-namespace` (namespace served by nothing), `brand-excluded-plugin` (namespace served by nothing on this brand, **but** the brand's `brand.json#plugins.excluded` list names it), or `malformed-name` (not CC-native and not `mcp__`-shaped). The first three pass. The next two refuse boot with one `boot-failed reason=specialist-tool-drift specialist=<name> tool=<t> drift=<class> path=<…>` line per defect, then `process.exit(1)`. A maxy-plugin `mcp__plugin_*` name is validated against `toolSurface.all`, so a typo or stale long-prefix tool name still refuses boot rather than passing as a bridge; the build-time `check-canonical-tool-names.mjs` gate catches the same drift in instruction files before publish. `brand-excluded-plugin` is a structural pass: it lands in a per-specialist strip-list, the manager continues to boot, and at spawn time `pty-spawner` removes those tool names from the `--agent <name>` spawn's `--allowed-tools` argv. The complementary observability emit `specialist-tool-strip specialist=<name> plugin=<p> tools=<csv> reason=brand-excluded` fires one line per stripped (specialist, plugin) pair so an operator who reads `server.log` sees the brand filter doing work without cross-referencing `brand.json` against the template. The startup-self-test line `startup-self-test specialist-tool-drift=ok inspected=<N> stripped-specialists=<M>` confirms the gate ran and how many specialists carry strip-lists.
 
 The `brand-excluded` branch closes the recurring crash-restart loop on brands that ship without a plugin the shared `personal-assistant.md` template references (e.g. `realagent-code` excludes `telegram` while the template hard-codes `mcp__telegram__*`). The brand-agnostic template stays a single file; the brand-aware filter expresses what the specialist *may* do on this install while the template expresses what it *can* do across brands. Tool typos and renamed plugins still refuse to boot — only namespaces explicitly named in `plugins.excluded` are demoted to strip-and-warn.
@@ -3970,6 +3974,8 @@ The `brand-excluded` branch closes the recurring crash-restart loop on brands th
 
 **Boot-time skill-availability gate.** A manager boot gate ([`skill-registration-drift.ts`](../../../services/claude-session-manager/src/skill-registration-drift.ts)) closes the silent divergence between that Maxy intent and the Claude Code registration surfaces. It resolves each premium sub named in every account's `account.json enabledPlugins` to its expected `name@marketplace` (nested sub → `maxy-premium-<bundle>`, standalone → `maxy-premium`) by descending the on-disk premium tree, then checks all three surfaces. For each enabled-but-unregistered sub it emits one `[skill-registration] op=drift FATAL accountId=<id> plugin=<sub> expected=<name@marketplace> missing=<surfaces>` line (best-effort mirrored to journald via `systemd-cat -t maxy-csm`), naming exactly which surface lacks the entry. Unlike the specialist-tool-drift gate this one does **not** `process.exit` — a mis-registered sub-plugin must not brick the whole install, so boot continues and the operator keeps a working admin for repair (re-running the corrected installer for the brand). A clean pass emits `startup-self-test skill-registration=ok inspected=<N>`.
 
+**Boot-time tool-availability gate.** The twin of the skill gate for the MCP surface ([`tool-registration-drift.ts`](../../../services/claude-session-manager/src/tool-registration-drift.ts)). Where the skill gate reconciles a premium sub's *skills*, this one reconciles a tool-plugin's *server mount*. Its tool-plugin set is `toolSurface.mcpServers` — every plugin that declares tools and an `mcp:` block, which includes specialist-only tool-plugins like `loop` whose tools are all `adminAllowlist: false` (the admin allowlist never lists them, so an admin-allowlist-derived check would miss them), and shared-lib-server plugins like `graph` (now that the generator emits an `mcpServers` block for them). For each account's `enabledPlugins` that names such a tool-plugin, it inspects the **generated** `.claude-plugin/plugin.json` rather than the PLUGIN.md source: an absent manifest is `reason=not-installed`, a manifest with no `mcpServers` is `reason=no-mcpServers-manifest` (the `skip` signature), and an `mcpServers` manifest whose server dist is missing is `reason=dist-missing` — for a plugin-local `mcp/` that dist is `mcp/dist/index.js`; for a shared-lib plugin the gate resolves the manifest's shared server arg via `${PLATFORM_ROOT}` and checks that binary. Each defect emits one `[tool-registration] op=drift FATAL accountId=<id> plugin=<name> expected-server=<name> reason=<…>` line (best-effort mirrored to journald via `systemd-cat -t maxy-csm`); like the skill gate it does **not** `process.exit`, so a single unmounted tool-plugin does not brick the install. A clean pass emits `startup-self-test tool-registration=ok inspected=<N>`. This is the standing check the no-event failure needs: an unmounted server emits no `[mcp-helper] op=spawn` line, so only a gate that converts its absence into `op=drift` makes it loud.
+
 **Structured journald mirror for boot-failed.** Every `boot-failed reason=specialist-tool-drift …` line is mirrored to journald via `systemd-cat -t maxy-csm -p err` with the fields `specialist=`, `tool=`, `drift_reason=`, `agent_path=` so `journalctl --user -u <brand>-claude-session-manager.service -t maxy-csm` can filter by any of them without grep on `server.log`. The stdout line stays unchanged so the existing diagnostic one-liners keep working. `systemd-cat` absence (e.g. macOS dev box) is swallowed — the stdout line is the primary surface; the structured emit is auxiliary.
 
 **Per-spawn signals (server.log).** Every spawn emits `pty-spawn-mcp-config servers=<N> tools=<M> bytes=<B> path=<…>` once, plus one `pty-spawn-agents-dir role=<admin|public> path=<…>` per added directory. Specialist spawns additionally emit `pty-spawn-allowlist specialist=<name> count=<N> stripped=<S> sourced-from=agent-frontmatter` where `stripped` is the count of brand-excluded tool names removed before argv emission. The diagnostic one-liner is `grep -E 'pty-spawn-mcp-config|pty-spawn-agents-dir|pty-spawn-allowlist|mcp-config-allowlist-coverage|specialist-tool-strip|boot-failed reason=' ~/.<brand>/logs/server.log | tail -50`.
@@ -4775,3 +4781,11 @@ sudo systemctl --user start maxy-ui
 - `grep -c '\[admin-ui\] sidebar-meta-pane-reconcile' ~/.maxy/logs/admin-ui-console.log` should equal the count of End / Resume / Purge clicks while the metadata pane was open. A `to=gone` line without a paired Close click means the pane's auto-close logic regressed.
 
 **Why this matters.** The render-body log was misleading: it read as "the admin agent is checking onboarding state continuously", when in fact `onboardingComplete` had not changed at all. The fix moved the log into `useEffect(…, [])` then dropped the per-tick poll entirely, so a quiet console is now the steady state. With both fixes in place, console output is a faithful record of what the page actually did each operator click.
+
+## Typing in the `/chat` composer is slow to render
+
+**Symptom.** In the admin/operator `/chat` webchat, typing into the message box lags. Characters appear behind the keystrokes, worse on a long conversation. CPU, RAM, and network show no pressure.
+
+**Cause.** A controlled-input re-render storm. The composer text lives in the chat host, and `<Transcript>` is a sibling under that host, so each keystroke re-renders the host and reconciles the whole transcript tree. Cost scales with transcript length. The "no CPU/RAM spike" reading is consistent, not contradictory: React reconciliation is short main-thread bursts, invisible in Activity Monitor averages; the felt symptom is per-keystroke input latency. See the webchat composer/transcript render contract in `.docs/platform.md`.
+
+**Diagnostic.** Open the surface with `?diag=composer` appended to the URL and watch the browser console while typing on a long conversation. Each `[diag:composer]` line is a transcript reconcile attributed to a keystroke, with its `actualDuration` (reconcile cost) and `latency` (keystroke to commit). Correct behaviour logs zero lines per keystroke and the transcript still streams and follows the tail. One or more lines per keystroke, or a latency that grows with conversation length, means the decoupling regressed: a keystroke state re-hoisted above the `<Transcript>` sibling, or a `<Transcript>` prop identity that now churns on a keystroke-only render.

package/payload/platform/plugins/docs/references/admin-identity-gate.md

@@ -34,16 +34,24 @@ sessions skip it.
 On a channel (WhatsApp today), the inbound sender phone is bound to a person's
 `userId` via `users.json` (`UserEntry.phone`), confirmed against the account's
 `admins[]`. The channel admin session carries that `userId` — graph writes and
-the `${USER_ID}` MCP env attribute to the actual sender. An unbound
-sender (the owner's self-phone, or an `adminPhones` entry with no `users.json`
-phone) falls back to the boot-time owner `userId`.
+the `${USER_ID}` MCP env attribute to the actual sender. An unbound sender falls
+into two cases. The owner's self-phone (a self-chat command, or a DM the gate
+admits as `reason:'self-phone'`) resolves to the owner `userId` (`admins[]` row
+with `role:'owner'`), which the UI passes as the per-session `userId` override —
+so the owner's own-phone session keeps owner attribution even when the owner
+phone is not bound in `users.json`. Every other unbound sender (an `adminPhones`
+entry with no `users.json` phone) gets an empty `USER_ID`; the boot-time owner is
+not substituted.
 
 A WhatsApp admin whose inbound arrives as an unresolved LID (a cold mapping
 cache) resolves to their own `userId` via a runtime LID cache
 (`whatsapp-lid-map.json`), populated the first time their LID resolves to their
-phone. A LID that has never resolved has no cache entry and still
-falls back to the owner `userId` — visible as the `op=admin-identity …
-userId=owner-fallback` log line.
+phone. A LID that has never resolved has no cache entry and gets an empty
+`USER_ID` — a LID-form inbound normalizes to no phone, so it cannot match the
+owner's E.164 self-phone and never takes the owner-self path. The
+`op=admin-identity … userId=<value>` log line reports `unbound-empty` for a
+non-owner unbound sender and `owner-self-unresolved` for an owner self-phone on
+an account with no `role:'owner'` row.
 
 On loopback (claude.ai/code), multiple admins resolve to the right *profile*
 conversationally but share the owner's `userId` at the env/MCP layer.
@@ -69,12 +77,17 @@ it read as an owner self-change.
 The binding now holds:
 
 - `USER_ID` at `/rc-spawn` is `resolvedAdminUserId (authenticated admin) ??
-  overrideUserId ?? ''`. The owner fallback is removed. An authenticated admin
-  always wins; an unbound sender with no admin identity gets empty `USER_ID`, a
-  documented-legal value. This changes the earlier accepted boundary: an unbound
-  channel sender's rc-spawn no longer inherits the owner `userId` at the env
-  layer. The `claude rc` daemon env (not a per-session conversation) is
-  unchanged and still carries the boot owner `userId`.
+  overrideUserId ?? ''`. The owner env fallback is removed. An authenticated
+  admin always wins; an unbound sender with no admin identity gets empty
+  `USER_ID`, a documented-legal value. This changes the earlier accepted
+  boundary: an unbound channel sender's rc-spawn no longer inherits the owner
+  `userId` at the env layer. Owner attribution is restored for one case without
+  reopening the leak: the WhatsApp channel resolves the owner self-phone
+  to the owner `userId` client-side and sends it as `overrideUserId`, so it
+  arrives as an explicit per-session identity, not a blanket env default; a
+  non-owner unbound sender still gets empty `USER_ID`. The `claude rc` daemon env
+  (not a per-session conversation) is unchanged and still carries the boot owner
+  `userId`.
 - A credential tool with no explicit `userId` resolves to the verified caller
   (`USER_ID`, empty treated as no identity). With no verified identity it errors
   and writes nothing; it never substitutes an ambient env value for a missing
@@ -96,13 +109,15 @@ The binding now holds:
 The channel-admin binding is reassembled at read time from three independently
 operator-maintained sources: `adminPhones` (role allowlist), `admins[]`
 (membership), and `users.json` `UserEntry.phone` (the phone→userId binding). If
-they disagree, `resolveAdminUserId` returns null and the session silently runs
-under the owner `userId` — the fallback named in the boundary above, but here as
-a *misconfiguration*, not an intentional unbound sender.
+they disagree, `resolveAdminUserId` returns null and the session runs with an
+empty `USER_ID` — here as a *misconfiguration*, not an intentional unbound
+sender. These are `adminPhones` entries, never the owner self-phone (the owner
+self-phone is attributed by the gate's `reason:'self-phone'` verdict), so no
+drift entry silently inherits the owner `userId`.
 
 On every server start the platform replays the resolution chain for each
-account's `adminPhones` entry and logs one line per entry that would silently
-fall to the owner `userId`:
+account's `adminPhones` entry and logs one line per entry that would run with an
+empty `USER_ID`:
 
     [admin-identity] binding-drift accountId=<id> phone=<p> reason=no-users-binding
     [admin-identity] binding-drift accountId=<id> phone=<p> reason=userid-not-admin userId=<u>

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

@@ -56,7 +56,7 @@ either is a regression.
 |---|---|---|
 | `/session` | Admin cookie session: PIN-gated mint, validate, rotate. | `GET /`, `POST /` |
 | `/sessions` | Legacy admin-server conversation routes. No UI consumer remains after the ConversationsModal was retired; the surviving handlers are deletion candidates and not described here. | (legacy, no live caller) |
-| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> unknownChannel=<n> excludedPublicWebchat=<n>`. | `GET /` |
+| `/sidebar-sessions` | Sole data path for the sidebar Sessions list. One JSONL on disk equals one row. The row's delete button is the only way a row disappears. Each row carries `sessionId`, `title`, `startedAt`, `live`, `isSubagent`, `pid: number \| null` (basename of the matched `sessions/<pid>.json`), and `projectDir` (the directory holding the JSONL — consumed by the delete route). The payload also carries top-level `accountId` so the pane renders the full UUID label whose first ~8 chars prefix-match the truncated Remote Control daemon entry in claude.ai/code. The legacy `rcUrl` field is gone — the row's external-link affordance now POSTs `/session-rc-spawn` to start a fresh local `claude --remote-control <name> --session-id <sid>` PTY on every click. **WhatsApp and Telegram sessions (admin + public) appear in this list**, colour-coded by channel (WhatsApp green `#25D366`, Telegram blue `#229ED9`, via a `conv-channel-*` left accent bar) and carrying the standard row kebab (Usage & cost, Reset/re-seat, Rename, Archive, Delete) so the operator can inspect and re-seat a channel session's params. Each row's `channel` is the authoritative `.meta.json` sidecar value (`whatsapp`/`telegram`/`webchat`/`browser`/null), not the JSONL-envelope channel. Each row also carries its sidecar `senderId`. For a WhatsApp/Telegram row with a `senderId` and no operator rename or ai-title (`titleSource:'prefix'`), the route resolves a contact `personName` and the sidebar renders the reader panel's `"<name>  <number>"` label via the shared `operatorConvName`, degrading to the number alone then the stripped title on a miss, so a Sessions row and that conversation's reader-panel row read identically. The name comes from the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The only role/channel excluded from the list is `public`+`webchat` (its dedicated reader is the sole surface); the exclusion predicate is `isSessionListExcluded`, decoupled from the reader's inclusion predicate `isReaderChannelSession` (unchanged), so the WhatsApp/Telegram reader panels are unaffected — a store-only WhatsApp conversation with no session JSONL stays reader-only. Observability rides `[admin-sessions-list] … channelInList=whatsapp:<n>,telegram:<n>,webchat:<n> channelNameCandidates=<n> channelNamesResolved=<n> unknownChannel=<n> excludedPublicWebchat=<n>`, and each unresolved channel name logs one `[admin-sessions-list] op=channel-name-unresolved sessionId=<id8> channel=<whatsapp\|telegram> senderId=<id> reason=<no-senderId\|classify-miss\|neo4j-down>` line so a persistent `channelNamesResolved` shortfall is never silent. | `GET /` |
 | `/session-delete` | POST `{ sessionId }`. Thin proxy over the manager: POST `/:id/stop` (idempotent) then DELETE `/:id`. Sends **no** accountId. The manager resolves the session by scanning every slug under `projects/` for its JSONL (`slugForExistingJsonl`, covering `archive/`), exactly as the sidebar list enumerates rows, and gates on file existence alone — so any session the operator can see is deletable. This replaces the earlier accountId-derived slug and the `!row` term, which narrowed resolution below the list and left a session under a non-house slug with no watcher row (e.g. a legacy `-home-admin` session on a single-account install) listed yet un-deletable. Account scope is a view filter, not a delete gate — admin access is install-wide, so there is nothing to scope against. The sibling `/session-stop` (the standalone End control) resolves identically and also forwards no accountId. | `POST /` |
 | `/session-rc-spawn` | POST `{ sessionId?, name? }`. Fire-and-forget `claude --remote-control [name] [--session-id <sid>]`. Present `sessionId` resumes; absent starts a fresh session (also used by the sidebar's "New session" button — it no longer opens claude.ai/code directly). Proxies to the manager's `/rc-spawn`, which waits up to **60 s** (raised from 12 s) for the spawned PTY to bind and returns `{ spawnedPid, sessionId, bridgeSessionId, slug, outcome, reason }`. For a webchat-bound spawn (every admin-gated host's "New session", returning a same-origin `/chat?session=<id>` target — `resolveRcSpawnOutcome` → `sameOrigin:true`) the Sidebar navigates the **current** tab via `window.location.assign`, replacing the dashboard in place (back returns to it); only a claude.ai/code slug (`sameOrigin:false`, the bare-admin resume bridge, never a new-session outcome) navigates a separately-opened tab. On `timeout` or `spawn-failed` it shows an error modal (reason + sessionId) and **never** opens a bare claude.ai/code tab. The new process registers itself as its own Remote Control entry in claude.ai/code. | `POST /` |
 | `/claude-sessions` | **Spawn surface only**. `POST /` is the Sidebar new-session-with-prompt path, cookie-auth only (the recorder loopback caller was removed; LinkedIn ingest moved to `/rc-spawn`). The former UI-facing handlers (SSE row feed, list, resume, stop, rename, archive, delete, `/:id/meta`, `/:id/input`, `/:id/log`) were removed — the maxy dashboard no longer manages or displays sessions. | `POST /` |

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

@@ -489,6 +489,8 @@ For subagents, the same spawn pushes `--add-dir` for every bundled plugin agents
 
 A boot gate refuses to start the manager when any admin-allowlisted tool `mcp__<plugin>__*` lacks a registered server. The signal is `boot-failed reason=mcp-allowlist-without-server plugin=<p> tool=<t>` followed by `process.exit(1)`. The remediation is a one-line edit to the named `PLUGIN.md`: add the `mcp:` block. The complementary observability emit `mcp-config-allowlist-coverage admin-tools=A admin-registered=R` (where `A === R`) confirms the invariant per boot.
 
+**Whether a plugin's server mounts is decided by the generated manifest, not the `mcp:` block.** A plugin ships its MCP as `mcp/`; the manifest generator ([`scripts/generate-plugin-manifests.mjs`](../../../../scripts/generate-plugin-manifests.mjs), run at bundle time over the payload) reads the plugin's `mcp-manifest:` frontmatter. `auto` emits an `mcpServers` block into the generated `.claude-plugin/plugin.json` — routed through `lib/mcp-spawn-tee`, carrying no per-session env (`LOG_DIR`/`SESSION_ID`/`ACCOUNT_ID`/`NEO4J_*`/`PLATFORM_ROOT` ride the PTY env block described above) — and copies the tee into the plugin's `lib/`; `skip` emits nothing, so Claude Code never spawns the server. The generator recognises two server shapes. A plugin-local `mcp/` (its `hasMcp` check: `mcp/dist/index.js` or `mcp/package.json`) uses `auto` or `skip`. A tool-plugin whose `mcp:` server is a shared `platform/lib/<name>` binary rather than a plugin-local `mcp/` (e.g. `graph`, served by `platform/lib/graph-mcp`) is annotated `mcp-manifest: shared-lib`: the generator emits that plugin's `mcp:` block verbatim into `mcpServers` — command, args (anchored on `${PLATFORM_ROOT}`, routed through the shared `lib/mcp-spawn-tee`), and env — which Claude Code expands at spawn from the PTY env block. No tee copy is made into the plugin, because both the tee and the server resolve from `${PLATFORM_ROOT}` outside the per-plugin cache. `graph` is the one shared-lib tool-plugin; every other tool-plugin ships a plugin-local `mcp/` and uses `auto`. A plugin with an `mcp:` block, no plugin-local `mcp/`, and no `mcp-manifest: shared-lib` annotation is a FATAL at generation time. Premium plugins import platform libs (`mcp-lifeline`, etc.) via a source-tree relative path; the bundler's premium-lib shipper (`packages/create-maxy-code/scripts/bundle.js`) rewrites that path and vendors each referenced `platform/lib/<name>` into `premium-plugins/<bundle>/lib/<name>/`, so the auto-mounted dist resolves its imports. The `mcp-allowlist-without-server` gate above proves only that a plugin's PLUGIN.md `mcp:` block matches its allowlist — it reads source, not the generated manifest — so a plugin left on `skip` passes that gate while its server silently never mounts (its tools are listed but not live). The `tool-registration` gate below closes that blind spot.
+
 A second boot gate walks every specialist `.md` under `platform/templates/specialists/agents/`, every bundled `<plugin>/agents/` directory, and the per-account `<accountDir>/specialists/agents/` directory, parses each file's `tools:` frontmatter line (canonical long-prefix names), and classifies every tool name as one of: CC-native (Read, Bash, …), a tool the loaded `PLUGIN.md` set actually serves (matched as the long canonical name in `toolSurface.all`), a third-party MCP bridge (a `mcp__plugin_*` name whose plugin segment is NOT a maxy platform plugin — Playwright etc., upstream-owned, passes unconditionally), `unknown-tool-in-plugin` (maxy plugin namespace served but tool name absent), `unknown-plugin-namespace` (namespace served by nothing), `brand-excluded-plugin` (namespace served by nothing on this brand, **but** the brand's `brand.json#plugins.excluded` list names it), or `malformed-name` (not CC-native and not `mcp__`-shaped). The first three pass. The next two refuse boot with one `boot-failed reason=specialist-tool-drift specialist=<name> tool=<t> drift=<class> path=<…>` line per defect, then `process.exit(1)`. A maxy-plugin `mcp__plugin_*` name is validated against `toolSurface.all`, so a typo or stale long-prefix tool name still refuses boot rather than passing as a bridge; the build-time `check-canonical-tool-names.mjs` gate catches the same drift in instruction files before publish. `brand-excluded-plugin` is a structural pass: it lands in a per-specialist strip-list, the manager continues to boot, and at spawn time `pty-spawner` removes those tool names from the `--agent <name>` spawn's `--allowed-tools` argv. The complementary observability emit `specialist-tool-strip specialist=<name> plugin=<p> tools=<csv> reason=brand-excluded` fires one line per stripped (specialist, plugin) pair so an operator who reads `server.log` sees the brand filter doing work without cross-referencing `brand.json` against the template. The startup-self-test line `startup-self-test specialist-tool-drift=ok inspected=<N> stripped-specialists=<M>` confirms the gate ran and how many specialists carry strip-lists.
 
 The `brand-excluded` branch closes the recurring crash-restart loop on brands that ship without a plugin the shared `personal-assistant.md` template references (e.g. `realagent-code` excludes `telegram` while the template hard-codes `mcp__telegram__*`). The brand-agnostic template stays a single file; the brand-aware filter expresses what the specialist *may* do on this install while the template expresses what it *can* do across brands. Tool typos and renamed plugins still refuse to boot — only namespaces explicitly named in `plugins.excluded` are demoted to strip-and-warn.
@@ -499,6 +501,8 @@ The `brand-excluded` branch closes the recurring crash-restart loop on brands th
 
 **Boot-time skill-availability gate.** A manager boot gate ([`skill-registration-drift.ts`](../../../services/claude-session-manager/src/skill-registration-drift.ts)) closes the silent divergence between that Maxy intent and the Claude Code registration surfaces. It resolves each premium sub named in every account's `account.json enabledPlugins` to its expected `name@marketplace` (nested sub → `maxy-premium-<bundle>`, standalone → `maxy-premium`) by descending the on-disk premium tree, then checks all three surfaces. For each enabled-but-unregistered sub it emits one `[skill-registration] op=drift FATAL accountId=<id> plugin=<sub> expected=<name@marketplace> missing=<surfaces>` line (best-effort mirrored to journald via `systemd-cat -t maxy-csm`), naming exactly which surface lacks the entry. Unlike the specialist-tool-drift gate this one does **not** `process.exit` — a mis-registered sub-plugin must not brick the whole install, so boot continues and the operator keeps a working admin for repair (re-running the corrected installer for the brand). A clean pass emits `startup-self-test skill-registration=ok inspected=<N>`.
 
+**Boot-time tool-availability gate.** The twin of the skill gate for the MCP surface ([`tool-registration-drift.ts`](../../../services/claude-session-manager/src/tool-registration-drift.ts)). Where the skill gate reconciles a premium sub's *skills*, this one reconciles a tool-plugin's *server mount*. Its tool-plugin set is `toolSurface.mcpServers` — every plugin that declares tools and an `mcp:` block, which includes specialist-only tool-plugins like `loop` whose tools are all `adminAllowlist: false` (the admin allowlist never lists them, so an admin-allowlist-derived check would miss them), and shared-lib-server plugins like `graph` (now that the generator emits an `mcpServers` block for them). For each account's `enabledPlugins` that names such a tool-plugin, it inspects the **generated** `.claude-plugin/plugin.json` rather than the PLUGIN.md source: an absent manifest is `reason=not-installed`, a manifest with no `mcpServers` is `reason=no-mcpServers-manifest` (the `skip` signature), and an `mcpServers` manifest whose server dist is missing is `reason=dist-missing` — for a plugin-local `mcp/` that dist is `mcp/dist/index.js`; for a shared-lib plugin the gate resolves the manifest's shared server arg via `${PLATFORM_ROOT}` and checks that binary. Each defect emits one `[tool-registration] op=drift FATAL accountId=<id> plugin=<name> expected-server=<name> reason=<…>` line (best-effort mirrored to journald via `systemd-cat -t maxy-csm`); like the skill gate it does **not** `process.exit`, so a single unmounted tool-plugin does not brick the install. A clean pass emits `startup-self-test tool-registration=ok inspected=<N>`. This is the standing check the no-event failure needs: an unmounted server emits no `[mcp-helper] op=spawn` line, so only a gate that converts its absence into `op=drift` makes it loud.
+
 **Structured journald mirror for boot-failed.** Every `boot-failed reason=specialist-tool-drift …` line is mirrored to journald via `systemd-cat -t maxy-csm -p err` with the fields `specialist=`, `tool=`, `drift_reason=`, `agent_path=` so `journalctl --user -u <brand>-claude-session-manager.service -t maxy-csm` can filter by any of them without grep on `server.log`. The stdout line stays unchanged so the existing diagnostic one-liners keep working. `systemd-cat` absence (e.g. macOS dev box) is swallowed — the stdout line is the primary surface; the structured emit is auxiliary.
 
 **Per-spawn signals (server.log).** Every spawn emits `pty-spawn-mcp-config servers=<N> tools=<M> bytes=<B> path=<…>` once, plus one `pty-spawn-agents-dir role=<admin|public> path=<…>` per added directory. Specialist spawns additionally emit `pty-spawn-allowlist specialist=<name> count=<N> stripped=<S> sourced-from=agent-frontmatter` where `stripped` is the count of brand-excluded tool names removed before argv emission. The diagnostic one-liner is `grep -E 'pty-spawn-mcp-config|pty-spawn-agents-dir|pty-spawn-allowlist|mcp-config-allowlist-coverage|specialist-tool-strip|boot-failed reason=' ~/.<brand>/logs/server.log | tail -50`.

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

@@ -15,7 +15,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 |------|---------|
 | `outlook-account-register` | Start the device-code flow for this account. Returns a user code + `microsoft.com/devicelogin` URL immediately; does not block. |
 | `outlook-account-register-poll` | Finish the device-code flow. One check per call: returns pending, registered, expired, or denied. |
-| `outlook-mail-list` | Recent mail. Default top=25, folder=Inbox. |
+| `outlook-mail-list` | Recent mail. Default top=25, folder=Inbox. `folder` takes a well-known name or alias (case/space-insensitive): Inbox, Sent Items/sent, Drafts, Deleted Items/trash, Junk Email/junk/spam, Archive, Outbox — or a raw folder id. Custom folder names are not resolved. |
 | `outlook-mail-search` | Microsoft Graph `$search` over the mailbox. |
 | `outlook-calendar-list` | Calendar events in next rangeDays days (default 7, max 365). |
 | `outlook-calendar-event` | Full detail of a single event by id. |
@@ -46,7 +46,7 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Auth ok | `auth-ok account=<id> graphUserId=<id> scopes=<csv> tokenExpSec=<N>` |
 | Token refreshed | `token-refreshed account=<id> oldExpSec=<N> newExpSec=<N>` |
 | Refresh failed | `token-refresh-failed account=<id> reason=<err>` (terminal) |
-| Mail list | `mail-list account=<id> folder=<id-or-Inbox> count=<N> elapsedMs=<N>` |
+| Mail list | `mail-list op=resolve account=<id> folderIn=<name> folderResolved=<token> asRawId=<bool> count=<N> elapsedMs=<N>` (on error, `error=<msg>` replaces `count`) |
 | Mail search | `mail-search account=<id> query=<trunc-32> count=<N> elapsedMs=<N>` |
 | Calendar list | `calendar-list account=<id> rangeDays=<N> count=<N> elapsedMs=<N>` |
 | Calendar event | `calendar-event account=<id> eventId=<trunc-12> elapsedMs=<N>` |

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

@@ -100,6 +100,8 @@ Some premium plugins are **bundles** — multiple sub-plugins shipped under one
 
 A bundle's sub-plugins carry the skills, so each must be registered as its own Claude Code plugin for its skills to load — the installer does this at install time for every bundle the brand ships. When a sub-plugin's skills are missing (a specialist dispatches but its skill answers *Unknown skill*), the manager names the gap at boot: grep `server.log` for `[skill-registration] op=drift` — each line gives the account, the sub-plugin, and which registration surface is missing. The fix is to re-run the installer for this brand; a clean boot instead logs `startup-self-test skill-registration=ok`.
 
+The same split applies to a premium plugin's **tools**: its MCP server mounts only when the generated plugin manifest carries an `mcpServers` block (set by `mcp-manifest: auto` in the plugin's `PLUGIN.md`). When a tool-plugin is enabled but its server never mounts — its tools are listed but every call finds an empty toolbox — the manager names it at boot: grep `server.log` for `[tool-registration] op=drift`, which gives the account, the plugin, and the reason (`no-mcpServers-manifest`, `dist-missing`, or `not-installed`). A clean boot instead logs `startup-self-test tool-registration=ok`.
+
 If you ask {{productName}} about a tool from a plugin your brand does not ship (for example, a Maxy install asking about a Real Agent Loop CRM tool), {{productName}} responds with a structured `<tool-surface-error>` envelope naming the missing plugin and the remedy, rather than improvising with a generic alternative.
 
 **Public agent embedding:** Premium plugins marked as public-eligible have their full content (skills and reference knowledge) embedded in public agent prompts. This means a public agent for a Real Agent member can handle buyer enquiries, book viewings, deliver coaching content, and onboard new applicants — all powered by the premium plugin's domain knowledge. Plugins marked admin-only (listings, vendors, leads, business) are only available to the account owner's admin agent.

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

@@ -306,3 +306,11 @@ sudo systemctl --user start maxy-ui
 - `grep -c '\[admin-ui\] sidebar-meta-pane-reconcile' ~/.maxy/logs/admin-ui-console.log` should equal the count of End / Resume / Purge clicks while the metadata pane was open. A `to=gone` line without a paired Close click means the pane's auto-close logic regressed.
 
 **Why this matters.** The render-body log was misleading: it read as "the admin agent is checking onboarding state continuously", when in fact `onboardingComplete` had not changed at all. The fix moved the log into `useEffect(…, [])` then dropped the per-tick poll entirely, so a quiet console is now the steady state. With both fixes in place, console output is a faithful record of what the page actually did each operator click.
+
+## Typing in the `/chat` composer is slow to render
+
+**Symptom.** In the admin/operator `/chat` webchat, typing into the message box lags. Characters appear behind the keystrokes, worse on a long conversation. CPU, RAM, and network show no pressure.
+
+**Cause.** A controlled-input re-render storm. The composer text lives in the chat host, and `<Transcript>` is a sibling under that host, so each keystroke re-renders the host and reconciles the whole transcript tree. Cost scales with transcript length. The "no CPU/RAM spike" reading is consistent, not contradictory: React reconciliation is short main-thread bursts, invisible in Activity Monitor averages; the felt symptom is per-keystroke input latency. See the webchat composer/transcript render contract in `.docs/platform.md`.
+
+**Diagnostic.** Open the surface with `?diag=composer` appended to the URL and watch the browser console while typing on a long conversation. Each `[diag:composer]` line is a transcript reconcile attributed to a keystroke, with its `actualDuration` (reconcile cost) and `latency` (keystroke to commit). Correct behaviour logs zero lines per keystroke and the transcript still streams and follows the tail. One or more lines per keystroke, or a latency that grows with conversation length, means the decoupling regressed: a keystroke state re-hoisted above the `<Transcript>` sibling, or a `<Transcript>` prop identity that now churns on a keystroke-only render.

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

@@ -4,5 +4,24 @@
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "graph": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${PLATFORM_ROOT}/lib/mcp-spawn-tee/dist/index.js",
+        "${PLATFORM_ROOT}/lib/graph-mcp/dist/index.js"
+      ],
+      "env": {
+        "MCP_SPAWN_TEE_NAME": "graph",
+        "LOG_DIR": "${LOG_DIR}",
+        "PLATFORM_ROOT": "${PLATFORM_ROOT}",
+        "ACCOUNT_ID": "${ACCOUNT_ID}",
+        "SESSION_ID": "${SESSION_ID}",
+        "NEO4J_URI": "${NEO4J_URI}",
+        "NEO4J_PASSWORD": "${NEO4J_PASSWORD}"
+      }
+    }
   }
 }

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

@@ -10,6 +10,7 @@ tools:
   - name: maxy-graph-write_neo4j_cypher
     publicAllowlist: false
     adminAllowlist: false
+mcp-manifest: shared-lib
 mcp:
   command: node
   args:
@@ -28,10 +29,15 @@ description: "Raw Neo4j Cypher proxy. Wraps the upstream `mcp-neo4j-cypher` serv
 
 # graph
 
-Cypher proxy plugin. The server is `platform/lib/graph-mcp`, which adopts the upstream
-Python `mcp-neo4j-cypher` server per brand and proxies its JSON-RPC stdio under the
-`maxy-graph` namespace. It is registered through the installed-plugin channel like every
-other platform MCP, so its tools surface as `mcp__plugin_graph_graph__maxy-graph-*`.
+Cypher proxy plugin. The server is the shared binary `platform/lib/graph-mcp`,
+which adopts the upstream Python `mcp-neo4j-cypher` server per brand and proxies
+its JSON-RPC stdio under the `maxy-graph` namespace. Unlike plugins that ship a
+plugin-local `mcp/` dir, graph's server is a shared `platform/lib/<name>` binary,
+so it mounts via the generator's `shared-lib` disposition: `mcp-manifest: shared-lib`
+tells `scripts/generate-plugin-manifests.mjs` to emit graph's `mcp:` block into the
+generated `.claude-plugin/plugin.json` `mcpServers`, routed through the shared
+`mcp-spawn-tee`. Its tools then surface to admin and specialist spawns as
+`mcp__plugin_graph_graph__maxy-graph-*`.
 
 Write Cypher is intercepted (not forwarded) so the shim can validate tokens against the
 live schema cache, stamp `createdBy` provenance, and roll back orphan-producing writes.

package/payload/platform/plugins/graph-viewer/.claude-plugin/plugin.json

@@ -4,5 +4,18 @@
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"
+  },
+  "mcpServers": {
+    "graph-viewer": {
+      "type": "stdio",
+      "command": "node",
+      "args": [
+        "${CLAUDE_PLUGIN_ROOT}/lib/mcp-spawn-tee/index.js",
+        "${CLAUDE_PLUGIN_ROOT}/mcp/dist/index.js"
+      ],
+      "env": {
+        "MCP_SPAWN_TEE_NAME": "graph-viewer"
+      }
+    }
   }
 }

package/payload/platform/plugins/graph-viewer/PLUGIN.md

@@ -11,7 +11,7 @@ mcp:
     PLATFORM_ROOT: ${PLATFORM_ROOT}
     ACCOUNT_ID: ${ACCOUNT_ID}
     SESSION_ID: ${SESSION_ID}
-mcp-manifest: skip
+mcp-manifest: auto
 description: "Inline Neo4j subgraph renderer. Provides graph-render — a Node-side PNG renderer that walks N hops from a starting node, applies the same palette and display strings the live /graph page uses, and returns the image as an MCP image content block. Removes the device-switch otherwise required for the agent to show the operator what a subgraph looks like. Account-scoped: the tool refuses to render nodes outside the caller's accountId. Layout is d3-force with a deterministic seed; drawing is @napi-rs/canvas with a system-font fallback for labels. The fidelity contract is palette and display-string parity — node positions will differ from the live page's vis-network layout. Ships one skill: render-graph."
 tools:
   - name: graph-render

package/payload/platform/plugins/graph-viewer/lib/mcp-spawn-tee/index.js

@@ -0,0 +1,193 @@
+#!/usr/bin/env node
+"use strict";
+/**
+ * MCP spawn-tee — in-process stderr capture + lifecycle observability.
+ *
+ * Claude Code spawns each MCP server itself; the platform never holds a
+ * ChildProcess handle. This shim sits between Claude Code and the real MCP
+ * server: Claude Code runs `node <this> <real-entry>`, and the shim runs the
+ * real entry IN ITS OWN PROCESS via dynamic import() — one node runtime, not
+ * two. Before importing, it replaces process.stderr.write with a tee so every
+ * stderr byte the server writes is mirrored to the log sinks; stdin and stdout
+ * (the JSON-RPC channel) are never touched.
+ *
+ *   Claude Code CLI → shim (this file) = node running <real-entry> in-process
+ *        stdin/stdout : untouched (JSON-RPC channel)
+ *        stderr       : process.stderr.write teed → per-date + per-session + passthrough
+ *
+ * Destinations (Task 706) — unchanged:
+ *   - `${LOG_DIR}/mcp-<name>-stderr-<date>.log`  — per-date raw (back-compat;
+ *     the in-process mcp-stderr-tee and the [mcp-init-error] probe read it).
+ *   - `${LOG_DIR}/mcp-<name>-<SESSION_ID>.log`   — per-session raw + lifecycle
+ *     lines. Authoritative sink. Absent when SESSION_ID is unset (enumeration
+ *     spawn) — then the per-date file is the fallback.
+ *   - `server.log` via the loopback log-ingest route — best-effort mirror of
+ *     the [mcp-helper] lifecycle lines.
+ *
+ * Lifecycle lines, correlation key `session=<id8> server=<name>` — unchanged:
+ *   [mcp-helper] op=spawn ... pid= entry=
+ *   [mcp-helper] op=boot  ... head=<first stderr bytes>
+ *   [mcp-helper] op=exit  ... code= signal= lifetimeMs= stderr-tail=
+ *
+ * Process model (Task 989): the shim IS the server's process. op=exit fires
+ * from process.on("exit"), so it covers a normal exit, a non-zero exit, an
+ * uncaught throw (code 1), and a catchable-signal exit (SIGTERM/SIGINT/SIGHUP,
+ * whose handlers record the signal name). An external SIGKILL is uncatchable
+ * and leaves no op=exit line — the per-session stderr tail already on disk and
+ * Claude Code's own transport-drop are the evidence for that death mode.
+ *
+ * The shim never writes to fd 1 (stdout) — that is the JSON-RPC channel.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+const node_fs_1 = require("node:fs");
+const node_path_1 = require("node:path");
+const node_url_1 = require("node:url");
+const SERVER_NAME = process.env.MCP_SPAWN_TEE_NAME ?? "unknown";
+const LOG_DIR = process.env.LOG_DIR;
+const SESSION_ID = process.env.SESSION_ID;
+const PLATFORM_PORT = process.env.PLATFORM_PORT;
+const ENTRY = process.argv[2];
+const SESSION_ID8 = SESSION_ID ? SESSION_ID.slice(0, 8) : "—";
+const spawnStamp = Date.now();
+// Per-session raw + lifecycle log (Task 706). Empty SESSION_ID (enumeration
+// spawn) → undefined, and the per-date file is the fallback.
+const perSessionPath = LOG_DIR && SESSION_ID
+    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-${SESSION_ID}.log`)
+    : undefined;
+const perDatePath = LOG_DIR
+    ? (0, node_path_1.resolve)(LOG_DIR, `mcp-${SERVER_NAME}-stderr-${new Date(spawnStamp).toISOString().slice(0, 10)}.log`)
+    : undefined;
+// Rolling tail of entry stderr for op=exit. Capped so a chatty server cannot
+// grow the buffer without bound.
+const TAIL_CAP = 2048;
+let stderrTail = "";
+let bootEmitted = false;
+let exitEmitted = false;
+let exitSignal;
+// The real stderr writer, captured before the tee replaces it. Lifecycle lines
+// and stderr passthrough both go through this so they are never re-teed into
+// the per-date sink nor recursed back into the patched writer.
+const rawStderrWrite = process.stderr.write.bind(process.stderr);
+// LOG_DIR is created once, lazily, on the first successful append — not per
+// chunk. teeWrite runs on the server's own stderr hot path now, so a per-call
+// mkdirSync would be two syscalls per log line for nothing.
+let logDirReady = false;
+function appendSafe(path, data) {
+    if (!path || !LOG_DIR)
+        return;
+    try {
+        if (!logDirReady) {
+            (0, node_fs_1.mkdirSync)(LOG_DIR, { recursive: true });
+            logDirReady = true;
+        }
+        (0, node_fs_1.appendFileSync)(path, data);
+    }
+    catch {
+        /* unwritable destination — never mask primary output */
+    }
+}
+// Best-effort mirror of a lifecycle line to server.log via the loopback
+// log-ingest route. Fire-and-forget: the per-session file is authoritative, so
+// a dropped POST loses nothing. On the "exit" event the loop is stopping, so
+// the op=exit mirror may not flush — the per-session line, written sync, holds.
+function postToServerLog(suffix, level) {
+    if (!PLATFORM_PORT)
+        return;
+    try {
+        const ctrl = new AbortController();
+        const t = setTimeout(() => ctrl.abort(), 500);
+        t.unref?.(); // never let the abort timer keep the shim's event loop alive
+        void fetch(`http://127.0.0.1:${PLATFORM_PORT}/api/admin/log-ingest`, {
+            method: "POST",
+            headers: { "content-type": "application/json" },
+            body: JSON.stringify({ tag: "mcp-helper", level, line: suffix }),
+            signal: ctrl.signal,
+        }).then(() => clearTimeout(t)).catch(() => clearTimeout(t));
+    }
+    catch {
+        /* fetch threw synchronously — best-effort only */
+    }
+}
+// Emit one [mcp-helper] lifecycle line: authoritative per-session file (sync,
+// survives process.exit), the shim's own stderr via the RAW writer (journald /
+// Claude Code visibility, never re-teed), and a best-effort server.log mirror.
+// `suffix` is the line body after the tag and carries no newline (the
+// log-ingest route rejects newlines).
+function emitLifecycle(suffix, level) {
+    const line = `[mcp-helper] ${suffix}\n`;
+    appendSafe(perSessionPath, line);
+    try {
+        rawStderrWrite(line);
+    }
+    catch { /* stderr closed */ }
+    postToServerLog(suffix, level);
+}
+if (!ENTRY) {
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason="no entry given (argv[2] missing)"`, "error");
+    process.exit(2);
+}
+// Replace process.stderr.write with a tee: mirror every server stderr byte to
+// the per-date and per-session sinks, keep a rolling tail for op=exit, emit
+// op=boot on the first bytes, then pass the write through to the real stderr.
+const teeWrite = ((...args) => {
+    const chunk = args[0];
+    appendSafe(perDatePath, chunk); // per-date raw (back-compat)
+    appendSafe(perSessionPath, chunk); // per-session raw (Task 706)
+    const text = typeof chunk === "string" ? chunk : Buffer.from(chunk).toString("utf8");
+    stderrTail = (stderrTail + text).slice(-TAIL_CAP);
+    if (!bootEmitted) {
+        bootEmitted = true;
+        const head = text.split("\n")[0].slice(0, 200);
+        emitLifecycle(`op=boot session=${SESSION_ID8} server=${SERVER_NAME} head=${JSON.stringify(head)}`, "info");
+    }
+    return rawStderrWrite(...args); // passthrough
+});
+process.stderr.write = teeWrite;
+// Catchable-signal handling. The shim drives the exit ONLY when it is the sole
+// listener for the signal — i.e. the imported entry installed no handler of its
+// own. In that case it records the signal (so op=exit carries signal=<sig>) and
+// exits with 128+signum, mirroring the prior wrapper's exit-status convention.
+//
+// When the entry DID install a handler, the shim defers entirely and records
+// nothing: the entry's handler decides the exit code, and op=exit reflects that
+// exit verbatim. This matches the prior two-process model, where a child that
+// caught the signal and exited cleanly was observed as code=0 signal=— (a clean
+// self-exit), not as a signal death. Setting exitSignal here unconditionally
+// would mislabel every graceful signal-driven shutdown as a signal kill.
+function onSignal(sig, code) {
+    return () => {
+        if (process.listenerCount(sig) === 1) {
+            exitSignal = sig;
+            process.exit(code);
+        }
+    };
+}
+process.on("SIGTERM", onSignal("SIGTERM", 143));
+process.on("SIGINT", onSignal("SIGINT", 130));
+process.on("SIGHUP", onSignal("SIGHUP", 129));
+// op=exit, emitted once from the process "exit" event. Sync-only — the loop is
+// stopping. When a catchable signal caused the exit, report code=— signal=<sig>
+// to match the prior wrapper's format; otherwise code=<exit code> signal=—.
+process.on("exit", (code) => {
+    if (exitEmitted)
+        return;
+    exitEmitted = true;
+    const lifetimeMs = Date.now() - spawnStamp;
+    const tail = stderrTail.slice(-200);
+    const codeField = exitSignal ? "—" : String(code);
+    const level = exitSignal || code !== 0 ? "error" : "info";
+    emitLifecycle(`op=exit session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} ` +
+        `code=${codeField} signal=${exitSignal ?? "—"} lifetimeMs=${lifetimeMs} stderr-tail=${JSON.stringify(tail)}`, level);
+});
+emitLifecycle(`op=spawn session=${SESSION_ID8} server=${SERVER_NAME} pid=${process.pid} entry=${ENTRY}`, "info");
+// Run the real MCP server in THIS process. Dynamic import() (not top-level
+// await — this file compiles to CommonJS) loads the ESM entry; a load-time
+// failure mirrors the old child spawn-error path (op=error, exit 127). The
+// op=exit handler is suppressed on this path so op=error stays the sole record.
+import((0, node_url_1.pathToFileURL)(ENTRY).href).catch((err) => {
+    const msg = err instanceof Error ? err.message : String(err);
+    exitEmitted = true;
+    emitLifecycle(`op=error session=${SESSION_ID8} server=${SERVER_NAME} reason=${JSON.stringify(`import error: ${msg}`)}`, "error");
+    process.exit(127);
+});
+//# sourceMappingURL=index.js.map

package/payload/platform/plugins/graph-viewer/lib/mcp-spawn-tee/package.json

@@ -0,0 +1,3 @@
+{
+  "type": "commonjs"
+}

package/payload/platform/plugins/outlook/mcp/dist/__tests__/mail-list.test.d.ts

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

package/payload/platform/plugins/outlook/mcp/dist/__tests__/mail-list.test.d.ts.map

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