@rubytech/create-sitedesk-code 0.1.563 → 0.1.564

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-sitedesk-code",
-  "version": "0.1.563",
+  "version": "0.1.564",
   "description": "Install SiteDesk — automated back office for independent building contractors",
   "bin": {
     "create-sitedesk-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 SiteDesk ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:b32b1b25459a9e306afca5d26363b21f184712e4260a08ebe8a0107b40b1f3da
+content-hash: sha256:7abf513cef95e198c855d6852580802593dbcb9ee5234b028916c03917d2afab
 brand: sitedesk-code
 product-name: SiteDesk
 ---
@@ -2544,6 +2544,25 @@ Ask SiteDesk: "What messages has the bot received?" or "Show recent Telegram act
 
 **Messages not arriving:** Make sure the bot hasn't been blocked. Try sending `/start` to the bot directly.
 
+## Sending from the dashboard
+
+Open a Telegram conversation in the dashboard and you can type a reply straight
+into it, the same way you already can with WhatsApp. The message goes out from
+your bot.
+
+Two things to know:
+
+- **Direct messages only.** Group and supergroup chats show no message box. A
+  Telegram conversation is filed under the person who spoke, so a message sent
+  from a group thread would reach that one person privately rather than the
+  group — the box is hidden rather than doing something you did not intend.
+- **History starts now.** Messages are only shown from the point this feature
+  was installed onward. A conversation that was already running looks empty
+  until the next message arrives, and then fills up from there.
+
+Text only for now. Photos, files and voice notes are not available on Telegram
+from the dashboard.
+
 ---
 # Outlook
 Source: https://docs.getmaxy.com/outlook-guide.md

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,12 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-08-05 (0.1.564)
+
+- You can now reply to a Telegram conversation from the dashboard. Telegram was read-only, so a conversation you could watch was one you could not answer; it now has a composer like WhatsApp. Sending is restricted to private chats.
+- An arriving Telegram message now raises a card and a desktop notification, the same as WhatsApp. Until now it arrived silently on every admin surface.
+- A portal job sheet now records time, so a day's labour reaches the timesheet. Field work could be marked done but carried no hours and wrote no labour cost at either end.
+
 ## 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.

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

@@ -1,6 +1,8 @@
 import { describe, it, expect } from 'vitest'
 import {
+  MAX_NOTE_LENGTH,
   MAX_STATUS_LENGTH,
+  WORK_DATE_RE,
   processVisitStatus,
 } from '../../skills/data-portal/template/functions/api/visit-status'
 import type {
@@ -174,3 +176,119 @@ describe('the visit-status write gate', () => {
     expect(joined).not.toContain('granary')
   })
 })
+
+describe('the working day a status edit may carry', () => {
+  const day = (extra: Record<string, unknown>) => ({ visitId: 'v1', status: 'done', ...extra })
+
+  it('inserts the day, the date and the note when the claim is well formed', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      day({ dayHundredths: 100, workDate: '2026-08-05', workNote: 'second fix' }),
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(200)
+    expect(inserted[0]).toContain(100)
+    expect(inserted[0]).toContain('2026-08-05')
+    expect(inserted[0]).toContain('second fix')
+  })
+
+  it('defaults to no claim when the body carries no day', async () => {
+    // A status-only edit is the common case and must stay a one-field write.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(day({}), 'sess', env(database), () => {}, 1)
+    expect(h.status).toBe(200)
+    expect(inserted[0]).toContain(0)
+    expect(inserted[0]).toContain('')
+  })
+
+  it('refuses a day outside 0..100 rather than writing it into the graph', async () => {
+    // A value above a full day is described by no shipped surface. Refused at
+    // the door, exactly as an over-long status is.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const e = env(database)
+    for (const d of [101, -1, 50.5, '100']) {
+      const h = await processVisitStatus(
+        day({ dayHundredths: d, workDate: '2026-08-05' }),
+        'sess',
+        e,
+        () => {},
+        1,
+      )
+      expect(h.status).toBe(400)
+    }
+    expect(inserted).toEqual([])
+  })
+
+  it('refuses a claim whose date is missing or malformed', async () => {
+    // The date becomes part of the cost key. A claim the roll-up cannot date is
+    // told to the person now, not left sitting in the queue.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const e = env(database)
+    for (const wd of [undefined, '', '5th Aug', '2026-8-5']) {
+      const h = await processVisitStatus(
+        day({ dayHundredths: 100, workDate: wd }),
+        'sess',
+        e,
+        () => {},
+        1,
+      )
+      expect(h.status).toBe(400)
+    }
+    expect(inserted).toEqual([])
+  })
+
+  it('accepts a date only in the shape the pull will key on', () => {
+    expect(WORK_DATE_RE.test('2026-08-05')).toBe(true)
+    expect(WORK_DATE_RE.test('2026-08-05T09:00:00Z')).toBe(false)
+  })
+
+  it('refuses a note longer than the cap rather than truncating it', async () => {
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      day({
+        dayHundredths: 100,
+        workDate: '2026-08-05',
+        workNote: 'x'.repeat(MAX_NOTE_LENGTH + 1),
+      }),
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(400)
+    expect(inserted).toEqual([])
+  })
+
+  it('logs whether the edit carried a day, and never the note', async () => {
+    const lines: string[] = []
+    const { database } = db(ROWS, person('alice', 'own'))
+    await processVisitStatus(
+      day({ dayHundredths: 100, workDate: '2026-08-05', workNote: 'granary court rewire' }),
+      'sess',
+      env(database),
+      (l) => lines.push(l),
+      1,
+    )
+    const joined = lines.join('\n')
+    expect(joined).toContain('labour=true')
+    expect(joined).not.toContain('granary')
+    expect(joined).not.toContain('2026-08-05')
+  })
+
+  it('still refuses another person visit when the edit carries a day', async () => {
+    // The gate is the SELECT and the new fields must not have moved it.
+    const { database, inserted } = db(ROWS, person('alice', 'own'))
+    const h = await processVisitStatus(
+      { visitId: 'v2', status: 'done', dayHundredths: 100, workDate: '2026-08-05' },
+      'sess',
+      env(database),
+      () => {},
+      1,
+    )
+    expect(h.status).toBe(404)
+    expect(inserted).toEqual([])
+  })
+})

package/payload/platform/plugins/cloudflare/skills/data-portal/SKILL.md

@@ -147,6 +147,21 @@ ALTER TABLE people ADD COLUMN recordScope TEXT NOT NULL DEFAULT 'own';
 No backfill follows it. Everyone already enrolled lands on the narrow scope, which is the intended
 outcome, and widening one person is a re-run of enrolment for that person.
 
+**A status edit may also carry a working day, and a store that predates those three columns needs
+them added once too.** `dayHundredths` is integer hundredths of a day, which is what the timesheet
+engine consumes: 100 is a full day, and 0 means the edit claims no labour. `workDate` is the day
+worked, and the pull refuses a claim without one rather than dating it from when the sheet was filed.
+`workNote` is what the worker did. The same `IF NOT EXISTS` rule applies, so run all three:
+
+```sql
+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 '';
+```
+
+Until they exist the endpoint's INSERT names columns the table lacks and fails loudly, which is the
+intended outcome: a status edit silently losing its hours is the failure worth avoiding.
+
 **A passcode is never stored in plaintext** — not in `data-portal.json`, not in a log line, nowhere
 on the device. The operator conveys it to the person out of band. Rotating a passcode is a re-run of
 the script for that person; there is no separate editor.

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

@@ -309,14 +309,32 @@ CREATE TABLE IF NOT EXISTS visits_state (
 -- is counted by the audit. It is never written under another id and never
 -- dropped: a dropped edit is a promise broken to the person who made it, and it
 -- emits nothing at the time it happens.
+-- `dayHundredths`, `workDate` and `workNote` are the working day the edit
+-- carries (Task 2432). `dayHundredths` is integer hundredths of a day, which is
+-- exactly what the timesheet engine consumes: 100 is a full day. 0 means this
+-- edit carries no labour claim, the same absent-sentinel convention `ownerId`
+-- uses above for unbound. The pull writes a labour :JobCost only when it is
+-- above 0, and refuses a claim carrying no `workDate` rather than dating it
+-- from anything else: `statusAt` would record the wrong day for a sheet filed
+-- the next morning, and a visit's scheduled date is not evidence of when it was
+-- attended.
+--
+-- IF NOT EXISTS adds none of the three to a table that predates them. Add them
+-- by hand in that case, in this order:
+--   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 '';
 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,
-  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 '',
+  claimed       INTEGER NOT NULL DEFAULT 0
 );
 
 -- The pull selects unclaimed rows for one account every sixty seconds, so the

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

@@ -12,6 +12,27 @@ import { q } from './_lib/log'
  */
 export const MAX_STATUS_LENGTH = 64
 
+/**
+ * The longest work note a person may attach to a day.
+ *
+ * The note reaches `:JobCost.description` through the device-side pull, so it
+ * is graph content arriving from the open web and gets the same treatment the
+ * status gets: refused at the door, never truncated. The size is chosen for a
+ * description cell on the A4 timesheet row, not derived from anything.
+ */
+export const MAX_NOTE_LENGTH = 500
+
+/**
+ * The only date shape a claim may carry.
+ *
+ * The date becomes part of the cost key the pull merges on, so a free-form
+ * string would produce a key nobody can reproduce. A COPY of this check lives
+ * in `platform/ui/server/portal-visits-pull.ts` as the invariant at the writer;
+ * the two cannot share a constant because this file ships to Cloudflare Pages
+ * and cannot import from the platform tree.
+ */
+export const WORK_DATE_RE = /^\d{4}-\d{2}-\d{2}$/
+
 /**
  * Record a status a person set against one of their visits.
  *
@@ -56,10 +77,39 @@ export async function processVisitStatus(
     return { status: 400, payload: { ok: false, error: 'status too long' } }
   }
 
+  // The working day the edit carries, if any. Absent means a status-only edit,
+  // which is the common case and stays a zero-claim write.
+  const dayHundredths = b.dayHundredths === undefined ? 0 : b.dayHundredths
+  if (
+    typeof dayHundredths !== 'number' ||
+    !Number.isInteger(dayHundredths) ||
+    dayHundredths < 0 ||
+    dayHundredths > 100
+  ) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=bad-day`)
+    return { status: 400, payload: { ok: false, error: 'dayHundredths must be an integer 0..100' } }
+  }
+  const workDate = typeof b.workDate === 'string' ? b.workDate : ''
+  const workNote = typeof b.workNote === 'string' ? b.workNote : ''
+  // A claim the roll-up could not date is refused now rather than queued. The
+  // pull holds the same invariant, so a row reaching the table another way is
+  // still never written under a guessed date.
+  if (dayHundredths > 0 && !WORK_DATE_RE.test(workDate)) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=undated-claim`)
+    return {
+      status: 400,
+      payload: { ok: false, error: 'a day claim requires workDate as YYYY-MM-DD' },
+    }
+  }
+  if (workNote.length > MAX_NOTE_LENGTH) {
+    log(`[data-portal] op=visit-status owner=${q(session.ownerId)} result=note-too-long`)
+    return { status: 400, payload: { ok: false, error: 'note too long' } }
+  }
+
   const scoped = session.recordScope === 'own'
   const sql =
-    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, claimed, visitId)
-     SELECT ?, ?, ?, ?, 0, v.visitId
+    `INSERT INTO visit_status (accountId, ownerId, status, statusAt, dayHundredths, workDate, workNote, claimed, visitId)
+     SELECT ?, ?, ?, ?, ?, ?, ?, 0, v.visitId
        FROM visits v
        JOIN visits_state s
          ON s.accountId = v.accountId AND s.currentGeneration = v.generation
@@ -74,6 +124,9 @@ export async function processVisitStatus(
         session.ownerId,
         status,
         statusAt,
+        dayHundredths,
+        workDate,
+        workNote,
         env.PORTAL_ACCOUNT_ID,
         session.ownerId,
         visitId,
@@ -83,6 +136,9 @@ export async function processVisitStatus(
         session.ownerId,
         status,
         statusAt,
+        dayHundredths,
+        workDate,
+        workNote,
         env.PORTAL_ACCOUNT_ID,
         visitId,
       )
@@ -100,11 +156,12 @@ export async function processVisitStatus(
     return { status: 404, payload: { ok: false, error: 'not found' } }
   }
 
-  // Counts, the scope and the outcome. Never the status text: it describes what
-  // a real person was doing.
+  // 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.
   log(
     `[data-portal] op=visit-status owner=${q(session.ownerId)} account=${q(session.accountId)} ` +
-      `scope=${session.recordScope} queued=${changes} result=ok`,
+      `scope=${session.recordScope} labour=${dayHundredths > 0} queued=${changes} result=ok`,
   )
   return { status: 200, payload: { ok: true, queued: changes } }
 }

package/payload/platform/plugins/docs/references/telegram-guide.md

@@ -56,3 +56,22 @@ Ask {{productName}}: "What messages has the bot received?" or "Show recent Teleg
 **Can't send to a group:** The bot must be a member of the group. Add it via the group settings in Telegram, then try again.
 
 **Messages not arriving:** Make sure the bot hasn't been blocked. Try sending `/start` to the bot directly.
+
+## Sending from the dashboard
+
+Open a Telegram conversation in the dashboard and you can type a reply straight
+into it, the same way you already can with WhatsApp. The message goes out from
+your bot.
+
+Two things to know:
+
+- **Direct messages only.** Group and supergroup chats show no message box. A
+  Telegram conversation is filed under the person who spoke, so a message sent
+  from a group thread would reach that one person privately rather than the
+  group — the box is hidden rather than doing something you did not intend.
+- **History starts now.** Messages are only shown from the point this feature
+  was installed onward. A conversation that was already running looks empty
+  until the next message arrives, and then fills up from there.
+
+Text only for now. Photos, files and voice notes are not available on Telegram
+from the dashboard.

package/payload/platform/plugins/memory/references/schema-construction.md

@@ -116,7 +116,7 @@ MERGE keys per label:
 - `:Contact` — `(accountId, contactId)` — write-time MERGE
 - `:PurchaseOrderLine` — `(accountId, poNumber, lineId)` — child of `:PurchaseOrder`
 - `:Note` — `(accountId, noteId)` — child of `:Job` via `(:Note)-[:ABOUT]->(:Job)`, append-only CREATE (a fresh `noteId` per note, not a content MERGE), so a second note never overwrites the first
-- `:Engineer` — `(accountId, personId)` — additional label on `:Person`, set via `memory-update`
+- `:Engineer` — `(accountId, engineerId)` — additional label on `:Person`, set via `memory-update`
 - `:Supplier` — `(accountId, organizationId)` — additional label on `:Organization`
 
 ---

package/payload/premium-plugins/sitedesk/agents/sitedesk--payroll-clerk.md

@@ -3,7 +3,7 @@ name: payroll-clerk
 description: "SiteDesk payroll clerk. Delegate when the operator wants to roll up field workers' daily check-ins into a per-worker timesheet and, for CIS subcontractors, an invoice for a period, reconciled to the penny and emailed to the office. Triggers are jobs like 'run the timesheets', 'do this week's invoices', 'roll up Dave's days'. Not for a new quote (that is the quoter) or an interim valuation (that is the valuer)."
 summary: "Your payroll clerk — turns field workers' daily check-ins into per-worker timesheets and CIS invoices, reconciled to the penny."
 model: claude-sonnet-5
-tools: Skill, Read, Write, Edit, Bash, Glob, Grep, mcp__plugin_browser_browser__browser-navigate, mcp__plugin_browser_browser__browser-pdf-save, mcp__plugin_email_email__email-send
+tools: Skill, Read, Write, Edit, Bash, Glob, Grep, mcp__plugin_browser_browser__browser-navigate, mcp__plugin_browser_browser__browser-pdf-save, mcp__plugin_email_email__email-send, mcp__plugin_memory_memory__memory-search
 pattern_deliverable: false
 ---
 
@@ -17,7 +17,7 @@ A message from the agent that dispatched you arrives on the platform's own dispa
 
 You are the SiteDesk payroll clerk — the one owner of timesheet and CIS-invoice work for an independent service business's field crew. You own one deliverable: a per-worker timesheet and, for a CIS subcontractor, the matching invoice for a period, rendered to A4 PDFs and emailed to the office. The admin agent dispatches a brief to you; you run the `timesheet` skill and return the result.
 
-You never invent the operator's business content. Day counts come from the workers' own daily check-ins; rates, the office invoice address and each worker's engagement are the operator's data — you apply them faithfully. A figure you cannot source is a gap you flag, not a number you guess.
+You never invent the operator's business content. Day counts come from the workers' own job sheets, filed on the data portal and carried into the graph as labour costs, which you read with `memory-search` and never write; rates, the office invoice address and each worker's engagement are the operator's data — you apply them faithfully. A figure you cannot source is a gap you flag, not a number you guess.
 
 ## What you own
 

package/payload/premium-plugins/sitedesk/plugins/sitedesk-job/skills/timesheet/SKILL.md

@@ -22,12 +22,12 @@ maths ([references/roll-up.md](references/roll-up.md)), and the two documents
 
 - **Worker setup (per worker, once).** Capture the worker's engagement, day rate, UTR (CIS only),
   whether the 20% deduction shows, and the office invoice address. Store it as the `:Engineer` config
-  on his `:Person`. The worker logs his days through the receive-only `worker-checkin` agent; the
-  platform's multi-channel transport delivers those messages into one session.
+  on his `:Person`. The worker files his days as job sheets on the operator's data portal, against
+  his own visits; the device carries each one into the graph as a labour cost within a minute.
 
 - **Roll-up (operator-run, per period).** For a worker (or all workers) and a period:
-  1. Read his check-ins for the period by `personId` — structure the worker's delivered messages
-     into `:JobCost` records (one per working day) at this point.
+  1. Read his labour `:JobCost` rows for the period with `memory-search`, by `engineerId`. They are
+     written by the portal visit exchange; this skill reads them and never creates them.
   2. Run `rollup.mjs compute <worker.json> <checkins.json>` — never compute by hand.
   3. Render the timesheet (and, for CIS, the invoice) from the computed figures.
   4. Run `rollup.mjs reconcile <computed.json> <netPence> <dayHundredths>` — both gates must pass.
@@ -42,6 +42,6 @@ total disagrees with the compute.
 
 ## Observability
 
-- one line per check-in read into a roll-up (worker id, source channel, date, site);
+- one line per labour cost read into a roll-up (engineer id, source, date, site);
 - one line on generation: worker id, period, day-count, artefact filenames, email recipient;
 - the `op=reconcile-fail` line whenever a gate stops a send.

package/payload/premium-plugins/sitedesk/plugins/sitedesk-job/skills/timesheet/references/checkin-contract.md

@@ -4,33 +4,51 @@ This skill ships these shapes, never a worker's data.
 
 ## `:Engineer` (operator config, one per worker)
 
-`(:Engineer { personId, accountId, name, engagement: "employee"|"cis", dayRatePence,
+`(:Engineer { engineerId, accountId, name, engagement: "employee"|"cis", dayRatePence,
             utr?, showCisDeduction: bool, invoiceEmail, createdAt })`
 
-`personId` ties the worker to his `:Person`. `dayRatePence` is integer pence. `utr` is present
-only for `engagement: "cis"`. `invoiceEmail` is the office invoice address. Captured by the
-operator at runtime (see [setup.md](setup.md)), never written into this tree.
+`engineerId` is the worker's key and the write-time MERGE key `(accountId, engineerId)`.
+`dayRatePence` is integer pence. `utr` is present only for `engagement: "cis"`. `invoiceEmail` is
+the office invoice address. Captured by the operator at runtime (see [setup.md](setup.md)), never
+written into this tree.
 
-## `:JobCost` (one labour cost per working day, `costType: "labour"`)
+`Engineer` is an additional label on that worker's `:Person`; there is no standalone node. The rate
+lives here, office-side, and never reaches the portal the worker files his day on.
 
-`(:JobCost { costId, costType: "labour", personId, accountId, source, receivedAt,
+## `:JobCost` (one labour cost per visit worked, `costType: "labour"`)
+
+`(:JobCost { costId, costType: "labour", engineerId, accountId, jobId, source, receivedAt,
              date, site, description, dayHundredths, createdAt })`
 
-A logged labour day is an incurred labour cost. `costType` is `"labour"` and `costId` is the
-write-time MERGE key (`(accountId, costId)`) — use a deterministic id such as `${personId}-${date}`
-so re-delivery of the same day stays idempotent. `personId` is the roll-up read key: the roll-up
-reads every labour `:JobCost` for the worker regardless of which channel produced it. `source`
-records the channel the message arrived on (`web`, `whatsapp`, …). `dayHundredths` is 100 for a
-full day; a smaller value only when the operator enabled part-day handling. One labour `:JobCost`
-per working day.
+Time worked is an incurred labour cost. `costType` is `"labour"` and `costId` is the write-time
+MERGE key (`(accountId, costId)`), formed as `${engineerId}-${visitId}`, so re-filing the same
+visit merges rather than duplicating and the later sheet corrects the earlier one.
+
+**One cost per visit, not per day.** A worker who attends two sites in a day files two sheets and
+holds two labour costs on that date, each with its own `site` and its own share of the day. Keying
+on the date instead would merge the second over the first and pay him for one of them; the roll-up
+sums `dayHundredths` across every cost in the period, so several on one date add up to that day.
+
+`engineerId` is the roll-up read key: the roll-up reads every labour `:JobCost` for the worker.
+`date` is the day worked, which is what the roll-up filters a period on and what the timesheet
+prints. `source` records where it came from (`portal`). `dayHundredths` is 100 for a full day; a
+smaller value when the day is split across visits, or when the operator enabled part-day handling.
 
 Each `:JobCost` is linked to the engineer who incurred it with the canonical edge
-`(:JobCost)-[:INCURRED_BY]->(:Engineer)` (an additional label on that worker's `:Person`), and to
-its job with `(:Job)-[:HAS_COST]->(:JobCost)` — the edge types are fixed by
-`schema-construction.md`; write no edge type absent from it. The edge satisfies the write-doctrine
-adjacency requirement (a node is written with at least one relationship); `personId` carries the
-same identity for roll-up reads.
-
-These records come from the worker's delivered messages. The platform's multi-channel transport
-delivers those messages into one session; the step that turns them into `:JobCost` records is this
-skill's roll-up (structure at roll-up — see [roll-up.md](roll-up.md)).
+`(:JobCost)-[:INCURRED_BY]->(:Engineer)`, and to its job with `(:Job)-[:HAS_COST]->(:JobCost)` — the
+edge types are fixed by `schema-construction.md`; write no edge type absent from it. The edges
+satisfy the write-doctrine adjacency requirement (a node is written with at least one relationship);
+`engineerId` carries the same identity for roll-up reads.
+
+## Where these records come from
+
+The worker files a job sheet against one of his own visits on the operator's data portal, stating
+the day worked and how much of it. The device carries that edit into the graph every sixty seconds,
+writing the labour cost in the same statement as the visit's status, so a visit never reads as done
+with the working day missing behind it. The day is attributed to the engineer the visit names rather
+than to whoever filed the sheet, so an office person completing a worker's day still produces that
+worker's cost.
+
+A claim the device cannot date, or one on a visit with no attending engineer, is left unwritten and
+counted in the journal rather than dated or attributed by guess. This skill reads these rows; it
+never creates them.

package/payload/premium-plugins/sitedesk/plugins/sitedesk-job/skills/timesheet/references/roll-up.md

@@ -3,13 +3,26 @@
 Days × rate and the CIS deduction are universal maths; they must reconcile to the penny, so they
 are computed by `rollup.mjs`, never by hand. The engine carries no operator content.
 
-## Turning messages into check-ins (structure at roll-up)
-
-A worker's daily messages arrive over whatever channel and the platform delivers them into one session.
-At roll-up time, read the worker's messages for the period and structure each working day into one
-`:JobCost` (see [checkin-contract.md](checkin-contract.md)): `date`, `site`, `description`,
-`dayHundredths`. One message-day = one check-in. Structuring happens here, in the operator-run step,
-not in the unattended receive path — so the operator can review before anything is sent.
+## Reading the period's days
+
+The days already exist as records. A worker files a job sheet against one of his own visits on the
+operator's data portal, and the device writes that as one labour `:JobCost` (see
+[checkin-contract.md](checkin-contract.md)) carrying `date`, `site`, `description` and
+`dayHundredths`, within a minute of him filing it.
+
+At roll-up time, read the worker's labour costs for the period with `memory-search`, by
+`engineerId`, and filter on `date`. Never create them here. The key is `${engineerId}-${visitId}`,
+so a re-filed sheet merges rather than duplicating; writing a record at roll-up would put a second,
+differently-keyed entry beside one that already exists.
+
+A worker who attends two sites in a day holds two costs on that date, each with its own site and
+its own share of the day. The engine sums `dayHundredths` across every cost you hand it, so several
+on one date add up to that day and each prints its own timesheet row.
+
+A day the worker filed that the device could not use — no date it can key on, or a visit with no
+attending engineer — was never written, and is counted in the journal as `undatedClaims` or as a
+`labourClaims` count that does not drain. A period whose day total looks short is worth checking
+there before it is treated as the worker's own record.
 
 ## The figures (integer pence; day amounts integer hundredths)
 

package/payload/premium-plugins/sitedesk/plugins/sitedesk-job/skills/timesheet/references/setup.md

@@ -2,7 +2,9 @@
 
 The skill defines the questions; the operator's answers are his data. Per worker:
 
-- **Name** and the **`:Person`** he maps to.
+- **Name**, the **`:Person`** he maps to, and his **`engineerId`** — the key everything else about
+  his days is read by. A worker with no `engineerId` has his job sheets refused rather than recorded
+  under a key nobody can reproduce.
 - **Engagement** — `employee` or `cis` (CIS subcontractor).
 - **Day rate** — captured in pounds, stored as integer pence (`dayRatePence`).
 - **UTR** — required when `engagement: cis`; omitted for employees.
@@ -14,7 +16,9 @@ Install-level, once:
 
 - **Invoice frequency** — weekly or monthly; this only sets the default roll-up period, never a
   scheduler. The roll-up is always operator-run.
-- **Part-day / overtime rule** — whether `dayHundredths` other than 100 are accepted, and how a
-  part day is expressed. If disabled, every check-in is a full day.
+- **Part-day rule** — whether `dayHundredths` below 100 are accepted, and how a part day is
+  expressed. If disabled, every day filed is a full day. The portal accepts an integer from 0 to
+  100 and refuses anything above it, so a day longer than a full day cannot be filed and no
+  overtime rule is expressible here.
 
 No value is invented. A missing required value is a gap the agent flags, never a guess.

package/payload/server/{chunk-G6ULACHG.js → chunk-3ABITJWB.js}

@@ -2080,6 +2080,8 @@ function classify(access) {
   }
   return access.agentType === "admin" ? "admin" : "public";
 }
+
+// app/lib/channel-notify/frame.ts
 function formatNotifyBody(text, mediaType) {
   const source = text.length > 0 ? text : mediaType ?? "";
   if (source.length === 0) return { body: "", truncated: false };
@@ -4237,9 +4239,10 @@ function buildNotifyPending(args) {
   const { body, truncated } = formatNotifyBody(args.text, args.mediaType);
   const trimmed = args.pushName?.trim() ?? "";
   return {
-    waMessageId: args.msgKeyId,
+    messageId: args.msgKeyId,
     accountId: args.persistAccountId,
     ledgerAccount: args.ledgerAccount,
+    channel: "whatsapp",
     senderType: args.senderType,
     senderDisplay: trimmed.length > 0 ? trimmed : formatSenderPhone(args.senderPhone),
     body,
@@ -5009,7 +5012,7 @@ function monitorInbound(conn) {
             }
             if (notifyDecision.emit && msg.key.id) {
               console.error(
-                `[wa-notify] op=eligible msgId=${msg.key.id} account=${persistAccountId} senderType=${notifyDecision.senderType} reason=${dmAccess?.reason ?? "none"} passive=${dmAccess?.passive === true}` + (dmAccess?.party ? ` party=${dmAccess.party}` : "")
+                `[channel-notify] op=eligible channel=whatsapp msgId=${msg.key.id} account=${persistAccountId} senderType=${notifyDecision.senderType} reason=${dmAccess?.reason ?? "none"} passive=${dmAccess?.passive === true}` + (dmAccess?.party ? ` party=${dmAccess.party}` : "")
               );
               if (onNotify) {
                 try {
@@ -5028,13 +5031,13 @@ function monitorInbound(conn) {
                   );
                 } catch (err) {
                   console.error(
-                    `[wa-notify] op=emit-failed msgId=${msg.key.id} detail=${err instanceof Error ? err.message : String(err)}`
+                    `[channel-notify] op=emit-failed channel=whatsapp msgId=${msg.key.id} detail=${err instanceof Error ? err.message : String(err)}`
                   );
                 }
               }
             } else if (!notifyDecision.emit) {
               console.error(
-                `[wa-notify] op=skip msgId=${msg.key.id ?? "none"} reason=${notifyDecision.reason}`
+                `[channel-notify] op=skip channel=whatsapp msgId=${msg.key.id ?? "none"} reason=${notifyDecision.reason}`
               );
             }
           }
@@ -5645,6 +5648,7 @@ export {
   isAdminPhone,
   buildPolicyInheritance,
   shouldDispatchInbound,
+  formatNotifyBody,
   formatSenderPhone,
   checkAccessRateLimit,
   recordAccessFailedAttempt,

package/payload/server/{manager-2VEJKVEO.js → manager-N2RVJN7T.js}

@@ -30,7 +30,7 @@ import {
   startConnection,
   stopConnection,
   storeMessage
-} from "./chunk-G6ULACHG.js";
+} from "./chunk-3ABITJWB.js";
 import "./chunk-SKYZG6OT.js";
 import "./chunk-HYQNUVGO.js";
 export {