@rubytech/create-sitedesk-code 0.1.519 → 0.1.521

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-sitedesk-code",
-  "version": "0.1.519",
+  "version": "0.1.521",
   "description": "Install SiteDesk — automated back office for independent building contractors",
   "bin": {
     "create-sitedesk-code": "./dist/index.js"

package/payload/platform/docs/superpowers/plans/2026-07-28-task-2097-email-signature-set.md

@@ -0,0 +1,65 @@
+# Task 2097 — `email-signature-set` implementation plan
+
+Design: [`2026-07-28-task-2097-email-signature-set-design.md`](../specs/2026-07-28-task-2097-email-signature-set-design.md).
+
+## Registration surfaces — corrected against the tree
+
+The task file names `ADMIN_CORE_TOOLS`. It does not exist: `grep -rn 'ADMIN_CORE_TOOLS' platform/` returns
+nothing outside comments. The live surfaces, each confirmed by reading the file, are four:
+
+| # | Surface | Evidence |
+|---|---|---|
+| 1 | `plugins/email/mcp/src/index.ts` | `eagerTool(server, "email-setup", …)` at line 124 |
+| 2 | `plugins/email/PLUGIN.md` | frontmatter `description:`, `tools:` list, Capabilities, Skills table |
+| 3 | `platform/templates/specialists/agents/personal-assistant.md` | the only template matching `grep -rl email-setup platform/templates/` |
+| 4 | `services/claude-session-manager/src/canonical-tool-names.generated.ts` | header: generated from `PLUGIN.md` `tools:` blocks, `check-canonical-tool-names.mjs` fails the build on drift |
+
+Surface 4 is not in the task file and would have broken the build. It is regenerated, never hand-edited:
+`cd platform && npm run gen:canonical-tools`.
+
+Three further files match `email-draft-send` and are deliberately **not** touched:
+`plugins/admin/hooks/preference-consult-gate.sh`, `scripts/lib/provision-account-dir.sh`, and the
+`plugins/admin/PLUGIN.md` prose describing them. All three are the outbound-send preference gate,
+matching sends that carry attachments. `email-signature-set` sends nothing, so it is not a gate member.
+
+## Steps
+
+1. **`lib/signature.ts`** — add `SIGNATURE_BASENAME`, `signatureDirFor(accountId)`, and
+   `saveSignature(accountDir, parts)`. `loadSignature` / `applySignature` unchanged.
+   `signatureDirFor` is `accountDirFor(accountId) || process.env.ACCOUNT_DIR || undefined`, which is the
+   expression `compose.ts:112` already computes, with an empty-string env normalised to `undefined`
+   (both already load as no-signature, so behaviour is unchanged). No import cycle: `attachment-resolve.ts`
+   imports only `node:fs` and `node:path`.
+2. **`lib/compose.ts`** — replace the inline `sigDir` expression with `signatureDirFor(accountId)` and the
+   literal `"email-signature"` in `assetNote` with `SIGNATURE_BASENAME`. `accountDirFor` stays imported for
+   the attachment path at line 75.
+3. **`tools/email-signature-set.ts`** — refuse an all-absent call and an unresolvable directory before any
+   write, call `saveSignature`, log, return the resolved paths.
+4. **`index.ts`** — import and `eagerTool` register, placed after the `email-setup` block. Guard with
+   `refuseNoAccount`, wrap in try/catch like `email-setup`. The handler's local result variable is named
+   `message`, not `text`, so it cannot shadow the `text` parameter.
+5. **`PLUGIN.md`** — `tools:` entry (`riskClass: write_local`, both allowlists false, matching `email-setup`),
+   a Config clause in the frontmatter `description:`, a Capabilities bullet, a Skills-table row.
+6. **`personal-assistant.md`** — add `mcp__plugin_email_email__email-signature-set` after `email-setup`.
+7. **Regenerate** `canonical-tool-names.generated.ts`.
+8. **`skills/email-signature/SKILL.md`** — new skill.
+9. **`skills/email-composition/SKILL.md`** — one added rule, see below.
+10. **`__tests__/email-signature-set.test.ts`** — committed, not ephemeral: the plugin already carries 34
+    test files and the task file mandates a regression test.
+
+## Addition beyond the task file
+
+The task specifies that the new `email-signature` skill carries the rule "never hand-build a signature
+inside a draft body". That skill activates when the operator asks to set or change a signature. The
+incident happened while **drafting**, when that skill is not loaded. `grep -in signature` over
+`skills/email-composition/SKILL.md` returns zero hits, so the drafting surface currently says nothing
+about signatures.
+
+So the rule is also stated in one sentence in `email-composition`, which is the skill that is loaded while
+drafting. Without it the doctrine lives only in a skill absent at the moment it is needed. Declared in Plan
+Conformity as an addition.
+
+## Verification
+
+`npm run build` and `npx vitest run` in `plugins/email/mcp`, then `npm run gen:canonical-tools` and the
+`check-canonical-tool-names.mjs` gate in `platform/`. No browser surface, no Pi hook surface.

package/payload/platform/docs/superpowers/specs/2026-07-28-task-2097-email-signature-set-design.md

@@ -0,0 +1,155 @@
+# Task 2097 — `email-signature-set` design
+
+Date 2026-07-28. Lane *Platform / email · signature provisioning*.
+Task file: [`.tasks/pending/2097-email-signature-setter-so-the-deterministic-loader-can-be-populated.md`](../../../../.tasks/pending/2097-email-signature-setter-so-the-deterministic-loader-can-be-populated.md).
+
+## Problem
+
+`email-draft` appends an account's signature deterministically, with no model judgement, at
+[`compose.ts:113`](../../../plugins/email/mcp/src/lib/compose.ts). It calls `loadSignature(sigDir)` then
+`applySignature`, where `loadSignature` (Task 1952,
+[`signature.ts:24`](../../../plugins/email/mcp/src/lib/signature.ts)) reads three fixed-convention files at the
+account root: `email-signature.txt`, `email-signature.html`, `email-signature.font`.
+
+Nothing in the platform writes those files. Task 1952 shipped the reader with no writer, so the
+path-and-format convention lives only in code and no account can be provisioned. On the G.L. Smith
+account none of the three exist, `applied` was false, no signature was appended, and a drafting
+subagent with no file-read tool reconstructed the HTML from a memory node and pulled a stale logo
+into a client draft.
+
+The failure is not a model ignoring a rule. The deterministic path works; it had no files to read.
+
+## Outcome
+
+An account's signature is installed into the loader's exact path and format through a sanctioned,
+discoverable tool, and every subsequent draft carries it byte-for-byte with no model-authored
+signature markup.
+
+## Architecture
+
+`lib/signature.ts` becomes the single owner of the signature convention in both directions. Read and
+write cannot drift because one file defines the base path, the three extensions, and the font
+trimming for both.
+
+| Unit | Responsibility | Depends on |
+|---|---|---|
+| `lib/signature.ts` → `signatureDirFor(accountId)` | Resolve the one directory an account's signature lives in | `attachment-resolve.ts` → `accountDirFor`, `process.env.ACCOUNT_DIR` |
+| `lib/signature.ts` → `saveSignature(accountDir, parts)` | Write present parts, remove absent ones, report both | `node:fs` |
+| `lib/signature.ts` → `loadSignature` / `applySignature` | Unchanged (Task 1952) | — |
+| `tools/email-signature-set.ts` | Param refusals, call `saveSignature`, log, format the response | `lib/signature.ts` |
+| `lib/compose.ts` | Swaps its inline dir expression for `signatureDirFor` | `lib/signature.ts` |
+
+### Directory resolution
+
+`compose.ts:113` currently resolves the read directory inline as
+`accountDirFor(accountId) || process.env.ACCOUNT_DIR`. The setter must write to the identical
+directory in every environment, so that expression moves into `signatureDirFor(accountId)` and both
+sides call it. Substituting the identical expression leaves `compose.ts` behaviour unchanged; the
+point is that "which directory" now has one definition rather than two copies that can diverge.
+
+Writing to `accountDirFor(accountId)` alone was rejected: on a spawn where `PLATFORM_ROOT` is absent
+but `ACCOUNT_DIR` is set, the setter would refuse while drafts would have read the file fine.
+
+## Behaviour
+
+Parameters, all optional strings: `text`, `html`, `font`. The account is the caller's `accountId`,
+the same authority `email-draft` uses. There is no `mailbox` parameter — a signature is account-scoped,
+because `loadSignature` reads one account root and knows nothing about mailboxes.
+
+| Input | Effect on `email-signature.<ext>` |
+|---|---|
+| `text` present | `.txt` written byte-for-byte verbatim, no reflow, no re-encoding |
+| `html` present | `.html` written byte-for-byte verbatim |
+| `font` present | `.font` written trimmed, matching `loadSignature`'s trim-on-read |
+| any one absent | that file removed if it exists; absence of the file is not an error |
+| all three absent | refused, nothing on disk is touched |
+| directory unresolvable | refused, nothing on disk is touched |
+
+Absent and empty are different inputs. A parameter is absent only when it is not supplied; a supplied
+empty string is present, so it writes an empty file and counts toward the all-three-absent check. That
+follows from writing verbatim: the tool stores what it was given rather than second-guessing it. The
+consequence is that an empty `.txt` makes the next draft report `applied` true while appending
+nothing visible, which is why an empty string is a deliberate act and omission is the way to remove.
+
+The removal rule is what makes a text-only call clear a stale `.html` rather than leave it to keep
+appending. The all-three-absent refusal is what stops a mis-shaped call silently wiping a working
+signature; removal stays reachable, but only as a side effect of setting something.
+
+The response names the resolved paths written and the resolved paths removed, so the caller sees the
+account root it landed in rather than trusting it.
+
+## Failure handling
+
+Files are written in the fixed order `.txt`, `.html`, `.font`. A filesystem error surfaces verbatim
+naming the offending path and the paths already written, so a half-applied state is reported rather
+than hidden. There is no transactional rollback: the task does not ask for one, and reaching the
+partial state requires a filesystem fault mid-call.
+
+## Observability
+
+`[email-signature-set] op=write accountId=<first-8> files=<written> removed=<removed>` on every
+successful write. The task specifies the line through `files=`; `removed=` is added because the task
+mandates removal as a behaviour and mandates that provisioning be auditable, and an unlogged removal
+is not auditable.
+
+The existing `[email-draft] op=signature applied=<bool> asset=<path>` line stays the per-draft
+signal. An account that has run the setter shows `applied=true` on its next draft. That pair is the
+end-to-end evidence: a write line naming the files, then a draft line reporting them applied.
+
+## Registration
+
+`ADMIN_CORE_TOOLS` is named in the task file but does not exist — `grep -rn 'ADMIN_CORE_TOOLS\s*[:=]'`
+over `platform/` returns nothing, and the name survives only in comments. The live surfaces are:
+
+1. `mcp/src/index.ts` — `eagerTool(server, name, description, zodShape, handler)`.
+2. `PLUGIN.md` — a `tools:` entry (`riskClass: write_local`, `publicAllowlist: false`,
+   `adminAllowlist: false`, matching `email-setup`), a clause in the frontmatter `description:` prose,
+   an operator-docs bullet, and a skills-table row for the new skill.
+3. `platform/templates/specialists/agents/personal-assistant.md` — the `tools:` frontmatter grant, the
+   canonical per-tool permission surface since Task 453.
+
+`riskClass: write_local` is correct because the tool writes account-local files and sends nothing
+outbound, which is the same class `email-setup` carries.
+
+## Skill
+
+`platform/plugins/email/skills/email-signature/SKILL.md`, activated when the operator asks to set or
+change an email signature. It states the loader convention, and three standing rules:
+
+- A signature is installed only through `email-signature-set`. Hand-writing the three files is not a
+  documented path.
+- The agent never hand-builds a signature inside a draft body, because `email-draft` applies the
+  stored one automatically and a hand-built one both duplicates it and drifts from the asset.
+- The signature content is read from the operator's own source of truth and passed through verbatim.
+  Reconstructing markup from memory or from stripped graph text is what put the stale logo in a
+  client draft.
+
+Written as outcomes and constraints, not a step recipe, per `maxy-code/CLAUDE.md`.
+
+## Testing
+
+Added to the plugin's existing vitest surface at `mcp/src/__tests__/`, not substituted for it.
+
+- Round trip: set all three, `loadSignature` returns the exact values, `applySignature` reports
+  `applied` true.
+- Verbatim: text and html land byte-identical, trailing newlines and all; font lands trimmed.
+- Text-only call writes `.txt` and removes a pre-existing `.html` and `.font`, so a later draft
+  carries no stale HTML.
+- All-three-absent call is refused and leaves pre-existing files untouched.
+- Unresolvable directory is refused.
+- A draft composed after a successful set carries body and html exactly equal to `applySignature`
+  output, with no model-authored signature text.
+- `signatureDirFor` prefers `accountDirFor` and falls back to `ACCOUNT_DIR`.
+- A supplied empty string writes an empty file and does not count as absent.
+- Existing `signature.test.ts` stays green.
+
+## Out of scope
+
+- Making `applied=false` a fail-closed refusal on client-facing drafts. Operator scoped this out on
+  2026-07-28 as separate hardening; deliberately not filed.
+- The one-off G.L. Smith provisioning and the stale memory-node deletion. That is a runtime action on
+  the live install, performed through the tool this task ships.
+- Any change to `loadSignature` / `applySignature` behaviour (Task 1952). `signatureDirFor` moves an
+  expression out of `compose.ts`; neither function's behaviour changes.
+- The drafts list/verify capability, which is
+  [Task 2098](../../../../.tasks/pending/2098-email-drafts-list-verify-tool-so-draft-presence-is-confirmable.md).

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:69ee9681cbe3bd78fa8d38f916aa5979d4814681b59f3c1bd3570c613315ca7c
+content-hash: sha256:5704ae2d754fce29e10cf6bb2ee38da35a78387a0ca67134d5a105f1cd004abb
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -1294,6 +1294,8 @@ 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.
 
+The image form's **Timezone** dropdown offers only netcup's own datacentre zones (`Europe/Berlin`, `Europe/Vienna`), so an install serving any other region cannot set its real timezone here. Leave the default and correct it in step 2 with `timedatectl set-timezone <zone>`. This is not cosmetic: the scheduler and cron fire on system local time, so a UK install left on Berlin runs an hour early. **Locale** is a free choice on the same form and should be set there; the fleet uses `en_US.UTF-8`.
+
 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
@@ -3246,7 +3248,7 @@ either is a regression.
 | `/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. 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. On a `whatsapp` row the number is printed in international form (`+44 7504 472444`, `+33 7 68 24 30 67`) by `formatSenderPhone` — `normalizeE164` then libphonenumber-js `formatInternational`, gated on `isPossible` so an unresolved LID prints raw; a `telegram` senderId is a Telegram user id and a `webchat` one is `session:<id>`, so neither is regrouped. The formatting is display-only: row identity, matching, and store keys stay on the normalized digits. Because the label function is shared, a Sessions row and that conversation's reader-panel row read identically. A channel row name has two sources, in precedence order. First the shared `resolveOperatorNamesBySender` helper the WhatsApp reader also calls, which matches the sender phone against the account's admins — that names an admin WhatsApp session and every Telegram session. Second, for a `whatsapp` row only, the WhatsApp pushName from the account's on-disk message store (`storePushNamesBySender` over `readConversationSummaries`, keyed by `normalizeE164` of the counterparty phone so a `+44 7…` sender matches a `447…` store key). The store is consulted only when the resolver reports **no binding** for that sender. That is typically a public WhatsApp customer, the case this exists for — such a sender has no admin record and so can only be named by the store, and without it those rows degraded to the bare number while the reader panel named them — though an admin missing from `users.json` qualifies too. A resolver miss caused by Neo4j being unreachable deliberately does NOT qualify: that is an outage rather than an absent binding, so the row degrades to the number and still logs `reason=neo4j-down`, keeping the outage signal intact. Telegram has no message store and is never looked up. The store read is guarded: a corrupt or absent store degrades to no pushName and logs `op=store-unreadable`, never 500s the list. Both sources are the ones the reader itself uses, so the two surfaces cannot drift; a renamed or ai-titled channel row keeps its own title. The Sessions list reads the viewed account's own store only. An account-manager's thread persists under the house account rather than the sub-account it manages, so on a multi-account install viewing a sub-account that row is not named here even though the reader panel names it — the reader additionally consults the house store, filtered to manager phones bound to that sub. 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> (operator=<n> store=<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 — emitted only when **both** sources miss, so a residual shortfall means a genuinely nameless sender rather than the expected public-customer floor, and the `operator=`/`store=` split says which source is carrying the names. | `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 /` |
+| `/session-rc-spawn` | POST `{ sessionId?, name?, title?, model?, effort? }`. 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. **Naming.** `title` is the operator's name for a NEW session, typed in the naming modal that gates all four New-session controls (sidebar CTA, composer popover, zero-sessions splash, Conversations flyout); nothing is POSTed until the operator confirms it, and the modal prefills `New session: <date, time>`. `resolveSpawnPlan` trims it, it never rides the manager spawn payload, and this route writes it to the user-title store through the manager's `POST /:id/rename` **before it answers**, so the client cannot navigate ahead of the write; the response gains `titleSource: 'user' \| 'none'`. A resume carries no title. A rejected or unreachable rename leaves the spawn intact and returns `'none'`. Lifeline: `[chat-spawn] op=title spawnReqId=… sessionId=… titleLen=… source=modal\|absent outcome=applied\|rejected\|failed`, where `source=absent` on a new spawn is the standing signal that a control bypassed the modal. | `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 /` |
 
 **Admin session management moved entirely to claude's own interfaces** (claude.ai/code, claude desktop). A manager-owned per-account `claude rc --spawn same-dir` daemon registers the device as a Remote Control target there; the composer creates / resumes / stops / renames / archives / deletes sessions, with model + permission-mode applied at inception. The model lever is `account.json.adminModel` → `CLAUDE_CONFIG_DIR/settings.json "model"`, written by the daemon supervisor at boot; the reasoning-effort lever is `account.json.effort` → `settings.json "effortLevel"` (accepted values `low|medium|high|xhigh`; any other value, e.g. legacy `"auto"`, leaves the key unset so claude's own default governs), written by the same read-merge-write at boot. A third inception lever, permission mode, is added: `account.json.adminPermissionMode` → `settings.json "permissions.defaultMode"` (the 5 composer-writable modes `default|acceptEdits|plan|auto|bypassPermissions`; `dontAsk` is out of scope). Unlike model/effort (top-level keys), this lever **deep-merges** the nested `permissions.defaultMode`, owning only that key and preserving sibling `permissions` keys (allow/deny/…) — what the binary and the spawn lifeline actually read. **For admin sessions, permission mode is fixed (Bypass) and not operator-chosen, while model and effort ARE operator-chosen at launch** via the composer's `+` new-session popover — a radio model list (Opus / Sonnet / Haiku) plus a 5-stop Faster→Smarter effort slider (Low / Medium / High / Extra / Max, where `max` applies via the `--effort` argv rather than `settings.json`); the popover description lives in `.docs/admin-webchat-native-channel.md`. Absent a pick (and on every resume), the daemon-pinned defaults govern: the `/chat` composer *footer* carries no live re-seat pickers — `rc-daemon.ts` pins settings.json `model`/`effortLevel`/`permissions.defaultMode` to `claude-opus-5[1m]` / `medium` / `bypassPermissions` regardless of `account.json` (read by the rc-spawn webchat path), and `pty-spawner.ts` forces the claude.ai/code PTY `--permission-mode` to `bypassPermissions` for `role=admin`. Public sessions are fixed to `claude-sonnet-5` (the `/public-spawn` chokepoint + `buildPublicWebchatSpawnRequest`), keeping `dontAsk`. **WhatsApp admin sessions override the daemon default:** the `/rc-spawn` handler pins `claude-sonnet-5` / `--effort max` / `bypassPermissions` for a `role=admin` WhatsApp spawn (constants `WHATSAPP_ADMIN_MODEL`/`WHATSAPP_ADMIN_EFFORT` in `http-server.ts`), pushing `--model`/`--effort` on both the fresh spawn and every resume so the params hold for the session's whole life. The override is scoped to sessions *born* under it: a fresh WhatsApp admin spawn stamps its classification sidecar `model=claude-sonnet-5`, and a resume re-asserts Sonnet/max only when that stamp is present — so a WhatsApp session created before this change (sidecar `model=null`) finishes its life on the Opus/medium default. Webchat and Telegram admin sessions are unaffected; public WhatsApp inbound never spawns. The composer footer instead renders a **read-only** params row (mode · model · effort labels) plus a context-window usage figure (`pct% · ~used/~window`), all sourced from the session pointer; the full path is in `.docs/admin-webchat-native-channel.md`. The composer cannot re-seat a session, so the "no transcript" 400 on a brand-new chat is unreachable; the `/api/admin/session-reseat` + `/api/webchat/settings` routes and the dashboard re-seat form stay as off-composer surfaces. When the live session runs in `default` ("Ask permissions") mode, a tool the agent attempts that needs approval surfaces an Allow/Deny card in the composer (tool, description, argument preview); a click sends the verdict over Claude Code's channel permission relay and the tool runs or is refused — webchat is the only interactive ask surface (WhatsApp stays text-only; Telegram has no agent channel). Beyond the composer, the maxy admin UI keeps a single "New session" link (`https://claude.ai/code`, opens in a new tab) and no separate session list, viewer, controls, or model/mode picker. The daemon supervisor lives at [`platform/services/claude-session-manager/src/rc-daemon.ts`](../../../services/claude-session-manager/src/rc-daemon.ts). The `/session-defaults` route and `SpawnPreference` node were deleted with the picker. `/new-session-failure`, `/new-session-submit`, and `/claude-capabilities` are now orphaned (consumed only by the deleted NewSessionModal) — see [`.tasks/501`](../../../.tasks/) for their removal.

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.521)
+
+- Starting a new session now opens a naming modal first, and New-session controls read white on black across every brand.
+- WhatsApp conversation reader now identifies group message senders by their real JID, and a turn no longer reports a still-in-flight attachment as missing.
+- A stale pending-interactive entry no longer sends its narration to the customer; the calendar attachment diagnostic now names the flat single-part shape it used to drop.
+
+## 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).

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 () => {