@rubytech/create-sitedesk-code 0.1.518 → 0.1.520

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 SiteDesk 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:f7196d99cda8a64e13d1951d4363a879f9141949c174d6d26810b0a47a2f4ee8
+content-hash: sha256:69ee9681cbe3bd78fa8d38f916aa5979d4814681b59f3c1bd3570c613315ca7c
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -1213,7 +1213,7 @@ npx -y @rubytech/create-realagent-code@latest --uninstall
 - **No SCP / rsync.** Updates are `npx -y @rubytech/create-maxy-code@latest …` again, never a file push from the operator's laptop.
 - **Tunnel auth is OAuth; the API is permitted for the rest.** The tunnel's only auth path is `cloudflared tunnel login` in the noVNC browser over SSH forward. DNS, Pages, and D1 use the Cloudflare API with a short-lived narrow token the agent mints from an operator-provisioned master token (see the `cloudflare` plugin).
 - **No shared state across brands.** Two brands on one server each have their own Neo4j port, systemd unit, VNC display, websockify port, tunnel, and persist directory.
-- **No public IPv4 exposure.** The Hetzner firewall opens port 22 only; every operator-facing surface is fronted by the Cloudflare tunnel.
+- **No public IPv4 exposure.** The Hetzner firewall opens port 22 only; every operator-facing surface is fronted by the Cloudflare tunnel. The provider firewall is no longer the only thing making that true for the admin edge: this host carries a public IPv4, so the installer writes `EDGE_HOSTNAME=127.0.0.1` into the edge unit and the edge port is loopback-only by construction. That holds whether or not the box also has a Cloud Network attached. It covers the edge port only; see [netcup.md](netcup.md) for what a host without a provider firewall still depends on `ufw` for.
 
 ## Smoke checklist
 
@@ -1294,7 +1294,7 @@ In netcup's Customer Control Panel:
 2. When the server is provisioned, install **Ubuntu 24.04 LTS** from the CCP's image list.
 3. Add your SSH public key during image setup, or paste it into `/root/.ssh/authorized_keys` from the remote console afterwards.
 
-netcup does not provide a network firewall product in front of the server, so the host firewall is the only inbound control. Close everything except SSH before going further:
+netcup does not provide a network firewall product in front of the server, so at this point the host firewall is the only inbound control. Close everything except SSH before going further:
 
 ```bash
 ufw default deny incoming
@@ -1369,7 +1369,7 @@ npx -y @rubytech/create-realagent-code@latest --hostname <realagent-hostname>
 
 The persist directory becomes `$HOME/.realagent-code`, the systemd user-service becomes `<realagent-hostname>.service`, Neo4j is provisioned on its own port, and the VNC display + websockify + ttyd ports shift to the brand's reserved range.
 
-Co-residency has an aggregate cost the per-brand capacity figure does not express: each brand's daemon reads whole-box RAM independently, so four brands each resolving 10 sessions can exceed what the box holds. On a 64 GB host this has more headroom than on 16 GB, but it is not unlimited.
+Co-residency has an aggregate cost the per-brand capacity figure does not express, and clearing the 56 GiB step makes it sharper, not safer. Each brand's daemon reads whole-box RAM independently and reaches its own conclusion, so on a 64 GB host **four co-resident brands each resolve 40**, an aggregate of 160 concurrent sessions at roughly 1.2 GB each against a box that holds 64 GB. No brand reaches its own cap and is wrong; the box runs out first. A count-based per-daemon cap derived from box-wide RAM cannot express a constraint shared by co-resident daemons — the box-wide `MemAvailable` reclaim in `slice-memory-policy.ts` is what actually bounds this. Treat a multi-brand 64 GB install as needing that reclaim path verified under load, not assumed.
 
 ## 5. Reach the dashboard and VNC browser over SSH port-forwarding
 
@@ -1411,21 +1411,31 @@ This stops and disables the systemd user-service, removes the unit file, removes
 - **No SCP / rsync.** Updates are `npx -y @rubytech/create-maxy-code@latest …` again, never a file push from the operator's laptop.
 - **Tunnel auth is OAuth; the API is permitted for the rest.** As on Hetzner.
 - **No shared state across brands.** Two brands on one server each have their own Neo4j port, systemd unit, VNC display, websockify port, tunnel, and persist directory.
-- **No provider firewall.** Unlike Hetzner Cloud, inbound control is the host `ufw` rules from step 1 alone. Verify with `ufw status` after install; the installer does not open ports.
+- **No provider firewall, so `ufw` is the only network-level layer.** On Hetzner Cloud the provider firewall opens 22 only; netcup has nothing in front of the server. What keeps the admin edge private here is the bind itself: the installer classifies the host from its interface table and, because this box carries a public IPv4, writes `EDGE_HOSTNAME=127.0.0.1` into the edge unit, so the edge port is loopback-only by construction and `ufw` is the backstop rather than the single control. Confirm which was written with `grep -E 'bind-decision|EDGE_HOSTNAME' $HOME/.<brand>/logs/install-*.log`. This covers the **edge port only**, not the whole box: the noVNC websockify transport still binds all interfaces, so `ufw` remains load-bearing for that port, and anything that clears the ruleset — a flushed nftables set after a kernel change, `ufw disable` during debugging, a CCP image reinstall — exposes it. Verify from **off** the box, not with `ufw status` on it.
 
 ## Smoke checklist
 
 Fresh-netcup smoke pass criteria:
 
-1. Provision an RS 8000 G12 with Ubuntu 24.04 x86_64 and an SSH key; `ufw status` reports SSH only; SSH in as `root`, create `admin`, switch.
-2. Snapshot taken with the OS prepared and nothing installed.
-3. Install completes on the clean image, prints a loopback URL, and the systemd user-service is `active (running)`.
-4. `logs-read.sh --tail server 200 | grep 'op=capacity-resolved'` returns one line, and its `totalMemGiB` matches the provisioned RAM.
-5. The noVNC page reached over `ssh -L` displays the admin UI.
-6. Cloudflare setup ends with `curl -I https://<hostname>.<your-zone>` returning `HTTP/2 200` from the operator's laptop.
-7. Reboot; both units come back up; the public URL is reachable again without any manual action.
-8. Install a second brand with a different `--hostname`; both admin UIs are reachable on their own public hostnames and neither has touched the other's state.
-9. Uninstall removes the systemd unit and the persist directory.
+1. Provision an RS 8000 G12 with Ubuntu 24.04 x86_64 and an SSH key; SSH in as `root`, create `admin`, switch.
+2. **From a machine off the server**, port 22 answers and the edge port does not. Two independent things make that true here: the edge binds loopback on this host class, and `ufw` denies inbound. `ufw status` on the box states the intention; only an external probe confirms the outcome:
+
+   ```bash
+   nc -z -w 5 <ipv4> 22 && echo "22 open (expected)"
+   nc -z -w 5 <ipv4> 19200 && echo "EDGE EXPOSED — check the bind, then ufw"
+   ```
+
+   If the edge port answers, read the bind first: `grep -E 'bind-decision|EDGE_HOSTNAME' $HOME/.<brand>/logs/install-*.log` should show `EDGE_HOSTNAME=127.0.0.1` on this host, and `ss -lntp` should show the edge on `127.0.0.1:19200`. A public bind there is a classification fault, not a firewall fault.
+
+   Re-run this after every reboot, after any brand install, and after any CCP image reinstall.
+3. Snapshot taken with the OS prepared and nothing installed.
+4. Install completes on the clean image, prints a loopback URL, and the systemd user-service is `active (running)`.
+5. `logs-read.sh --tail server 200 | grep 'op=capacity-resolved'` returns one line reporting `capacity=40`, with `totalMemGiB` matching the provisioned RAM. A `capacity=10` on a 64 GB box means the host resolved below the 56 GiB step and needs investigating before load.
+6. The noVNC page reached over `ssh -L` displays the admin UI.
+7. Cloudflare setup ends with `curl -I https://<hostname>.<your-zone>` returning `HTTP/2 200` from the operator's laptop.
+8. Reboot; both units come back up; the public URL is reachable again without any manual action; the step-2 external probe still shows the edge port closed.
+9. Install a second brand with a different `--hostname`; both admin UIs are reachable on their own public hostnames and neither has touched the other's state.
+10. Uninstall removes the systemd unit and the persist directory.
 
 If any step fails, attach `$HOME/.<brand>/logs/install-<timestamp>.log` to the report.
 
@@ -3257,7 +3267,7 @@ either is a regression.
 
 **`/chat` Claude-desktop transcript presentation.** The admin webchat keeps the shared `Transcript` shell (stream, follow-tail) but injects a /chat-only item renderer via the component's optional `renderItems` prop: `renderChatTimeline` in `app/chat/transcript-render.tsx`. Presentation: operator turns render as a right-aligned grey bubble showing the message text and, beneath it, a subtle always-visible time-of-day stamp (no label); delivered agent replies render as plain prose with the same time-of-day stamp beneath (the reply-document filename line stays, as prose); the stamp is HH:MM from the turn's `ts` (locale-formatted, right-aligned inside the operator bubble, left-aligned under agent prose), and a turn whose `ts` is null/unparseable shows no stamp, never an empty line — so only delivered operator and agent-reply turns are stamped, while tool runs, the collapsed "Thinking" block, and the agent-error banner stay time-free; a maximal consecutive run of `tool-call`/`tool-result` turns renders as one collapsed grey one-liner ("Used N tools ›") whose expansion shows every call and result payload — a lone call still gets the one-liner, and prose or a directive row ends a run. The WhatsApp/operator reader (`/whatsapp`, `OperatorConversations`) omits the prop and keeps the default `renderTimeline`, so its bubble/DM chrome is unchanged — except that since the attachment-render extraction the default renderer draws inbound `operator-inbound` uploads and `agent-file` deliveries inline (image thumbnail / pdf.js preview / voice-note player / download chip) via the attachment renderer shared with `/chat`, extracted to `app/chat/attachment-render.tsx` to break the cycle with `transcript-render.tsx`; `renderChatTimeline` is untouched. Both presentations are test-pinned (`app/whatsapp/__tests__/Transcript-*.test.tsx`, `app/chat/__tests__/transcript-render.test.tsx`, `app/chat/__tests__/pdf-preview.test.tsx`). **Day-divider:** both renderers insert a centered `.day-divider` row between two consecutive timeline items on different local calendar days (label `Today`/`Yesterday`, else `Sat 14 Jun 2026`), so a thread spanning midnight is never an ambiguous run of HH:MM; the first dated item gets a leading divider, a null/unparseable `ts` marks no boundary, dividers are computed over the filtered `visibleItems`, and in `/chat` a day crossover flushes any open tool/think run first so a collapsed run never spans it. Per-bubble HH:MM stamps are unchanged. Shared helpers `dayKey`/`dayLabel`/`itemTs`/`DayDivider` live in `app/whatsapp/Transcript.tsx`.
 
-**One delivered bubble per turn when the agent replied.** On the admin `/chat`, a turn that used the reply tool shows exactly one delivered bubble — the reply. A trailing sign-off or recap the agent writes after the reply is treated as narration and is not shown as a second bubble (it collapses like any mid-turn prose). Only a turn that ends **without** using the reply tool has its final text promoted to a delivered bubble, so a genuine no-reply answer is never lost. The tradeoff, accepted by the operator: a turn that acknowledges on the reply tool and then writes the real answer as trailing text will not show that trailing answer — the agent is steered to put the answer on the reply tool so this stays rare.
+**One delivered bubble per turn on the admin `/chat`.** The admin webchat has no outbound transport, so the agent has no reply tool there: the text its turn ends with **is** the delivered answer, and it renders as the one prominent prose bubble. Mid-turn prose collapses into the folded run as before, so a turn shows exactly one delivered bubble. A turn that reaches its end with no trailing text delivers nothing and is logged as `op=turn-answer-absent`. Public webchat, WhatsApp and Telegram keep their reply tool, and every historical admin transcript still renders its recorded reply-tool bubbles unchanged.
 
 **WhatsApp reader is read/write (WhatsApp-Web surface).** A WhatsApp store conversation in the operator Conversations reader (`OperatorConversations`) and the admin root channel viewer (`app/page.tsx`) no longer opens the plain read-only DM chrome — it opens `app/whatsapp/WhatsappWebConversation.tsx`, a WhatsApp-Web-styled surface: a conversation header, the delivered-only store transcript reskinned green/white under a `.wa-web` root class, and a reply composer (`app/whatsapp/ReplyComposer.tsx`). The operator can type text, insert emoji (a codepoint-data picker — no OS input, so the `check-no-emoji-in-jsx` gate stays green), record a voice note (MediaRecorder → the existing audio send path), attach a file **from device storage** (a modal browsing the DATA_ROOT tree via `GET /api/admin/files`, sent by reference — the OS file dialog is no longer the reader's picker), reply to a specific message (a per-bubble affordance that quotes the original in the composer and threads natively on WhatsApp), and search the loaded transcript (a header control that filters to matching turns and highlights the match). The header carries only that Search control — the former Video / Phone / menu icons are gone, because no call or presence data exists behind them. Sent files honour the webchat allowlist (`SUPPORTED_MIME_SET` / 50 MB / 5 files); a device-file reference is authorised server-side (`authorizeReplyFileRef`) against the send's own account (the conversation owner) **or** the session's pinned account (`getAccountIdForSession` — the exact scope the DeviceFilePicker used to offer it), so a house/managing-admin session can attach a managed-client file the picker listed. Because a reply sends bytes OUT to an external WhatsApp recipient, any other account, a `public` partition, and any install-wide / non-account path are refused fail-closed; the cross-account admission's authority is the session's pinned account, never the caller-supplied body `accountId` (the own-account admission matches the body `accountId`, which the route already trusts via `isValidAccountId` and the existing-conversation guard). A scope refusal returns a distinct HTTP 403 reason (`file-ref-cross-account` / `file-ref-public` / `file-ref-foreign`) and copy, never "device file not found" (reserved for a genuine resolve/stat miss). Per-ref `[wa-manual-send] op=reply-file-ref … via=own|session|deny reason=<…> ok=<bool>` logs the decision before any send; `via=deny ok=true` is the exfiltration signature that must never appear. **Send is reply-only and DM-only:** `POST /api/whatsapp-reader/reply` (`requireAdminSession`) refuses any target with no existing stored conversation (`reason=no-existing-conversation`, HTTP 403) — a cold first-contact send bans the account, so the composer is never a cold-contact path, enforced server-side — and refuses `@g.us` groups (`reason=group-send-blocked`), matching the agent's observe-only group invariant; a group thread shows a read-only note in place of the composer. The endpoint is the sole store writer for a manual send: right after each send resolves it appends the record itself, stamped `origin:'operator-manual'` (attributed "You", distinct from an assistant reply), because the Baileys echo that normally persists the store is gated on message text (`manager.ts:906`) and would leave an uncaptioned media send delivered-but-invisible. The record's `messageId` matches the echo's derivation so the async text echo's own persist dedups to a no-op; the send is confirmed by re-read (`op=recorded present=<bool>`). A sent send does not spawn an assistant turn (echo dispatch stays suppressed). Attachments deliver as WhatsApp media/documents and render **inline** in the store reader (image thumbnail / pdf preview / audio player / download chip), because the manual-send path records the message with the servable `attachmentId`. The `.wa-web` skin is scoped to WhatsApp store threads only, so `/chat`, the admin agent session view, and the public visitor webchat are unchanged; the visitor webchat gains no send capability. The in-bubble delivered-tick is cosmetic (no read-receipt data is stored); inbound bubbles keep their sender name so group threads stay attributable, and both directions carry a WhatsApp callout tail (`.wa-web`-scoped only). Non-WhatsApp reader rows (Telegram/webchat session JSONLs) keep the plain read-only `Transcript`. Observability rides `[wa-manual-send]` lines correlated by a per-request `sendId`. **Composer sizing matches the webchat composer:** the reply textarea auto-grows to fit multi-line content (measured from `scrollHeight`, clamped to a one-row minimum and a `viewport/3` maximum, scrollable past the cap with the scrollbar hidden), and a top-border grab handle drags (pointer) or nudges (ArrowUp/ArrowDown, keyboard-focusable) to an explicit height in the same clamp; a manual drag pins the height and overrides auto-grow until the field is cleared, which releases it back to auto-grow. A completed manual resize logs `[operator-ui] op=wa-composer-resize mode=drag|key h=<px>`; a bare click on the handle (no drag) logs nothing.
 
@@ -3935,7 +3945,7 @@ authoritative. This section names the surfaces and what backs each.
 > a read-only reader. The item gates on the flyout handler being wired, exactly
 > like the admin and lite items. The read-only inbound-channel **Conversations**
 > reader (WhatsApp, Telegram, public webchat, via the admin-gated
-> `/api/whatsapp-reader/conversations` route) remains on `/data`'s Conversations
+> `/api/operator-conversations/conversations` route) remains on `/data`'s Conversations
 > item and in the admin Sidebar; it is no longer reachable from the operator chat
 > surface. The operator surface is documented in full in the internal doc
 > `maxy-code/.docs/operator-dashboard.md`.
@@ -3977,7 +3987,7 @@ authoritative. This section names the surfaces and what backs each.
 > count. On the operator **chat** surface the handler is always wired, so the
 > item is always present and opens the live session switcher (above). On `/data`
 > the handler is wired only when ≥1 reviewable inbound conversation exists
-> (fetched from `/whatsapp-reader/conversations` with the operator's session
+> (fetched from `/operator-conversations/conversations` with the operator's session
 > key), and selecting it renders the read-only reader in place (the file browser
 > is swapped for it; Back returns) — so `/data` keeps its hide-when-empty
 > behaviour. The flyout-open signal `[operator-ui] op=conversations-menu
@@ -3991,8 +4001,8 @@ authoritative. This section names the surfaces and what backs each.
 | Nav rows (Chat / People / Agents / Projects / Tasks / Artefacts) | People, Agents, Tasks open the artefact-pane Graph filtered to the matching label. Chat selects the active conversation. Artefacts swaps the list to editable documents. **The "Projects" row is brand-aware:** its visible term and the graph label it filters to both come from the injected `window.__BRAND__.primaryContainer` (`brand.json` → `server/index.ts` inject → `brand.ts` `brandPrimaryContainer()`), so SiteDesk reads "Projects" → `:Project`, SiteDesk "Jobs" → `:Job`, Real Agent "Properties" → `:Property`. A brand JSON missing `primaryContainer` falls back to Project/Projects (server logs `[brand] op=primaryContainer-default reason=absent brand=<hostname>`; the populated case logs `[brand] op=inject primaryContainer=<label>/<term>`). | `graph-search.ts`, `graph-subgraph.ts`, `sidebar-artefacts.ts` |
 | Sessions list (Active / Archived / All) | Live row store driven by SSE; manual reconcile button on the segmented control re-fetches the full id set. Every listed row carries two launch actions: the claude.ai/code resume (`ExternalLink`) and a chat-launch (`MessageSquare`) that opens `/chat?session=<full sessionId>` — the admin webchat pointed at that exact session; sending there resumes a stopped session with the webchat channel bound to that id (see `admin-webchat-native-channel.md`, "Session-targeted mode"). **Clicking the row's body** (live-dot, title, id, or timestamp) opens that same `/chat?session=<id>` as the chat-launch action. The main area stays a `<div>` (it wraps the inline rename input, which a `<button>` may not contain) carrying `role="button"`, `tabIndex`, an "Open <title> in webchat" aria-label, and Enter/Space activation, styled with `conv-main-clickable` for pointer + hover parity with the channel-row button. The click and keyboard handlers no-op while the row is being renamed, so an in-progress edit is preserved; the action icons and the `⋯` overflow menu are a sibling cluster running their own handlers, so activating them never triggers the row-body open. At the ≤720 px drawer breakpoint each row stacks into two lines — dot + title + id/stamp, then the action icons — with a divider between rows and actions at full opacity (the desktop hover-gated 0.5 opacity never resolves on touch). Below a 400 px list width each row's action icons collapse to a single `MoreHorizontal` ellipsis trigger; its popover menu lists the same actions as the inline icons but labels them with concise verbs (`Resume in claude.ai/code`, `Open in webchat`, `Stop`, `Archive` / `Unarchive`, `Rename`, `Delete`, `Re-seat`) rather than the inline icon buttons' verbose per-session aria-labels — the inline buttons keep those verbose labels because an icon-only control needs the full descriptive accessible name. **Re-seat:** Re-seat is a member action of the one `SessionRowActions` cluster, not a separate sibling control — wide it is the sliders icon inline with the other icons (sharing the cluster geometry and alignment); collapsed it is the `Re-seat` menu item, which expands the model/mode/effort form inline inside the overflow menu. The form (`SessionReseatControl`) forks the session via `/api/admin/session-reseat` and navigates to the fork (the same fork mechanism `/chat`'s pickers drive); its model picker defaults to the row's current model (a `model` field on each row, read from the JSONL tail), and mode and effort each carry a "Keep" option that omits the field. The overflow menu and the Re-seat form render through a `document.body` portal, fixed-positioned from the trigger's rect (right-aligned, flipped above the trigger when there is no room below), so neither is clipped by `.side-list`'s `overflow-y:auto`; Escape, a pointerdown outside the trigger/popover, and any scroll or resize dismiss them. | `/claude-sessions/events`, `/claude-sessions`, `/session-reseat` |
 | Data pane | A "Data" nav row beside Artefacts/Sessions. Uses the same `activeNav` toggle, but its content — the headless `DataFileBrowser` (graph search + `{installDir}/data/` file browser) — renders in the shell's **main column** via `DataPaneSurface`, like the WhatsApp Transcript, not in the side-list; there is no side-list block under `activeNav==='data'`. `AdminShell` owns a `dataOpen` main-column state (mutually exclusive with the WhatsApp selection); the row lifts the choice through `onSelectData`. On `/` it opens in place; from any other route (`/graph`, `/chat`, `/browser`) it navigates to `/?data=1`, which the root shell hydrates on mount (`hydrateDataFromUrl`, then strips the query). The admin burger no longer carries a Data item (the operator surface, which has no Sidebar, keeps the burger → `/data` route). Client breadcrumbs: `[admin-ui] sidebar-nav surface=data …`, `[admin-ui] data-open route=… via=<in-place\|navigate>`, `[admin-ui] data-hydrate route=/`. | `sidebar-artefacts.ts`, `files.ts`, `graph-search.ts` |
-| Channel reader nav rows (WhatsApp / Telegram) | One conditional nav row per channel that has ≥1 conversation. Each row carries its brand glyph (WhatsApp `#25D366`, Telegram `#229ED9`); a channel with no conversations shows no row, and no install ever shows an always-empty "No conversations" row. The channel list loads **once on sidebar mount**, so a failed load shows one muted, non-clickable line instead of channel rows. **WhatsApp rows are sourced from the on-disk message store** (`readAllConversations`), one row per stored conversation keyed by `remoteJid`, independent of whether any session JSONL exists — a blocked non-admin DM or a group-observed thread that never produced a session is listed here. **Telegram rows are session-sourced** (one per admin Telegram session), unchanged. Each conversation row shows a **display name**: for WhatsApp, the store record's `senderName` (else the `senderTelephone`, else the `remoteJid`); for Telegram, the precedence `operatorName ?? senderId ?? title` where `operatorName` is the bound `Person givenName familyName`. Under the name each row shows a **last-message-time breadcrumb** (`conv-timestamp`) from `lastMessageAt`, never "Invalid Date". **Scope colour (WhatsApp):** each WhatsApp row is coloured by its conversation's scope — a thin left accent bar, green for `admin`, orange for `public`, taken from the conversation's most-recent stored record (this replaces the former "Public" text pill). **Re-seat:** only session-sourced rows (Telegram, and webchat in the Sessions panel) carry a `SessionRowActions` Re-seat cluster; a WhatsApp store row has no session, so it carries no Re-seat. A click on a conversation **opens its transcript on the home surface**: on `/` it selects in place, and from any other route it navigates to `/?wa=<remoteJid>&acct=<accountId>`, which the root shell hydrates on mount (then strips the query). **Account-scoped** exactly as the sidebar Sessions list: both row sources (WhatsApp store rows and Telegram/public-webchat session rows) are scoped to the caller's pinned account (`getAccountIdForSession(cacheKey)`), multi-account-gated (`listValidAccounts().length > 1`). On a multi-account install a subaccount view shows only its own conversations; the house account's WhatsApp appears only under the house view; an untagged session sidecar is excluded and counted; an unresolvable scope fails closed to an empty list (logs `op=list-scope-unresolved`). A single-account install filters nothing, byte-identical to before. Server logs `[wa-reader] op=list pinnedAccount=<id8> resolvedAccount=<id8> multiAccount=<bool> conversations=<n> sessionRows=<m> storeRows=<k> adminScope=<n> publicScope=<n> sessionRowsExcludedUntagged=<n>` per list build (`pinnedAccount === resolvedAccount` is the post-fix invariant when `multiAccount=true`; `conversations=0` on an account with a non-empty store dir is the over-filtering drift signal); the client logs `[admin-ui] wa-open route=… via=<in-place\|navigate> …` and `[admin-ui] wa-hydrate route=/ remoteJid=…`. | `/whatsapp-reader/conversations` |
-| Channel transcript (`<Transcript>`) | **WhatsApp** reads its conversation verbatim from the message store file (`<remoteJid>.jsonl`) over SSE (`/whatsapp-reader/store-stream`): both directions, `dateSent`-ordered, backlog on connect then a live tail so a newly stored message appears without reload — no session JSONL is read. **Telegram** still reads one session's JSONL over SSE (`/whatsapp-reader/stream`) and renders both sides plus tool calls — the turns claude.ai/code hides because channel inbound is stamped `isMeta`. Every turn shows its time-of-day (HH:MM from the turn's `ts`; a null/unparseable `ts` shows no time, never "Invalid Date"). On the Telegram session stream, `tool-call`/`tool-result` turns render as **collapsed cards** so the human↔agent text is not buried in JSON. The thread **follows the tail**: it opens at the newest turn and pins to the bottom on each live append **only while the operator is already within 32 px of the bottom**; while scrolled up a **jump-to-bottom control** (`.wa-jump`) appears. Both streams send a 20 s heartbeat so an idle Cloudflare tunnel does not idle-drop, tag each frame with a byte-offset `id:`, and resume from the client's `Last-Event-ID` on reconnect (no duplicate backlog); the client clears the "Stream disconnected" banner on reopen and latches it only on a terminal CLOSED state. The Telegram session stream also interleaves a collapsed `⚙ directive injected (N B)` row per turn (listed by `GET /whatsapp-reader/directives?sessionId=`, bytes served by `GET /whatsapp-reader/directive?sessionId=&name=`); a WhatsApp store conversation has no session, so it has no directives. A centered day-divider row (`.day-divider`) marks each local calendar-day crossover. This viewer renders **delivered messages only** (both WhatsApp store rows and Telegram session rows, via `forceDeliveredOnly`) with **no per-viewer toggle** — the former "Messages only" pill is retired; the admin `/chat` composer's own messages-only control is unaffected. The panel — wallpaper included — is **bounded to `--chat-measure` and centred** (`.platform > .wa-reader`), so it reads as a column the same width as `/data`, not an edge-to-edge beige surface. The store stream open logs `[wa-reader] op=open remoteJid=<jid> scope=<admin\|public> messages=<n> source=store`. | `/whatsapp-reader/store-stream`, `/whatsapp-reader/stream`, `/whatsapp-reader/directives`, `/whatsapp-reader/directive` |
+| Channel reader nav rows (WhatsApp / Telegram) | One conditional nav row per channel that has ≥1 conversation. Each row carries its brand glyph (WhatsApp `#25D366`, Telegram `#229ED9`); a channel with no conversations shows no row, and no install ever shows an always-empty "No conversations" row. The channel list loads **once on sidebar mount**, so a failed load shows one muted, non-clickable line instead of channel rows. **WhatsApp rows are sourced from the on-disk message store** (`readAllConversations`), one row per stored conversation keyed by `remoteJid`, independent of whether any session JSONL exists — a blocked non-admin DM or a group-observed thread that never produced a session is listed here. **Telegram rows are session-sourced** (one per admin Telegram session), unchanged. Each conversation row shows a **display name**: for WhatsApp, the store record's `senderName` (else the `senderTelephone`, else the `remoteJid`); for Telegram, the precedence `operatorName ?? senderId ?? title` where `operatorName` is the bound `Person givenName familyName`. Under the name each row shows a **last-message-time breadcrumb** (`conv-timestamp`) from `lastMessageAt`, never "Invalid Date". **Scope colour (WhatsApp):** each WhatsApp row is coloured by its conversation's scope — a thin left accent bar, green for `admin`, orange for `public`, taken from the conversation's most-recent stored record (this replaces the former "Public" text pill). **Re-seat:** only session-sourced rows (Telegram, and webchat in the Sessions panel) carry a `SessionRowActions` Re-seat cluster; a WhatsApp store row has no session, so it carries no Re-seat. A click on a conversation **opens its transcript on the home surface**: on `/` it selects in place, and from any other route it navigates to `/?wa=<remoteJid>&acct=<accountId>`, which the root shell hydrates on mount (then strips the query). **Account-scoped** exactly as the sidebar Sessions list: both row sources (WhatsApp store rows and Telegram/public-webchat session rows) are scoped to the caller's pinned account (`getAccountIdForSession(cacheKey)`), multi-account-gated (`listValidAccounts().length > 1`). On a multi-account install a subaccount view shows only its own conversations; the house account's WhatsApp appears only under the house view; an untagged session sidecar is excluded and counted; an unresolvable scope fails closed to an empty list (logs `op=list-scope-unresolved`). A single-account install filters nothing, byte-identical to before. Server logs `[wa-reader] op=list pinnedAccount=<id8> resolvedAccount=<id8> multiAccount=<bool> conversations=<n> sessionRows=<m> storeRows=<k> adminScope=<n> publicScope=<n> sessionRowsExcludedUntagged=<n>` per list build (`pinnedAccount === resolvedAccount` is the post-fix invariant when `multiAccount=true`; `conversations=0` on an account with a non-empty store dir is the over-filtering drift signal); the client logs `[admin-ui] wa-open route=… via=<in-place\|navigate> …` and `[admin-ui] wa-hydrate route=/ remoteJid=…`. | `/operator-conversations/conversations` |
+| Channel transcript (`<Transcript>`) | **WhatsApp** reads its conversation verbatim from the message store file (`<remoteJid>.jsonl`) over SSE (`/whatsapp-reader/store-stream`): both directions, `dateSent`-ordered, backlog on connect then a live tail so a newly stored message appears without reload — no session JSONL is read. **Telegram** still reads one session's JSONL over SSE (`/session-reader/stream`) and renders both sides plus tool calls — the turns claude.ai/code hides because channel inbound is stamped `isMeta`. Every turn shows its time-of-day (HH:MM from the turn's `ts`; a null/unparseable `ts` shows no time, never "Invalid Date"). On the Telegram session stream, `tool-call`/`tool-result` turns render as **collapsed cards** so the human↔agent text is not buried in JSON. The thread **follows the tail**: it opens at the newest turn and pins to the bottom on each live append **only while the operator is already within 32 px of the bottom**; while scrolled up a **jump-to-bottom control** (`.wa-jump`) appears. Both streams send a 20 s heartbeat so an idle Cloudflare tunnel does not idle-drop, tag each frame with a byte-offset `id:`, and resume from the client's `Last-Event-ID` on reconnect (no duplicate backlog); the client clears the "Stream disconnected" banner on reopen and latches it only on a terminal CLOSED state. The Telegram session stream also interleaves a collapsed `⚙ directive injected (N B)` row per turn (listed by `GET /session-reader/directives?sessionId=`, bytes served by `GET /session-reader/directive?sessionId=&name=`); a WhatsApp store conversation has no session, so it has no directives. A centered day-divider row (`.day-divider`) marks each local calendar-day crossover. This viewer renders **delivered messages only** (both WhatsApp store rows and Telegram session rows, via `forceDeliveredOnly`) with **no per-viewer toggle** — the former "Messages only" pill is retired; the admin `/chat` composer's own messages-only control is unaffected. The panel — wallpaper included — is **bounded to `--chat-measure` and centred** (`.platform > .wa-reader`), so it reads as a column the same width as `/data`, not an edge-to-edge beige surface. The store stream open logs `[wa-reader] op=open remoteJid=<jid> scope=<admin\|public> messages=<n> source=store`. | `/whatsapp-reader/store-stream`, `/session-reader/stream`, `/session-reader/directives`, `/session-reader/directive` |
 | Conversations row hover actions | Inline rename, archive, delete, JSONL view / download per row. The historical `.conversations-modal` CSS block exists in `globals.css` but is no longer mounted from any TSX — Sidebar.tsx now owns every per-row affordance directly. | `claude-sessions.ts` |
 | Artefacts list | Lists every `:FileArtifact` under this account's tree (`relativePath STARTS WITH 'accounts/'`, all file types, excluding the `uploads/<id>/` subtree) plus this account's IDENTITY / SOUL / KNOWLEDGE / specialist templates. Click downloads the row's backing file (`downloadPath` → `GET /api/admin/files/download`) so the operator opens it in their local app; rows whose file is outside `DATA_ROOT` (bundled-fallback templates) show a "can't be downloaded" pill. The in-app artefact pane is dead pending removal. | `sidebar-artefacts.ts`, `files.ts` |
 | System-stats widget | CPU / RAM widget at the foot of the sidebar. | `system-stats.ts` (see above) |
@@ -4094,6 +4104,44 @@ equivalent wording: the reader reply path and the `/send-admin` route.
 Consolidating them is tracked separately; do not copy their strings into
 new callers.
 
+## WhatsApp inbound notifications
+
+An inbound WhatsApp message raises a WhatsApp-green card at the **top right** of
+every admin surface within about a second of arrival. The card shows the
+sub-account it arrived on, the sender (their WhatsApp profile name, or their
+number when they have none), and the first two lines of the message, with an
+ellipsis when there was more. A media message with no caption shows its media
+type instead.
+
+The card disappears within five seconds and is **stored nowhere** — there is no
+history, no unread count, and nothing to click. It exists to tell the operator a
+message landed; the reader is where the message itself is read.
+
+**Bursts drain rather than pile up.** One card alone lasts five seconds. As more
+arrive, every card on screen speeds up: two share 2.5 seconds each, three 1.7,
+four 1.25, and five or more sit on a 1.2 second floor. A card's dwell only ever
+shortens, so it does not linger once the stack empties. There is no cap on how
+many cards can appear at once.
+
+**Four sender types, one icon each:**
+
+| Icon | Sender |
+|---|---|
+| Shield | **Admin** — the operator's own number, or a bound admin |
+| Two-way arrows | **Account manager (active)** — a manager whose messages drive an agent turn |
+| Eye | **Account manager (passive)** — a passive bind, which files work but never replies |
+| Person | **Public** — a member of the public |
+
+Cards from **every** sub-account appear regardless of which account the tab is
+currently pinned to, and each is labelled with that sub-account's name. That is
+deliberate: seeing another account's message is what tells the operator to
+switch to it.
+
+Messages that raise no card, by design: anything the operator sent, group
+messages (groups are observation-only), history catch-up during a re-sync, and
+any sender the access rules decline. A blocked or unrecognised contact is
+silent.
+
 ## Related references
 
 - [`platform.md`](platform.md) — UI layout, session reconcile model,
@@ -5402,6 +5450,8 @@ So:
 
   The share is reachable solely from the box itself. Operators reach it by forwarding loopback over SSH — `ssh -L 4445:localhost:445 admin@<tunnel-host>` and then mounting `smb://localhost:4445` — or by joining the box to a private network and re-installing, which makes the private interface the chosen LAN bind.
 
+  That second remedy applies to SMB only. The admin edge uses a different rule: it binds loopback whenever the host carries a public IPv4, whether or not a private interface exists alongside it, so joining a private network does not make the edge LAN-reachable on a cloud box.
+
 If the device has no non-loopback IPv4 interface at all, the installer refuses to provision and exits — there is nothing safe to bind to. This is distinct from the public-only case, which still provisions a working (host-local) share.
 
 This classification is the structural guarantee that SMB never leaves the box (loopback-only) or the LAN (LAN-only), even if upstream firewall rules are misconfigured. The Cloudflare tunnel that fronts the admin UI carries HTTPS only; it does not route SMB.

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

@@ -9,6 +9,18 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-28 (0.1.520)
+
+- The admin now lands on the Dashboard, with a Public pages card linking the booking site and file-drop portal.
+- The scheduling read surface now returns meetings alongside events, so a note-only meeting update explains why instead of saying not found.
+- New email tools: a signature setter to populate the deterministic signature loader, and a drafts list to confirm a draft is really there.
+
+## 2026-07-28 (0.1.519)
+
+- The admin webchat now delivers the assistant's answer as the turn's final text, and the separate reply tool has been retired for admin sessions (public visitors still get it).
+- The Edge tunnel now binds to the correct interface on hosts without a LAN, and the port is documented as private by construction with ufw as the backstop.
+- WhatsApp group messages in the reader show sender colours and avatars.
+
 ## 2026-07-28 (0.1.518)
 
 - WhatsApp sender numbers are now shown in full international form instead of a bare string of digits.

package/payload/platform/plugins/cloudflare/bin/portal-assemble.mjs

@@ -0,0 +1,187 @@
+#!/usr/bin/env node
+// portal-assemble.mjs - fill a data portal's wrangler.toml from the shared
+// house store identity and the account's own config.
+//
+// This exists because hand-filling those values is what broke a portal (Task
+// 2099). The skill used to say "fill __D1_DATABASE_NAME__, __D1_DATABASE_ID__
+// and __R2_BUCKET_NAME__, leave no placeholder", and two sessions resolving the
+// same placeholder independently chose different names: a bucket was created as
+// <acct>-portal while the config named <acct>-data-portal, and cross-account
+// list isolation meant neither session could see the other's resource. The
+// platform rule is to take the model out of a decision that has one right
+// answer, so the values now come from one file and are substituted here.
+//
+// Every refusal below is fail-closed and names what is wrong. A portal that
+// deploys with a blank binding is worse than one that does not deploy: it
+// serves, and every upload lands nowhere.
+//
+// Pure core (assembleTree) is separated from the CLI so the refusals are
+// testable without a filesystem.
+
+import { readFileSync, writeFileSync } from 'node:fs'
+import { basename, join, resolve } from 'node:path'
+
+/** The three keys the shared store is identified by, in cloudflare-house.env. */
+export const SHARED_KEYS = ['DATA_PORTAL_DB_NAME', 'DATA_PORTAL_DB_ID', 'DATA_PORTAL_BUCKET']
+
+/**
+ * Parse KEY=value lines without polluting process.env. Same discipline as
+ * readHouseCredential in lib/storage-broker, and the same file is being read.
+ * @param {string} raw
+ * @returns {Record<string,string>}
+ */
+export function parseEnvFile(raw) {
+  /** @type {Record<string,string>} */
+  const env = {}
+  for (const line of raw.split('\n')) {
+    const m = line.match(/^\s*([A-Za-z_][A-Za-z0-9_]*)=(.*)$/)
+    if (m) env[m[1]] = m[2].trim()
+  }
+  return env
+}
+
+/**
+ * Substitute every placeholder in the template wrangler.toml.
+ *
+ * @param {{
+ *   toml: string,
+ *   shared: Record<string,string>,
+ *   cfg: { accountId?: string, projectName?: string, storageModel?: string },
+ *   installOrigin: string,
+ *   expectedAccountId?: string,
+ * }} opts
+ * @returns {string} the assembled wrangler.toml
+ */
+export function assembleTree({ toml, shared, cfg, installOrigin, expectedAccountId }) {
+  // The storage model is checked FIRST, because a dedicated account is not a
+  // missing-value problem to report but a portal this template cannot serve at
+  // all: its database has no accountId column, and every query this template
+  // emits binds one. Absent means dedicated, so a pre-2099 config file that
+  // never heard of the field is refused rather than silently treated as shared.
+  const model = cfg?.storageModel ?? 'dedicated'
+  if (model !== 'shared') {
+    throw new Error(
+      `portal-assemble: account ${cfg?.accountId ?? '(unnamed)'} is on the "${model}" storage ` +
+        `model. This template targets the shared house store and binds accountId in every query, ` +
+        `which a dedicated database does not have. Pre-2099 portals stay on their own template; ` +
+        `migrating one is deliberate work, not a redeploy.`,
+    )
+  }
+
+  for (const key of SHARED_KEYS) {
+    if (!shared?.[key]) {
+      throw new Error(
+        `portal-assemble: ${key} is missing or empty in the house config. The shared store must ` +
+          `exist and be recorded before any portal can bind it; assembling without it would ` +
+          `deploy a portal whose binding points at nothing.`,
+      )
+    }
+  }
+  if (!cfg?.accountId) {
+    throw new Error('portal-assemble: accountId is missing from data-portal.json')
+  }
+  // PORTAL_ACCOUNT_ID becomes the tenant scope for every query and every object
+  // key the deployed worker issues, and it is baked in permanently at this
+  // point. The house-side loops do NOT read it: they scope by the account
+  // DIRECTORY name. So the two must be the same string, or the worker writes
+  // rows and objects under one tenant while the pull, the index push and the
+  // audit look under another. Nothing downstream would report that: the reads
+  // simply return nothing and the client's files never arrive.
+  if (expectedAccountId && cfg.accountId !== expectedAccountId) {
+    throw new Error(
+      `portal-assemble: data-portal.json says accountId "${cfg.accountId}" but the account ` +
+        `directory is "${expectedAccountId}". The house-side loops scope by the directory, so ` +
+        `baking the other value would strand every upload. Fix the config, not this check.`,
+    )
+  }
+  // The same charset the deployed worker's authorizeKey enforces on both key
+  // segments. Baking a value it will reject means every upload 403s after
+  // deploy rather than here.
+  if (!/^[a-z0-9-]+$/.test(cfg.accountId)) {
+    throw new Error(
+      `portal-assemble: accountId "${cfg.accountId}" is outside [a-z0-9-], which the portal's own ` +
+        `key gate rejects, so every upload would be denied after deploy.`,
+    )
+  }
+  if (!cfg?.projectName) {
+    throw new Error('portal-assemble: projectName is missing from data-portal.json')
+  }
+  if (!installOrigin) {
+    throw new Error('portal-assemble: install origin is required (the public host, not the admin host)')
+  }
+
+  const out = toml
+    .replaceAll('__PROJECT_NAME__', cfg.projectName)
+    .replaceAll('__D1_DATABASE_NAME__', shared.DATA_PORTAL_DB_NAME)
+    .replaceAll('__D1_DATABASE_ID__', shared.DATA_PORTAL_DB_ID)
+    .replaceAll('__R2_BUCKET_NAME__', shared.DATA_PORTAL_BUCKET)
+    .replaceAll('__PORTAL_ACCOUNT_ID__', cfg.accountId)
+    .replaceAll('__PORTAL_INSTALL_ORIGIN__', installOrigin)
+
+  // The post-condition, verified rather than assumed. A placeholder that
+  // survives substitution is a value nobody supplied, and wrangler would
+  // happily deploy the literal string.
+  const left = out.match(/__[A-Z0-9_]+__/g)
+  if (left) {
+    throw new Error(
+      `portal-assemble: placeholder(s) left unfilled: ${[...new Set(left)].join(', ')}`,
+    )
+  }
+  return out
+}
+
+/** @param {string} msg */
+function die(msg) {
+  console.error(`[portal-assemble] error: ${msg}`)
+  process.exit(1)
+}
+
+/** @param {string} flag */
+function arg(flag) {
+  const i = process.argv.indexOf(flag)
+  return i === -1 ? undefined : process.argv[i + 1]
+}
+
+// Run only as a CLI, so the pure core above stays importable by the tests.
+if (process.argv[1] && process.argv[1].endsWith('portal-assemble.mjs')) {
+  const accountDir = arg('--account-dir')
+  const platformRoot = arg('--platform-root')
+  const installOrigin = arg('--install-origin')
+  const templateToml = arg('--template')
+  if (!accountDir) die('--account-dir <dir> is required')
+  if (!platformRoot) die('--platform-root <dir> is required')
+  if (!installOrigin) die('--install-origin <https://host> is required')
+  if (!templateToml) die('--template <path to template wrangler.toml> is required')
+
+  try {
+    const shared = parseEnvFile(
+      readFileSync(join(/** @type {string} */ (platformRoot), 'config', 'cloudflare-house.env'), 'utf8'),
+    )
+    const cfg = JSON.parse(
+      readFileSync(join(/** @type {string} */ (accountDir), 'data-portal.json'), 'utf8'),
+    )
+    const toml = readFileSync(/** @type {string} */ (templateToml), 'utf8')
+    const out = assembleTree({
+      toml,
+      shared,
+      cfg,
+      installOrigin: /** @type {string} */ (installOrigin),
+      // The directory is the id every house-side loop scopes by, so it is the
+      // one the baked-in value has to match.
+      expectedAccountId: basename(resolve(/** @type {string} */ (accountDir))),
+    })
+    const dest = join(
+      /** @type {string} */ (accountDir),
+      'sites',
+      cfg.projectName,
+      'wrangler.toml',
+    )
+    writeFileSync(dest, out)
+    console.log(
+      `[portal-assemble] op=assemble account=${cfg.accountId} project=${cfg.projectName} ` +
+        `db=${shared.DATA_PORTAL_DB_NAME} bucket=${shared.DATA_PORTAL_BUCKET} result=ok dest=${dest}`,
+    )
+  } catch (err) {
+    die(/** @type {Error} */ (err).message)
+  }
+}

package/payload/platform/plugins/cloudflare/bin/portal-enrol.mjs

@@ -71,6 +71,23 @@ if (!/^[A-Za-z0-9-]+$/.test(/** @type {string} */ (accountId))) {
   die('--account must match ^[A-Za-z0-9-]+$ — an account id, not a path')
 }
 
+// Which people table this row is going into (Task 2099), because the two have
+// different keys and SQLite requires an ON CONFLICT target to match a real
+// unique index.
+//
+//   shared     PRIMARY KEY (accountId, ownerId)  the one house store
+//   dedicated  ownerId TEXT PRIMARY KEY          a pre-2099 portal's own database
+//
+// Getting this wrong cannot corrupt anything: the conflict target simply does
+// not match an index and SQLite refuses the statement outright with "ON CONFLICT
+// clause does not match any PRIMARY KEY or UNIQUE constraint". It fails at the
+// database, before any row moves, which is why a default is safe here. It
+// defaults to the go-forward model; a grandfathered portal must say so.
+const storageModel = arg('--storage-model') ?? 'shared'
+if (storageModel !== 'shared' && storageModel !== 'dedicated') {
+  die('--storage-model must be "shared" or "dedicated" (see the account\'s data-portal.json)')
+}
+
 // Optional per-person folder allowlist: comma-separated top-level names that
 // narrow what this person sees below the account's exposed set. Absent means
 // the full set. Each name is validated to the dir-segment charset, so a grant
@@ -116,12 +133,36 @@ const createdAt = new Date().toISOString()
 // `createdAt` is deliberately absent from the DO UPDATE: it records when the
 // person was enrolled, and rotating a passcode is not creating a person.
 //
-// `accountId` IS in the DO UPDATE: re-enrolling someone against a different
-// sub-account has to move them, or they keep reading folders they no longer
-// belong to. `folders` IS too, for the same reason: re-enrolment replaces the
-// grant, so a narrower or wider set on re-run takes effect rather than sticking.
+// On the shared store the conflict target is (accountId, ownerId), not ownerId
+// alone (Task 2099). That table is shared by every portal, so two clients may
+// each enrol a person of the same name: conflicting on ownerId alone would treat
+// the second client's enrolment as a rotation of the first client's person and
+// overwrite their passcode, their grant, and the ownership of their files.
+//
+// On a grandfathered database the key really is ownerId alone, and naming the
+// pair there does not degrade gracefully: SQLite refuses the whole statement,
+// which would silently take passcode rotation away from those portals. Rotation
+// is the one remedy for a leaked passcode, so it must keep working on every
+// portal, not just the new ones.
+//
+// On the shared path `accountId` is NOT in the DO UPDATE: it is half the key
+// that decides which row was matched, so it cannot also be a field the match
+// rewrites. A consequence worth stating plainly, because it used to be possible:
+// re-running enrolment with a different --account no longer MOVES a person, it
+// enrols a separate person in that other portal. `--account` is the portal's own
+// account, and a person always reads that portal's folders (Task 2104).
+//
+// The dedicated path keeps `accountId` in the DO UPDATE exactly as before, so a
+// grandfathered portal's behaviour is unchanged in every respect.
+//
+// `folders` IS in the DO UPDATE on both: re-enrolment replaces the grant, so a
+// narrower or wider set on re-run takes effect rather than sticking.
+const conflict =
+  storageModel === 'shared'
+    ? 'ON CONFLICT(accountId, ownerId) DO UPDATE SET name=excluded.name, salt=excluded.salt, hash=excluded.hash, folders=excluded.folders'
+    : 'ON CONFLICT(ownerId) DO UPDATE SET name=excluded.name, salt=excluded.salt, hash=excluded.hash, accountId=excluded.accountId, folders=excluded.folders'
 console.log(
-  `INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders) VALUES ('${ownerId}', '${sqlName}', '${saltHex}', '${hash}', '${createdAt}', '${accountId}', '${folders}') ON CONFLICT(ownerId) DO UPDATE SET name=excluded.name, salt=excluded.salt, hash=excluded.hash, accountId=excluded.accountId, folders=excluded.folders;`,
+  `INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders) VALUES ('${ownerId}', '${sqlName}', '${saltHex}', '${hash}', '${createdAt}', '${accountId}', '${folders}') ${conflict};`,
 )
 
 // stderr: everything for the human. Never stdout — see the note at the top.

package/payload/platform/plugins/cloudflare/mcp/__tests__/auth-route.test.ts

@@ -12,11 +12,16 @@ const SALT = '000102030405060708090a0b0c0d0e0f'
 const RIGHT = generatePasscode()
 const WRONG = generatePasscode()
 const IP = '203.0.113.7'
+// This portal's own account, baked into its wrangler vars at assemble time. One
+// shared store backs every portal (Task 2099), so this value is what separates
+// these rows from another client's and every query below binds it.
+const ACCOUNT = 'acct-a'
 
 async function envWith(people: Array<{ ownerId: string; passcode: string }>, attemptCount = 0) {
   const rows = await Promise.all(
     people.map(async (p) => ({
       ownerId: p.ownerId,
+      accountId: ACCOUNT,
       salt: SALT,
       hash: await hashPasscode(p.passcode, SALT),
     })),
@@ -45,7 +50,11 @@ async function envWith(people: Array<{ ownerId: string; passcode: string }>, att
           async first<T>() {
             if (/FROM auth_attempts/i.test(query)) return { count: attemptCount + 1 } as T
             if (/FROM people/i.test(query)) {
-              return (rows.find((r) => r.ownerId === bound[0]) ?? null) as T | null
+              // Keyed on the pair, because the people table is shared: bound[0]
+              // is the ownerId, bound[1] this portal's account. An ownerId-only
+              // fake would let a same-named person in another tenant answer.
+              return (rows.find((r) => r.ownerId === bound[0] && r.accountId === bound[1]) ??
+                null) as T | null
             }
             return null as T | null
           },
@@ -54,6 +63,7 @@ async function envWith(people: Array<{ ownerId: string; passcode: string }>, att
       },
     },
     BUCKET: {} as never,
+    PORTAL_ACCOUNT_ID: ACCOUNT,
   } as unknown as PortalEnv
   return { env, sessions, cleared, scopes }
 }
@@ -174,12 +184,14 @@ describe('processAuth', () => {
     expect(hashesForUnknown).toBe(hashesForKnown)
   })
 
-  it('scopes the rate limiter on owner AND ip, so one caller cannot lock out another', async () => {
+  it('scopes the rate limiter on account, owner AND ip, so one caller cannot lock out another', async () => {
     // Keyed on the owner alone the counter is a weapon: six unauthenticated
-    // requests naming a person lock that person out of their own portal.
+    // requests naming a person lock that person out of their own portal. The
+    // account leads the key because auth_attempts is shared by every portal, so
+    // without it two clients who both enrol an "alice" share one lockout.
     const { env, scopes } = await envWith([{ ownerId: 'alice', passcode: RIGHT }])
     await processAuth({ ownerId: 'alice', passcode: RIGHT }, env, () => {}, () => 's', 1_000_000, IP)
-    expect(scopes[0]).toBe(`alice|${IP}`)
+    expect(scopes[0]).toBe(`${ACCOUNT}|alice|${IP}`)
     expect(String(scopes[0])).toContain(IP)
   })
 
@@ -187,7 +199,7 @@ describe('processAuth', () => {
     const { env, cleared } = await envWith([{ ownerId: 'alice', passcode: RIGHT }])
     await processAuth({ ownerId: 'alice', passcode: RIGHT }, env, () => {}, () => 's', 1_000_000, IP)
     expect(cleared.length).toBe(1)
-    expect(cleared[0][0]).toBe(`alice|${IP}`)
+    expect(cleared[0][0]).toBe(`${ACCOUNT}|alice|${IP}`)
   })
 
   it('does not clear the counter on a failed sign-in', async () => {
@@ -203,8 +215,8 @@ describe('processAuth', () => {
     const { env, sessions } = await envWith([{ ownerId: 'alice', passcode: RIGHT }])
     await processAuth({ ownerId: 'alice', passcode: RIGHT }, env, () => {}, () => 's', 1_000_000, IP)
     const expected = (await hashPasscode(RIGHT, SALT)).slice(0, 16)
-    // bind order: sessionId, ownerId, pcCheck, expiresAt, createdAt
-    expect(sessions[0][2]).toBe(expected)
+    // bind order: sessionId, ownerId, accountId, pcCheck, expiresAt, createdAt
+    expect(sessions[0][3]).toBe(expected)
   })
 
   it('quotes the owner in log lines, so a crafted ownerId cannot forge one', async () => {