@rubytech/create-sitedesk-code 0.1.519 → 0.1.520

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-sitedesk-code",
-  "version": "0.1.519",
+  "version": "0.1.520",
   "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/whats-new/SKILL.md

@@ -9,6 +9,12 @@ 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).

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