@rubytech/create-maxy-code 0.1.562 → 0.1.563

package/package.json

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

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

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:2a6a3a040c8d55a472cfc2eda9180b15e5a0ebd8e5ce49a997c4348570ffd37b
+content-hash: sha256:5b93e9b58f687c920da46bec1137f326c5c00d5f2b1d4a460a5f5248eaee0c15
 brand: maxy-code
 product-name: Maxy
 ---
@@ -294,9 +294,11 @@ The Data search panel ranks results by combining vector similarity with keyword
 
 ## Software Update and Cloudflare Setup
 
-Both flows run on the native Claude Code PTY surface in admin chat. There is no in-app upgrade modal and no Cloudflare setup form — the agent invokes the relevant Bash command directly and its stdout streams into chat verbatim.
+Cloudflare setup runs on the native Claude Code PTY surface in admin chat: there is no Cloudflare setup form, the agent invokes the relevant Bash command directly and its stdout streams into chat verbatim.
 
-- **Software update.** Re-run the installer (`npx -y @rubytech/create-<brand>@latest`) from a shell; HeaderMenu's version row turns sage when `installed === latest`.
+Software update has two doors. The PTY one is the same shape: the agent runs the installer via Bash and its stdout streams into chat. The dashboard one is a modal over the edge-hosted `/api/admin/actions` routes, which run the installer as a `systemd-run` transient unit and stream its log back by byte offset. Both re-run the same installer; neither mutates state directly.
+
+- **Software update.** Re-run the installer (`npx -y @rubytech/create-<brand>@latest`), from a shell, from admin chat via the `upgrade` skill, or from the dashboard control in the sidebar brand head. The brand head shows the installed version at all times and grows a download icon only while `updateAvailable` is true.
 - **Cloudflare setup.** Operator asks in chat; the agent invokes `cloudflared` directly via the Bash tool, following the numbered steps in `plugins/cloudflare/references/manual-setup.md`. cloudflared's stdout and stderr stream into the PTY; the OAuth URL printed by `cloudflared tunnel login` is linkified by the terminal so the operator clicks it and authorises Cloudflare in their own browser.
 
 **Mid-turn stream-drop banners.** If a chat turn ends abruptly the bubble shows one of two messages depending on what actually happened. You see "Server is restarting — reconnect will happen automatically." only when the app server itself emits the restart signal — typically during a Software Update or a Cloudflare setup that re-launches the brand service. You see "Lost connection — retrying." when your browser's connection to the Pi dropped mid-stream while the server was still up — typically a flaky Wi-Fi moment or the tunnel hiccupping. Either way the chat resumes once the connection is back; the previously-rendered messages stay on screen so you don't lose context.
@@ -6110,11 +6112,11 @@ The logs will show which service failed to start and why. Common causes:
 Each installed brand runs two per-brand `--user` systemd units (earlier platform fixes + — unit filenames are prefixed with the brand's `hostname` so two brands on the same device never share a unit file):
 
 - `{hostname}.service` — the admin + public HTTP server on `127.0.0.1:19201` (public port + 1). Restarted by the upgrade flow; short downtime is expected during steps 8→11 of an upgrade. An earlier fix: the unit carries two port env vars — `PORT=<public>` (canonical public port, read by the upgrade detector) and `MAXY_UI_INTERNAL_PORT=<public+1>` (the port maxy-ui actually binds).
-- `{hostname}-edge.service` — the always-on public listener on the configured port (default 19200). Reverse-proxies HTTP to the main brand service and handles `/websockify` (VNC) WebSocket upgrades locally. An earlier fix: also hosts `/api/admin/actions/*` and `/api/admin/version*` — the Software Update modal's own routes — so the log stream survives the brand service's restart window. Does NOT restart during an upgrade — the browser WebSocket stays connected by construction. The operator views the device's Chromium in the admin UI via the standalone `/browser` page (peer to `/graph` and `/data`) and on the Claude sign-in screen; both render CDP screencast frames over `/cdp-screencast`, not the framebuffer. Virtual-mode Chromium is headless, so nothing renders onto the X display and the `/websockify` upgrade has no remaining consumer; deleting that stack is separate work.
+- `{hostname}-edge.service` — the always-on public listener on the configured port (default 19200). Reverse-proxies HTTP to the main brand service and handles `/websockify` (VNC) WebSocket upgrades locally. An earlier fix: also hosts `/api/admin/actions/*` and `/api/admin/version*` — the Software Update modal's own routes — so they survive the brand service's restart window. It is restarted by the upgrade flow too (`packages/create-maxy-code/src/index.ts:5143`, after the brand service is stopped and before it is restarted), so the update stream drops near the end of every run and resumes by byte offset. It is not a connection that survives; the log file is what survives, and the browser's `EventSource` replays `Last-Event-ID` to pick the tail back up. The operator views the device's Chromium in the admin UI via the standalone `/browser` page (peer to `/graph` and `/data`) and on the Claude sign-in screen; both render CDP screencast frames over `/cdp-screencast`, not the framebuffer. Virtual-mode Chromium is headless, so nothing renders onto the X display and the `/websockify` upgrade has no remaining consumer; deleting that stack is separate work.
 
-Upgrade and Cloudflare setup run as detached actions: `systemd-run --user` transient units per invocation with stdout+stderr persisted to `~/.maxy/logs/actions/<actionId>.log` and streamed to the UI via SSE. No boot-time service file exists for these.
+The upgrade runs as a detached action: a `systemd-run --user --unit=maxy-action-<actionId> --collect` transient unit per invocation, with stdout+stderr persisted to `~/.<brand>/logs/actions/<actionId>.log` and streamed to the UI via SSE. The unit has its own cgroup, so it outlives both service restarts the installer performs. Its final log line is `[action-exit] code=<n>`, written by the wrapper, which is how the exit code survives a unit that `--collect` has already reaped. A sidecar `~/.<brand>/logs/actions/<actionId>.json` holds the package, start time and pre-upgrade version, so a modal reopened after a reload can still report what changed. No boot-time service file exists for these. Cloudflare setup is not an action; it runs PTY-native from admin chat.
 
-If an action looks stuck, read `~/.maxy/logs/actions/<actionId>.log` directly for the full output, or `journalctl --user --identifier=maxy-action-<actionId>` for systemd's record.
+If an action looks stuck, read `~/.<brand>/logs/actions/<actionId>.log` directly for the full output, or `journalctl --user --identifier=maxy-action-<actionId>` for systemd's record. The lifecycle lines are tagged `[admin-action]` and keyed by `actionId`; they land in `~/.<brand>/logs/edge.log`, not `server.log`, because these routes run on the edge process.
 
 ## Linux laptops: snap-confined Chromium replacement
 
@@ -6223,17 +6225,23 @@ Empty output from step 3 = brand.json resolved cleanly and the badge reflects th
 
 ## Upgrading
 
-To upgrade Maxy to the latest version, ask Maxy: "Upgrade Maxy." The platform checks the current device identity (hostname and port via `system-status`), then re-runs the installer with explicit `--hostname` and `--port` flags to preserve them across the upgrade.
+There are two ways to upgrade, and both run the same installer.
+
+From the dashboard, press the download icon in the sidebar header (see below). From chat, ask Maxy: "Upgrade Maxy." The platform checks the current device identity (hostname and port via `system-status`), then re-runs the installer with explicit `--hostname` and `--port` flags to preserve them across the upgrade.
 
 The docs plugin (this plugin) is upgraded in the same step — you always have the documentation that matches your installed version.
 
-### Automatic upgrade alert
+### Upgrading from the dashboard
+
+The sidebar header shows the version you are running, under the product name, at all times. When a newer one is published a download icon appears beside it. There is no icon when you are already up to date, so the icon appearing is itself the news. If you work with the sidebar collapsed to the narrow rail, the version and the icon are hidden with the rest of the header text and a small coloured dot on the brand icon carries the same signal.
+
+Pressing the icon opens the Software Update window, which shows the version you have against the version available and an Update button. Pressing Update runs the installer and streams its output into the window as it happens.
 
-Maxy checks for new releases on every admin session start — whenever you log in, reload the page, or return to the admin chat. When a newer version is available, the Software Update window opens automatically showing your current and the latest version, with a one-click Upgrade button. Dismissing the window (click outside or the close button) defers the alert until your next login or reload; no alert is shown when you are already on the latest version.
+Closing the window does not cancel the upgrade. The installer runs in its own background unit, so it keeps going whether or not anything is watching, and reopening the window reattaches to the run in progress.
 
-The upgrade runs inside a live terminal embedded in the Software Update window — you see each installation step stream as it happens, and any password prompts from `sudo` appear directly in the terminal for you to answer. Closing the window does not cancel the upgrade; re-opening it reattaches to the same shell so you can see what happened while disconnected.
+**The connection drops near the end of every upgrade, and that is expected.** The installer restarts the server as its last step, which cuts the browser's connection to it. The window says "Reconnecting" while that happens, then picks the output back up from exactly where it left off. Nothing is lost and nothing needs restarting. When it finishes, the window reports the exit code and whether the version actually moved.
 
-The header menu's version indicator still reflects real-time status: a green dot means you are up to date, and an accent-coloured dot means an upgrade is available. Opening the menu refreshes the version check, so a long-lived session can still surface an upgrade that became available after login without reloading the page.
+The window reports a genuine failure in two shapes worth knowing. If the installer exits non-zero it says so with the code. If it exits cleanly but the version did not change, it says that too, rather than claiming success.
 
 ---
 # Samba Share

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-08-05 (0.1.563)
+
+- You can now update from the dashboard. The installed version sits in the sidebar header rather than buried in the footer menu, and when a newer one is available the control there starts the update and shows its progress live. Previously the only route was asking the assistant in chat, and an available update was invisible until you opened the menu.
+- A public bot no longer loses the first message it is sent. A message that arrived while the conversation was still starting up was handed over a moment too early and discarded silently; delivery now waits until the conversation is ready to receive it.
+- The data portal can now hold records, not just files. A portal login can be scoped to see only the records assigned to that person rather than everything for the account, work assigned in the office appears on the portal, and what is filled in on site comes back. A standing check reports any exchange that stalls.
+
 ## 2026-08-05 (0.1.562)
 
 - A public agent no longer sees anything about you or your machine. A stranger messaging a public bot was having your connected mailbox list, this machine's name and network addresses, its admin and tunnel web addresses, today's date and your working preferences added to every turn, alongside the persona you wrote. A public turn now carries only what the agent's author wrote plus its single reply tool.

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

@@ -108,6 +108,17 @@ if (foldersArg !== undefined) {
   folders = [...new Set(names)].join(',')
 }
 
+// Which RECORDS this person reads, as distinct from --folders, which is which
+// files they browse. Two values and no third.
+//
+// The absent flag is the NARROW one. Nobody is granted account-wide visibility
+// by leaving a flag off, and a typo is refused rather than resolved to
+// whichever value happens to be nearer — there is no third scope for it to be.
+const recordScope = arg('--record-scope') ?? 'own'
+if (recordScope !== 'own' && recordScope !== 'account') {
+  die('--record-scope must be "own" or "account" — there is no third scope')
+}
+
 const saltBytes = new Uint8Array(16)
 crypto.getRandomValues(saltBytes)
 const saltHex = randomSaltHex(saltBytes)
@@ -155,14 +166,17 @@ const createdAt = new Date().toISOString()
 // 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.
+// `folders` and `recordScope` are BOTH in the DO UPDATE on both models:
+// re-enrolment replaces each, so a narrower or wider setting on a re-run takes
+// effect rather than sticking. Narrowing matters most — a person moved off the
+// account-wide scope must actually lose it, and the re-run is the only path
+// there is.
 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'
+    ? 'ON CONFLICT(accountId, ownerId) DO UPDATE SET name=excluded.name, salt=excluded.salt, hash=excluded.hash, folders=excluded.folders, recordScope=excluded.recordScope'
+    : 'ON CONFLICT(ownerId) DO UPDATE SET name=excluded.name, salt=excluded.salt, hash=excluded.hash, accountId=excluded.accountId, folders=excluded.folders, recordScope=excluded.recordScope'
 console.log(
-  `INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders) VALUES ('${ownerId}', '${sqlName}', '${saltHex}', '${hash}', '${createdAt}', '${accountId}', '${folders}') ${conflict};`,
+  `INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders, recordScope) VALUES ('${ownerId}', '${sqlName}', '${saltHex}', '${hash}', '${createdAt}', '${accountId}', '${folders}', '${recordScope}') ${conflict};`,
 )
 
 // stderr: everything for the human. Never stdout — see the note at the top.

package/payload/platform/plugins/cloudflare/mcp/__tests__/authorize.test.ts

@@ -102,6 +102,9 @@ describe('sessions', () => {
       ownerId: 'alice',
       accountId: ACC,
       folders: [],
+      // The fake's people row carries no recordScope, which is a legacy row.
+      // It resolves narrow, not wide (Task 2425).
+      recordScope: 'own',
     })
   })
 
@@ -186,6 +189,9 @@ describe('session revocation — the property the design claims', () => {
       ownerId: 'alice',
       accountId: ACC,
       folders: [],
+      // The fake's people row carries no recordScope, which is a legacy row.
+      // It resolves narrow, not wide (Task 2425).
+      recordScope: 'own',
     })
 
     peopleRows[0].hash = 'HASH-v2-rotated0' // operator re-runs enrolment

package/payload/platform/plugins/cloudflare/mcp/__tests__/portal-enrol.test.ts

@@ -32,7 +32,7 @@ function parse(r: { stdout: string; stderr: string }) {
 }
 
 const valuesOf = (sql: string) =>
-  /VALUES \('([^']*)', '((?:[^']|'')*)', '([0-9a-f]+)', '([0-9a-f]+)', '([^']*)', '([^']*)', '([^']*)'\)/.exec(
+  /VALUES \('([^']*)', '((?:[^']|'')*)', '([0-9a-f]+)', '([0-9a-f]+)', '([^']*)', '([^']*)', '([^']*)', '([^']*)'\)/.exec(
     sql,
   )!
 
@@ -129,9 +129,9 @@ describe('portal-enrol', () => {
     const r = await enrol(['--owner', 'alice', '--name', 'Alice'])
     const { sql } = parse(r)
     expect(sql).toContain(
-      'INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders)',
+      'INSERT INTO people (ownerId, name, salt, hash, createdAt, accountId, folders, recordScope)',
     )
-    const [, owner, name, salt, hash, createdAt, accountId, folders] = valuesOf(sql!)
+    const [, owner, name, salt, hash, createdAt, accountId, folders, recordScope] = valuesOf(sql!)
     expect(owner).toBe('alice')
     expect(name).toBe('Alice')
     expect(salt).toMatch(/^[0-9a-f]{32}$/)
@@ -139,6 +139,57 @@ describe('portal-enrol', () => {
     expect(Number.isNaN(Date.parse(createdAt))).toBe(false)
     expect(accountId).toBe('acc-1')
     expect(folders).toBe('')
+    expect(recordScope).toBe('own')
+  })
+
+  describe('record scope (Task 2425)', () => {
+    it('defaults to own when the flag is absent', async () => {
+      const { sql } = parse(await enrol(['--owner', 'alice', '--name', 'Alice']))
+      expect(valuesOf(sql!)[8]).toBe('own')
+    })
+
+    it('writes account when asked for it', async () => {
+      const { sql } = parse(
+        await enrol(['--owner', 'marie', '--name', 'Marie', '--record-scope', 'account']),
+      )
+      expect(valuesOf(sql!)[8]).toBe('account')
+    })
+
+    it('dies on a third value, before any SQL reaches stdout', async () => {
+      // There is no third scope. A typo must not silently land as one of the
+      // two, and it must not land at all: stdout is empty, so the documented
+      // pipe carries nothing into wrangler.
+      await expect(
+        enrol(['--owner', 'alice', '--name', 'Alice', '--record-scope', 'admin']),
+      ).rejects.toMatchObject({ stdout: '' })
+    })
+
+    it('replaces the scope on re-enrolment, on both storage models', async () => {
+      const shared = parse(
+        await enrol(['--owner', 'a', '--name', 'A', '--record-scope', 'account']),
+      )
+      expect(shared.sql).toContain('recordScope=excluded.recordScope')
+      const dedicated = parse(
+        await enrol(['--owner', 'a', '--name', 'A', '--storage-model', 'dedicated']),
+      )
+      expect(dedicated.sql).toContain('recordScope=excluded.recordScope')
+    })
+
+    it('lands in a real database and the re-run narrows it back', async () => {
+      // Against the template's own schema.sql, not a fake: a fake would model
+      // the very constraint we are proving we satisfy, which is how 1689
+      // shipped a UNIQUE-violating upload.
+      const db = await d1('portal-record-scope-')
+      const wide = parse(
+        await enrol(['--owner', 'alice', '--name', 'Alice', '--record-scope', 'account']),
+      )
+      await db.exec(wide.sql!)
+      expect(await db.query("SELECT recordScope FROM people WHERE ownerId='alice'")).toBe('account')
+
+      const narrow = parse(await enrol(['--owner', 'alice', '--name', 'Alice']))
+      await db.exec(narrow.sql!)
+      expect(await db.query("SELECT recordScope FROM people WHERE ownerId='alice'")).toBe('own')
+    })
   })
 
   it('refuses enrolment with no --account', async () => {
@@ -175,8 +226,14 @@ describe('portal-enrol', () => {
   })
 
   describe('the conflict target follows the storage model (Task 2099)', () => {
-    /** A pre-2099 portal's own database: `people` keyed on ownerId alone. */
-    async function legacyDb(dir: string) {
+    /** A pre-2099 portal's own database: `people` keyed on ownerId alone.
+     *
+     *  `withRecordScope` is the hand `ALTER` schema.sql tells an operator to run
+     *  on a table that predates the column (Task 2425). Both shapes are real and
+     *  the tests below need each: without it, enrolment must fail loudly, which
+     *  is what the schema comment claims; with it, rotation must keep working,
+     *  which is what the composite-target regression is about. */
+    async function legacyDb(dir: string, withRecordScope = true) {
       const { mkdtemp } = await import('node:fs/promises')
       const { tmpdir } = await import('node:os')
       const root = await mkdtemp(resolve(tmpdir(), dir))
@@ -185,7 +242,10 @@ describe('portal-enrol', () => {
         db,
         'CREATE TABLE people (ownerId TEXT PRIMARY KEY, name TEXT NOT NULL, salt TEXT NOT NULL, ' +
           "hash TEXT NOT NULL, createdAt TEXT NOT NULL, accountId TEXT NOT NULL DEFAULT '', " +
-          "folders TEXT NOT NULL DEFAULT '');",
+          "folders TEXT NOT NULL DEFAULT '');" +
+          (withRecordScope
+            ? " ALTER TABLE people ADD COLUMN recordScope TEXT NOT NULL DEFAULT 'own';"
+            : ''),
       ])
       return {
         exec: (sql: string) => run('sqlite3', [db, sql]),
@@ -193,6 +253,17 @@ describe('portal-enrol', () => {
       }
     }
 
+    it('fails loudly on a table that never got the recordScope column', async () => {
+      // schema.sql claims enrolment's INSERT names the column, so a table
+      // predating it fails loudly rather than writing a row with no scope. A
+      // property a comment asserts has to be a property the code has.
+      const db = await legacyDb('enrol-legacy-noscope-', false)
+      const r = parse(
+        await enrol(['--owner', 'dale', '--name', 'Dale', '--account', 'acct-a', '--storage-model', 'dedicated']),
+      )
+      await expect(db.exec(r.sql!)).rejects.toThrow(/no column named recordScope/)
+    })
+
     it('lets two tenants each enrol the same person on the shared store', async () => {
       const db = await d1('enrol-two-tenants-')
       await db.exec(parse(await enrol(['--owner', 'rob', '--name', 'Rob', '--account', 'acct-a'])).sql!)

package/payload/platform/plugins/cloudflare/mcp/__tests__/portal-session-grant.test.ts

@@ -72,6 +72,45 @@ describe('resolveSession folders', () => {
   })
 })
 
+describe('resolveSession recordScope', () => {
+  const row = (recordScope?: unknown) => ({
+    ownerId: 'alice',
+    accountId: 'acc-a',
+    folders: '',
+    ...(recordScope === undefined ? {} : { recordScope }),
+  })
+
+  it('returns account for a person who holds it', async () => {
+    const s = await resolveSession(db(row('account')), 'sess', 'acc-a', 1)
+    expect(s?.recordScope).toBe('account')
+  })
+
+  it('returns own for a person who holds it', async () => {
+    const s = await resolveSession(db(row('own')), 'sess', 'acc-a', 1)
+    expect(s?.recordScope).toBe('own')
+  })
+
+  // Every unreadable reading is the NARROW one. Only the exact token widens.
+  // Reverting the fallback to 'account' must turn all four of these red — a
+  // read failure that grants account-wide visibility is the one outcome this
+  // column exists to prevent.
+  it('falls back to own for an empty string', async () => {
+    expect((await resolveSession(db(row('')), 'sess', 'acc-a', 1))?.recordScope).toBe('own')
+  })
+
+  it('falls back to own for an unknown token', async () => {
+    expect((await resolveSession(db(row('admin')), 'sess', 'acc-a', 1))?.recordScope).toBe('own')
+  })
+
+  it('falls back to own for a null value', async () => {
+    expect((await resolveSession(db(row(null)), 'sess', 'acc-a', 1))?.recordScope).toBe('own')
+  })
+
+  it('falls back to own for a legacy row with no column at all', async () => {
+    expect((await resolveSession(db(row()), 'sess', 'acc-a', 1))?.recordScope).toBe('own')
+  })
+})
+
 describe('grantAllows', () => {
   it('admits everything when the grant is empty', () => {
     expect(grantAllows([], 'documents/secret.pdf')).toBe(true)

package/payload/platform/plugins/cloudflare/mcp/__tests__/portal-visit-status-write.test.ts

@@ -0,0 +1,176 @@
+import { describe, it, expect } from 'vitest'
+import {
+  MAX_STATUS_LENGTH,
+  processVisitStatus,
+} from '../../skills/data-portal/template/functions/api/visit-status'
+import type {
+  D1Database,
+  PortalEnv,
+} from '../../skills/data-portal/template/functions/api/_lib/types'
+
+interface Row {
+  accountId: string
+  ownerId: string
+  visitId: string
+}
+
+/**
+ * A fake that HONOURS the INSERT ... SELECT, because the gate IS the SELECT.
+ *
+ * It applies the same account and owner filters the statement names and reports
+ * `meta.changes` as the number of rows the SELECT admitted. A fake that always
+ * reported one change would pass a handler with no gate at all.
+ */
+function db(rows: Row[], person: { ownerId: string; recordScope: string; accountId: string }) {
+  const inserted: unknown[][] = []
+  const database = {
+    prepare(sql: string) {
+      let bound: unknown[] = []
+      const stmt = {
+        bind(...v: unknown[]) {
+          bound = v
+          return stmt
+        },
+        async first<T>() {
+          return person as unknown as T
+        },
+        async run() {
+          if (!sql.startsWith('INSERT INTO visit_status')) return { meta: { changes: 0 } }
+          // Bind order matches the statement: the SELECT's literals first, then
+          // the WHERE's account, the optional owner, and the visitId last.
+          const acct = bound[0] as string
+          const visitId = bound[bound.length - 1] as string
+          const owner = bound[1] as string
+          let admitted = rows.filter((r) => r.accountId === acct && r.visitId === visitId)
+          if (sql.includes('AND v.ownerId = ?')) admitted = admitted.filter((r) => r.ownerId === owner)
+          if (admitted.length) inserted.push(bound)
+          return { meta: { changes: admitted.length } }
+        },
+        async all<T>() {
+          return { results: [] as T[] }
+        },
+      }
+      return stmt
+    },
+  }
+  return { database: database as unknown as D1Database, inserted }
+}
+
+const env = (d: D1Database): PortalEnv =>
+  ({ DB: d, BUCKET: {}, PORTAL_ACCOUNT_ID: 'acc-a' }) as unknown as PortalEnv
+
+const ROWS: Row[] = [
+  { accountId: 'acc-a', ownerId: 'alice', visitId: 'v1' },
+  { accountId: 'acc-a', ownerId: 'bob', visitId: 'v2' },
+  { accountId: 'acc-a', ownerId: '', visitId: 'v3' },
+  { accountId: 'acc-b', ownerId: 'alice', visitId: 'v4' },
+]
+
+const person = (ownerId: string, recordScope: string) => ({
+  ownerId,
+  recordScope,
+  accountId: 'acc-a',
+})
+
+const body = (visitId: string, status = 'on-site') => ({ visitId, status })
+
+describe('the visit-status write gate', () => {
+  it('accepts an own-scoped person setting status on their own visit', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(body('v1'), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(200)
+    expect(inserted).toHaveLength(1)
+  })
+
+  it('refuses an own-scoped person setting status on someone else visit', async () => {
+    // A read leak shows someone a day that is not theirs. A write leak lets
+    // them change it, which is why the gate is the same one and is structural.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(body('v2'), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(404)
+    expect(inserted).toEqual([])
+  })
+
+  it('refuses an own-scoped person setting status on an unbound visit', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(body('v3'), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(404)
+    expect(inserted).toEqual([])
+  })
+
+  it('lets an account-scoped person set status on any visit for the account', async () => {
+    const { database, inserted } = db(ROWS, person('marie', 'account'))
+    const h = await processVisitStatus(body('v2'), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(200)
+    expect(inserted).toHaveLength(1)
+  })
+
+  it('refuses another account visit even at account scope', async () => {
+    const { database, inserted } = db(ROWS, person('marie', 'account'))
+    const h = await processVisitStatus(body('v4'), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(404)
+    expect(inserted).toEqual([])
+  })
+
+  it('denies when the session does not resolve', async () => {
+    const d = {
+      prepare: () => ({ bind: () => ({ first: async () => null }) }),
+    } as unknown as D1Database
+    const h = await processVisitStatus(body('v1'), '', env(d), () => {}, 1)
+    expect(h.status).toBe(401)
+  })
+
+  it('refuses a body with no visitId or no status', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const e = env(database)
+    expect((await processVisitStatus({ status: 'x' }, 'sess', e, () => {}, 1)).status).toBe(400)
+    expect((await processVisitStatus({ visitId: 'v1' }, 'sess', e, () => {}, 1)).status).toBe(400)
+    expect((await processVisitStatus(null, 'sess', e, () => {}, 1)).status).toBe(400)
+    expect(inserted).toEqual([])
+  })
+
+  it('refuses a status longer than the cap, rather than writing it into the graph', async () => {
+    // The value reaches :Visit.status through the pull. An unbounded free-text
+    // field written from the open web is refused at the door, not truncated:
+    // a truncated status is a different status, silently.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      body('v1', 'x'.repeat(MAX_STATUS_LENGTH + 1)),
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(400)
+    expect(inserted).toEqual([])
+  })
+
+  it('stamps the setter own id, never one the request supplies', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    await processVisitStatus(
+      { visitId: 'v1', status: 'on-site', ownerId: 'bob' },
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(inserted[0]).toContain('alice')
+    expect(inserted[0]).not.toContain('bob')
+  })
+
+  it('logs the scope and the outcome, and no status text', async () => {
+    const lines: string[] = []
+    const { database } = db(ROWS, person('alice', 'own'))
+    await processVisitStatus(
+      body('v1', 'on-site-at-granary-court'),
+      'sess',
+      env(database),
+      (l) => lines.push(l),
+      1,
+    )
+    const joined = lines.join('\n')
+    expect(joined).toContain('scope=own')
+    expect(joined).toContain('result=ok')
+    expect(joined).not.toContain('granary')
+  })
+})

package/payload/platform/plugins/cloudflare/mcp/__tests__/portal-visits-scope.test.ts

@@ -0,0 +1,112 @@
+import { describe, it, expect } from 'vitest'
+import { processVisits } from '../../skills/data-portal/template/functions/api/visits'
+import type {
+  D1Database,
+  PortalEnv,
+} from '../../skills/data-portal/template/functions/api/_lib/types'
+
+interface Row {
+  accountId: string
+  ownerId: string
+  visitId: string
+}
+
+/**
+ * A fake that HONOURS the SQL it is handed rather than replaying a fixture.
+ *
+ * It reads the WHERE clause and the bound values and filters accordingly, so
+ * deleting the scope branch in the endpoint changes what comes back. A fake
+ * that replayed rows would pass whatever the gate did, which is the same defect
+ * shape as 1689's upload fake accepting duplicates the schema rejected.
+ */
+function db(rows: Row[], person: { ownerId: string; recordScope: string; accountId: string }) {
+  return {
+    prepare(sql: string) {
+      let bound: unknown[] = []
+      const stmt = {
+        bind(...v: unknown[]) {
+          bound = v
+          return stmt
+        },
+        async first<T>() {
+          return person as unknown as T
+        },
+        async run() {
+          return { meta: { changes: 0 } }
+        },
+        async all<T>() {
+          if (!sql.includes('FROM visits')) return { results: [] as T[] }
+          const [acct, owner] = bound as string[]
+          let out = rows.filter((r) => r.accountId === acct)
+          if (sql.includes('v.ownerId = ?')) out = out.filter((r) => r.ownerId === owner)
+          return { results: out as unknown as T[] }
+        },
+      }
+      return stmt
+    },
+  } as unknown as D1Database
+}
+
+const env = (d: D1Database): PortalEnv =>
+  ({ DB: d, BUCKET: {}, PORTAL_ACCOUNT_ID: 'acc-a' }) as unknown as PortalEnv
+
+const ROWS: Row[] = [
+  { accountId: 'acc-a', ownerId: 'alice', visitId: 'v1' },
+  { accountId: 'acc-a', ownerId: 'bob', visitId: 'v2' },
+  { accountId: 'acc-a', ownerId: '', visitId: 'v3' },
+  { accountId: 'acc-b', ownerId: 'alice', visitId: 'v4' },
+]
+
+const ids = (h: { payload: Record<string, unknown> }) =>
+  (h.payload.visits as Row[]).map((v) => v.visitId).sort()
+
+const asPerson = (ownerId: string, recordScope: string) => ({
+  ownerId,
+  recordScope,
+  accountId: 'acc-a',
+})
+
+describe('the visits scope gate', () => {
+  it('shows an own-scoped person only their own visits', async () => {
+    const h = await processVisits('sess', env(db(ROWS, asPerson('alice', 'own'))), () => {}, 1)
+    expect(ids(h)).toEqual(['v1'])
+  })
+
+  it('shows an account-scoped person every visit for the account', async () => {
+    const h = await processVisits('sess', env(db(ROWS, asPerson('marie', 'account'))), () => {}, 1)
+    expect(ids(h)).toEqual(['v1', 'v2', 'v3'])
+  })
+
+  it('never returns another account rows, at either scope', async () => {
+    // The tenant filter is the baked-in var, not the session, and it is applied
+    // whichever scope the person holds. `v4` belongs to acc-b.
+    const own = await processVisits('sess', env(db(ROWS, asPerson('alice', 'own'))), () => {}, 1)
+    const acct = await processVisits('sess', env(db(ROWS, asPerson('marie', 'account'))), () => {}, 1)
+    expect(ids(own)).not.toContain('v4')
+    expect(ids(acct)).not.toContain('v4')
+  })
+
+  it('hides an unbound visit from an own-scoped person', async () => {
+    // An unbound visit carries ownerId ''. Enrolment pins ownerId to
+    // ^[a-z0-9-]+$ (portal-enrol.mjs), so no enrolled person's id is ever '',
+    // and the own-scoped filter cannot match the unbound sentinel.
+    const h = await processVisits('sess', env(db(ROWS, asPerson('alice', 'own'))), () => {}, 1)
+    expect(ids(h)).not.toContain('v3')
+  })
+
+  it('denies when the session does not resolve', async () => {
+    const d = {
+      prepare: () => ({ bind: () => ({ first: async () => null }) }),
+    } as unknown as D1Database
+    const h = await processVisits('', env(d), () => {}, 1)
+    expect(h.status).toBe(401)
+    expect(h.payload).toEqual({ ok: false, error: 'denied' })
+  })
+
+  it('logs the scope it applied, and no visit detail', async () => {
+    const lines: string[] = []
+    await processVisits('sess', env(db(ROWS, asPerson('alice', 'own'))), (l) => lines.push(l), 1)
+    expect(lines.join('\n')).toContain('scope=own')
+    expect(lines.join('\n')).toContain('visits=1')
+  })
+})