@rubytech/create-maxy-code 0.1.576 → 0.1.578

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

@@ -9,8 +9,20 @@ interface Row {
   accountId: string
   ownerId: string
   visitId: string
+  /** The Task 2511 record counts, when a fixture wants to prove they travel. */
+  notes?: number
+  media?: number
+  parts?: number
+  checklistDone?: number
+  checklistTotal?: number
+  signatures?: number
 }
 
+/** Every statement the endpoint prepared, so a test can assert on the column
+ *  list rather than only on what a fixture happened to carry. A fake that only
+ *  replays rows cannot tell a SELECT naming six columns from one naming none. */
+const prepared: string[] = []
+
 /**
  * A fake that HONOURS the SQL it is handed rather than replaying a fixture.
  *
@@ -30,18 +42,32 @@ interface RosterFixture {
 interface MetaFixture {
   vocabulary: string
   statuses: string
+  transitions: string
   zone: string
   publishedAt: string
 }
 
+/** One published candidate row (Task 2511). `conflicts` is the JSON column. */
+interface CandidateFixture {
+  accountId: string
+  visitId: string
+  workerId: string
+  name: string
+  kind: string
+  reason: string
+  conflicts: string
+}
+
 function db(
   rows: Row[],
   person: { ownerId: string; recordScope: string; accountId: string },
   roster: RosterFixture[] = [],
   meta: MetaFixture | null = null,
+  candidates: CandidateFixture[] = [],
 ) {
   return {
     prepare(sql: string) {
+      prepared.push(sql)
       let bound: unknown[] = []
       const stmt = {
         bind(...v: unknown[]) {
@@ -58,6 +84,23 @@ function db(
           return { meta: { changes: 0 } }
         },
         async all<T>() {
+          // visit_candidates FIRST: its statement also names `visits` in a JOIN,
+          // so testing for that table first would answer the candidate read with
+          // visit rows and the scope assertion below would pass on nothing.
+          if (sql.includes('FROM visit_candidates')) {
+            const [acct, owner] = bound as string[]
+            let out = candidates.filter((c) => c.accountId === acct)
+            if (sql.includes('v.ownerId = ?')) {
+              // The endpoint scopes candidates THROUGH the visits join, so the
+              // fake resolves the same way: a candidate is visible when its
+              // visit is.
+              const mine = new Set(
+                rows.filter((r) => r.accountId === acct && r.ownerId === owner).map((r) => r.visitId),
+              )
+              out = out.filter((c) => mine.has(c.visitId))
+            }
+            return { results: out as unknown as T[] }
+          }
           if (sql.includes('FROM visit_roster')) {
             const [acct, owner] = bound as string[]
             let out = roster.filter((r) => r.accountId === acct)
@@ -161,10 +204,43 @@ const ROSTER: RosterFixture[] = [
 const META: MetaFixture = {
   vocabulary: '{"job":"job","visit":"visit","worker":"technician"}',
   statuses: '[{"name":"new","terminal":false}]',
+  transitions: '[["new","done"]]',
   zone: 'Europe/London',
   publishedAt: '2026-08-07T12:00:00.000Z',
 }
 
+const CANDIDATES: CandidateFixture[] = [
+  // Against v1, which alice owns.
+  {
+    accountId: 'acc-a',
+    visitId: 'v1',
+    workerId: 'w1',
+    name: 'Alice Stone',
+    kind: 'offered',
+    reason: '',
+    conflicts: '[{"visitId":"v9","start":"a","end":"b"}]',
+  },
+  {
+    accountId: 'acc-a',
+    visitId: 'v1',
+    workerId: 'w2',
+    name: 'Bob Reed',
+    kind: 'excluded',
+    reason: 'missing-qualification',
+    conflicts: '',
+  },
+  // Against v2, which bob owns.
+  {
+    accountId: 'acc-a',
+    visitId: 'v2',
+    workerId: 'w1',
+    name: 'Alice Stone',
+    kind: 'offered',
+    reason: '',
+    conflicts: '[]',
+  },
+]
+
 describe('the roster and the config come back through the same gate', () => {
   it('gives an account-scoped person every worker on their own account', async () => {
     const h = await processVisits(
@@ -239,3 +315,189 @@ describe('the roster and the config come back through the same gate', () => {
     expect((h.payload.roster as Array<{ workingHours: unknown }>)[0].workingHours).toEqual({})
   })
 })
+
+describe('the planner write half reads through the same gate (Task 2511)', () => {
+  const payload = (h: { payload: Record<string, unknown> }) => h.payload
+
+  it('returns the account transitions in meta', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    expect((payload(h).meta as { transitions: unknown }).transitions).toEqual([['new', 'done']])
+  })
+
+  it('returns an empty transition list when the column is malformed, never a throw', async () => {
+    // One bad value must not take a whole week off the screen. An empty list
+    // refuses every move, which is visibly wrong on screen; accepting every
+    // move would leave the page enforcing nothing and looking identical to a
+    // working one.
+    const broken = { ...META, transitions: 'not json' }
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, broken, CANDIDATES)),
+      () => {},
+      1,
+    )
+    expect((payload(h).meta as { transitions: unknown }).transitions).toEqual([])
+  })
+
+  it('returns the transitions to both scopes, because they are config not personal data', async () => {
+    for (const scope of ['own', 'account']) {
+      const h = await processVisits(
+        'sess',
+        env(db(ROWS, asPerson('alice', scope), ROSTER, META, CANDIDATES)),
+        () => {},
+        1,
+      )
+      expect((payload(h).meta as { transitions: unknown[] }).transitions).toHaveLength(1)
+    }
+  })
+
+  it('gives an account-scoped person every candidate for the account', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    expect((payload(h).candidates as Array<{ workerId: string }>)).toHaveLength(3)
+  })
+
+  it('scopes candidates to the visits the person may already see', async () => {
+    // A candidate row names a colleague. An own-scoped worker receiving
+    // candidates for a visit they cannot see would learn the roster the file
+    // drop deliberately withholds.
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('alice', 'own'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const got = payload(h).candidates as Array<{ visitId: string }>
+    expect(got.map((c) => c.visitId)).toEqual(['v1', 'v1'])
+  })
+
+  it('parses conflicts out of its JSON column so the page never parses it', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const got = payload(h).candidates as Array<{
+      workerId: string
+      kind: string
+      conflicts: Array<{ visitId: string }>
+    }>
+    const offered = got.find((c) => c.kind === 'offered' && c.conflicts.length > 0)
+    expect(offered!.conflicts[0].visitId).toBe('v9')
+  })
+
+  it('reads an excluded row empty conflicts column as an empty list, not a throw', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const got = payload(h).candidates as Array<{ kind: string; conflicts: unknown }>
+    expect(got.find((c) => c.kind === 'excluded')!.conflicts).toEqual([])
+  })
+
+  it('answers with an empty candidate list when the account published none', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META)),
+      () => {},
+      1,
+    )
+    expect(payload(h).candidates).toEqual([])
+  })
+
+  it('logs a candidate COUNT and never a worker name', async () => {
+    const lines: string[] = []
+    await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      (l) => lines.push(l),
+      1,
+    )
+    expect(lines.join('\n')).toMatch(/candidates=3/)
+    expect(lines.join('\n')).not.toContain('Alice Stone')
+  })
+
+  it('names all six record counts in the visits SELECT', async () => {
+    // Asserted on the statement, not on the fixture: the fake ignores the
+    // column list, so a row carrying counts would come back whether or not the
+    // endpoint asked for them.
+    prepared.length = 0
+    await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('alice', 'own'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const visitsSelect = prepared.find((s) => s.includes('FROM visits v'))
+    expect(visitsSelect).toBeDefined()
+    for (const field of [
+      'notes',
+      'media',
+      'parts',
+      'checklistDone',
+      'checklistTotal',
+      'signatures',
+    ]) {
+      expect(visitsSelect!.includes(`v.${field} AS ${field}`), `SELECT names ${field}`).toBe(true)
+    }
+  })
+
+  it('passes the counts through to the caller untouched', async () => {
+    // The endpoint computes no count. Whatever the mirror holds is what the
+    // page draws, which is what makes the push the only place a count is made.
+    const counted: Row[] = [
+      { accountId: 'acc-a', ownerId: 'alice', visitId: 'v1', parts: 3, checklistDone: 2, checklistTotal: 5 },
+    ]
+    const h = await processVisits(
+      'sess',
+      env(db(counted, asPerson('alice', 'own'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const [visit] = payload(h).visits as Array<Record<string, unknown>>
+    expect(visit.parts).toBe(3)
+    expect(visit.checklistDone).toBe(2)
+    expect(visit.checklistTotal).toBe(5)
+  })
+
+  it('scopes the candidate read through the visits join, not beside it', async () => {
+    // The owner filter must be the join's, or a second check would have to be
+    // kept in step with the visits read for ever.
+    prepared.length = 0
+    await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('alice', 'own'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const candidateSelect = prepared.find((s) => s.includes('FROM visit_candidates'))
+    expect(candidateSelect).toBeDefined()
+    expect(candidateSelect!).toContain('JOIN visits v')
+    expect(candidateSelect!).toContain('v.generation = c.generation')
+    expect(candidateSelect!).toContain('v.ownerId = ?')
+  })
+
+  it('drops the owner filter from the candidate read at account scope', async () => {
+    prepared.length = 0
+    await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META, CANDIDATES)),
+      () => {},
+      1,
+    )
+    const candidateSelect = prepared.find((s) => s.includes('FROM visit_candidates'))
+    expect(candidateSelect!).not.toContain('v.ownerId = ?')
+  })
+})

package/payload/platform/plugins/cloudflare/skills/data-portal/schema.sql

@@ -253,10 +253,20 @@ CREATE TABLE IF NOT EXISTS directory_state (
 --
 -- READ THE ASYMMETRY WITH THE COLUMN NOTES ABOVE. Those warn that
 -- IF NOT EXISTS adds no COLUMN to an existing table. It does create an absent
--- TABLE, so these three need no hand step on a database that predates them.
--- Stated because a reader who has just absorbed the column warning would
+-- TABLE, so a database that predates these tables gets them whole, with no hand
+-- step. Stated because a reader who has just absorbed the column warning would
 -- otherwise carry it across and go looking for a migration that is not needed.
 --
+-- The asymmetry bites the OTHER way for the six count columns Task 2511 added
+-- to `visits` below. A database that already holds this table gets none of
+-- them, so add them by hand in that case, in this order:
+--   ALTER TABLE visits ADD COLUMN notes INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visits ADD COLUMN media INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visits ADD COLUMN parts INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visits ADD COLUMN checklistDone INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visits ADD COLUMN checklistTotal INTEGER NOT NULL DEFAULT 0;
+--   ALTER TABLE visits ADD COLUMN signatures INTEGER NOT NULL DEFAULT 0;
+--
 -- `ownerId` is the enrolled portal person the visit is assigned to, resolved by
 -- the push from an explicit `portalOwnerId` on the :Person carrying :Engineer.
 -- It is '' when the engineer carries no such property. That row is NOT dropped:
@@ -269,16 +279,32 @@ CREATE TABLE IF NOT EXISTS directory_state (
 -- in one forward-only statement, then sweeps what the pointer no longer names.
 -- A listing that races a push reads the old set or the new one, never a
 -- half-built one.
+-- The six count columns are what the worker recorded, and they are COUNTS and
+-- never contents (Task 2511). A note, a signature and a media reference
+-- describe a real person's working day; this table's own header states that a
+-- job sheet's contents are files the manifest already carries. The counts are
+-- enough for the office to see what was recorded and what is still missing,
+-- which is what it could not see at all before. The contents are Task 2563.
+--
+-- `checklistDone` against `checklistTotal` is the one pair read together: a
+-- count of ticked items with no total says nothing about whether the work is
+-- finished.
 CREATE TABLE IF NOT EXISTS visits (
-  id         INTEGER PRIMARY KEY AUTOINCREMENT,
-  accountId  TEXT NOT NULL,
-  visitId    TEXT NOT NULL,
-  ownerId    TEXT NOT NULL DEFAULT '',
-  jobId      TEXT NOT NULL DEFAULT '',
-  status     TEXT NOT NULL DEFAULT '',
-  startDate  TEXT NOT NULL DEFAULT '',
-  purpose    TEXT NOT NULL DEFAULT '',
-  generation INTEGER NOT NULL DEFAULT 0,
+  id             INTEGER PRIMARY KEY AUTOINCREMENT,
+  accountId      TEXT NOT NULL,
+  visitId        TEXT NOT NULL,
+  ownerId        TEXT NOT NULL DEFAULT '',
+  jobId          TEXT NOT NULL DEFAULT '',
+  status         TEXT NOT NULL DEFAULT '',
+  startDate      TEXT NOT NULL DEFAULT '',
+  purpose        TEXT NOT NULL DEFAULT '',
+  notes          INTEGER NOT NULL DEFAULT 0,
+  media          INTEGER NOT NULL DEFAULT 0,
+  parts          INTEGER NOT NULL DEFAULT 0,
+  checklistDone  INTEGER NOT NULL DEFAULT 0,
+  checklistTotal INTEGER NOT NULL DEFAULT 0,
+  signatures     INTEGER NOT NULL DEFAULT 0,
+  generation     INTEGER NOT NULL DEFAULT 0,
   UNIQUE (accountId, visitId, generation)
 );
 
@@ -324,17 +350,40 @@ CREATE TABLE IF NOT EXISTS visits_state (
 --   ALTER TABLE visit_status ADD COLUMN dayHundredths INTEGER NOT NULL DEFAULT 0;
 --   ALTER TABLE visit_status ADD COLUMN workDate TEXT NOT NULL DEFAULT '';
 --   ALTER TABLE visit_status ADD COLUMN workNote TEXT NOT NULL DEFAULT '';
+--   ALTER TABLE visit_status ADD COLUMN assignedOwnerId TEXT NOT NULL DEFAULT '';
+--   ALTER TABLE visit_status ADD COLUMN startDate TEXT NOT NULL DEFAULT '';
+--
+-- `assignedOwnerId` and `startDate` are the re-assignment and the re-timing an
+-- office person made on the planner (Task 2511). They ride THIS table and the
+-- existing door rather than a second write endpoint, so a status change and a
+-- move reach the graph in one statement and cannot half-apply.
+--
+-- `assignedOwnerId` is the portal person the visit is being moved to, and ''
+-- means this edit re-assigns nobody — the same absent-sentinel convention
+-- `ownerId` uses above. The pull resolves it back to an engineer through
+-- `:Engineer.portalOwnerId`, the property the push resolved forward. That
+-- binding is not unique by construction, so an id naming zero or several
+-- engineers writes nothing rather than picking one: a silent cross-assignment
+-- shows one worker another's day.
+--
+-- `startDate` is the new start INSTANT, and '' means this edit re-times
+-- nothing. An instant and not a date: `readCommitments` compares stored start
+-- values lexically, so an offset-bearing or date-only value reads the wrong
+-- window and a real double-booking goes unreported. The door refuses any other
+-- shape rather than normalising one.
 CREATE TABLE IF NOT EXISTS visit_status (
-  id            INTEGER PRIMARY KEY AUTOINCREMENT,
-  accountId     TEXT NOT NULL,
-  visitId       TEXT NOT NULL,
-  ownerId       TEXT NOT NULL,
-  status        TEXT NOT NULL,
-  statusAt      TEXT NOT NULL,
-  dayHundredths INTEGER NOT NULL DEFAULT 0,
-  workDate      TEXT NOT NULL DEFAULT '',
-  workNote      TEXT NOT NULL DEFAULT '',
-  claimed       INTEGER NOT NULL DEFAULT 0
+  id              INTEGER PRIMARY KEY AUTOINCREMENT,
+  accountId       TEXT NOT NULL,
+  visitId         TEXT NOT NULL,
+  ownerId         TEXT NOT NULL,
+  status          TEXT NOT NULL,
+  statusAt        TEXT NOT NULL,
+  dayHundredths   INTEGER NOT NULL DEFAULT 0,
+  workDate        TEXT NOT NULL DEFAULT '',
+  workNote        TEXT NOT NULL DEFAULT '',
+  assignedOwnerId TEXT NOT NULL DEFAULT '',
+  startDate       TEXT NOT NULL DEFAULT '',
+  claimed         INTEGER NOT NULL DEFAULT 0
 );
 
 -- The pull selects unclaimed rows for one account every sixty seconds, so the
@@ -394,12 +443,68 @@ CREATE INDEX IF NOT EXISTS visit_roster_account ON visit_roster (accountId);
 -- `publishedAt` is when this generation was staged, so the page can state the
 -- age of what it shows. A mirror that stopped refreshing is otherwise identical
 -- to a week with no changes.
+--
+-- `transitions` is the account's own `visitTransitions` as JSON, `[[from, to]]`
+-- (Task 2511). It rides the same generation as the statuses beside it, so the
+-- moves a page offers and the statuses it draws can never be one flip apart.
+-- Absent from the list means refused, on both sides: there is no state machine
+-- in the code, and the door and the page each check this same published list.
+-- The page's copy is what lets an illegal drag be refused while the install is
+-- offline; the door's copy is what makes that refusal binding.
+--
+-- On a database that predates this column, add it by hand:
+--   ALTER TABLE dispatch_meta ADD COLUMN transitions TEXT NOT NULL DEFAULT '';
 CREATE TABLE IF NOT EXISTS dispatch_meta (
   accountId   TEXT NOT NULL,
   vocabulary  TEXT NOT NULL DEFAULT '',
   statuses    TEXT NOT NULL DEFAULT '',
+  transitions TEXT NOT NULL DEFAULT '',
   zone        TEXT NOT NULL DEFAULT '',
   publishedAt TEXT NOT NULL DEFAULT '',
   generation  INTEGER NOT NULL DEFAULT 0,
   UNIQUE (accountId, generation)
 );
+
+-- Who may be sent to an unallocated visit, and why the others may not, per
+-- staging generation (Task 2511).
+--
+-- Precomputed on the install by the one implementation of qualification and
+-- clash (`platform/lib/dispatch-read/src/allocate.ts`) and never recomputed on
+-- the page. `functions/api/visits.ts` states the rule: an account's own page
+-- renders what that endpoint returns and never re-implements the filter,
+-- because a gate written once per client is a gate got wrong once per client.
+--
+-- Rows exist for UNALLOCATED visits only, meaning a :Visit carrying no
+-- attendance. A visit already staffed has nobody to offer.
+--
+-- `kind` decides which of the two following columns carries anything. An
+-- `offered` row has `reason` empty and `conflicts` holding that worker's
+-- commitments overlapping the window, which is '[]' when they are free — a
+-- qualified worker already committed is offered WITH the conflict shown and
+-- never dropped, because the office double-books on purpose and a surface that
+-- removes the busy option makes that decision for them. An `excluded` row has
+-- `conflicts` empty and `reason` naming the exclusion.
+--
+-- No travel estimate. Producing one costs a provider call per offered worker,
+-- which on this path is one call per qualified worker per unallocated job every
+-- sixty seconds, for as long as a job stays unallocated. The estimate stays in
+-- `dispatch-allocate-candidates`, where the office asks about one job at a
+-- time. Carrying it here is Task 2564.
+--
+-- Staged at the visits' generation and live through the same `visits_state`
+-- flip, so a week and the candidates offered against it can never be one
+-- generation apart.
+CREATE TABLE IF NOT EXISTS visit_candidates (
+  id         INTEGER PRIMARY KEY AUTOINCREMENT,
+  accountId  TEXT NOT NULL,
+  visitId    TEXT NOT NULL,
+  workerId   TEXT NOT NULL,
+  name       TEXT NOT NULL DEFAULT '',
+  kind       TEXT NOT NULL DEFAULT '',
+  reason     TEXT NOT NULL DEFAULT '',
+  conflicts  TEXT NOT NULL DEFAULT '',
+  generation INTEGER NOT NULL DEFAULT 0,
+  UNIQUE (accountId, visitId, workerId, generation)
+);
+
+CREATE INDEX IF NOT EXISTS visit_candidates_account ON visit_candidates (accountId);

package/payload/platform/plugins/cloudflare/skills/data-portal/template/functions/api/visit-status.ts

@@ -33,6 +33,31 @@ export const MAX_NOTE_LENGTH = 500
  */
 export const WORK_DATE_RE = /^\d{4}-\d{2}-\d{2}$/
 
+/**
+ * The longest portal owner id a re-assignment may name.
+ *
+ * `assignedOwnerId` reaches the graph through the pull, where it is matched
+ * against `:Engineer.portalOwnerId`, so it is graph input arriving from the open
+ * web and gets the treatment the status gets: refused at the door, never
+ * truncated. A truncated id matches a different person, or nobody, silently,
+ * and the person who dragged the card is never told.
+ */
+export const MAX_OWNER_ID_LENGTH = 64
+
+/**
+ * The only instant shape a re-timing may carry.
+ *
+ * `new Date().toISOString()`'s own output, which is what every canonical instant
+ * in this exchange already stores. An offset-bearing value is REFUSED rather
+ * than converted: `readCommitments` compares these values LEXICALLY against the
+ * stored start, so an offset-bearing row reads the wrong window and a real
+ * double-booking goes unreported. A COPY of this check lives in
+ * `platform/ui/server/portal-visits-pull.ts` as the invariant at the writer,
+ * for the reason WORK_DATE_RE gives above: this file ships to Cloudflare Pages
+ * and cannot import from the platform tree.
+ */
+export const INSTANT_RE = /^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{3}Z$/
+
 /**
  * Record a status a person set against one of their visits.
  *
@@ -103,13 +128,115 @@ export async function processVisitStatus(
   }
   if (workNote.length > MAX_NOTE_LENGTH) {
     log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=note-too-long`)
+    log(`[data-portal] op=rejected visitId=${q(visitId)} reason=note-too-long`)
     return { status: 400, payload: { ok: false, error: 'note too long' } }
   }
 
+  // The move this edit carries, if any (Task 2511). Both absent means a
+  // status-only edit, which is the common case and stays a zero-move write.
+  const assignedOwnerId = typeof b.assignedOwnerId === 'string' ? b.assignedOwnerId : ''
+  const startDate = typeof b.startDate === 'string' ? b.startDate : ''
+  if (assignedOwnerId.length > MAX_OWNER_ID_LENGTH) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=owner-too-long`)
+    log(`[data-portal] op=rejected visitId=${q(visitId)} reason=owner-too-long`)
+    return { status: 400, payload: { ok: false, error: 'assignedOwnerId too long' } }
+  }
+  if (startDate !== '' && !INSTANT_RE.test(startDate)) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=bad-instant`)
+    log(`[data-portal] op=rejected visitId=${q(visitId)} reason=bad-instant`)
+    return {
+      status: 400,
+      payload: { ok: false, error: 'startDate must be an instant as YYYY-MM-DDTHH:MM:SS.sssZ' },
+    }
+  }
+  // A move and a labour claim in one edit is refused, not merged. The device
+  // applies a move in one statement that writes no cost, so a row carrying both
+  // would set the status, move the worker, be claimed, and drop the day the
+  // worker stated — silently, with nothing left to retry against. No shipped
+  // surface sends both; this door is on the open web and admits any body, which
+  // is exactly why the pair is named and refused rather than assumed absent.
+  if ((assignedOwnerId !== '' || startDate !== '') && dayHundredths > 0) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=move-with-labour`)
+    log(`[data-portal] op=rejected visitId=${q(visitId)} reason=move-with-labour`)
+    return {
+      status: 400,
+      payload: { ok: false, error: 'a move and a day claim must be sent as separate edits' },
+    }
+  }
+
   const scoped = session.recordScope === 'own'
+
+  // The visit's CURRENT status and the account's declared moves, read under THE
+  // SAME TWO FILTERS the insert applies (Task 2511).
+  //
+  // THIS IS A REFUSAL, NOT THE GATE. The insert's own SELECT still decides what
+  // may be written, so nothing added here can be reordered past the write, and
+  // the property this file states at `processVisitStatus` is unchanged.
+  //
+  // The refusal is synchronous and it is here. The device-side pull runs sixty
+  // seconds later with no screen to refuse to, and `buildVisitStatusWrite` sets
+  // the status unconditionally, so an illegal move accepted here reaches the
+  // graph with nothing saying so.
+  const currentSql =
+    `SELECT v.status AS status, m.transitions AS transitions
+       FROM visits v
+       JOIN visits_state s
+         ON s.accountId = v.accountId AND s.currentGeneration = v.generation
+       LEFT JOIN dispatch_meta m
+         ON m.accountId = v.accountId AND m.generation = v.generation
+      WHERE v.accountId = ?` +
+    (scoped ? ' AND v.ownerId = ?' : '') +
+    ' AND v.visitId = ?'
+  const currentStmt = env.DB.prepare(currentSql)
+  const current = await (
+    scoped
+      ? currentStmt.bind(env.PORTAL_ACCOUNT_ID, session.ownerId, visitId)
+      : currentStmt.bind(env.PORTAL_ACCOUNT_ID, visitId)
+  ).first<{ status: string; transitions: string }>()
+
+  if (!current) {
+    // The SAME single answer the insert gives below, and for the same reason:
+    // "no such visit" and "not yours" are one fact to a caller who may not see
+    // it, and distinguishing them would let anyone enumerate the account's
+    // visit ids.
+    log(
+      `[data-portal] op=visit-status owner=${q(session.ownerId)} account=${q(session.accountId)} ` +
+        `scope=${session.recordScope} result=not-found`,
+    )
+    log(`[data-portal] op=rejected visitId=${q(visitId)} reason=unknown-visit`)
+    return { status: 404, payload: { ok: false, error: 'not found' } }
+  }
+
+  // A write whose status equals the current one is NOT A MOVE. `[from, to]`
+  // declares a move, and no account declares a self-transition, so without this
+  // a pure re-timing would be refused for failing to be a transition — and this
+  // endpoint requires a status on every request.
+  if (status !== current.status) {
+    let legal: unknown = []
+    try {
+      legal = JSON.parse(current.transitions || '[]')
+    } catch {
+      // A malformed list refuses every move rather than allowing every move.
+      // Refusing is visible on screen; allowing leaves a page that enforces
+      // nothing and is indistinguishable from one that enforces correctly.
+      legal = []
+    }
+    const allowed =
+      Array.isArray(legal) &&
+      legal.some((t) => Array.isArray(t) && t[0] === current.status && t[1] === status)
+    if (!allowed) {
+      log(
+        `[data-portal] op=visit-status owner=${q(session.ownerId)} ` +
+          `scope=${session.recordScope} result=illegal-transition`,
+      )
+      log(`[data-portal] op=rejected visitId=${q(visitId)} reason=illegal-transition`)
+      return { status: 400, payload: { ok: false, error: 'illegal-transition' } }
+    }
+  }
+
   const sql =
-    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, dayHundredths, workDate, workNote, claimed, visitId)
-     SELECT ?, ?, ?, ?, ?, ?, ?, 0, v.visitId
+    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, dayHundredths, workDate, workNote, assignedOwnerId, startDate, claimed, visitId)
+     SELECT ?, ?, ?, ?, ?, ?, ?, ?, ?, 0, v.visitId
        FROM visits v
        JOIN visits_state s
          ON s.accountId = v.accountId AND s.currentGeneration = v.generation
@@ -127,6 +254,8 @@ export async function processVisitStatus(
         dayHundredths,
         workDate,
         workNote,
+        assignedOwnerId,
+        startDate,
         env.PORTAL_ACCOUNT_ID,
         session.ownerId,
         visitId,
@@ -139,6 +268,8 @@ export async function processVisitStatus(
         dayHundredths,
         workDate,
         workNote,
+        assignedOwnerId,
+        startDate,
         env.PORTAL_ACCOUNT_ID,
         visitId,
       )
@@ -159,6 +290,15 @@ export async function processVisitStatus(
   // Counts, the scope, whether a day was claimed, and the outcome. Never the
   // status text, the date or the note: they describe what a real person was
   // doing and when.
+  //
+  // THE `op=rejected` LINES ABOVE DO CARRY THE visitId, which this file
+  // otherwise omits (Task 2511, operator decision 2026-08-08). The failure they
+  // exist to catch is a write this door accepted that the pull never applied,
+  // which leaves the page showing a change the graph does not have; detecting
+  // it means pairing a refusal or an acceptance here to one visit in
+  // `[portal-visits-pull] op=applied`, and no other field the two logs share
+  // identifies one. The exception is those lines alone: this line still carries
+  // counts and no visit.
   log(
     `[data-portal] op=visit-status owner=${q(session.ownerId)} account=${q(session.accountId)} ` +
       `scope=${session.recordScope} labour=${dayHundredths > 0} queued=${changes} result=ok`,