@rubytech/create-maxy-code 0.1.439 → 0.1.441

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.439",
+  "version": "0.1.441",
   "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:e690411f7e4ae35c40dfed7076ea09bfeff4f175206c436385b5c0c1ac7a749e
+content-hash: sha256:9f7fc73400d2f9cf942e2df6f544bc69b95abe820ac1ff9b529807c3c7fd6407
 brand: maxy-code
 product-name: Maxy
 ---
@@ -2031,6 +2031,7 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 2. **Per account: register the Outlook account** — in admin chat, ask the agent to "register my Outlook account". The agent runs `outlook-account-register`, which returns a short user code and the URL `microsoft.com/devicelogin` and relays both to you.
 3. **Consent on any device** — open `microsoft.com/devicelogin` on your phone or laptop, enter the code, sign in to your Microsoft account, and consent to the requested scopes (`offline_access`, `User.Read`, `Mail.ReadWrite`, `Mail.Send`, `Calendars.ReadWrite`, `Contacts.Read`). `Mail.Send` enables sending and `Calendars.ReadWrite` enables calendar control; a mailbox last consented on an older read-only scope set must re-register before send or any calendar write succeeds. The agent finishes by calling `outlook-account-register-poll`.
 4. **Done.** Subsequent tool calls (mail, calendar, contacts) use the persisted refresh token transparently.
+5. **Several mailboxes on one account.** Register again to add a second mailbox; it is stored alongside the first, not in place of it. Every operational tool then takes an optional `mailbox` argument — an email address or graphUserId. With one mailbox, omit it. With two or more, name it; omitting it returns a refusal listing the connected mailboxes. `outlook-mailbox-list` shows every connected mailbox. Only one registration runs at a time per account; starting another while one is live returns an in-progress signal.
 
 ## Tools
 
@@ -2038,7 +2039,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. |
@@ -2048,7 +2049,8 @@ The `outlook` plugin gives the admin agent access to Microsoft 365 / Outlook.com
 | `outlook-calendar-respond` | Accept, decline, or tentatively accept an invite. |
 | `outlook-calendar-freebusy` | Availability for one or more addresses over a window. |
 | `outlook-contacts-list` | Top contacts. Default top=50. |
-| `outlook-mailbox-info` | Health probe — auth state, refresh-window, folder count. |
+| `outlook-mailbox-info` | Health probe for one mailbox — auth state, refresh-window, folder count. Name the mailbox with `mailbox` when several are attached. |
+| `outlook-mailbox-list` | Every connected mailbox with its email, scopes, and token health. Local only — no network — so it also flags a mailbox whose stored credentials cannot be read. |
 | `outlook-mail-send` | Send a message (`POST /me/sendMail`). to/cc/bcc arrays, subject, body, isHtml. Success asserted on Graph 202. Needs `Mail.Send`. |
 | `outlook-draft` | Create a draft in Drafts (`POST /me/messages`). Same body model. Returns the draft id. Needs `Mail.ReadWrite`. |
 | `outlook-draft-send` | Send an existing draft by id (`POST /me/messages/{id}/send`). Graph consumes the draft, returns 202. Needs `Mail.Send`. |
@@ -2066,10 +2068,12 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Pending-store census | `pending-store-census account=<id> live=<N>` |
 | Pending cleared | `pending-cleared account=<id> verified=<bool>` |
 | /me failed post-token | `me-failed account=<id> status=<N>` |
-| Auth ok | `auth-ok account=<id> graphUserId=<id> scopes=<csv> tokenExpSec=<N>` |
+| Auth ok | `auth-ok account=<id> graphUserId=<id> mail=<addr> scopes=<csv> tokenExpSec=<N>` |
+| Registration already in flight | `register-in-progress account=<id>` (start refused; one device-code flow at a time) |
+| Credential resolve | `cred-resolve account=<id> mailbox=<id-or-empty> source=arg|sole|none|refused` — names the resolved mailbox and how it was chosen; `source=refused` is the ambiguity/not-found refusal |
 | 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>` |
@@ -2081,6 +2085,7 @@ All log lines start with `[outlook-mcp]` and write to `server.log`. They are key
 | Scope insufficient | `scope-insufficient tool=<t> account=<id> missing=Calendars.ReadWrite` (stale read-only consent) |
 | Contacts list | `contacts-list account=<id> count=<N> elapsedMs=<N>` |
 | Mailbox info | `mailbox-info account=<id> tokenWithinRefreshWindow=<bool> folderCount=<N>` |
+| Mailbox list | `mailbox-list account=<id> count=<N> unreadable=<N>` (unreadable>0 flags an orphaned or corrupt mailbox store) |
 | Graph error | `graph-error account=<id> status=<N> code=<graphErrorCode> retryAfterMs=<N-or-null>` — writes flow through the same `callGraph` loop, so a failed write logs `graph-error` too |
 | On-prem rejected | `on-prem-rejected account=<id> mailServer=<host>` (terminal) |
 | Scope insufficient | `scope-insufficient account=<id> tool=<t> missing=Mail.Send` (terminal — re-register to grant send) |
@@ -2292,7 +2297,7 @@ A `pendingUnreconciled` number that stays above zero across several runs means t
 
 ## What this does not do
 
-One meeting type only (one length, one weekly window, one buffer). No syncing to Google or iCloud calendars: your meetings in Maxy are the source of truth. No rescheduling or cancellation links, reminders, or visitor time-zone selection. The booking page shows availability live from your device, so while your device is offline the page can still take a booking but may not show fresh open times until it is back.
+One meeting type only (one length, one weekly window, one buffer). No syncing to Google or iCloud calendars: your meetings in Maxy are the source of truth. No rescheduling or cancellation links, reminders, or visitor time-zone selection. The booking page shows open times from a snapshot your device publishes to the edge on a short timer, so the page keeps showing availability and taking bookings even while your device is offline — a slot that gets booked drops off at once, and times that have passed are never shown. If your device stays offline a long time the open times can go stale, but they never vanish; they refresh the moment it is back online.
 
 ---
 # LinkedIn Extension
@@ -2739,7 +2744,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 /` |
@@ -3182,8 +3187,10 @@ Source: https://docs.getmaxy.com/graph.md
 # Graph View
 
 The **Graph** admin page (`/graph`) renders a force-directed view of your
-account's Neo4j subgraph. Labels on the canvas follow the zoom level, so you
-see the most useful identity at every scale.
+account's Neo4j subgraph. Node captions are hidden on first load so the
+whole-graph overview stays uncluttered, and appear the moment you interact.
+Once shown, captions follow the zoom level so you see the most useful identity
+at every scale.
 
 ## Default view
 
@@ -3239,11 +3246,25 @@ This is an in-page overlay, so the browser tab and address bar stay put. It is
 not the operating system's full-screen mode. The maximize button shows only on
 the `/graph` page, not where the graph is embedded in another pane.
 
+## Captions hidden on first load
+
+When you open `/graph` (or refresh the page) the whole graph auto-fits into the
+viewport, which on a busy graph would render every caption at once and overlap
+them into unreadable clutter. So captions start hidden. They appear on your
+first interaction of any kind — zoom, drag, a filter chip, a search, clicking a
+node — and stay visible for the rest of that visit. To get the clean
+caption-free overview back, reload the page.
+
+This is a one-off marker tied to page load, not a zoom threshold: after the
+first interaction, captions follow the zoom tiers below and do not hide again
+until the next reload.
+
 ## Conversation label tiers
 
 Conversation nodes carry the most operator-meaningful identity in the
 subgraph (the conversation name or summary, the date it started, the message
-count). They render in one of three tiers, switched by canvas scale:
+count). Once captions are showing they render in one of three tiers, switched
+by canvas scale:
 
 | Zoom | Label shape | Example |
 |------|-------------|---------|
@@ -3962,7 +3983,7 @@ 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 only recognises a plugin-local `mcp/` (its `hasMcp` check: `mcp/dist/index.js` or `mcp/package.json`); 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 `mode=no-mcp` and its `mcp-manifest` annotation is ignored — a distinct mount architecture. Every tool-plugin that ships a plugin-local `mcp/` uses `auto`. 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.
+**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.
 
@@ -3974,7 +3995,7 @@ 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` restricted to plugins that ship a plugin-local `mcp/` dir — 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), but excludes shared-lib-server plugins like `graph` whose generated manifest carries no `mcpServers` by architecture (judging those by the generated-manifest criterion would false-FATAL on every boot). 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 `mcp/dist/index.js` is missing is `reason=dist-missing`. 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.
+**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.
 
@@ -4781,3 +4802,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/cloudflare/skills/calendar-site/SKILL.md

@@ -24,7 +24,11 @@ A booking visitor and the admin look at the booking from opposite sides — the
 | Admin calendar (4 views) | the install, at `/calendar` on the admin host (resolve via `admin-hostname`) | admin sign-in | every time-bound item for the account — booked and imported meetings, agent-scheduled appointments, and tasks with a due date |
 | Public booking page | Cloudflare Pages, on the booking domain | open | free/busy only, never any meeting detail |
 
-Only the public page is deployed here, because it must stay reachable and keep capturing bookings even when the install device is briefly offline. The admin calendar is dynamic, account-scoped, and authenticated, so it is served by the install over the tunnel and is same-origin with its data. Do not try to put the admin calendar on Pages.
+Only the public page is deployed here, because it must stay reachable and keep capturing bookings even when the install device is offline. The admin calendar is dynamic, account-scoped, and authenticated, so it is served by the install over the tunnel and is same-origin with its data. Do not try to put the admin calendar on Pages.
+
+## Availability survives the device going offline
+
+The booking page does not fetch open times from the device. It reads them same-origin from its own edge Function, `functions/api/calendar/free-busy.ts`, which serves a snapshot stored in the D1 `availability_snapshot` table minus any slot already booked (so a taken slot disappears at once, and two visitors never see the same slot) and with past slots filtered out (so a stale snapshot never offers an expired time). The snapshot is kept fresh by a publish job the platform server arms on a short timer: while the device is online it pushes the account's computed free/busy into `availability_snapshot`; while the device is off it simply does not run and the edge keeps serving the last snapshot until the device returns. There is no per-account cron or setup; the server arms it for the account it resolves, which is the one account whose booking site this install serves.
 
 ## Set the availability window first
 
@@ -34,7 +38,7 @@ The public page shows open slots computed as the weekly window minus busy `:Meet
 <accountDir>/calendar-availability.json
 ```
 
-Collect from the operator, then write the file: the account `timezone` (IANA), the meeting `durationMins`, the `bufferMins` between meetings, and the `weekly` window as `{ mon: [["09:00","17:00"]], ... }` with an empty array for days that are closed. Also collect `daysAhead` (the booking horizon — a positive integer count of days the page lets visitors book into, e.g. `14`) and `allowMultiSlot` (a boolean: may a visitor combine consecutive open slots into one longer back-to-back booking? default `false`). Add the `apiBase` (the brand tunnel origin that serves free/busy, `https://<brand-tunnel-domain>`), the `bookingDomain` (the custom domain the page will answer on), and `bookingDbName` (the D1 database name chosen below). Re-running this skill with new numbers is how availability — including the horizon and the multi-slot choice — is changed later; there is no separate editor.
+Collect from the operator, then write the file: the account `timezone` (IANA), the meeting `durationMins`, the `bufferMins` between meetings, and the `weekly` window as `{ mon: [["09:00","17:00"]], ... }` with an empty array for days that are closed. Also collect `daysAhead` (the booking horizon — a positive integer count of days the page lets visitors book into, e.g. `14`) and `allowMultiSlot` (a boolean: may a visitor combine consecutive open slots into one longer back-to-back booking? default `false`). Add the `bookingDomain` (the custom domain the page will answer on) and `bookingDbName` (the D1 database name chosen below). Re-running this skill with new numbers is how availability — including the horizon and the multi-slot choice — is changed later; there is no separate editor. The device-side job that keeps the edge snapshot fresh is armed by the always-running platform server, so there is nothing per-account to schedule.
 
 ## Assemble the canonical tree
 
@@ -44,11 +48,11 @@ Copy the skill template into the one canonical Pages source path `site-deploy` e
 <accountDir>/pages/<project>/
 ```
 
-The template ships `public/index.html`, `public/booking.js`, `public/booking.css`, `functions/api/book.ts`, `wrangler.toml`, and `schema.sql`. The substitutions that make it concrete are: in `public/index.html`, set the `<meta name="api-base">` content to the `apiBase` value (the booking page fetches free/busy cross-origin from the brand tunnel), set `<meta name="days-ahead">` content to `daysAhead`, and set `<meta name="allow-multi-slot">` content to `allowMultiSlot` as the literal `true` or `false`; and fill `wrangler.toml`'s `__PROJECT_NAME__`, `__D1_DATABASE_NAME__`, and `__D1_DATABASE_ID__` from the project name and the database created below. Leave no `__...__` placeholder in the assembled tree.
+The template ships `public/index.html`, `public/booking.js`, `public/booking.css`, `functions/api/book.ts`, `functions/api/calendar/free-busy.ts`, `wrangler.toml`, and `schema.sql`. The substitutions that make it concrete are: in `public/index.html`, set `<meta name="days-ahead">` content to `daysAhead` and set `<meta name="allow-multi-slot">` content to `allowMultiSlot` as the literal `true` or `false`; and fill `wrangler.toml`'s `__PROJECT_NAME__`, `__D1_DATABASE_NAME__`, and `__D1_DATABASE_ID__` from the project name and the database created below. Leave `<meta name="api-base">` empty as it ships; the page reads availability same-origin from the site's own `free-busy` edge Function (see the snapshot section below), never the device tunnel. Leave no `__...__` placeholder in the assembled tree.
 
 ## Provision the D1 bookings table
 
-This is a `bookings` table, not the `leads` table of a contact form, so the booking-specific schema ships with the template. Load the stable `<brand>-pages-d1` token from the account secrets file, minting it once only if absent and persisting it, exactly as `references/api.md` and `references/d1-data-capture.md` prescribe; the token needs both Pages Edit and D1 Edit. Create the database, record its id into `wrangler.toml`, and apply `schema.sql` to the remote database. The token is never written into the tree, never committed, never echoed.
+The booking-specific schema ships with the template: `schema.sql` creates both the `bookings` table (written by the booking page) and the `availability_snapshot` table (the single-row free/busy cache the publish job upserts and the `free-busy` edge Function reads). Applying `schema.sql` provisions both. Load the stable `<brand>-pages-d1` token from the account secrets file, minting it once only if absent and persisting it, exactly as `references/api.md` and `references/d1-data-capture.md` prescribe; the token needs both Pages Edit and D1 Edit. Create the database, record its id into `wrangler.toml`, and apply `schema.sql` to the remote database. The token is never written into the tree, never committed, never echoed.
 
 ## Deploy through site-deploy
 
@@ -59,7 +63,13 @@ Hand the assembled tree to `cloudflare:site-deploy`: it builds nothing for a sta
 Done is a live behavioural signal on the booking domain, surfaced verbatim:
 
 - The booking domain returns `HTTP/2 200` on a cache-busted request.
-- The page's free/busy call succeeds: `curl` the brand tunnel free/busy endpoint and confirm it returns a `slots` array and carries no meeting title, description, or location field. A `404` here means availability was not written; a blocked or unauthenticated response means the free/busy path is not reachable on the brand host.
+- The page's free/busy call succeeds same-origin: `curl` the booking domain's own `free-busy` edge Function and confirm it returns a `slots` array (with `updatedAt`) and carries no meeting title, description, or location field. Immediately after deploy it may return `{"slots":[],"updatedAt":null,"stale":true}` until the platform server's publish job runs once (within ~5 minutes); re-check until `updatedAt` is fresh and `slots` is populated. A response missing the `slots` field means the edge Function did not deploy; empty-with-`stale` after several minutes means the publish job is not reaching D1 (check the brand journal for `[calendar-availability]`).
+
+```bash
+curl -s "https://<booking-domain>/api/calendar/free-busy?from=$(date -u +%Y-%m-%dT00:00:00Z)&to=$(date -u -v+14d +%Y-%m-%dT00:00:00Z)" | head -c 400
+```
+
+The device's own free/busy (the publish job's source) should also return a `slots` array; a `404` there means the availability window was not written:
 
 ```bash
 curl -s "https://<brand-tunnel-domain>/api/calendar/free-busy?from=$(date -u +%Y-%m-%dT00:00:00Z)&to=$(date -u -v+14d +%Y-%m-%dT00:00:00Z)" | head -c 400

package/payload/platform/plugins/cloudflare/skills/calendar-site/template/functions/api/calendar/free-busy.ts

@@ -0,0 +1,152 @@
+// Edge free/busy Function (calendar-site skill) — offline-resilient availability.
+//
+// Served at GET /api/calendar/free-busy on the booking domain, same-origin with
+// the page. It serves open times from a snapshot the device publishes into D1
+// on a short timer (platform/ui server → publish-availability), MINUS any slot
+// already booked in the D1 `bookings` table:
+//   - Serving the snapshot means the public page keeps showing availability
+//     while the install device is offline (the device's own tunnel free/busy is
+//     then unreachable, but the snapshot survives on the edge).
+//   - Subtracting accepted bookings here — at the edge — means a booked slot
+//     disappears the instant it is taken, with no wait for the device to
+//     reconcile and republish, so two visitors are never shown the same slot.
+//   - Past slots are always filtered out, so a stale snapshot never offers a
+//     time that has already passed.
+//
+// Split like book.ts so the logic is verifiable without the Pages runtime:
+// computeFreeBusy takes an injected DB + logger and returns the HTTP shape.
+
+interface D1PreparedStatement {
+  bind: (...values: unknown[]) => D1PreparedStatement
+  first: <T = Record<string, unknown>>() => Promise<T | null>
+  all: <T = Record<string, unknown>>() => Promise<{ results?: T[] }>
+}
+interface D1Database {
+  prepare: (query: string) => D1PreparedStatement
+}
+interface FreeBusyEnv {
+  DB: D1Database
+}
+
+interface Slot {
+  start: string
+  end: string
+}
+interface Snapshot {
+  durationMins?: number
+  timezone?: string
+  slots?: Slot[]
+}
+
+type Logger = (line: string) => void
+
+interface FreeBusyQuery {
+  from?: string | null
+  to?: string | null
+  nowMs: number
+}
+
+// Default horizon when `to` is absent — a generous ceiling so a snapshot always
+// covers the page's own (operator-set) horizon.
+const DEFAULT_HORIZON_MS = 31 * 24 * 3600 * 1000
+
+export interface FreeBusyResult {
+  durationMins: number | null
+  timezone: string | null
+  slots: Slot[]
+  updatedAt: string | null
+  stale?: boolean
+}
+
+export async function computeFreeBusy(
+  env: FreeBusyEnv,
+  query: FreeBusyQuery,
+  log: Logger,
+): Promise<FreeBusyResult> {
+  const { nowMs } = query
+  const from = query.from ? Date.parse(query.from) : nowMs
+  const to = query.to ? Date.parse(query.to) : nowMs + DEFAULT_HORIZON_MS
+
+  let row: { payload?: string; updatedAt?: string } | null = null
+  try {
+    row = await env.DB
+      .prepare('SELECT payload, updatedAt FROM availability_snapshot WHERE id = 1')
+      .first<{ payload?: string; updatedAt?: string }>()
+  } catch {
+    row = null
+  }
+
+  // No snapshot published yet (first deploy) is distinct from a corrupt payload
+  // below — both otherwise collapse to empty slots, so name them apart in the log.
+  if (!row || !row.payload) {
+    log('[calendar-availability] op=serve result=no-snapshot slots=0')
+    return { durationMins: null, timezone: null, slots: [], updatedAt: null, stale: true }
+  }
+
+  let snap: Snapshot
+  try {
+    snap = JSON.parse(row.payload) as Snapshot
+  } catch {
+    log('[calendar-availability] op=serve result=corrupt slots=0')
+    return { durationMins: null, timezone: null, slots: [], updatedAt: row.updatedAt ?? null, stale: true }
+  }
+
+  const lower = Math.max(Number.isNaN(from) ? nowMs : from, nowMs)
+  const upper = Number.isNaN(to) ? nowMs + DEFAULT_HORIZON_MS : to
+
+  // Slots already taken (optimistic subtraction). Bound the scan to bookings at
+  // or after `lower`: reconcile only marks rows swept, never de-accepts them, so
+  // without this the accepted set grows without bound over the calendar's life —
+  // and a past booking can never match a snapshot slot that survives the
+  // start >= lower filter below, so the bound drops nothing. A failed read
+  // serves the snapshot as-is rather than 500 — the booking page still works.
+  const booked = new Set<string>()
+  try {
+    const res = await env.DB
+      .prepare("SELECT slotStart FROM bookings WHERE status = 'accepted' AND slotStart >= ?1")
+      .bind(new Date(lower).toISOString())
+      .all<{ slotStart?: string }>()
+    for (const b of res.results || []) {
+      if (b && typeof b.slotStart === 'string') booked.add(b.slotStart)
+    }
+  } catch {
+    /* keep the snapshot as-is */
+  }
+  const slots = (snap.slots || []).filter((s) => {
+    const t = Date.parse(s.start)
+    return !Number.isNaN(t) && t >= lower && t < upper && !booked.has(s.start)
+  })
+
+  const ageMs = row.updatedAt ? nowMs - Date.parse(row.updatedAt) : null
+  log(`[calendar-availability] op=serve result=ok slots=${slots.length} ageMs=${ageMs ?? 'na'}`)
+
+  return {
+    durationMins: snap.durationMins ?? null,
+    timezone: snap.timezone ?? null,
+    slots,
+    updatedAt: row.updatedAt ?? null,
+  }
+}
+
+interface PagesContext {
+  request: Request
+  env: FreeBusyEnv
+}
+
+export async function onRequestGet(context: PagesContext): Promise<Response> {
+  const url = new URL(context.request.url)
+  const result = await computeFreeBusy(
+    context.env,
+    {
+      from: url.searchParams.get('from'),
+      to: url.searchParams.get('to'),
+      nowMs: Date.now(),
+    },
+    (line) => console.log(line),
+  )
+  // Free/busy carries no credentials; a wildcard origin keeps it readable if a
+  // page ever fetches it cross-origin, matching the device endpoint's CORS.
+  return Response.json(result, {
+    headers: { 'Access-Control-Allow-Origin': '*' },
+  })
+}

package/payload/platform/plugins/cloudflare/skills/calendar-site/template/public/index.html

@@ -3,9 +3,12 @@
 <head>
   <meta charset="UTF-8" />
   <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-  <!-- The calendar-site skill rewrites the content of this tag to the brand
-       tunnel origin that serves /api/calendar/free-busy. -->
-  <meta name="api-base" content="__API_BASE__" />
+  <!-- Availability is read same-origin from this site's own edge Function
+       (functions/api/calendar/free-busy.ts), which serves the snapshot the
+       device publishes to D1. Empty = same-origin, so the page keeps working
+       when the install device is offline. Left blank deliberately; do not point
+       it at the device tunnel. -->
+  <meta name="api-base" content="" />
   <!-- Operator-set booking horizon (positive integer days). The skill rewrites
        the content; booking.js falls back to 14 when it is left unsubstituted. -->
   <meta name="days-ahead" content="__DAYS_AHEAD__" />

package/payload/platform/plugins/cloudflare/skills/calendar-site/template/schema.sql

@@ -16,3 +16,14 @@ CREATE TABLE IF NOT EXISTS bookings (
 );
 
 CREATE INDEX IF NOT EXISTS bookings_unswept ON bookings (status, swept);
+
+-- Single-row cache of the account's computed free/busy, published by the device
+-- on a short timer (platform/ui server → publish-availability). The booking
+-- page's edge free/busy Function serves open times from this snapshot minus any
+-- accepted booking, so the public page keeps showing availability while the
+-- device is offline. id is pinned to 1: one account per booking site, one row.
+CREATE TABLE IF NOT EXISTS availability_snapshot (
+  id        INTEGER PRIMARY KEY CHECK (id = 1),
+  payload   TEXT,
+  updatedAt TEXT
+);

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/calendar-booking.md

@@ -55,4 +55,4 @@ A `pendingUnreconciled` number that stays above zero across several runs means t
 
 ## What this does not do
 
-One meeting type only (one length, one weekly window, one buffer). No syncing to Google or iCloud calendars: your meetings in Maxy are the source of truth. No rescheduling or cancellation links, reminders, or visitor time-zone selection. The booking page shows availability live from your device, so while your device is offline the page can still take a booking but may not show fresh open times until it is back.
+One meeting type only (one length, one weekly window, one buffer). No syncing to Google or iCloud calendars: your meetings in Maxy are the source of truth. No rescheduling or cancellation links, reminders, or visitor time-zone selection. The booking page shows open times from a snapshot your device publishes to the edge on a short timer, so the page keeps showing availability and taking bookings even while your device is offline — a slot that gets booked drops off at once, and times that have passed are never shown. If your device stays offline a long time the open times can go stale, but they never vanish; they refresh the moment it is back online.

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

@@ -1,8 +1,10 @@
 # Graph View
 
 The **Graph** admin page (`/graph`) renders a force-directed view of your
-account's Neo4j subgraph. Labels on the canvas follow the zoom level, so you
-see the most useful identity at every scale.
+account's Neo4j subgraph. Node captions are hidden on first load so the
+whole-graph overview stays uncluttered, and appear the moment you interact.
+Once shown, captions follow the zoom level so you see the most useful identity
+at every scale.
 
 ## Default view
 
@@ -58,11 +60,25 @@ This is an in-page overlay, so the browser tab and address bar stay put. It is
 not the operating system's full-screen mode. The maximize button shows only on
 the `/graph` page, not where the graph is embedded in another pane.
 
+## Captions hidden on first load
+
+When you open `/graph` (or refresh the page) the whole graph auto-fits into the
+viewport, which on a busy graph would render every caption at once and overlap
+them into unreadable clutter. So captions start hidden. They appear on your
+first interaction of any kind — zoom, drag, a filter chip, a search, clicking a
+node — and stay visible for the rest of that visit. To get the clean
+caption-free overview back, reload the page.
+
+This is a one-off marker tied to page load, not a zoom threshold: after the
+first interaction, captions follow the zoom tiers below and do not hide again
+until the next reload.
+
 ## Conversation label tiers
 
 Conversation nodes carry the most operator-meaningful identity in the
 subgraph (the conversation name or summary, the date it started, the message
-count). They render in one of three tiers, switched by canvas scale:
+count). Once captions are showing they render in one of three tiers, switched
+by canvas scale:
 
 | Zoom | Label shape | Example |
 |------|-------------|---------|