@rubytech/create-maxy-code 0.1.573 → 0.1.575

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

@@ -19,7 +19,27 @@ interface Row {
  * 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 }) {
+interface RosterFixture {
+  accountId: string
+  workerId: string
+  ownerId: string
+  name: string
+  workingHours: string
+}
+
+interface MetaFixture {
+  vocabulary: string
+  statuses: string
+  zone: string
+  publishedAt: string
+}
+
+function db(
+  rows: Row[],
+  person: { ownerId: string; recordScope: string; accountId: string },
+  roster: RosterFixture[] = [],
+  meta: MetaFixture | null = null,
+) {
   return {
     prepare(sql: string) {
       let bound: unknown[] = []
@@ -29,12 +49,21 @@ function db(rows: Row[], person: { ownerId: string; recordScope: string; account
           return stmt
         },
         async first<T>() {
+          // The session resolve and the meta read both use first(); branching on
+          // the table is what keeps the fake honest about which one answered.
+          if (sql.includes('FROM dispatch_meta')) return meta as unknown as T
           return person as unknown as T
         },
         async run() {
           return { meta: { changes: 0 } }
         },
         async all<T>() {
+          if (sql.includes('FROM visit_roster')) {
+            const [acct, owner] = bound as string[]
+            let out = roster.filter((r) => r.accountId === acct)
+            if (sql.includes('r.ownerId = ?')) out = out.filter((r) => r.ownerId === owner)
+            return { results: out as unknown as T[] }
+          }
           if (!sql.includes('FROM visits')) return { results: [] as T[] }
           const [acct, owner] = bound as string[]
           let out = rows.filter((r) => r.accountId === acct)
@@ -110,3 +139,103 @@ describe('the visits scope gate', () => {
     expect(lines.join('\n')).toContain('visits=1')
   })
 })
+
+const ROSTER: RosterFixture[] = [
+  {
+    accountId: 'acc-a',
+    workerId: 'w1',
+    ownerId: 'alice',
+    name: 'Alice Stone',
+    workingHours: '{"mon":["08:00","17:00"]}',
+  },
+  { accountId: 'acc-a', workerId: 'w2', ownerId: 'bob', name: 'Bob Reed', workingHours: '{}' },
+  {
+    accountId: 'acc-b',
+    workerId: 'w3',
+    ownerId: 'alice',
+    name: 'Another Alice',
+    workingHours: '{}',
+  },
+]
+
+const META: MetaFixture = {
+  vocabulary: '{"job":"job","visit":"visit","worker":"technician"}',
+  statuses: '[{"name":"new","terminal":false}]',
+  zone: 'Europe/London',
+  publishedAt: '2026-08-07T12:00:00.000Z',
+}
+
+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(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), ROSTER, META)),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(200)
+    expect((h.payload.roster as Array<{ workerId: string }>).map((w) => w.workerId).sort()).toEqual(
+      ['w1', 'w2'],
+    )
+  })
+
+  it('gives an own-scoped person only their own roster row, so the page is not a staff list', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('alice', 'own'), ROSTER, META)),
+      () => {},
+      1,
+    )
+    expect((h.payload.roster as Array<{ ownerId: string }>).map((w) => w.ownerId)).toEqual(['alice'])
+  })
+
+  it('parses workingHours 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)),
+      () => {},
+      1,
+    )
+    const roster = h.payload.roster as Array<{
+      workerId: string
+      workingHours: Record<string, string[]>
+    }>
+    expect(roster.find((w) => w.workerId === 'w1')!.workingHours.mon).toEqual(['08:00', '17:00'])
+  })
+
+  it('returns the zone and the nouns 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)),
+        () => {},
+        1,
+      )
+      const m = h.payload.meta as { zone: string; vocabulary: { worker: string } }
+      expect(m.zone).toBe('Europe/London')
+      expect(m.vocabulary.worker).toBe('technician')
+    }
+  })
+
+  it('answers with an empty roster and a null meta when the account published none', async () => {
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'))),
+      () => {},
+      1,
+    )
+    expect(h.payload.roster).toEqual([])
+    expect(h.payload.meta).toBeNull()
+  })
+
+  it('survives a malformed JSON column rather than failing the whole week', async () => {
+    const broken = [{ ...ROSTER[0], workingHours: '{not json' }]
+    const h = await processVisits(
+      'sess',
+      env(db(ROWS, asPerson('marie', 'account'), broken, META)),
+      () => {},
+      1,
+    )
+    expect((h.payload.roster as Array<{ workingHours: unknown }>)[0].workingHours).toEqual({})
+  })
+})

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

@@ -340,3 +340,66 @@ CREATE TABLE IF NOT EXISTS visit_status (
 -- The pull selects unclaimed rows for one account every sixty seconds, so the
 -- pair carries its own index or every cycle is a full scan.
 CREATE INDEX IF NOT EXISTS visit_status_pending ON visit_status (accountId, claimed);
+
+-- One row per configured worker, per staging generation (Task 2539). The office
+-- planner draws a row per worker, including a worker with nothing on: an
+-- omitted row reads as a worker who does not exist.
+--
+-- `workerId` is the id in the account's own dispatch/config.json. `ownerId` is
+-- the enrolled portal person that worker signs in as, resolved by the push from
+-- an explicit `portalOwnerId` on the :Engineer carrying that engineerId, and ''
+-- when they carry none. The binding is a property and NEVER a name match, the
+-- same rule `visits.ownerId` above states: two people share a first name, and a
+-- silent cross-assignment shows one worker another's day.
+--
+-- A worker whose ownerId is '' still gets a row. They are visible to an
+-- account-scoped person, invisible to every own-scoped one, and counted by the
+-- push as `workers-unresolved`, so an unbound worker is found in the journal
+-- rather than by somebody opening an empty week.
+--
+-- `workingHours` is the JSON object from the config ({"mon":["08:00","17:00"]}).
+-- It is read as one unit by one consumer and never filtered on, so it is one
+-- column rather than a table that would need a migration per config field.
+--
+-- `generation` and the flip are the visits' own: this table is staged at the
+-- generation the visits push claims and becomes live through the SAME
+-- `visits_state` pointer, so the roster a week is drawn against and the week
+-- itself can never be one generation apart.
+CREATE TABLE IF NOT EXISTS visit_roster (
+  id           INTEGER PRIMARY KEY AUTOINCREMENT,
+  accountId    TEXT NOT NULL,
+  workerId     TEXT NOT NULL,
+  ownerId      TEXT NOT NULL DEFAULT '',
+  name         TEXT NOT NULL DEFAULT '',
+  workingHours TEXT NOT NULL DEFAULT '',
+  generation   INTEGER NOT NULL DEFAULT 0,
+  UNIQUE (accountId, workerId, generation)
+);
+
+CREATE INDEX IF NOT EXISTS visit_roster_account ON visit_roster (accountId);
+
+-- One row per account, per staging generation: the configuration the planner
+-- renders itself from (Task 2539).
+--
+-- `vocabulary` and `statuses` are JSON straight off the account's
+-- dispatch/config.json, so a taxi firm's fare/pickup/driver and a contractor's
+-- job/visit/engineer render through one page with no operator-facing literal in
+-- its source.
+--
+-- `zone` is the account's own timezone, resolved on the device. The page formats
+-- every date in it and never consults the browser's: a browser-zone fallback
+-- renders plausibly and wrongly, which is the defect Task 2280 left on thirteen
+-- other surfaces.
+--
+-- `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.
+CREATE TABLE IF NOT EXISTS dispatch_meta (
+  accountId   TEXT NOT NULL,
+  vocabulary  TEXT NOT NULL DEFAULT '',
+  statuses    TEXT NOT NULL DEFAULT '',
+  zone        TEXT NOT NULL DEFAULT '',
+  publishedAt TEXT NOT NULL DEFAULT '',
+  generation  INTEGER NOT NULL DEFAULT 0,
+  UNIQUE (accountId, generation)
+);

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

@@ -19,6 +19,53 @@ export interface VisitRow {
   purpose: string
 }
 
+/**
+ * One configured worker, as the office planner draws a row for (Task 2539).
+ *
+ * `workerId` is the id in the account's own dispatch config; `ownerId` is the
+ * enrolled portal person that worker signs in as, and '' when they have no
+ * binding. The page groups visits onto rows by `ownerId`, which is the key both
+ * halves of the exchange already use.
+ */
+export interface RosterRow {
+  workerId: string
+  ownerId: string
+  name: string
+  workingHours: Record<string, [string, string]>
+}
+
+/**
+ * The configuration the planner renders itself from, and the age of what it
+ * shows.
+ *
+ * Null when the account has published none, which is every portal carrying no
+ * dispatch config. Null rather than an empty object: a page that renders
+ * defaults for a missing config states an account's nouns wrongly instead of
+ * saying it has none.
+ */
+export interface Meta {
+  vocabulary: { job: string; visit: string; worker: string }
+  statuses: Array<{ name: string; terminal: boolean }>
+  zone: string
+  publishedAt: string
+}
+
+/**
+ * A column of JSON text, or the fallback.
+ *
+ * Never a throw. One malformed value must not take a whole week off the screen:
+ * the worker's row still renders with no hours, which is visibly wrong, where a
+ * 500 is indistinguishable from the device being down.
+ */
+function parseJson<T>(raw: string, fallback: T): T {
+  try {
+    const v = JSON.parse(raw) as T
+    return v === null || v === undefined ? fallback : v
+  } catch {
+    return fallback
+  }
+}
+
 /**
  * The visits a signed-in person may read.
  *
@@ -67,13 +114,67 @@ export async function processVisits(
   const rows = await bound.all<VisitRow>()
   const visits = rows.results ?? []
 
+  // THE SAME TWO FILTERS, and the owner one for the same reason: an own-scoped
+  // person may see their own row and no other, or this page becomes a way to
+  // read colleague names that the file drop deliberately does not give them.
+  // Read through the generation pointer, as the visits read is.
+  const rosterSql =
+    `SELECT r.workerId AS workerId, r.ownerId AS ownerId, r.name AS name,
+            r.workingHours AS workingHours
+       FROM visit_roster r
+       JOIN visits_state s
+         ON s.accountId = r.accountId AND s.currentGeneration = r.generation
+      WHERE r.accountId = ?` +
+    (scoped ? ' AND r.ownerId = ?' : '') +
+    ' ORDER BY r.name ASC, r.workerId ASC'
+  const rosterStmt = env.DB.prepare(rosterSql)
+  const rosterRows = await (
+    scoped
+      ? rosterStmt.bind(env.PORTAL_ACCOUNT_ID, session.ownerId)
+      : rosterStmt.bind(env.PORTAL_ACCOUNT_ID)
+  ).all<{ workerId: string; ownerId: string; name: string; workingHours: string }>()
+
+  // Parsed here, once, rather than on the page: a column of JSON parsed by every
+  // consumer is a shape each of them can disagree about.
+  const roster: RosterRow[] = (rosterRows.results ?? []).map((r) => ({
+    workerId: r.workerId,
+    ownerId: r.ownerId,
+    name: r.name,
+    workingHours: parseJson<Record<string, [string, string]>>(r.workingHours, {}),
+  }))
+
+  const metaRow = await env.DB.prepare(
+    `SELECT m.vocabulary AS vocabulary, m.statuses AS statuses, m.zone AS zone,
+            m.publishedAt AS publishedAt
+       FROM dispatch_meta m
+       JOIN visits_state s
+         ON s.accountId = m.accountId AND s.currentGeneration = m.generation
+      WHERE m.accountId = ?`,
+  )
+    .bind(env.PORTAL_ACCOUNT_ID)
+    .first<{ vocabulary: string; statuses: string; zone: string; publishedAt: string }>()
+
+  // NOT owner-scoped. The nouns, the statuses and the account's timezone are
+  // configuration, not a record about a person, and the page cannot draw a day
+  // in the right zone without them.
+  const meta: Meta | null = metaRow
+    ? {
+        vocabulary: parseJson(metaRow.vocabulary, { job: '', visit: '', worker: '' }),
+        statuses: parseJson<Array<{ name: string; terminal: boolean }>>(metaRow.statuses, []),
+        zone: metaRow.zone,
+        publishedAt: metaRow.publishedAt,
+      }
+    : null
+
   // Counts and the scope, never a visitId or a purpose: those are a real
-  // person's job, and a Pages log is not where they belong.
+  // person's job, and a Pages log is not where they belong. A worker's NAME is
+  // the same kind of thing, so the roster contributes a count too.
   log(
     `[data-portal] op=visits owner=${q(session.ownerId)} account=${q(session.accountId)} ` +
-      `scope=${session.recordScope} visits=${visits.length} result=ok`,
+      `scope=${session.recordScope} visits=${visits.length} roster=${roster.length} ` +
+      `meta=${meta !== null} result=ok`,
   )
-  return { status: 200, payload: { ok: true, visits } }
+  return { status: 200, payload: { ok: true, visits, roster, meta } }
 }
 
 interface PagesContext {

package/payload/platform/plugins/dispatch/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "dispatch",
-  "description": "Field-work dispatch. Creates a job, allocates it to a qualified worker, moves it through the account's own configured statuses, and records what happened on site. Every status, job type, qualification, checklist, SLA target and operator-facing noun is read from $ACCOUNT_DIR/dispatch/config.json, never hard-coded, so a taxi firm's fare/pickup/driver and a contractor's job/visit/engineer run identical code. Provides dispatch-config-get, dispatch-job-create, dispatch-job-get, dispatch-job-list, dispatch-allocate-candidates, dispatch-allocate, dispatch-visit-status-set, dispatch-visit-record, dispatch-site-history and dispatch-day. Ships the dispatch-setup skill, which elicits and validates the config.",
+  "description": "Field-work dispatch. Holds an inbound request as a reviewable draft, creates a job when somebody approves it, allocates it to a qualified worker with an estimate of how far each candidate has to come, moves it through the account's own configured statuses, sends the worker the card he presses to move it, and records what happened on site. Every status, job type, qualification, checklist, SLA target and operator-facing noun is read from $ACCOUNT_DIR/dispatch/config.json, never hard-coded, so a taxi firm's fare/pickup/driver and a contractor's job/visit/engineer run identical code. Provides dispatch-config-get, dispatch-intake-draft, dispatch-intake-decide, dispatch-intake-list, dispatch-site-upsert, dispatch-site-location-set, dispatch-job-create, dispatch-job-get, dispatch-job-list, dispatch-allocate-candidates, dispatch-allocate, dispatch-visit-status-set, dispatch-visit-record, dispatch-site-history, dispatch-day and dispatch-notify-worker. Ships the dispatch-setup skill, which elicits and validates the config, and the dispatch-page skill, which puts the account's week planner on its own portal domain.",
   "version": "0.1.0",
   "author": {
     "name": "Rubytech LLC"

package/payload/platform/plugins/dispatch/PLUGIN.md

@@ -1,11 +1,27 @@
 ---
 name: dispatch
-description: "Field-work dispatch. Creates a job, allocates it to a qualified worker, moves it through the account's own configured statuses, and records what happened on site. Every status, job type, qualification, checklist, SLA target and operator-facing noun is read from $ACCOUNT_DIR/dispatch/config.json, never hard-coded, so a taxi firm's fare/pickup/driver and a contractor's job/visit/engineer run identical code. Provides dispatch-config-get, dispatch-job-create, dispatch-job-get, dispatch-job-list, dispatch-allocate-candidates, dispatch-allocate, dispatch-visit-status-set, dispatch-visit-record, dispatch-site-history and dispatch-day. Ships the dispatch-setup skill, which elicits and validates the config."
+description: "Field-work dispatch. Holds an inbound request as a reviewable draft, creates a job when somebody approves it, allocates it to a qualified worker with an estimate of how far each candidate has to come, moves it through the account's own configured statuses, sends the worker the card he presses to move it, and records what happened on site. Every status, job type, qualification, checklist, SLA target and operator-facing noun is read from $ACCOUNT_DIR/dispatch/config.json, never hard-coded, so a taxi firm's fare/pickup/driver and a contractor's job/visit/engineer run identical code. Provides dispatch-config-get, dispatch-intake-draft, dispatch-intake-decide, dispatch-intake-list, dispatch-site-upsert, dispatch-site-location-set, dispatch-job-create, dispatch-job-get, dispatch-job-list, dispatch-allocate-candidates, dispatch-allocate, dispatch-visit-status-set, dispatch-visit-record, dispatch-site-history, dispatch-day and dispatch-notify-worker. Ships the dispatch-setup skill, which elicits and validates the config, and the dispatch-page skill, which puts the account's week planner on its own portal domain."
 tools:
   - name: dispatch-config-get
     publicAllowlist: false
     adminAllowlist: true
     riskClass: read
+  - name: dispatch-intake-draft
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: write_local
+  - name: dispatch-intake-decide
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: write_local
+  - name: dispatch-intake-list
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: read
+  - name: dispatch-site-upsert
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: write_local
   - name: dispatch-job-create
     publicAllowlist: false
     adminAllowlist: true
@@ -42,6 +58,14 @@ tools:
     publicAllowlist: false
     adminAllowlist: true
     riskClass: read
+  - name: dispatch-notify-worker
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: write_local
+  - name: dispatch-site-location-set
+    publicAllowlist: false
+    adminAllowlist: true
+    riskClass: write_local
 always: false
 embed: false
 metadata: {"platform":{}}
@@ -67,9 +91,19 @@ A write path for field work. Admin agent only.
 
 ## What it does and does not do
 
-It creates a job at a site for a customer, offers the workers who could take it, sends one of them, moves the job and its visits through the statuses this account declared, and records what happened on site: notes, photos, parts fitted, checklist items, signatures, and when the worker arrived.
+It holds an inbound request until somebody decides on it, creates a job at a site for a customer, offers the workers who could take it, sends one of them, moves the job and its visits through the statuses this account declared, and records what happened on site: notes, photos, parts fitted, checklist items, signatures, and when the worker arrived.
+
+It does not price work, invoice it, optimise a route, or generate a planned-maintenance schedule. It estimates no travel time; that is separate work. It creates no site, customer, worker or vehicle — it refuses when one of those is missing rather than inventing it, because a job pointing at a site nobody has heard of is worse than no job.
+
+## A request is a draft before it is a job
+
+An inbound request becomes an `:IntakeDraft`, not a `:Job`. It records the fields that resolved on this account and names the required ones that did not, so a half-understood request is visible rather than guessed at. A value naming nothing counts as missing exactly like an omitted one; there is one list to act on, not two.
 
-It does not price work, invoice it, optimise a route, or generate a planned-maintenance schedule. It holds no intake queue and estimates no travel time; both are separate work. It creates no site, customer, worker or vehicle — it refuses when one of those is missing rather than inventing it, because a job pointing at a site nobody has heard of is worse than no job.
+Approval creates the job through the same write path `dispatch-job-create` uses, so the opening status and the SLA target come from this account's config and nothing reaches the graph by a route the census was never taught about. Rejection records a reason and keeps the draft. A decision is final, because approving twice turns one request into two jobs with no line saying which was real.
+
+A draft is deliberately not a `:Job` carrying a flag. A draft that is a `:Job` appears in `dispatch-job-list`, in the census `jobs=` count and in the planner, which is the confusion the queue exists to prevent.
+
+The failure that emits nothing here is a draft nobody decided on: nothing was created so there are no write logs, nothing was refused so there are no rejection logs, and the requester never got an answer. Only the census can see it.
 
 ## Nothing an operator can name is in the source
 
@@ -77,6 +111,12 @@ It does not price work, invoice it, optimise a route, or generate a planned-main
 
 A test walks every source file in this plugin and fails if any string from either shipped fixture config appears in it. That is the mechanism behind the claim, not a convention. Both fixtures — an electrical contractor and a taxi firm — share no status, job type, qualification or noun, and the same suite drives both from creation to a terminal status.
 
+## Two skills: author the config, then put the week on a page
+
+`dispatch-setup` elicits and validates `$ACCOUNT_DIR/dispatch/config.json`. Until it exists, every tool here registers and refuses with `reason=no-config`.
+
+`dispatch-page` puts the account's week planner on the domain its people already sign in to, as a page inside their existing data portal at `/planner`. It is not a dashboard route and not a second site: the people, the passcodes, the sessions and the scope that decides who may read what are already rows in the portal's own database, and `functions/api/visits.ts` is the one place that filter is written. An office person enrolled `--record-scope account` sees every worker's week; a field worker enrolled `own` sees their own. The device publishes the roster, the nouns, the statuses and the account's timezone with the visits every sixty seconds, so the page renders one account's words with no literal of its own.
+
 ## Legality is data
 
 A move from one status to another is legal when the account's own transition list contains that pair, and refused otherwise. There is no state machine in the code. The refusal names both ends, so `op=transition-refused … from=X to=Y reason=not-in-config` says exactly what was attempted and why it did not happen. A move into a terminal status is refused a second way when the visit is missing a field the account requires there, and that refusal names the field.
@@ -97,13 +137,16 @@ A pressed arrival is what somebody said; an observed one is what was measured. T
 
 ## The standing checks
 
-Six ways this can fail emit no event at all, because no action occurs: a job created and never allocated, a job past its SLA target, a status no transition reaches, a job type no worker is qualified for, a worker with no qualification recorded, and visits closing hours after the work ended.
+Eight ways this can fail emit no event at all, because no action occurs: a draft nobody decided on, a job created and never allocated, a job past its SLA target, a status no transition reaches, a job type no worker is qualified for, a worker with no qualification recorded, visits closing hours after the work ended, and an assignment card sent to a worker's phone that never arrived.
 
-None can be caught by logging an action. Three standing lines cover them, emitted by the UI server rather than by this plugin, because a plugin only runs when somebody calls it:
+None can be caught by logging an action. Four standing lines cover them, emitted by the UI server rather than by this plugin, because a plugin only runs when somebody calls it:
 
-- `[dispatch-census]`, per account, every 15 minutes: job counts, unallocated count and the age of the oldest, overdue count, open visits and those open over 24 hours.
+- `[dispatch-census]`, per account, every 15 minutes: job counts, unallocated count and the age of the oldest, overdue count, open visits and those open over 24 hours, undecided drafts and the age of the oldest.
 - `[dispatch-config-audit]`, on config load and each census tick: status and job-type counts, unreachable statuses, job types with no qualified worker, workers with no qualification.
 - `[dispatch-record-census]`, daily: closed visits, how many carry a note or a photo, and the median and 90th-percentile lag between work ending and the record being written.
+- `[dispatch-tg-census]`, per account, every 15 minutes: cards sent today against cards pressed, the age of the oldest unacknowledged one, live keyboards and how many sit on closed visits, presses and failures, voice notes awaiting transcription, and sites with no coordinates. `op=delivered` proves the server holds the payload, not that the worker received it, so only reconciling sent against pressed sees a card that never landed.
+
+Per press and per inbound, the card path emits `[dispatch-tg]`: `op=dispatch-sent`, `op=callback-stale`, `op=callback-applied`, `op=card-redrawn`, `op=location-update`, `op=geofence-enter`, `op=voice-received` then `op=voice-transcribed`, `op=media-attached`, `op=unbound-inbound`, `op=button-too-long`. The absence of `op=voice-transcribed` after an `op=voice-received` is the failure, not an error line.
 
 `overdue` is the count the reference account's incumbent system reports as zero, because its response-time targets were never configured. A non-zero and believable number here is the feature working, not a fault.