Dispatch board, request idempotency, and the batch 2-5 programme (#296) * fix(auth): scope standalone login lookup to tenant, fail closed on ambiguity * chore(auth): refresh tenant-scope baseline for line shift; full-suite gate green * feat(reports): generate reports from sold services, publish and notify per report An order sold three services and delivered one document, because nothing created a second report: the `reports` entity could model a radon report but no code path produced one. Selling the services now produces the deliverables, and each one publishes and announces itself on its own schedule. Generation runs at the point the work is scheduled to begin, never at booking — a report that materialises weeks early clutters the order and freezes a template the tenant may still be editing. A cron sweep picks up orders whose `scheduled_start_ms` has arrived; `inspections.reports_generated_at` is its latch, so finished orders are not re-scanned for ever. Reconciliation itself is idempotent per LINE rather than latched, because a client who adds a sewer scope at the door should get a sewer report. Title and template are snapshotted when the report is created, so a catalogue default configured tomorrow rewrites nothing. The placeholder primary every order is born with is ADOPTED by the first line rather than left orphaned beside it — but only while it is still empty; a primary somebody has written into keeps its title and its template. Two notification faults fall out of publishing per report, and each is invisible on its own: - The `report.published` dedup key named only the inspection, so the radon report's first publish read as a retry of the standard report's and was dropped for ever, not for a window. The key is per report now. - `resolvePublishTrigger` asked "has anything on this inspection been published" and so called the radon report's FIRST publish an amendment, sending the client "your report was updated" about a document they had never seen. It asks per report now. Fixing those makes two documents finished in one sitting cost the client two emails, so publishes coalesce inside a one-hour window: the second report is still published, versioned and signed, only the second announcement is suppressed. An amendment is never coalesced. `reports.published_at` / `notified_at` record which document shipped and which publish did the telling — `inspections.report_status` stays the order-wide roll-up every existing reader consumes and cannot answer either question. Migration 0030: four ADD COLUMNs, no table rebuild. Verified with db:check. Not in this change: the reports LIST surface and its delete-with-confirmation modal. There is no per-report UI in the tree at all yet, so a confirmation modal would have nothing to confirm; publishing a named report is reachable through the API (`POST /inspections/:id/publish` now takes `reportId`) and that is the seam the UI will use. Two behaviour-preserving extractions to keep the publish service inside the file-size gate: auto-sign-on-publish and the per-report publish bookkeeping both move to lib/inspection. The remaining +7/+2/+4 lines on three already- grandfathered files are baselined. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01FGxHcE92k4t3d79y6DQfi3 * feat(i18n): per-contact language preference NULL means no stated preference, not English. Only a stored value is evidence a client wanted another language, which is the signal this column exists to produce. resolveContactLocale owns the fall-through order in one place — contact, then the account a contact is bound to, then the company default, then the request's Accept-Language, then English — because a notification is rendered for a recipient whose language is not the request's, and in a queue or cron context there is no request at all. Each level falls through when it names a language the catalogue has no messages for, so a stored fr-FR gets the company's language rather than untranslated keys. The supported set is restated in server/ (the BFF boundary forbids importing the paraglide runtime) and the equality with project.inlang/settings.json is asserted by the spec rather than asked of a comment: resolving to a locale with no messages behind it degrades to English silently. The workers batch spec's hand-written contacts DDL gains the column too — drizzle's multi-row INSERT binds every schema column, so a missing one fails the whole batch (verified: it goes red without it). * feat(booking): let a client state their language on the public form The contact locale column landed with nowhere to fill it from. This asks the person booking, on every public surface, and stores the answer on the contact the booking creates. Nothing is selected by default, and that is the point of the change. A pre-selected English would make every booking look like a stated preference, and the reason to collect this at all is to find out how many clients actually ask for another language — which only works if silence stays distinguishable from a choice. So the payload omits the key when unanswered, and the column stays NULL. - LanguageChoice wraps the shared-ui RadioGroup and takes its option labels from the same table the Workspace and Profile pickers use, so there is one vocabulary for one choice. Labels are never translated: someone who cannot read English cannot find an option labelled in English, which would defeat the control. - Both public forms carry it — the wizard and the embed. An embed is what a company puts on its own website, so leaving it out there would have collected nothing from the higher-traffic path. - It is NOT shown when an agent books for someone else. The agent would be guessing at their client's language, and a guess recorded as a stated preference corrupts the one number this field exists to produce. - The submitted tag is reduced through the resolver's own normalizer, so es-MX lands on es-419 and a language we have no messages for is stored as NULL rather than as a promise we would break at send time. The API takes a free BCP-47 tag rather than an enum for the same reason a cosmetic field must never reject a booking. - Unlike name and phone, a locale does not fill forward: a returning client who picks a different language gets the newer answer, because being written to in English after asking for Spanish is the failure. An omitted choice still never clears a stored one. RadioGroup gains a legendClassName so one component can wear the wizard's and the embed's field-label idioms; the legend element always renders, since it is the group's accessible name. booking.service.ts is over the file-size cap already; the baseline moves 966 -> 972 rather than splitting it, which this change does not justify. * feat(contacts): let staff set and correct a contact's language Collection so far only happens where the client speaks for themselves, on the public booking form. That leaves no way to act on the commonest correction of all — the client said it on the phone, or picked wrong — and no way to undo a mistake once it is stored. The contact form is where a record gets fixed, so this is where the field belongs. Three states, same as the booking form: not set / English / Espanol. "Not set" is an option here rather than merely the initial state, because a correction path that cannot get back to "no stated preference" is not a correction path; it is first, and nothing is pre-selected, because a pre-selected English would turn every contact anyone ever edits into a stated preference and a stated preference is the only thing the column is evidence of. The control is the shape the profile locale picker already has — a select whose first option is the empty one — over the option labels the booking form and the settings pickers share, and over the same list of tags the server accepts. One vocabulary for one choice. Server side, the thing to get right is what an update MEANS by silence: - UpdateContactSchema is CreateContactSchema.partial(), and zod's .partial() KEEPS a .default(). A defaulted field therefore arrives on every request whether the caller sent it or not, and the handler writes it. `locale` carries no default for exactly that reason, and the spec asserts the ABSENCE OF THE KEY in what reaches the service rather than its value — a default of null would pass a value check and still be a silent overwrite of a real choice. - An explicit null must still clear it, so the handler tests `'locale' in raw` rather than `!== undefined`, as it already does for every other nullable field. - The service reduces whatever it is handed through the resolver's own normalizer before writing, so es-MX lands on es-419 and a language we have no messages for is stored as NULL. Every stored value is one resolveContactLocale would hand back; anything else is a promise broken at send time. The API keeps taking a free BCP-47 tag rather than an enum, matching the booking payload. * docs(i18n): make the contact-language demand signal readable, and honest `contacts.locale` exists to decide whether the rest of the multilingual work is worth building, so the deciding number needs a definition someone can look up — and one that cannot be quoted without what it cannot see. docs/developers/multilingual-demand-signal.md fixes the decision rule BEFORE there is data (a threshold chosen afterwards is not a threshold) and pins the denominator, which the rule alone left open. It gives four queries rather than one: the composition of stated languages, the answer rate that qualifies it, the size of the blind spot, and a seed-data check — identical per-tenant counts and a single created_at day are fixtures, not demand. The blind spot is structural. The question is only asked where a client speaks for themselves; the agent-on-behalf booking path carries no locale field, and that is deliberate, because an agent's guess recorded as a client's stated preference is exactly what would poison this measurement. Every such client therefore sits in '(not stated)' whatever they speak, so the signal undercounts by however much of a deployment's volume is agent-booked. Query C measures the floor of that gap, and the caveat is written inside every SQL block so a copy-paste cannot leave it behind. tests/unit/contacts/demand-signal-queries.spec.ts executes each block in the doc against a database built from the real migrations and asserts the counts on an adversarial fixture: an archived Spanish speaker, an agent contact with a locale, a stated `en` that is a choice and a NULL that is an absence. A renamed column now breaks a test instead of the monthly report, and a query that loses its undercount comment fails the suite. * fix(invoices): stop discarding the balance QuickBooks sends qbo/invoice-sync.ts already computes the partial-payment branch and passes the balance, and all three adapters dropped it as _balance because markPartial had nowhere to put it. The 'partial' status is derived, rendered in the client hub and the report-lock notice, and until now could not say what was still owed. Stores the amount PAID rather than QuickBooks' remaining Balance: our amountCents is the authoritative total, so remaining is derived against it and does not drift when either side edits the invoice. markPaid and markRefunded both clear it, so the amount can never contradict the derived status. The dollar-to-cent conversion happens once, in applyInvoiceStatusFromQBO where the QBO shape is still in view, so MarkPartialFn now carries cents already paid and no adapter repeats the arithmetic. Each side is rounded to its own exact cent before subtracting -- truncating the float difference loses a cent on ordinary amounts (a $100 invoice with $18.15 owed yields 8184.999999999999). Migration 0032 is a plain ADD COLUMN; invoices is FK-referenced, so the column goes at the end of the table definition to keep drizzle from rebuilding it. Refs #273. * feat(invoices): say what is still owed on a partially paid invoice The balance column landed with the previous commit and nothing read it. A 'partial' invoice could state that a payment had happened and not how much, so neither the inspector nor the client could see the outstanding figure. Remaining is derived, never stored: `amountCents - amountPaidCents` against our own authoritative total, clamped at zero. An external system can report more received than we billed after a divergent edit, and a negative balance shown to a client reads as a refund nobody promised. Two states, deliberately distinct. With a recorded amount the hub card and the invoices table say "$200.00 remaining", in the invoice's own snapshot currency rather than the viewer's default. With no recorded amount — rows written before the column existed — the card says the amount was not recorded and shows no figure at all. "$0.00 remaining" would be a false statement about money, and a client would read it as nothing owed. A viewer without the `financial` capability gets neither line: the balance is not unknown to the business, only to that reader, so `redactMoney` drops the field and the card stays silent. Three payload boundaries had to carry the new column, and one was dropping it silently: the public pay endpoint parses through `PublicInvoiceBodySchema` (IA-86), so an undeclared field is stripped one line before the payer's page — the column was written, the row carried it, and nothing failed. The checkout endpoint projects columns explicitly, and `InvoiceResponseSchema` describes the invoices list. All three now declare it, each pinned by a test. The OpenAPI snapshot reduces request schemas only, so no bump was needed. The public pay page's balance and Stripe pay panel are deliberately unchanged: the payment intent is minted from `amountCents`, and showing a reduced balance beside a charge that is not reduced would state a price the payer would not be charged. Charging the remainder is a payment-collection change, not a display one. File-size baseline bumped for four files already far over the cap (1202/510/769/674) whose growth here is 1-7 lines of return type and column projection — the return type cannot live anywhere but with its method. The invoices route stayed under the cap by extracting the amount cell instead. * docs(i18n): es-419 glossary before translating 4,249 keys One equivalent per canonical product term, decided once. Without it the same noun gets four translations across 29 module files and the result reads as machine output. Register: formal usted, sentence case for buttons. Usted is chosen for reach, not politeness: es-419 spans voseo countries where the tu imperative is audibly foreign, so usted is the only second person that is correct across the whole region. The glossary is machine-read rather than advisory. lint:i18n-glossary parses its own tables and holds messages/es-419 to them: - banned terms — only context-free wrong words are listed, so a hit is real - consistency — character-identical English must have identical Spanish, which is what stops Satisfactory reading two ways across the five modules that use it - placeholders — {name} tokens must survive translation; a dropped or renamed one compiles to a different function signature It also fails when it cannot trust its own inputs: markers gone, tables shrunk below a floor, or a divergence entry naming a key that does not exist. A gate that silently reads nothing passes everything. The 15 login-pilot keys predate the glossary and were written in tu; they are re-registered to usted here so the gate is green at rest rather than carrying a standing exception. * i18n(es-419): translate common.json (18 keys) First module end to end, to surface the mechanics at a scale where a mistake is cheap. Every one of these 18 keys is reused across the app -- 203 call sites, 65 of them common_cancel -- so they set the vocabulary the other 28 modules are held to. Register is usted, per docs/developers/i18n-glossary.md. Terms come from the glossary tables; the four words not in a table (Close, Copied, Done, Undo/Redo) are single-word UI verbs with no regional split. Proved the gates actually bite before trusting them. Deliberately broke each check and watched it fail: an empty value ("key": "") -- the shape a translator leaves behind when they skip a hard string -- fails lint:i18n-catalog naming the key; a banned term, a tu-register possessive, a dropped {placeholder} and the same English translated two ways across modules each fail lint:i18n-glossary. Verified rendered, not just compiled: with PARAGLIDE_LOCALE=es-419 the server renders lang="es-419" and the Spanish strings with JS off, so the locale is resolved in the paraglide ALS scope and not patched in at hydration. Light and dark, 1440px and 390px, no console errors. Spanish is ~31% wider than English across these 18 strings (Add -> Agregar is +96%), but nothing clipped: the surfaces checked size to their widest label, not to the English one. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01FGxHcE92k4t3d79y6DQfi3 * i18n(es-419): translate labels.json (99 keys) Carries the severity scale the rest of the catalogue inherits: Satisfactory / Monitor / Defect become Satisfactorio / Vigilar / Defecto, per the glossary's rating table. Settles the one decision this module could not avoid. A status word attaches to a feminine noun in one module and a masculine one in the next -- inspeccion, informe, factura, acuerdo -- while the consistency check forces exactly one Spanish string per English string. 'Published' alone labels an inspections tab and two report states in this file. Status labels are therefore masculine singular, agreeing with the implicit estado, which is the only form that needs no divergence declaration anywhere in the remaining catalogue. Prose hints still agree normally: 'Cancelled inspections' is a sentence, not a chip. The glossary said Published -> Publicado and Scheduled -> programada in adjacent rows; that contradiction is resolved here rather than left for the next module to guess at. Coverage 33 -> 132, exactly the 99 keys this module holds. * i18n(es-419): translate library.json (191 keys) The severity trio repeats here (repair_items_severity_*) and matches labels.json exactly, which is the point of doing these two together. Two collisions worth naming. 'Tag' and 'Label' are both etiqueta: they never share a surface, and inventing rotulo for one of them would spend a word nobody uses on a clash nobody sees. 'Est. min'/'Est. max' stay abbreviated -- the field is a narrow numeric input, est. abbreviates estimado in Spanish exactly as in English, and the glossary's ban on estimado is about the noun for a priced offer, not this abbreviation. Both are now glossary rows. Marketplace is left in English: it is a feature name, it is the word the region's software uses, and the MP badge that abbreviates it has no Spanish equivalent. Coverage 132 -> 323, exactly the 191 keys this module holds. * i18n(es-419): translate templates.json (114 keys) Third file carrying the severity trio (templates_mapping_row2_*), and it agrees with labels.json and library.json. The Spectora mapping panel keeps Spectora's vocabulary on the left-hand side: 'Orders' is translated as Ordenes because that is what the competitor calls the thing being mapped away. The glossary's ban is on 'orden de trabajo' as a name for our own Inspection, which this is not. Coverage 323 -> 437, exactly the 114 keys this module holds. * feat(agreements): neutral language disclosure, not a contractual clause Counsel advised against embedding InterNACHI's governing-language clause as platform contractual language: it allocates risk between the tenant and their client, and we are not a party, author none of the agreement text, and control none of its terms. This states a fact and decides nothing. A test forbids govern/prevail/controls/ binding/shall, because "strengthening the wording" is the edit that would undo it. Containment is structural, not advisory. The copy is a

, and the agreement body's write-time sanitizer allows neither -- so the disclosure cannot pass through the agreement pipeline and come out intact. Two guards hold the line: the spec asserts the agreement sanitizer destroys it, and a source scan asserts nothing on the agreement-body path imports the module. DOMPurify is deliberately not exercised here. Under happy-dom it drops the outermost element and applies no allow-list at all, so a round-trip assertion would have been a green that proved nothing about a browser. The spec reads the two real allow-lists from source instead. * feat(agreements): show the language disclosure beside the agreement, not in it Three surfaces show an agreement to a signer: the standalone signing page, the same section inside the client Hub, and the checkout sign card. A fourth — the archived copy rendered for the signed PDF — is the one a dispute produces. All four now carry the platform language disclosure, and none of them puts it in the agreement body. That distinction is the whole point. "Append it at render" and "append it to the body" produce identical screens and completely different legal positions: the body is a contract between the tenant and their client, which we are not a party to and write no word of. So the tests assert placement, not presence alone — the disclosure must sit outside the body container, and after a render the pinned snapshot and its content_hash must be byte-identical. They are: the hash is taken over the stored string, and the disclosure never enters it, so no existing signature is invalidated. The copy gained a plain-text heading, "Not part of this agreement", held to the same no-contractual-assertion test as the sentence. Position is what counsel asked for and a reader does not infer position from a border. Two guard changes fall out of this: - The renderer sanitizes with DISCLOSURE_SANITIZER_PROFILE, never . That component's allow-list is the tenant rich-text one, which permits neither

nor role, and would deliver the sentence as a loose paragraph among the terms — the exact reading this exists to prevent. Asserted against source, because DOMPurify under happy-dom applies no allow-list at all and both components emit identical markup on the first pass. - The containment scan previously listed agreements-render.ts as an agreement-body host, which would have kept the disclosure out of the archived copy entirely. It now names only the modules that compose the stored string; the renderer is held to a stronger pair of tests instead. * fix(i18n): drop the unused export on DEFAULT_CONTACT_LOCALE Full lint at the batch boundary found the one thing the per-task hooks cannot: knip went from zero to one finding. The constant is used only by the resolver in its own module, so it stops being an export rather than gaining a consumer -- the same call the same task made for normalizeLocale. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01FGxHcE92k4t3d79y6DQfi3 * feat(agreements): record which language disclosure a signer was shown The disclosure is on four screens as of the last commit, and nowhere in the database. That gap only matters later: bump the copy, and every signature ever collected silently becomes a signature against text nobody can identify. agreement_signers gains language_disclosure_version, nullable. Nullable is the feature, not a concession — NULL means "the platform did not draw this screen and cannot say what was on it", and two real cases produce it. Signatures older than this commit are one. The other is POST /api/inspections/:id/sign: that endpoint hands the agreement text to a caller through GET /:id/agreement and takes back a signature, so what the signer read is the caller's business, not ours. It records null. The public sign route records the live version, because the two surfaces it serves both render the disclosure component and a test says so. markSignedBySigner takes the version as a required argument and never defaults it. The service knows nothing about screens; only a caller does. An optional field would let the next sign surface record silence indistinguishable from a pre-feature signature. What the record now supports decides what the evidence surfaces may print: - The archived copy shows the disclosure only when EVERY signature on the envelope recorded the version live today. Superseded copy is archived nowhere, so against an older signature the choice is between printing nothing and printing words that signer demonstrably never read. It prints nothing. - /verify follows the same rule — Task 2 deferred it here for exactly this reason — and gets the answer as a server-decided boolean. A public page is not where that rule gets re-derived. - The certificate of completion is a different document: it states facts ABOUT the signing event rather than reproducing what was signed, so it names whatever version was recorded, superseded included, and stays silent when nothing was. Erasure lint checked rather than assumed: its PII heuristic matches none of language_disclosure_version, so no ERASURE_OUT_OF_SCOPE entry is needed until the heuristic widens. The migration is a plain ALTER TABLE ADD (column at the table end, no rebuild); db:check green at hand=87 / generated=87. Every guard here was run with its fix removed first; eleven went red. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * docs(agreements): put counsel's reasoning, and what it does NOT settle, in the module Counsel's recommendation was already reflected in the disclosure's shape. What was missing is everything around it: the date, the three facts that make the recommendation land, and — the part that costs something if it is lost — that California Civil Code §1632 is still an open question, and what that question gates. The reader this header is now written for is the one about to translate the agreement body. That work is blocked on §1632, it must not be started on an assumption about the answer, and translating the disclosure is not a route around it. Nothing in the module said so; a person could have read the whole file, seen a disclosure about language, and concluded translation was the obvious next step. The three supplied facts are recorded with their edges intact rather than summarised into comfort. The material one is that we hold NO record of the language a booking was negotiated in — negotiation is typically a phone call outside the software — and that contacts.locale is a stated reading preference that must not be offered as evidence of it. That distinction is the one most likely to be lost by someone looking for a field to point at. One question is deliberately unasked and now says so where it will be found: if a tenant offers a courtesy Spanish report, does that report's limitations notice suffice or does the agreement need a companion sentence? It depends on wording that does not exist yet, so asking now buys an answer to the wrong question. Whoever schedules that work owns asking it. Four assertions hold the record in place — the date, the §1632 gate and what it blocks, the parked question, and that the cited counsel document EXISTS, so a rename fails in CI rather than in a dispute. A tidy-up that prunes "background" comments is the realistic way this gets deleted. All four were run against a stripped module first and went red. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * feat(#270): tenant + user date/time format preferences Enums, not a pattern string: three real answers do not justify a parser and a validation surface. Defaults reproduce today's output exactly (us + 12h), so nothing changes for anyone until they choose. The workers specs build tenant_configs and users from literal CREATE TABLE strings, and the cmd-apply upsert binds every schema column, so both DDLs grow the columns too. Only the tenant_configs copy is guarded by a sync test; the users copy is duplicated inline in two specs with no guard. * feat(#270): resolve date/time format in the session context Per-field fallback, not per-object: a user who set only the clock keeps the tenant's date order. Same contract as useDisplayTimeZone -- which returns its default outside a data router rather than throwing, so the chrome still renders on routes that are not under auth-layout. resolveDisplayPrefs also rejects a stored value outside the enum. The drizzle enum is type-layer only and D1 has no CHECK constraint, so a bad row would otherwise reach Intl as an unknown option key. useTenantFormatPrefs is the second half of the design rule: anything a second party also reads anchors to the tenant, and that needs a hook rather than a convention every caller re-implements. * feat(#270): thread the format preference through the shared formatter format-date.ts pinned locale:'en-US' at two call sites with a comment saying Phase A would thread the viewer's locale through; it never did, so a tenant on es-419 read `Aug 3 · 7:58 AM EDT` -- English month, English meridiem, on a Spanish page. The pin was three files from anything a reviewer was looking at. `locale` is now a REQUIRED fourth argument, the same remedy already applied to `timeZone` in this file for the same class of defect: an optional locale with an 'en-US' default would have left all fourteen call sites rendering the bug. All fourteen now name a locale. The date is assembled part-by-part rather than handed to Intl as an option bag, because an option bag cannot express the requirement: Intl derives the ORDER from the locale, so es-419 with {month:'short',day:'numeric'} gives `11 sept`, not the American order a US company asked for. The month WORD comes from the locale, the ORDER from the enum. Only the clock goes to Intl whole, via hourCycle. Language follows the viewer, shape follows the tenant. Translating a month name cannot be misread; reordering one can, and the inspector, the client and the agent discuss one inspection out loud. Public surfaces have no session, so the tenant brand grows defaultLocale + dateFormat + timeFormat. The report payload already carried the brand. Defaults render byte-identically to before. * feat(#270): route the five hardcoded date renders through the shared formatter All five read the BROWSER's locale and the BROWSER's zone. That is not a cosmetic inconsistency: on this machine the settings tooltip rendered "2023/11/15 06:13:20" for an instant every other surface calls Nov 14 — a different DAY, from the same millisecond, on the same page. format-date.ts gains formatShapedDate / formatShapedDateTime. formatInspectionDateTime does not fit these callers: it takes a `now` and elides the year, which is right for a dashboard row and wrong for an audit stamp. The new pair takes no `now`, always carries the year, and always attaches the short zone name. Which resolution each site uses is a decision, not a detail. The settings panels and the Stripe delivery log are CHROME — one admin reading their own page — so the personal override applies. Version history is TENANT-anchored: collaborators point at a row and say "restore that one", and two dates for one snapshot is the failure the design forbids. Plan Risk 3 fired. v.$token.tsx had no brand and nothing in the payload identified the tenant, so GET /api/public/verify/report/:token now returns tenantSlug and the loader resolves the brand through resolveTenantBrand — the one resolver every other public surface already uses. The slug is already a company's public identifier and the reader is holding that company's report link. The guard goes in lint:i18n, not lint:tz as the plan said. check-tz-safety is scoped to three calendar paths and its patterns are only sound there; check-i18n already scans app/ + server/, already excludes the formatter modules, and already carried a test asserting the OPPOSITE of this rule ("bare toLocale is already viewer-responsive"). Two gates demanding different things of one line is how a fix gets reverted by the other gate. That test is inverted, and the inversion is the proof. useDisplayDateFormat / useDisplayTimeFormat are deleted: nothing ever wanted one axis without the other, and lint:deadcode flagged them. useChromeDateTimeFormat replaces them as the viewer-side counterpart to useInspectionDateTimeFormat. The file-size baseline moves for three files, not one: the gate reads the working tree, so it cannot be satisfied one commit at a time. VersionHistoryPanel is this commit's; the two settings routes belong to the Settings UI that follows. * feat(#270): settings UI for the tenant default and the personal override Both pickers render the SAME component, and both label every option with a worked example instead of the enum's name — "2026-09-11", "11 Sep 2026", "14:30". "ISO" tells a reader nothing they can check, and an unverifiable label is why somebody changes this setting twice. The sample instant is fixed rather than `Date.now()`: a live clock renders one value on the server and another in the browser, and the current minute teaches nobody anything. The write path did not exist and the plan did not list it: UpdateBrandingSchema, PatchProfileSchema, the profile GET projection and PATCH assignment, and the branding read-back and no-config-row default all had to be taught the two columns. Both schemas use `.optional()` with NO `.default()`, because a default turns an omitted key into an explicitly-sent one and rewrites a preference the caller never mentioned. tests/unit/session/format-prefs-write-path.spec.ts asserts the ABSENCE of the key — asserting its value would pass against exactly the broken schema it exists to catch. Chrome caught a defect nothing else could have. Conform's parseWithZod maps an empty string to `undefined`, so "Use workspace default" dropped the key out of the PATCH body and the stale override survived the save. The server was right the whole time — a hand-rolled PATCH {dateFormat:''} cleared it — and every type and unit test passed. `overrideFieldFromForm` reads the raw FormData, where '' still means clear and an absent key still means leave-alone. `timezone` and `locale` shipped with the same defect and are fixed in the same loop: clearing either override through the profile UI has never worked. The profile hint says what the setting does NOT reach, because the answer is counter-intuitive and every support ticket that re-opens the decision starts with someone assuming the opposite. Verified live: with the tenant on iso/24h and the user on eu/12h, the inspections list read 2026-08-03 · 07:58 EDT while the settings tooltip read 3 Aug 2026 · 10:32 PM EDT. Both sides of the rule, on one screen, at the same time. * fix(reports): bind inspection_results.report_id at creation `uq_results_report` replaced `uq_results_inspection`, but it is a unique index on a NULLABLE column: SQLite accepts any number of NULLs. Both creation paths wrote the results row without a `report_id`, so nothing errored and every per-report read matched no document or a sibling's. `createPrimaryReport` now returns its id, and both paths create the report BEFORE the results row that has to name it. * feat(reports): per-report list on the order page, with a delete that names what it destroys One order delivers several documents, but the page showed a single report status pill derived from the inspection row — so an order carrying three deliverables looked exactly like an order carrying one. The list rides the existing hub payload rather than a second round trip. Deletion is the one irreversible action here: a report owns its findings document, its Yjs state and its version chain, and with no foreign keys nothing notices the orphans. The confirmation names the report and says that the content already filled into it is destroyed. Two refusals, decided by ONE server function the endpoint enforces and the payload reports, so the card cannot offer what the API refuses: - the primary report (the collab route fails closed without one, so deleting it makes the whole order uneditable); - a published report (delivered, and its signed versions are what let a client verify the document they hold). Also: ConfirmDialog's "Cancel"/"Delete" were bare literals, shipping untranslated chrome from all ten of its call sites. Fixed at source. And the hub facade's return type is now DERIVED from its delegate — the hand-copy had rotted past `services`, `communication` and `unlockedAt`. * i18n(es-419): translate editor.json (135 keys) * i18n(es-419): translate editor-2.json (205 keys) * i18n(es-419): translate editor-3.json (102 keys) * i18n(es-419): translate editor-4.json (153 keys) Also narrows one glossary ban that this module proves false-fires: the Repair Items row ruled out the word *recomendaciones* outright, but ASTM E2018 has a "1.5 Recommendations" section (here and in pca-report.json) and public.json says "grouped under Recommendations". The prohibition is real but cannot be a machine ban, and a gate with false positives gets bypassed — so it moves to the Why column as a rule. The Estimate row gets the same treatment in prose before someone machine-bans *estimado* and breaks "Costo estimado". Adds the editor-family and ASTM PCA term tables (29 rows) so the seven remaining waves inherit the decisions rather than re-arguing them, plus a rule that a format literal a parser matches on stays English — the units CSV hint shows `label,floor` and parseUnitCsv compares against exactly that. * i18n(es-419): translate reports.json (258 keys) * i18n(es-419): translate pca-report.json (130 keys) Also records the client-portal and invoice vocabulary as glossary rows (21). reports.json shares 58 English strings with checkout, inspections, communication, booking, components, misc and public — more overlap than any other module — so the waves that own those files inherit these decisions instead of re-deciding them and red-gating the consistency check. * i18n(es-419): translate settings.json (244 keys) The settings hub, profile, account/security, company, data and team pages. Glossary gains a settings section: the chrome words here (Configuración, Facturación, Rol, Zona horaria, Sin definir, Guardado.) recur across settings-components, settings-integrations, misc and nav, so they are decided once rather than re-argued per module. Settings is Configuracion, singular, and only the plural Ajustes is banned — the singular ajuste already means preset. Coverage 1427 -> 1671 of 4323. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): translate settings-catalog.json (123 keys) Services, inspection workflow, inspection/event/contractor types, My Schedule and the report-link expiry controls. Glossary gains the catalogue subsection: Slug is Identificador (the radon_pickup placeholder beside it stays English — it is a format sample), and the report-link bulk actions are Aplicar/Quitar vencimiento because Spanish vencer is intransitive and 'Expire N links' has no verb-for-verb rendering. Coverage 1671 -> 1794 of 4323. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): translate settings-components.json (491 keys) The largest module in the catalogue: holidays, weekly schedule, Google Calendar, booking policies, the report gate, Stripe, video, 2FA, four email providers and managed SMS. First declared divergence. English 'Resend' is two unrelated things: the verb on the team page (Reenviar) and the email vendor Resend in the integrations catalogue and provider select, where rule 3 forbids translating a product name. Both readings are registered under gate:divergence — and every key sharing that English has to sit on the bullet's first line or the parser drops it, which is now written down beside the marker. Glossary also fixes how third-party text is handled: menu paths into Stripe / Twilio / Cloudflare, credential field names, key prefixes, format samples and the SMS keywords STOP / START / HELP all stay English. Translating a STOP keyword is a compliance failure, not a typo. Coverage 1794 -> 2285 of 4323. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): translate settings-integrations.json (294 keys) Communication, message templates, QuickBooks, connected MCP apps, billing, GDPR compliance and automations. Second declared divergence: English 'Subject' is a homograph. On the template editor it is the email subject line (Asunto); in the erasure log it is the GDPR data subject, a person (Interesado). No Spanish word covers both. Three more instances of the {plural} call-site defect the plan already tracks — settings_msgtpl_delete_conflict, settings_msgtpl_segments_count and settings_billing_seat_line. All three now use number-invariant phrasing that attaches {plural} to a noun taking a bare -s (flujo/flujos, segmento/segmentos, puesto/puestos), because automatizacion+s is not a Spanish word. settings_msgtpl_delete_confirm_* is a fourth shape of the same problem: the sentence is split around the name, the prefix is pinned to 'Eliminar' by the consistency rule, and Spanish cannot then open with the mandatory inverted question mark. Rendered as a statement instead. Coverage 2285 -> 2579 of 4323. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): translate auth.json (126 keys) Finishes the module the Phase C login pilot started: password rules, forgot / reset, team invite accept, first-run setup, and the whole agent invite / signup / sign-in track. auth is almost entirely imperatives, which is exactly where the usted decision is lost silently — the register gate reads pronouns, so it would have caught 'tus' and would not have caught 'Ingresa'. Every imperative here is the usted form: Ingrese, Revise, Defina, Solicite, Cree, Configure, Regístrese. English uses both 'log in' and 'sign in' for one act; Spanish has one, so both land on Iniciar sesion and both 'Back to ...' links become Volver al inicio de sesion — the destination is the page. Still distinct from Firmar. 'You have been invited' is rendered as 'Usted recibio una invitacion' rather than 'Ha sido invitado': the catalogue cannot know the reader's gender, and a participle agreeing with the reader is wrong half the time. Coverage 2579 -> 2705 of 4323. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): disambiguate one settings-catalog string from a tu imperative 'Espera antes de que el editor avance...' was meant as the noun (the delay) but is a complete, correct tu imperative read the other way ('Wait before...'), and nothing in the sentence forces the noun reading. Retraso is the noun only, and matches settings_automations_delay_title. Found by sweeping the five modules for tu-imperative verb forms, which is the one register error no gate can see: check-i18n-glossary matches pronouns and clitics, not verb conjugations. Eleven other hits in that sweep were genuine third-person indicatives or nouns. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * i18n(es-419): translate inspections.json (251 keys) * i18n(es-419): translate contacts.json (133 keys) * i18n(es-419): translate calendar.json (61 keys) * i18n(es-419): translate booking.json (74 keys) * i18n(es-419): translate checkout.json (175 keys) * i18n(es-419): translate public.json (165 keys) * i18n(es-419): translate communication.json (103 keys) * i18n(es-419): translate components.json (183 keys) Shared-ui surface text — modals, the new-inspection wizard, the inspection hub action sheets, link expiry and the notification preference matrix. Every string here renders on more than one screen, so the pinned lexicon did most of the work: 44 of the strings already had a committed Spanish form elsewhere and were copied character for character. Two strings set the standard for a later module: "Workspace" (the email group) -> "Espacio de trabajo", which nav must match, and "Creating…" -> "Creando…", which misc must match. "Concierge" as an email group follows the glossary's "concierge review" -> "revisión previa" rather than the doorman sense. The US address placeholder stays English, as already shipped elsewhere. * i18n(es-419): translate nav.json (30 keys) The chrome every user sees on every page. Fifteen of the thirty were already pinned by earlier modules, including "Workspace" -> "Espacio de trabajo" set one commit ago in components.json. "Metrics" -> "Métricas" is set here and binds metrics.json and misc.json. Sidebar labels set the width of the rail: Settings -> Configuración (+63%), Inspections -> Inspecciones, and the Workspace section header -> Espacio de trabajo (+100%) are the ones the browser pass must look at in the collapsed and expanded rail and in the mobile drawer. Roughly half these keys render only as aria-label or title (command palette, menu open/close, sidebar expand/collapse, the theme switcher), so they need a DOM-attribute sweep, not a visual read. * i18n(es-419): translate helpers.json (54 keys) Defaults and derived strings the helper modules hand to the UI: booking steps and time windows, rating descriptions, the PDF service errors, the Google Calendar OAuth failure set, onboarding checklist labels and the not-found titles. Two judgement calls worth stating. The booking window details are display-only (booking-constants.ts passes them straight through), so the clock strings become "8:00 a.m. - 12:00 p.m." to match what Intl actually renders for es-419 rather than staying English. And "Morning"/"Afternoon" became "Por la mañana"/"Por la tarde": bare "Mañana" reads as "tomorrow" in a screen where the user has just picked a date. "Confirm" -> "Confirmar" is set here and binds misc.json. * i18n(es-419): translate validation.json (28 keys) Form error text — the copy a user meets at their most frustrated moment, and the file in the catalogue most exposed to the tú/usted trap because it is almost entirely imperatives and second person. Every imperative here is usted: Ingrese, Confirme, Vuelva a escribir. A sweep for tú possessives, tú preterites and the bare tú imperatives the register gate cannot see returned nothing in this file. "acct_" stays English inside the Stripe account-ID message: it is the literal prefix the validator matches on. "Enter a valid email address" follows the already-shipped settings-integrations wording (dirección de correo electrónico válida) rather than inventing a second phrasing for the same failure. * i18n(es-419): translate metrics.json (47 keys) The metrics dashboard: KPI tiles, two charts, three tables and the date-range picker. "Avg Order Value" became "Valor promedio por inspección" rather than anything built on *orden*. The product forbids "Order" as a name for an inspection in English and the Spanish glossary bans *orden de trabajo* for the same reason; the figure is revenue divided by inspections, so naming it after the inspection is both the accurate reading and the one the terminology allows. "{count} insp" keeps its abbreviation — it is the same clipping in Spanish and it sits in a narrow bar-chart label. * i18n(es-419): translate media.json (93 keys) Photo Studio, the cropper, the signature pad and the video walk-through. A third divergence is declared with it. English "Free" is price on the agent-portal invite (Gratis) and shape in the photo cropper, where it sits beside Portrait and Landscape and means the unconstrained aspect ratio (Libre). Both keys are on the bullet's first line, because the parser only reads keys from a line beginning with a dash and .every() means an unlisted key voids the whole declaration. Verified the declaration is load-bearing: with the bullet disabled the gate fails naming "Free", with it restored the gate is green. The three-part video privacy sentence is reordered for Spanish and still joins correctly — VideoCapture.tsx concatenates before + " " + no + " " + after, so the emphasis lands on the negation as it does in English. * i18n(es-419): translate misc.json (221 keys) The catch-all, and the last file in the catalogue. Command palette, audit trail, the canned-comment / defect-category / rating-system editors, the documents panel, the legal checkbox, the template combobox and the whole invoices surface. Fifty-four of the strings were already pinned by the twenty-eight modules that came before, which is what a catch-all looks like when it is translated last. Two things needed reading the render, not the key. The legal checkbox is built from four fragments, so the articles have to agree across the seam: "Acepto los" + Términos del servicio + "y reconozco la" + Política de privacidad. And the keyboard hints keep their letters — "G luego I" — because G and I are the keys the shortcut handler listens for, not words. es-419 coverage is now 4323 of 4323. * chore(i18n): restore the catalog parity gate Coverage is 4323/4323 across all 29 modules, so a missing es-419 key is no longer the expected state — it is a gap that reaches a Spanish-speaking user as English mid-sentence. FALLBACK_ALLOW stays empty: nothing needed a grace entry. Proven red before landing: deleting nav_item_inspections from messages/es-419/nav.json made the gate exit 1 naming that key; restoring the file (backup-and-move, never `git checkout --`, which would have destroyed an uncommitted module while leaving the gates green) returned it to 4323/4323. Closes #268. * fix(i18n): three es-419 layouts that were sized for the English word Found by running the app under es-419 — the browser pass the translation waves deferred. All three are containers sized for an English label that the Spanish one outgrows; none of them is visible in the JSON. - Notification preference matrix: channel columns were 5rem and "Correo electrónico" measures 85px, so it bled out of its column into the next one. 6rem fits it; English is unaffected. - Editor item-filter strip: the column is a fixed 280px, so "Sin calificar" broke mid-phrase inside its own chip while its neighbours stayed on one line. The strip now wraps (the batch toggle drops to a second row) and the chip labels do not. - Services DURATION column: durationLabel's own comment says the English was already compacted because "1 hr 30 min" wrapped. es-419 "2 h 30 min" has spaces to break at and split as "2 h 30 / min"; a duration is one token. Verified at 1280px in light and dark by applying each fix to the live DOM and re-measuring: no clipping, no spill, no page overflow. Catalogue untouched — coverage stays 4323/4323. * chore(mcp): record the per-report delete route in the OpenAPI snapshot Task 4b added DELETE /api/inspections/:id/reports/:reportId and the snapshot gate lives only in the full unit run, not pre-commit, so the batch boundary is the first place it could be seen. Purely additive: 452 routes, was 451. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * test(collab): stub the session hooks in the second VersionHistoryPanel suite #270 Task 4 routed VersionHistoryPanel through useDisplayTimeZone, whose useRouteLoaderData invariants outside a data router. version-history-panel.test.ts got the stub; this suite renders the same component and did not, so it went red at the batch boundary rather than at the commit that caused it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * test(e2e): scope the People 'Primary' assertions now that reports have their own The per-report card added by the reports work renders a Primary badge on the same page, so two page-wide exact-text matches for 'Primary' started resolving to two nodes. Asserted as relationships instead: the badge in the person's own row, and the count taken inside the people-groups container. Note people-group-client is on the group HEADING -- its rows are siblings, so scoping to that testid finds nothing. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * feat(events): make results_received notify `results_received` was a dead state: it existed in the schema, in the API's Zod enum, and in EventService, which wrote `results_received_at` and told nobody — the automation trigger list had only `event.created` and `event.completed`. The single moment a radon client has been waiting 48 hours for notified no one, while "we completed the pickup" did. Adds the `event.results_received` trigger (type-layer enum only, no DDL) with client and buyer's-agent seeds on both seed paths, email and SMS, plus the two notification classes the send boundary needs to name them. It fires through the ordinary automation fan-out rather than the hand-rolled pre-insert the reminder/follow-up paths use: those exist only because their send time is COMPUTED, and they pay for it by addressing one recipient on one channel. Results are "now", so every rule, channel and recipient applies. TriggerContext gains an optional `eventId` so the delivered copy can name the event type and a retried transition dedupes on uq_automation_logs_event instead of notifying the client twice. Also fixes the existing follow-up seed's copy, which pointed the client at "your inspection report", singular — the wrong document once an order carries more than one deliverable. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * feat(events): make the follow-up delay per event type The 72-hour follow-up delay was a constant in EventService. That is a radon answer — sampling is a 48-hour standard and the lab takes its own time — and it is wrong for a sewer scope, whose results exist the moment the camera comes out, where a follow-up three days later tells the client something they already knew. Adds `event_types.follow_up_delay_hours`, appended at table end, defaulting to the 72 hours that used to be hard-coded so nothing moves for any existing tenant on deploy. Reachable through both event-type CRUD surfaces (the app API and the admin/MCP one) — a column no caller can set would be a setting in name only. Zero is a legitimate value, so the read uses `??` and neither schema rejects it; the specs fail against `||`, which is the trap this shape invites. Migration 0035, local-applied; `db:check` clean at 87/87 tables, migchain intact at 36 snapshots. The file-size baseline moves for admin-settings.ts, which the two schema fields push 6 lines past its recorded size. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * feat(events): give the inspection hub the visits that make up the job `inspection_events` has had a table, a full CRUD API and an automation trigger per transition since it shipped, and no frontend anywhere — which is why production holds zero rows. A radon job is a drop-off and a pickup two days apart; without this card the second half of it lived in the inspector's head and nowhere else. The card sits beside Services on purpose: the visits ARE what the services committed the company to turning up for. Its add picker leads with the visit types the order's own services imply (`services.default_event_type_slugs`), so booking a radon test proposes its drop-off and its pickup in that order rather than asking anyone to remember them. A slug with no surviving event type is simply not proposed — the same rule `ServiceService.proposeEventsForService` applies server-side. Who may do what comes from ONE function, `visitActions(role, status)`, read by the card and the row alike, so the page cannot grow a second opinion. Completion is the FIELD's act: the inspector in the crawlspace is the person who knows the visit is over, so every role is offered it. Recording that lab results ARRIVED is an office act about a different moment entirely — the sample reaching the lab is not the inspector finishing — so it is owner/manager. This governs what the UI INVITES; the server is where it is enforced. The loader and both handlers live in `app/lib/inspection-visits.ts` and the add picker in its own component, rather than inline: the route is against its size ceiling, which is the same reason `inspection-order-actions.ts` exists beside it. The route's baseline still moves by 40 lines for the card's own wiring. One trap worth naming, because it cost a browser pass to find: `api` is a plain record of named clients, not a Hono proxy, so `api["event-types"]` is `undefined` and — behind the optional chaining these best-effort fetches use — degrades to an empty list SILENTLY. The symptom was a visit row titled with a raw UUID. Everything hangs off `api.events`. Twenty strings, both catalogues, es-419 at full parity. * feat(events): give the follow-up delay a control a human can reach `event_types.follow_up_delay_hours` shipped with a column, a default and both CRUD schemas, and no UI — Settings > Event types is the only screen that edits an event type and it did not offer the field, so the setting was API-only and in practice unsettable. Zero is a legitimate value ("a sewer scope's results exist when the camera comes out"), which makes the control's two failure modes symmetrical and both easy to write by accident: - a READ that treats 0 as unset. The list cell uses `??` and an explicit `=== 0`, and renders "Immediately" rather than "0 h". - a WRITE that treats "untouched" as 0. The form field holds a STRING, not a number, because `Number("")` is 0: an emptied box is OMITTED from the PATCH, and since the PUT schema is a `.partial()` an absent key leaves the stored delay alone. Both are pinned by tests confirmed to fail when the fix is removed — `||` for the first, an unconditional key for the second. The hint is always-on, against the usual rule, because the field's whole subtlety is that 0 is a setting rather than a blank and neither a label nor a placeholder can say that. Five strings, in both catalogues; es-419 stays at full parity. * fix(calendar): make a calendar item land somewhere real The calendar is the field's entry point, so the only thing that matters about an item is whether tapping it goes anywhere. Two kinds did not. The modal offered "Open Inspection" for ANY item carrying an id, and fell back to the item's OWN id when it had no inspection id — so a company holiday, whose id is `holiday:2026-08-04`, navigated to `/inspections/holiday:2026-08-04`. Landing on a 404 in a crawlspace is the failure this removes. Destination now comes from one pure function, `calendarItemHref`, which is allowed to answer null; the modal renders no action at all in that case rather than a confident button into nothing. A visit resolves to its INSPECTION, never to its own event id, which is the same 404 wearing a different hat. The action is a real now, so an inspector in a driveway can long-press it open in another tab. Second, an ALL-DAY item's date was converted as if it were an instant: the same holiday, stored as `2026-08-27`, rendered "Aug 26, 2026, 8:00 PM EDT" — the wrong DAY and a time nobody set. All-day items are formatted from their civil date, anchored and read back at UTC so the day comes out as written. Timed items keep showing the wall clock the SERVER already resolved in the viewer's zone (startTime/endTime), never one re-derived here. Visit status is translated instead of printed with its underscores swapped for spaces, so a Spanish UI stops showing "results received". Those labels follow the VIEWER'S LANGUAGE via the catalogue — deliberately not `useDisplayLocale`, which resolves the tenant's locale SETTING and is why the chrome above still says "August 2026" under a Spanish UI. Language follows the viewer; only date SHAPE follows the tenant. Two DST-boundary cases join the tz spec, for the interval that is COMPUTED rather than entered: a radon pickup at dropOff + 48h across US spring-forward keeps its instant but MOVES its wall clock (09:00 EST to 10:00 EDT), and a late-evening pickup at 02:00Z belongs to the previous civil day in a UTC-negative zone. Both were confirmed to fail when civilPartsInTz is replaced with an ISO slice. Visits already appeared as calendar items — `listCalendarItems` has emitted `kind: 'inspection_event'` all along. Three strings, both catalogues, es-419 at full parity. * feat(events): keep results_received in the office, enforced at the API Completing a visit is the field's own act — the inspector standing on site knows it is over. Recording that lab RESULTS arrived is an office act about a different event, and until now the API took it from anyone: `visitActions` declined to offer the verb, but the UI is not a gate. One hand-rolled PUT to `/api/events/:id` moved a radon visit to results_received and fired the follow-up automation. The distinction is body-dependent — one method, one path, two transitions — so route-level `requireRole` cannot express it; the check sits in the handler ahead of the write. Asserted the way this repo has learned to: real requests through the routers mounted as `server/index.ts` mounts them, reading status codes off responses. A capability checked inside a service proves the service checks it, and `createRoutesStub` runs no middleware at all. Each 403 was confirmed to go red first — the results_received gate stubbed out returns 200, and widening either delete guard to include 'inspector' turns those two red as well. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * fix(sync): send a field write to the report it belongs to `inspection_results` is one row per REPORT — `uq_results_report` is unique on `report_id`, and the standard report and the sewer report each own their findings. The two routes the field actually uses were never converted: the inspector signature and the authoritative photo delete both selected `WHERE inspection_id = ?` and took whatever the scan returned first. On an order with two reports that is a coin toss. An inspector signs on site and the signature lands on the sewer scope; a photo is deleted from a phone and it comes out of the other document. Worse in the insert branch: with no results row yet, the signature route created one with a NULL `report_id`. The unique index permits any number of NULLs, so nothing complained — the row simply became invisible to every report-scoped read. That is the shape of the orphan rows already in the database. Both now resolve the order's primary report the way the collab route does (the offline client holds no report id, so the primary is the answer), and fail closed when there is not one rather than writing a row that belongs to no deliverable. The editor's Durable Object already worked this way — "per REPORT when we know which one"; this is the same rule reaching the field. The specs seed the ANCILLARY row first, so an inspection-keyed select picks the wrong document and they fail rather than passing by row order. Confirmed against the unfixed routes: all four red, and each one red for its own reason — signature on the sewer row, `sewer-a.jpg` deleted instead of `primary-a.jpg`, `report_id` NULL, and a missing primary report answered 200. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_0125yvQL7kgEym1oR6hiqUAQ * feat(payments): give a payment a row of its own An append-only `order_payments` table. It records what was RECEIVED, never what is OWED — the total keeps coming from the money-authority chain, and the invoice's paid_at / partial_paid_at / amount_paid_cents become a cache that a later commit recomputes from these rows. Keyed on the ORDER, not the invoice: a booking deposit is taken before any invoice exists, so an invoice-keyed table would make `kind: 'deposit'` unrepresentable and force a re-key of append-only financial rows later. `invoice_id` is a nullable link, written once when the invoice is raised. `inspection_id` is nullable too, against the original design: a …

Uh oh!

Partial / installment payment collection UI #273

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions