Changelog

A board save the database did not store is no longer reported as saved. When the API could not prepare the board write at all, it wrote no runs and no run lines, answered the browser with an ordinary success, and the browser then treated those records as already in the database — so they were left out of every later save. A scheduler's lane edits were gone, with a green "Synced" over them, and nothing said so: not the board, not the sync pill, and not the change log, which recorded the edit as made and even recorded a deletion that never happened. Measured by driving the real API: the reply was {"ok":true,"written":1} with not one run or run line stored, and two change-log entries filed for a save that did not happen. The board now shows a notice naming exactly what was not stored, in the database's own words, saying that the edits are still on the screen and that the next save sends them again — it has no dismiss button and it clears itself only when a save really does land. Nothing is retried automatically, on purpose. The two things that can go wrong on one save are kept apart: "we saved it and could not check whether somebody else had edited it" is a different notice from "we did not save it". Records the database could not file at all — a run with no number, a run line with no name — are now named too, instead of being dropped with only a server log line.

A test that crashed reported a smaller break than it caused, so the number read off it was not a measurement. One of the checks over the production purge script read the dump file it produces without first asking whether there was one. When the run under test wrote no dump — which is what happens if a collection is missing from the registry — that read raised an error and the whole file stopped where it stood, running none of its remaining checks. Anybody deliberately breaking something to prove the check works would then read off whatever partial count was printed and publish it. Measured, on exactly that break: the file stopped after 59 failures with 127 still to come, printed no summary line and no completion marker, and the backend runner reported it as failed with no count at all — so failures plus passes could not be reconciled against anything. Read defensively, the same break reports 102 failures and 177 passes, which is exactly the file's own total. A missing result is now a third state and never zero: the helpers answer −1 for the run produced no such list and 0 only for it produced an empty one, and the absent case is a failure with a name on it rather than a check that quietly does not run.

The tool built to catch stale claims carried two of its own, and nothing in the repository could have told us. tools/claim-census.js named 91-claim-census.js under tests/suites/ as the suite that gates it — twice, once in its header and once in what it prints when it finds something — and that file has never existed, at any commit, on any branch. The census suite landed under another number and was renumbered again since. Both citations are gone: the gate is now found by name at run time, by the one part of a suite's filename a renumber does not touch, so the path the tool prints is one it has just looked up rather than one somebody typed into a comment. It answers three ways, keeping "we could not list that directory" apart from "there is no such suite", and it does not refuse — a census that declines to print because a sentence in its own header went stale is a census somebody deletes.

The refusal belongs instead to a new check over the whole tree, tools/suite-citation-check.js, which is the answer to a cost #842 named and declined to pay: it refused to renumber all 122 suites partly because "a rename rots the prose citations of the old filename and nothing checks for a stale one". Nothing did. Measured over CLAUDE.md, tools/, docs/ and .github/ — 182 files, 365 citations — the tree held seven rotted citations across five files, of which the issue knew about two, and three of the five are files a dispatch is sent to read: the schedule-board doc pointed at a suite number that was moved off a collided prefix by the very commit whose subject says it settled that doc's figures, and the compliance register pointed at a suite that was folded into another one before it ever merged. All seven are corrected, each naming the file that really holds the assertions, and each keeping the wrong name as a quotation so the record of what was wrong is not destroyed by the fix.

The check proves it can register a positive before its zero is believed: it self-tests on every invocation over the citations as they really stood, and refuses — rather than reporting a clean sweep — if its own matcher cannot find them, or if there was nothing to look at. A citation whose file is missing is reported beside the file on disk that carries the same name under a different number, which makes the repair a one-word edit. A suite directory it could not read is reported as we could not look and never as a tree with nothing wrong in it.

A booking made after the database was cleared is no longer thrown away as if it had been made before it. A browser opening FleetView for the first time after the database was cleared would read the empty database, take a booking, fail to send it (no signal, a shut laptop) — and then, on the next start, silently delete that booking and report in its log that the copy "predates a purge of the database". It did not: it had been written a whole day afterwards. The cause was that the marker recording this browser has looked was only ever written when a copy was actually thrown away, so a browser that had looked and found nothing to throw away was indistinguishable from one that had never looked at all — and the second was answered by deleting its work. A start that finds the database cleared and has nothing of its own to discard now records that it looked, so the work survives; measured over a four-start sequence on one machine's storage, the booking now survives all four.

Two things are unchanged on purpose. A copy that really was written before the clear-out is still discarded even when it is carrying unsent work, which is the deliberate rule that stops a stale copy being written back over live data. And the obvious one-line fix — keeping any copy that has unsent work in it — was measured and refused, because it would have exempted exactly the machine that rule was written for.

The log line itself is also now honest in two ways it was not. It no longer claims a copy is old when it is not: it says which of the three things it actually established — that the copy predates the clear-out, that it does not, or that it could not be read at all. And where a copy is discarded it now says what went with it, naming whether it was carrying unsent work, instead of only saying why — with "we could not tell" kept distinct from "nothing was lost".

The driver tablet no longer says "Synced" before it has read anything. At start-up, on a build with a database configured, the sync pill took its one reading from the app before the first read of the database had come back — and the answer it got was "Synced", because that was what the app said when it had no news either way. So "we have not started" and "we finished and everything is fine" were the same answer. The pill then cleared itself off the screen after 2.6 seconds and nothing ever corrected it, because nothing is announced while a read is still out. Usually the read landed a moment later and no harm was done. Behind a wifi sign-in page — a mine-site gate, a depot with a captive portal — the request is held open rather than refused, so the green "Synced" was the last word for the rest of the shift, over a run sheet nobody had checked against the office. The app now answers reading until a whole document has actually come back and been merged, and the cab shows "Not checked with the office yet — this is what was already on the tablet", drawn in the hatched treatment this app uses for we do not know, and it does not hide itself. It is deliberately not the same answer as a read that asked and failed: not having asked yet and having been refused are different phone calls. A build with no database configured is unchanged — it is not waiting for anything, and its pill stays hidden exactly as it always has.

The check that stops a merge closing the wrong backlog item was reading one commit and calling it a clean bill. Every change is scanned for a wording that makes GitHub close an item nobody meant to close — a comma-separated list where only the first is acted on, or a sentence saying an item was not fixed, which the parser reads as an instruction to close it anyway. That scan reads the commit messages the checkout in front of it happens to hold, and the automated checks fetch only the most recent commit, so it was reading one message and reporting a clean result over it. Measured on two runs of the same change: the automated check examined 1 message and passed; the same change read with the full history examined 1,558 and found two malformed lines in one of the change's own messages. The gap was 1,557 messages, and always in the reassuring direction — the newest messages are exactly the ones a truncated checkout drops, and exactly the ones a check run before a merge exists to read. Two things changed. The pre-merge check now fetches the whole history, measured at about ten seconds and 20 MB more on a step that took two seconds. And the scan now has three answers instead of two: it says clear only when it could see everything, says could not look when it could not, and prints how many messages it examined beside whichever answer it gives, so a scan of one message can never again be reported in the same words as a scan of the lot. A run that finds a problem still reports it whatever it could see, because finding one is finding one.

A con note's pickup and delivery boxes now open on the places the con note already names. The panel only ever filled them from a copy saved by this same panel, so a con note that had not been through it opened asking you to choose a location — a few inches under a header already reading FLEETWOOD → HOPE DOWNS 1. That is every con note imported from FMS. The location is durable reference data and defaults; the site contact still never does, which was the whole point of this panel — a name nobody has checked must not be the easy option. A place already saved onto the con note still wins, so a default never quietly overwrites somebody's decision. And where the con note names an end the address book does not hold — which is the ordinary state until the places are imported — the panel now says so and prints what the con note says, instead of showing an empty box that looks identical to a con note naming nowhere at all.

The Fleet Dynamics time-zone knob can now be set by a deploy, and a guard refuses any future setting that nothing can reach. Fleet Dynamics sends a bare wall clock with no time zone, and how many minutes to subtract from it decides whether a truck's last fix reads as four minutes old or 147 days in the past. The Lambda has read that setting since the fix that introduced it, and the template has declared it — but the deploy workflow, which is the only way the stack is ever deployed, had no way to pass it. Measured on the merged tree: the parameter appeared 5 times in the template and 0 times in the workflow, against 4 for its neighbour, which is the control that makes that zero a measurement rather than a broken search. It is the same defect, in the same file, one parameter along from the one repaired earlier — left behind by that repair.

The deploy now offers the setting, and refuses a value it cannot use rather than passing it on: anything non-numeric, and anything outside ±14 hours, is rejected by name before the build runs — because a value the Lambda cannot parse is read there as zero, which silently asserts the feed is UTC. A knob that reports itself set while doing nothing is the failure this exists to prevent.

Leaving it blank and setting it to zero are now different acts, and the deploy log says which one happened. Blank changes nothing; zero is a positive statement that the feed really is UTC. That distinction exists only in the deploy log, because the running code cannot tell missing from empty from zero — and the change deliberately does not make it refuse an unset value, since doing so would leave every fix undated until somebody set it, taking the live map dark. That trade-off is recorded rather than taken quietly.

And the wider problem behind it is now guarded. A parameter that exists and cannot be set turned out to be a class rather than an incident: of 44 settings the stack declares, 12 can be set by a deploy and 32 cannot. Most of those should not be — a credential's location, a vendor's address, a database's name — so each is now listed with the reason it is deliberately fixed, and the two that are real gaps are listed as gaps against the issues that filed them. The list fails if it grows and if one of its entries is quietly repaired, so it cannot rot in either direction. Nothing about the live fleet changes until somebody runs a deploy and passes a value; what changes today is that they can.

The suite-number tool no longer tells you the branch list is half an hour old seconds after you fetched. It dates its own answer off FETCH_HEAD, and a git fetch run in a linked worktree — which is how every agent on this project works — writes that worktree's own copy and leaves the shared checkout's alone. The tool read only the shared one, so --next printed "AS LAST FETCHED — 27 minute(s) ago" immediately after a successful fetch, and told the reader to do the thing they had just done. It failed the reassuring way too, which is the worse direction: a worktree that had not fetched for a day read as current because a different checkout fetched a minute ago. The remote-tracking refs are shared between worktrees, so the freshness of what the tool actually reads is the newer of the two timestamps, and that is what it now answers — measured in a linked worktree of this repository at 01:50:18 for the fetch made there against 01:50:11 for the shared copy, where the tool had been answering 01:50:11. Reading only the worktree's copy would have been the opposite mistake and is guarded against separately. "We could not read either" is still its own answer, printed as NEVER FETCHED rather than as an age of zero.

The close-keyword check printed a remedy that could not clear it, measured end to end on one pull request. The check that stops a pull request closing an issue against its own meaning fired correctly on a description reading "Do not close #602" — GitHub's parser reads the keyword and not the negation — and then told the author "Edit the pull request title or description — no push is needed." The description was edited, the job re-run, and it failed again on the same step. Two independent mechanisms, either alone sufficient: an edit fires no workflow at all, because edited is not one of GitHub's default activity types for pull_request; and a re-run replays the original event payload, so the step re-reads the body as it was, however many times the button is pressed. The only thing that could clear the check was a push — and the two ways to force one without a code change are an empty commit and a close-and-reopen, both of which this repository bans. A guard satisfiable only by a banned action gets satisfied by the banned action, or it gets ignored; either way the protection measured at 12 orphaned issues and two wrongly closed ones is gone.

The check now also runs from its own workflow, .github/workflows/close-keyword.yml, on types: [opened, edited, synchronize, reopened] — so saving an edit fires a fresh run carrying the new text, which is the printed remedy actually working. It is a separate file rather than one line added to ci.yml's triggers because types: is per-workflow and not per-job: every description edit would re-run all seven of that pipeline's jobs, six of them browser shards, roughly 28 runner-minutes to re-read a body. The cost of the alternative is recorded in the new file rather than left implicit, and ci.yml keeps its own copy on the default triggers.

The printed remedy was rewritten in the same change, because a remedy that names an action which does not work is worse than none — it tells you you have fixed the thing. It now names the file that makes an edit fire (so the sentence is true only for as long as that file is there, which an assertion binds), refuses the "Re-run jobs" button by name with the reason, and says the half nobody can fix from here: fixing the text may not undo the link. On the same pull request #602 closed on merge four minutes after the closing phrase had been edited out, from a squash message carrying no closing keyword at all — verified from inside this repository by running the tool over that commit — with no commit id on the close event. So the remedy points at the pull request's own linked-issues list and says whose answer that is, rather than claiming the link is clear; nothing here can read GitHub's linkage table, and nothing here will pretend to.

Two smaller repairs ride with it. Every we could not read the text answer — the body never written, the title never written, the title arriving empty — used to end "Repair the wiring in .github/workflows/ci.yml", which was true while there was one caller and sends half of those failures to a file that did not run the step now there are two; the workflows are named from one exported list, and a guard asserts that list is exactly the set that invokes the tool, derived off disk in both directions, so a third caller cannot be added without the sentence learning about it. And the older suite's printed coverage note, which recorded "the edited activity type is not in the trigger" as a known gap, carries its correction in place with the original kept, since that sentence is still true of ci.yml and the figure beside it is what the decision was sized against.

It is a report and not yet a gate, which is a repository setting and not a file. Nothing committable here can make a check required. The new job's name is the string an admin adds to master's required-status-check list, and it is asserted rather than left to care — renaming it would silently un-require the check. It is a separate workflow precisely so that switch can be thrown without making six browser shards required at the same time.

The dispatch report dated its own fetch to a sibling checkout's, and in the worktree every agent actually works in it could say "just fetched" about a clone that had never fetched at all. tools/preflight.js carried its own copy of the FETCH_HEAD read repaired last week in the suite-number tool — same function name, same shared-directory-only lookup, same direction of error. A git fetch run in a linked worktree writes that worktree's own FETCH_HEAD and leaves the shared checkout's alone, so “Last fetch in this clone: …” reported a different checkout's fetch. Measured in a linked worktree of this repository: the worktree's own fetch at 06:24:53 against the shared copy's 06:22:59, with the tool answering 06:22:59 — and two minutes earlier the worktree had no FETCH_HEAD at all while the tool still answered the shared checkout's fetch of ninety seconds before, which is the unbounded version of the same error and the reassuring direction. The size of the gap is never the magnitude: it was 114 seconds here, 27 minutes in the suite-number tool and 7 seconds in the issue that reported it, every one of them a fact about what the other agents were doing at that moment. The read is now the one reader, called rather than copied — the freshness of what the tool actually consults is the newer of the two timestamps, because the remote-tracking refs are shared between worktrees. "We could not read either" is still its own answer and still prints as NEVER, never as an age of zero and never as today's clock.

The driver sign-on screen no longer tells a driver the register is empty when it simply could not read it. When a tablet had nobody to offer, the sign-on screen disabled the picker and the Sign on button and said “No drivers on the register yet — ask the office.” The refusal was right and has not changed — an empty picker submits an empty name, and a tablet signed on to nobody is worse than one that will not let anybody on — but the sentence was a flat claim about the database, made over a list that is empty for at least three different reasons: the register really holds no drivers, the last answer from the database could not be used, or this tablet has not had an answer at all yet. On the screen that gates a driver’s whole working day, it sent people to ring an office that may have had nothing to fix. The screen now asks the one reader the rest of the app already uses for this question and gives three answers instead of one. We read the database and it holds no drivers still sends the driver to the office, because there it really is the remedy, and is drawn dimmed and dashed — we know exactly. We could not read it and we have not read it yet are drawn in the hatched “we do not know” pattern instead, each says in as many words that it is not a statement that the register is empty, and neither sends anybody to the office: the first says to get back into signal and reopen the app, and the second says this fills itself in the moment a document lands and no call is needed. The refusal was measured in all three answers and in five more — including a reader that fails outright and a state this app has never heard of, both of which fall to the hatch rather than to a claim — and by pressing Enter in the password box, which is the one route past a disabled button. The hatch is read as the pattern the browser really painted rather than as a class name, because the driver app loads only its own stylesheet and a pattern borrowed from the dispatcher would have shipped as a plain box with every check still green.

The deploy's timezone-offset guard accepted the exact typo its own error message warned about. fdTzOffsetMin is the number of minutes a bare Fleet Dynamics wall clock reads east of UTC, typed by an operator on the backend deploy form; the Lambda takes it through parseInt and uses whatever falls out, so a wrong value does not fail, it re-dates every fix in the fleet. The check shipped with it tested that the value was a whole number and that it lay between -840 and 840 — and every hours-typed-as-minutes value passes both. Measured by extracting the block verbatim and running it under bash: 8, -8, 12, 48, -0 and 0480 were all ACCEPTED and appended to --parameter-overrides, while the error printed when the range check did fire read “8 means eight MINUTES, not eight hours”. Typed on a deploy, 8 dated every fix eight minutes out, silently.

No bounded-integer rule can close that hole, which is why the fix is a third axis rather than a tighter bound: 48 is a whole number and inside the range, so integer-and-bounded refuses nothing. The axis that works is quarter hours — every UTC offset in use anywhere is a multiple of 15, including Eucla's UTC+8:45 (525) and the :45 zones in Nepal and the Chathams — and no value from 1 to 14 divides by 15, so one rule covers all 28 hours-as-minutes typos with no special case. The guard is now shape, then range, then quarter hour: shape by regex because parseInt truncates 480.5 to 480 and reads 0x1E0 as 0 in silence; range narrowed to -720…840, UTC−12 to UTC+14, the asymmetry being the truth rather than a typo. The order is load-bearing and measured: with no shape check in front, [ 480.5 -lt -720 ] writes “integer expression expected” to stderr and returns a status the if reads as false — the range test silently passing the value it could not read — and 0480 clears the range test with no complaint at all before the modulo aborts it as invalid octal. Everything is refused rather than repaired, so +480 and 480 cannot become two spellings of one value in a deploy log somebody later reads as evidence.

The reason this was invisible is that its tests read the guard instead of running it. A regex confirms the message says the right thing and cannot notice that the bash does the wrong thing. So backend/tests-template-fd-knobs.js now extracts the block from the file CI dispatches, substitutes the one ${{ }} expression and executes it under bash -e — 37 checks to 109, covering 8 accepted values and 19 refused, each axis proved to fire alone with the other two asserted to have accepted the value, and the blank / explicit-zero / non-zero deploy-log distinction measured off the running block rather than matched in the file. Verify-to-fail, measured on that suite (109 assertions, passes + reds summing to 109 under every break, so nothing is gated): reverting the whole guard to the shipped one reddens 23 — and the revert is confirmed behaviourally, by watching 8 be accepted again rather than by a diff — dropping the shape axis alone 24, moving it after the two bash integer tests 14, dropping the quarter-hour axis alone 12, and widening the range back to -840 3. 0 in tests/run.js under every one of them, which stays at 31,091: no front-end file is involved, and that silence is worth stating rather than leaving to be assumed.

The deploy form described the offset in the wrong direction. The input an operator reads said “Minutes a bare FD wall clock is behind UTC”, and the arithmetic subtracts: fed 480, the deployed parser turns a 13:00 bare wall clock into 05:00 UTC, so the wall clock reads 480 minutes ahead of UTC, which is what AWST is. Corrected to name the unit and the direction together, with an assertion that runs the shipped parser and refuses the old wording, so the sentence and the arithmetic cannot drift apart again. Nothing about the value changed: 480 was and remains correct for this feed.

A test guard that says "this name appears nowhere" can now see the name when it is written inside a string. Several of this app's guards work by reading its own source and refusing a name — that a screen sets no client tag on a geofence, that the cab does not re-derive a sync stamp from a timestamp. Two of them read the source through a stripper that blanks comments and string literals, which meant they could not see the very thing they forbid whenever it was written as a string — and a tag key, a storage key, a label or a data- attribute is written as a string more or less by definition. The guards did not go red when they went blind; they went on passing. Measured: a client tag added to the geofence editor as a plain string is visible to the correct reader and completely invisible to the one that was being used, so the guard reported "still no client tag" over a screen that set one on every fence. Both guards now read the stripper that blanks comments only, which is all the reason they were written for ever asked for. Neither was failing, so nothing that was wrong has been fixed — what has been closed is that both would have quietly stopped noticing. A new check drives both readers over made-up source and pins the difference, establishing first that each reader can find a name it should find, so that a zero from it is a measurement rather than a broken matcher; and every remaining use of the string-blanking reader is now declared with its reason, so the next one added has to say which reader it wants instead of getting whichever came to hand.

The tool every regression measurement is taken with could silently rewrite the change it was asked to make — whenever the replacement text contained a dollar sign. The evidence a fix is guarded is produced by deliberately breaking the guard and counting what goes red, so a tool that quietly writes something other than what it was handed produces a count for a change nobody made. That reads exactly like a result.

Three shapes were affected, and all three are ordinary things to type: a doubled dollar sign arrived as a single one, an ampersand form silently expanded into the text being replaced, and a quote form swallowed the rest of the line. The doubled one matters most here, because it spells this codebase's own shorthand for "find every matching element on the page" — so a break meant to restore such a line wrote the shorthand for "find the first one" instead. That is a change in behaviour rather than a failure, which is why nothing noticed: it turned a harmless edit into a crash for one agent, and the number that came out of it described a different change altogether.

And the safeguard built for exactly this could not see it. The tool already counts the changed text back out of the file to prove an edit landed where it was meant to — but that count still came back correct, because the damage sat in whichever part of the replacement carried the dollar sign rather than in the part being counted. So "it changed something" and "it changed the thing you meant" came apart in the one place built to hold them together.

The substitution no longer goes through the mechanism that gave those characters a second meaning. One form that was already safe is left alone and said to be safe, rather than escaped along with the rest — escaping it too would have been guessing at the cause instead of fixing it. A check now types all four forms through the real tool and reads the file back, so the next change to this code that reintroduces the problem fails on the commit that makes it.

The in-cab app no longer says the driver register is empty when it has not been able to look. With nobody signed on, the tablet's main panel printed "No drivers on the register. This tablet has no driver to sign on. Add drivers in the dispatcher app, then reopen this portal." — a statement about the database and an instruction, over a register that is empty for at least three different reasons. The instruction was wrong in two of them: reopening the app does nothing about a document that arrived and would not merge, and where nothing has been read yet there is nothing for anybody to add. The panel now asks the same reader the sign-on screen asks, and gives the answer it actually has — the register really is empty (and then, and only then, it says who has to add a driver); a document arrived and this tablet could not use it, in the database's own words, saying in the same breath that it is not a statement that the register is empty; or no copy of the database has reached this tablet yet, which fills itself in when one lands and needs no call to anybody. The two we-cannot-tell answers are drawn hatched and the two we-know answers dimmed and dashed, so the difference is visible on the glass and not only in the words. A fourth case turned up while this was being tested and is fixed with it: nobody is signed on until somebody signs on, so the old sentence also claimed an empty database over a full one — the panel now says how many drivers are on the register and that this glass simply has no shift open on it. The sign-on gate is unchanged in every one of the four: a driver signed on as nobody is worse than a driver who cannot sign on.

A guard that forbade a mail link from being composed could not see a mail link, in any spelling, and never could have. Several of this app's checks work by reading its own source and refusing a name. One of them asserts that the quote-chasing code composes no mailto: — which matters, because the rule it protects is that no blank-addressed mail is composed when no recipient resolves. It read the source through a stripper that blanks string literals as well as comments, and mailto: is a URI scheme rather than a name, so there is no way to write it except inside a string: every possible spelling was blanked before the check looked. This was not a guard that might one day go blind — it could not have failed under any edit, ever. Measured: with a plain mailto: composition inserted into the very code the check reads, the whole suite still reported ALL PASS; through the correct reader the same insertion turns it red. A second check, over the cab's sign-on screen, was moved for the same reason before it could go the same way — there the two readers agree on today's source, so nothing was wrong and what has been closed is that it would have quietly stopped noticing. Both now state in place why they read what they read. A new check drives a scheme-shaped name through both readers in the five ways somebody would really write one, establishing first that the honest reader finds it, so that the zero reported is a measurement rather than a broken matcher; and it pins the difference between a name that cannot be seen at all and one that is merely exposed, which is what decides how urgent each case is.

Every status pip now tells a screen reader its phase and its state in words. Each pip carries a real accessible name — "Line haul — In progress: rolling since 07:05" — and not only a hover tooltip, which is unreachable by keyboard and unreachable by touch. It was previously the visible letters that named the phase; with those gone the name is doing the work, so it is written on all four states including the grey resting one, and read back out of the browser's own accessibility tree with the tooltip removed, because the browser falls back to a tooltip for a name and a check that did not strip it would pass over a pip that had none. The blank column-holders stay hidden from it: three unnamed circles announced on every run would make the board unusable to exactly the person this is for.

The charge screen could tell you every account was settled over a book it had not been able to read. The note under the detention allowance — the one that says which customers are measured against a figure nobody has reconciled — was built from a count of how many accounts disagreed. A count cannot tell we looked and found none from there was nothing to look at, so when the read failed the count was nought and the note opened "Every one of the 12 accounts on the book is measured against an allowance that is settled", immediately followed by "12 could not be read at all". Whoever stopped at the first sentence — the one written to be read first — was told the opposite of the truth. It answers three ways now: the whole book read, part of it read, or none of it. Where only part could be read it states the number it did read against the number on the book, never a bare total; where none could be read it makes no claim about settlement at all and says so in those words, while still naming the accounts, because that is the next thing anybody would ask. Both of the answers that rest on a failed read are drawn hatched, the same "we do not know" treatment used everywhere else — and a genuinely settled book is deliberately not hatched, because that is something we know and drawing it as an unknown would be the opposite mistake. Raising the free allowance to an hour made this reachable from a much smaller failure than before: until then it took the whole customer book failing at once, and afterwards any part of it failing was enough.

A workflow that GitHub would refuse to compile is now caught before it merges. A recent branch made the backend deploy workflow uncompilable. Every local check was honestly green and the change looked ready — and had it merged, the only way to deploy the backend would have been gone: not a deploy that fails, a deploy that is no longer offered at all. The cause was a sentence warning people not to write a particular kind of placeholder, written inside a shell comment, which the shell ignores and GitHub does not. That failure is the quietest kind there is: the run it produces has no jobs, so there is nothing to read in the logs, and every tool that reads these files as ordinary configuration parses them perfectly. The check that already measures these files now also refuses an empty placeholder anywhere GitHub would read one, naming the exact place it sits. It reads the files the way GitHub does, so a note written in an ordinary comment is left alone — and it proves it can still spot a real one every time it runs, so a clean result means it looked.

A customer's browser no longer receives every field of every con note. The client portal is opened from an emailed tracking link and keeps a copy of what it is sent, with no expiry, on whatever device opened it. Until now that copy carried the whole con note: the contact names and phone numbers at both ends of every customer's freight, the GPS fix under every arrival and departure stamp, and — the moment a wait was decided — the dispatcher's own notes on why a demurrage charge was waived or queried, with the names of who decided. The portal now receives only the fields it actually shows. The arrival and departure times still arrive, so the demurrage notice a customer is owed still renders exactly as before (checked end to end, byte for byte); what is under those stamps, and what the office wrote about a claim, does not. A visitor whose browser already held a whole copy has it trimmed on the next read. The portal also stops sending con notes back to the database except the bookings it makes itself, so a trimmed record can never overwrite the full one. One consequence is recorded rather than hidden: the portal's own "this notice was shown" mark no longer reaches the office, so the office reads "untold", which is the safe direction. The recipient's printed name and the tracking link's own token are deliberately still sent, for reasons written beside the table; whether the recipient's name may be shown at all is a decision for Simon. This binds only after the next backend deploy.

When a customer opens their shipment page and sees a demurrage notice, the office record now knows it. The demurrage notice is what tells a client, on their own tracking page, that a load waited beyond the free allowance in their terms and is being charged for it. FleetView keeps three different facts apart here, on purpose: nobody has told them, it was on their screen, and a named person told them, by a named means, at a recorded time. The middle one is worth strictly more than the first and strictly less than the last, and it is the one that stopped being recorded when the client portal was narrowed in September so that a customer's browser no longer receives — or sends back — fields it has no business holding. The portal went on marking its own copy of the page, and the office copy went on reading "not told", so the demurrage report could never show that anybody had seen a notice. Under-stating it that way was the safe direction and it was still wrong. The showing is now recorded straight onto the office record, using the private link the customer already followed from their email as the proof of who they are, so the portal still never sends back a con note it merely received. Three things it deliberately will not do: it cannot create a demurrage claim that nobody in the office has raised and attributed; it never overwrites a record of somebody actually ringing the client, because that is the stronger record; and if it cannot reach the database it says so rather than reporting the notice as unseen — a question nobody managed to ask is not an answer about a customer. A second visit to the same page changes nothing and writes nothing.

The Dispatch Board no longer says it checked a driver's compliance before it has read the register. Every card on the board carries a chip saying whether anything will refuse that driver at departure. Until now those chips were drawn the same way whether or not the database had actually been read, so on a device that had not yet synced — or where the read had failed — three cards told a dispatcher "we looked, and none of the rules that gate a departure applies" over a register nobody had opened. That is the wording reserved for something we know, printed for something we could not look at. Those chips now say plainly that the register has not been read on this device and that nothing on them is a statement in either direction, and they are drawn in the hatched style the board already uses for what it does not know. A chip that refuses a driver is deliberately left alone, because refusing when unsure is the safe direction — it now adds that the file has not been read, so "no record on file" is not mistaken for "nothing is on it".

The board's drag test now checks which card it actually dragged. The browser check that proves a dispatcher can move a job between columns asserted only what happened afterwards — the job's status, the roster line, the toast — and never that the card the mouse picked up was the one it aimed at. Those are not the same thing: the board's columns are several thousand pixels tall, the page scrolls while a card is being dragged, and the pointer can end up over a different card between pressing and releasing. The check now reads which card the browser itself began dragging, and it settles the drop point while the mouse is down instead of trusting one measured beforehand. Nothing about the board itself changed.

Eleven test suites re-run themselves in several timezones to prove a date is derived the same way everywhere, and the number they printed afterwards was not the number of timezones they had covered. Each decided which zones still needed running by comparing names against a setting that is usually blank, so on an unconfigured machine one zone was run twice and the total said four where the truth was three. The count is now measured rather than assumed: a zone already running is recognised however it is spelled, a zone name the machine does not know is run anyway rather than quietly counted as covered, and the line printed at the end states how many distinct zones were covered and how many processes it took, so the two can never again be read as one number.

Three backend test suites defended themselves against a day boundary using the wrong clock, and one of them was red in a whole band of timezones. Each pins the clock to midday so a fixture cannot straddle a day boundary, and each pinned it to midday where the machine happens to be — while every row they write is keyed by the Perth day. The distance from the boundary was therefore a property of the machine rather than a constant, and it falls to zero wherever local noon lands on 16:00 UTC. Measured: the speed-event suite failed four assertions under America/New_York on 19 September and was green under UTC, Perth and Chatham in the same sweep. Continuous integration pins no timezone and the container is UTC, four hours clear of the boundary, so nothing could see it. All three now pin to midday Perth, derived from the same offset the day key itself uses, and each asserts it is at least six hours into its own day — six rather than ninety minutes so that restoring the old pin goes red in the timezone the build really runs in.

The demo-data purge decided which records the sample fleet mints by comparing two loads in two timezones, and it named one of those timezones outright — so on a machine already in it, that half of the comparison quietly did nothing. The field it exists to catch is the one every job thread carries, so on such a machine 65 threads were listed as seeded‑but‑edited rather than as sample data: the exact mistake the second comparison was added to prevent, on the report somebody reads before deciding what to remove from a database that cannot be restored. The comparison now picks a timezone this machine is not already in, says in the report which one it picked, and refuses outright rather than falling back if no candidate differs — a comparison that measured nothing must never read as one that measured and found nothing.

A check could be added to the list a developer runs before committing without ever being added to the build, and nothing would say so. The existing guard ran one way only: it required every check the build runs to be runnable locally, which cannot notice a local check the build does not run. One had already slipped through that way and sat unnoticed. The reverse rule is not the answer either, and measuring it is what shows why — the build runs ninety-two scripts the local list deliberately leaves out, including every browser check. What is asserted now is the narrower thing that matters: every entry in the local list has a step in the build, so running it locally is a gate rather than a habit. The one entry that does not is recorded by name with the reason and the three edits it needs, and that record is itself checked, so the day it gains a step the test asks for the record to be deleted rather than letting it become permanent.

Two of the repository's own prose checks were reading other people's checkouts and reporting what they found as this repository's problem. Both sweep the tree looking for a sentence that has since been corrected, and neither knew to stop at the edge of a second checkout sitting inside it — the working copies the agent harness leaves under .claude/worktrees/. In the shared checkout on the build machine, one of them reported 57 places still carrying the old wording where the repository has 5; three assertions were failing there and nowhere else.

The reason it mattered more than the noise suggests is which way it was wrong. Every single phantom was reported as still-broken, and it could not have gone the other way: a stale checkout is by definition from before the fix. So the check reported work that had been done as work still outstanding, and it did it on the machine where somebody would be reading the result. A red that nobody believes is a red that nobody reads.

A sweep now stops at any directory that is itself a checkout, which is detected by what every checkout carries rather than by the folder name the harness happens to use today. The two checks report identical numbers in every tree. A related finding is recorded rather than quietly fixed: deliberately breaking the second check first proved nothing, because it could only ever fail on a machine that already had the problem — so its own scan was restructured to build that situation instead of waiting for it.

The rule that says customer email leaves the production build and no other is now asked at the browser's send seams, rather than only printed on a banner. NF.Env.maySendCustomerMail() (FR-AO-05) shipped with exactly one consumer per app — lines.push(maySendCustomerMail() .message), the environment banner's own sentence — which made it a display function rather than a gate, and left the requirement stated everywhere and enforced nowhere in the browser. That is the shape this repository has recorded four times: a complete, correct mechanism nothing calls. NF.Intake.envSendGate() is the one reader for it in the shared layer, and both seams now come through it — sendPath(), which gates the unattended send, and NF.Mailbox.capability(), the enquiry desk's Send button, which now says so before a person presses it instead of letting POST /mail/send refuse after the attempt. The allow-list stays in NF.Env: production and nothing else, so a declared test, a typo such as prodution and nobody having said anything all land on the same refusal, printed in NF.Env's own wording rather than a second one.

It withholds the send and never the draft, which is the shape backend/src/mailquote.js chose deliberately — refusing to draft as well would lose the work and tell nobody anything extra. On a non-production build in autosend the enquiry is still parsed, priced, drafted and auto-approved; only the send is withheld, and the record says reason:'environment', which is the server's own word for the same refusal and is kept apart from no_send_path — "there is no route from here" is a build waiting on a deployment, while "this build may not write to customers" is a deployment nobody labelled, and folding the second into the first sends whoever reads the record off to deploy a mailbox that would change nothing. A realm with no NF.Env at all — the Lambda, which brings the shared layer up without an app shell — is a third answer, asked:false, and it passes, because reading that absence as a refusal would stop an unattended send the production stack is entitled to make; that realm holds its own gate, and the claim that no browser can reach the pass-through is asserted against the three HTML files rather than trusted.

And the warning that sent this work is corrected in place rather than swapped out. All three app shells carried a ⚠ reading "NOT YET CALLED AT THE SEND SEAM … and neither is writable on this branch". Its backend half had been false since #242 — backend/src/mailquote.js has asked the server twin once per run since then — and its branch clause had outlived the branch that wrote it, so it read as a standing fact about the repository and was the clause most likely to stop somebody picking the work up. The original wording is kept verbatim as a quotation under a retraction that names what falsified it and says which half survived, and the lease is dropped by name; the same lease is corrected in the suite's own header. A lease is not a property of a repository and does not belong in a comment that ships.

One thing broke on the way in, and it is recorded because the shape recurs. The refusal a screen prints carries two facts — why we may not send and what that means for the draft — and the second of them, "nothing is marked as sent", lived only inside the missing-route refusal's prose. Giving sendPath() a second reason therefore took that sentence off the Transport Configuration panel on every non-production build, which is every build there is. It is this module's own demurrage refusal — v1 stamped demurrageNotified the instant a driver tapped depart, the KPI counted them, and nothing was ever sent anywhere — so losing it is the defect that panel exists to prevent. It is NF.Intake.NOT_MARKED_SENT now, appended to both refusals rather than copied into the new one. node tests/run.js could not see it at all (no DOM, no NF.Env): dropping the clause reddens 0 there against 2 in the browser suite. And the browser suite found it only by accident, because it pinned a constant rather than the model's live answer — which made it go red over a screen that was right. It reads sendPath().why now, so it cannot go stale the next time a reason is added.

A sentence in a decision brief that was wrong when it was written, rather than overtaken by later work, is retracted and marked as such. The backload-readiness brief explained why the driver pool holds five people by saying the driver list was "not in snapshot() — so it is a code seed, not a register". It was in snapshot(), and had been for nineteen days before the brief was written: the key was added by the same change that gave the master records an add/edit/archive screen, which is an ancestor of the commit the brief says it measured against. It is also in the other two places a collection needs to persist. So no version of the repository ever made that sentence true, and it is retracted on those terms instead of being described as having gone stale — the original wording is kept as a quotation under the retraction, with the commands that settle it and a control showing the same check reports the key absent before that change.

The figure the sentence sat beside is unchanged, and correcting the reason makes the brief's case stronger rather than weaker: a driver list that simply has not been wired up yet would be fixed by wiring, whereas a register that really is saved to the database, holding five people against a workforce of about forty, is fixed only by somebody entering the data. The brief's own summary table already said it that way, three sections further down, which is how the error survived. The brief's answer — that a backload optimiser cannot be built on the data held today, on eight stated preconditions — does not rest on the retracted sentence and is untouched. A second brief flagged for the same class of error was checked and already handled it correctly, so it was left alone.

A reason given in the app's own source for how a driver's qualifications are stored was never true, and is retracted where it was written. Two comments in js/data.js — one of them an instruction telling future developers not to change something — explained the separate, editable map of driver qualifications by saying the driver list itself "is not in snapshot()", so anything recorded against a driver's own record "would not survive a sync". The driver list is saved, and has been since the change that added the screen for adding, editing and archiving master records — eight days before the comment saying otherwise was written. It is in all three of the places a collection needs to be in to persist. So no version of the repository ever made that sentence true, and it is retracted on those terms rather than described as having gone out of date. The same false reason is retracted in the crew module's notes, which carried it as the recorded justification for the original decision.

Nothing about how qualifications are stored or read has changed, and that is the point. The decision the false reason was defending is correct for the other reason given alongside it: a set of qualifications arriving from an import or a future integration has to take precedence over what somebody ticks by hand, so the driver record's own field stays reserved for that and the editor still does not write to it. The instruction not to repoint the editor is kept, and deliberately kept forceful, since a retraction that softens into a doubt invites exactly the change it exists to prevent. The code is unchanged — byte for byte once comments are removed — and the precedence itself is already covered by existing tests, which is why the conclusion was never at risk while the reason for it was wrong. One further copy of the same false sentence, in a file this change did not have the lease on, is named in the notes rather than left to be rediscovered.

• workflow_dispatch was checked as the subject of a zero that belonged to the grep pattern permitFor|permitsFor|…. The window had skipped the pattern because it is not an identifier.
• dayRate was checked as the subject of "so that grep would return zero".
• arrivalSlot's printed scope included docs/requirements from the clause before a semicolon. The verdict did not change, because that folder holds no .js files.

The test guard against suites that abort on an empty list now sees the three shapes it missed. A suite that asserts a list's length and then reads its first element throws when a break empties the list, and a throw stops the run at that file — so the break is scored as one red instead of every assertion it really turned. This happened while #283 was being verified: one break scored 1 red where it was worth 32, and the guard built for this (backend/tests-abort-shapes.js) was green throughout. It missed all three sites in that suite, each for a different reason, which was shown by running it on the suite as it was before the fix: a length assertion that was itself written defensively, eq((c.deckPos || []).length, 1), hid the unguarded index under it; a map lookup by a computed key, read inside the assertion, matched no arm; and (xs || [])[0].seq guards the list but not the element, so it throws on exactly the path its own guard exists for. The guard now catches all three. Those three sites, copied verbatim, are fixtures it must flag, and the fixed versions are fixtures it must not. Run on today's tree, it finds 14 more live sites (11 of the half-guarded kind, 2 keyed-length, and 1 behind a defensive assertion). They are listed as a known budget rather than fixed here. The list fails the build if it grows and again if an entry goes stale, so nobody can add a new one and a fixed one has to be struck off. A read taken straight off a function's return, such as placementOf(…).bay, is still not covered, and the guard says so.

The in-cab browser check that the sync pill heals once the office answers no longer fails at random — and the cab was never at fault. The check paints "Synced", "Syncing…" and "Not checked" on the pill itself, then lets the held read through and waits for the store to say "synced" again. The wait looked for any "synced" in the list of events seen so far, and the check had put one there itself. So the wait was already satisfied before the read was answered. It returned in 7 ms, and whether the check passed depended on whether the tablet had finished merging the reply by the next line. Reproduced on purpose by holding the reply 1.5 s: the old check failed with the exact reported words (syncState reading, emitted ["synced","pending","reading"], all three of them the check's own events), and 4 s later the same page answered synced with a real "synced" from the store. The check now waits only for a "synced" the store sends after the reply. A new check, taken while the read is still genuinely held, proves that wait cannot be satisfied early. Measured: going back to the old wait reddens that check on every run, not only on busy machines. A reply that never comes reddens the healing check with "waited 20s and the store never said synced". A store that says "synced" but still answers reading reddens it too. No application code changed.

A test suite can no longer take the shared sample-data realm away from every other suite in the run. tests/run.js evaluates each suite into one shared script scope, so a suite declaring its own top-level const NF shadowed the runner's realm for the rest of the process — and because the damage lands on async work that settles later, the resulting failure printed under the shadowing suite's name while the file that actually failed was never named. Measured in this repository: a clean ALL PASS — 34338 became 34314 passed, 2 FAILED with 23 assertions never run, and a run of the offending suite on its own was green. A new guard derives the reserved names from the runner's own publish list and reads every suite file off disk, so a binding published tomorrow or a suite added tomorrow is covered without anybody remembering; the runner carries the same warning at the evaluation site, and docs/modules/testing.md records the mechanism and the cost.

Two people working at the same time no longer quietly undo each other's work. Every browser tab reads the whole database once when it opens, and it used to send the whole thing back every time anybody saved anything — so a tab that had been open since the morning would put its morning copy back over whatever had happened since. Nobody was told. The screen said Synced, and a consignment somebody else had marked delivered an hour earlier was quietly back to Booked. Reproduced exactly, start to finish: one person marks a con note delivered, a second person who has never opened that con note edits a different one, and the first person's delivery is gone.

A save now says nothing at all about the parts of the database it has nothing to say about. On a realistic office database, changing one setting used to re-send 60 consignments, the whole address book and all 33 of the other lists — 17,809 bytes of a document nobody had touched. It now sends 701 bytes: the setting that changed, and nothing else. The tablet's own offline copy is still the complete one, so a driver out of signal is unaffected, and a stamp a driver has captured but not yet sent can never be mistaken for something the office already has — that case is checked on every test run.

One part of this needs a server update before it takes effect, and it is named rather than glossed over: the case above where two people hold the same list and one of them loses an edit is fixed in the browser and waits on a small change to the server, which is deployed by hand rather than automatically. The much more common case — a tab restating work it never touched, on a list nobody in it has changed — stops as soon as this ships. Service history from Odoo is deliberately left exactly as it was, because changing how the browser speaks for it is a decision about Odoo rather than about saving.

The automated safety net could lose a batch of checks and still report that everything passed. FleetView's test run is what stands between a change and the live site: it is the first gate the deploy waits on, and its verdict is read as a statement about the whole system. Some of those checks run in the background and report back a moment later. If anything went wrong inside one of those background checks — a lookup that found nothing, a record that was not where it was expected — the run simply stopped scoring the rest of them and never said so. No warning, no failure, nothing on screen: the run finished and announced all passed, over checks that had never been carried out.

That is now impossible. A background check that fails is reported as a failure, named, with enough detail to find it, and the run can no longer claim a clean bill of health while it has one. Just as important, the run is honest about what it cannot know: when this happens it says plainly that its total is a floor rather than a total, because the checks that were skipped can never be counted — nobody got as far as running them. It does not invent a number for them, and it does not overstate the damage by throwing away a verdict that is sound for everything else.

Measured, and worth stating because it is the point of the change: on the very first full run with the new reporting in place, a failure that had been hidden this way turned up immediately in the compliance checks — a single mistaken line that had been quietly stopping four later checks in that area from running at all, under a green result. It is repaired, and the four run again. The honest summary is that recent green runs were a little less green than they looked, and from now on they mean what they say.

A failing check now names the part of the system it is actually about. The automated checks that run before anything reaches the live site print a heading above each group of results, and whoever investigates a failure starts by reading that heading. Checks that have to wait for something — a saved record coming back, a page finishing drawing — finish out of order, and until now a failure in one of those was printed under whichever heading happened to be on screen at the moment it finished. That is usually a completely different part of the system, and one that was working perfectly, so the first hour of looking into a problem was spent in the wrong place. Measured on the checks as they stood: 732 results across 18 files were being filed under a heading belonging to another file. Every one of those now re-states its own heading, so a failure says where it came from. Two earlier rounds of this fix covered two of the three ways it happens; this is the third and by far the largest. A standing check was added that reads every test file and refuses a new one written the old way, and the handful of places that could not be corrected in this pass — because somebody else was editing those files at the time — are listed by name with their exact counts, so they cannot be quietly forgotten and cannot quietly grow. Nothing a customer, driver or dispatcher sees has changed, and no check was weakened, skipped or removed: the total number of checks is exactly what it was.

A delivery photograph that fails to upload is now retried, instead of staying inside the con note for good. Before this, when a signature or photograph could not be uploaded — no signal, a timeout, the server mid-update — the cab kept it inside the con note and nothing ever tried again. And one "service unavailable" answer (what the server gives during a deploy) switched uploads off for the rest of the session, so every later photograph stayed inside the con note too. A POD with a signature and several photographs is the record most likely to be refused by the database as too large, so a driver in a dead spot could end up with "Not saved — call the office" on the record that proves the delivery happened.

Now a failed upload is queued on the tablet and retried on its own: after 30 seconds, then 1, 2 and 5 minutes, then every 10 minutes while nothing gets through. Taking more photographs does not make it ask sooner, and restarting the app does not either. A POD taken in a dead spot costs one request, not one per photograph. The photograph stays in the con note, unchanged, until the office's server confirms where it has stored it. A request still in flight is not treated as a confirmation. Neither is a hotspot login page that answers "OK". Measured over a simulated hour with no signal: ten requests, where before it was one per capture for ever, or none at all after a single 503. "Service unavailable" and "not found" are temporary now. A photograph the server refuses for good (too large, or a file type it does not accept) is not retried, and the cab says so.

The job's docket on the cab has a new Uploads row. It shows three separate answers, never one: uploaded, waiting to upload (with when it will next try and what the server last said), and could not upload (in the server's own words, with "tell the office"). A photograph taken before this change shows as on this tablet only. The row updates while the docket is open. The privacy screen's "work still waiting" card now counts photographs as well as times.

Not covered yet: form photographs, a credential's evidence and a session signature are still not retried, because they are stored somewhere other than a con note. Photographs already held inline from before this change are not re-uploaded by the tablet. The server's own clean-up on save still handles them.

A split shipment reads as one shipment on the customer portal again. Since the portal was cut down to the con note fields it shows (#1222), it had been receiving a split part without the two fields that say which shipment the part belongs to and which part it is (parent and splitNo). So the portal could not fold a part into its shipment. We measured this on a con note split into three parts with the real split tool and drawn by the real portal page. A part's tracking link showed the part under its own number. The shipment's own page lost its "Your loads" card. The account list showed the shipment and its three parts as four separate shipments. With the two fields restored, all three views are identical, byte for byte, to what they were before #1222. Both fields are references inside the customer's own booking and name nobody. Who split the con note is still withheld.

The check that should have caught this compared the portal's answers before and after the cut, but the sample data holds no split con note, so it never tested one. It now builds a split through the real writer and compares every page against the whole record. Taking either field back out now fails 16 checks across two backend suites. This binds only after the next backend deploy (deploy-backend.yml runs by hand only). The tracking link's narrowed read (#569) already carries the whole split family, so nothing else has to change for the link page to fold.

The enquiry desk now asks "is this the right client?" before a drafted reply can be sent. When the mail poller cannot be sure who a message is from, it drafts a reply instead of sending it (#1370). Before this change, nothing on the desk then asked whether the client was right. Once a quote existed, the desk said the client came "from the quote record", however it had really been found. Measured on the desk before the change: a draft whose client was guessed from the sender's email domain, and one where nothing recorded how the client was found, both showed a Send button. Neither asked "right client?" anywhere on the page. Now the reply card asks that question above the Send button. Pressing Send first refuses and says why, in place. Pressing Yes records who confirmed the client and when, and it needs a name. Only two kinds of match skip the question: the sender's exact address is in the address book, or a person has already chosen the client. These are the same two the poller will send on. A quote raised by hand is not asked, because no sender's email was matched to a client.

The desk no longer says "Chosen by a person" when nobody chose the client. A message could carry a client with nothing recording how that client was found. The desk reported that as a person's choice, and the queue labelled it "Chosen by a person." It now says, on a hatched background, "Not recorded how this client was found", and treats it as needing a check. Picking a client with the desk's Save button now also records who picked it. Front end only, and live on merge. (#1373)

A timing clash is now found when one of the runs crosses midnight. The schedule's timing check compared the runs on one day only. So if a driver had an overnight run from 22:00 to 04:00, and their 02:00 run the next morning was marked timing critical, nothing was flagged, even though the two overlap by two hours on the same driver and the same truck. Measured by putting those two runs on a real run line and letting the board make their jobs: the check found 0 clashes on either day, at four clock settings including a month end and a year end. It now compares a day's runs against the day before and the day after as well, so the conflicts panel lists that pair once, says it is across midnight, and names each run's own date. The answer is the same at five clock settings, including a month end and a year end.

A run whose time cannot be read is no longer treated as clear. When one of two runs on the same driver or truck is marked timing critical and the other run's start or finish is blank, or cannot be read as a time (for example 7am), the check used to skip the pair without saying anything. Now the panel lists it, hatched, as timing not checked. It names the run and the time that could not be read, and says this does not mean the two runs are clear. The panel does not count it as a conflict. A pair that cannot overlap whatever the unread time says (for example, a run that finished at 15:00 the day before) is still cleared, and a board with nothing marked timing critical still shows nothing.

The schedule board's Projects group now holds the rows recorded as the projects board, not the rows whose caption happens to mention a crane. Which group a row landed in was decided by searching its free-text caption for the words "crane" or "project", while the answer built to record it — the row's own Hired in? control, set to Projects division — was ignored. So it went wrong both ways: a row recorded as projects with an ordinary caption was not pinned at the top, and one of our own rows captioned "Cranes / Projects" was lifted out of its depot and out of that depot's "no work today" count, under a note saying it is managed outside this board while it was being scheduled on it. On the sample board that was four rows at each of the three clock settings tried: three of our own crane rows and a grey-fleet row, all now back under their own depot. On a live board, where every caption is typed into the Run lines form, the caption now moves nothing: to put a row in the Projects group, use its Hired in? button and pick Projects division. The strip that lists bookings beyond the board's last day tags projects rows off the same answer.

A tablet can now be assigned to any truck on the fleet register. The cab's truck picker offered only the operational vehicle list and whatever the board had a lane for, so a tablet in any other truck could not be bound at all — and since only a bound tablet is enrolled, such a truck could never reach the device register either. Measured in Chromium with 40 register-only prime movers seeded: 0 of 40 were offered. It now reaches the register, with a find box because that list is searched rather than scrolled.

The list also says what it left out, which it did not: how many trucks fell off the page, and how many trailers, dollies and plant items were excluded because a tablet is not mounted in one. A register row nobody has typed is offered rather than dropped — we cannot tell that it is not a truck — and says so on itself, hatched.

Three empties are told apart, where there had been none: we have never read the fleet register (hatched — a fact about this tablet's copy of the database, not about the fleet), we read it and it holds no truck, and nothing matches what you typed. The first is answered by NF.readComplete(), this being its first call site anywhere in driver/.

On Settings → In-cab tablets, a refused revocation is now shown inside the revoke form, and the reason you typed is kept. Before this, if Request revocation was refused (for example because nobody was named under Recorded against), the reason for the refusal appeared in a box above the whole table, away from the form it was about. The form then redrew with the Reason box empty. A repaint of the screen while somebody was still typing, which happens whenever the database syncs, also emptied both boxes. We checked this in a browser before making the fix: the refusal appeared only in the card-level box, and the typed reason came back empty.

The revoke form now works the same way as the rename form. The register's own refusal sentence is printed inside the form, above the Request revocation button. Both boxes keep what was typed through a refusal and through a repaint. Nothing about what a revocation does has changed: it is still a request, and the tablet still has to acknowledge it.

The estimate promised an hour of free waiting time and did not say what the invoice bills from. The allowance sentence on every quote is a hard-coded literal — one hour loading and one hour unloading per trailer — while a wait is measured against NF.Demurrage.termsFor(), which is the customer's negotiated allowance where they have one and NF.settings.demurrageFreeMin (shipped 30) where they do not. Measured through the shipped resolver on the shipped customer book with the clock pinned: 11 of 12 accounts were billed against an allowance that is not the hour the document promises — ten at 30 minutes with nothing negotiated, and Water Corporation at 45 minutes, whose estimate contradicted itself on the same page, its own 45 printed two lines under the unconditional hour.

The estimate now states the figure it is actually measured against, and where the published rate card disagrees it names the size and direction of the gap and says the two have not been reconciled. Three answers, never two: demurrage that is not charged at all gets no line, because it has no allowance to state; a figure that cannot be read says so in those words and that it is not an allowance of nothing; a figure that reads is stated. Where the rate card holds no free-hours figure the comparison is dropped rather than defaulted to an hour — an assumed hour would manufacture the very agreement the sentence exists to check.

The promise itself is unchanged. Reconciling 30 against 60 is a commercial decision — 60 gives away wait time the business bills today, 30 in the quote changes what customers are promised — and a composer does not take it. What changed is that the document is no longer silent about the disagreement.

The dispatch board now says when it could not check whether somebody else had edited a run. Since the two-schedulers fix shipped, a save that landed on somebody else's change has raised the "Somebody else was editing this too" notice. What was never drawn is the third answer: the database could not compare the records at all — the row read failed, or one save carried more records than it will check in one go — and it has been saying so on every such reply, in a field nothing in the app read. Measured on 12 September 2026 by driving the real API: one transient database error, three run lines, all three genuinely written over, and the board stayed silent — identical to a clean save. It now says so, in its own hatched notice that names which part of the board it could not check, never claims anybody was written over, and does not auto-hide on the next autosave.

A proof of delivery no longer changes whose it says it is when a run is re-crewed. The con note's "who has done what" trail attributed a POD to whoever was allocated to the run at the moment you looked rather than to whoever captured it, so moving a job onto another driver — the ordinary act of re-crewing a board — silently rewrote the attribution on an evidentiary record. Measured on the sample dataset: a POD signed at 08:55 read as Dev Sharma's, and one field change made the same POD read as Wayne Carter's, with nothing on the record altered and nothing on any screen saying so. That derivation is removed: a capture now names a person only where one was recorded at the time, and the flat trail no longer falls back onto the current allocation either. A time stamp names nobody and now says so rather than borrowing a name.

A refusal to split a con note that already has work against it no longer prints the word "undefined". It read two field names the record has never carried, so a dispatcher was told A driver has already recorded "undefined" instead of what was actually captured. Found while removing the attribution above; every existing test stayed green because they all check the refusal's name rather than its sentence.

Marking a con note delivered on the board no longer prints a proof of delivery nobody took. Dragging a job card into the board's Delivered column sets the con note's status and nothing else — no signature, no recipient name, no image. The con note screen keyed its whole proof-of-delivery panel on that status and then drew a tick and the words “Signed on device” over a record holding no evidence at all, with the recipient shown as a dash. The same defect was corrected on the customer's own shipment page in an earlier release; this was the other copy of it. The panel now asks whether an artefact was actually captured, and a record carrying a recipient's name but no signature image says so in those words instead of claiming a signature was taken on a device.

• Internal notes found: firm, with every flagged line quoted and the kind of wording it is named.
• We cannot tell: hatched. It is never shown as "none found", because that would tell a dispatcher it is safe to send a message nobody could attribute.
• None found: plain text, not green. It says it read the message we received and not what is typed into the reply.
• No check: a build where the check did not run is hatched too, and never falls through to "none found".

• Folding "cannot tell" into "none found" reddens 8 in the main suite and 4 in the desk browser check.
• Removing the verdict from the card reddens 27 and 14.
• Flattening the hatch in the stylesheet reddens 4 in the browser check. Two of those are this change's and two are earlier checks on the same rule. It reddens 0 in the main suite, which loads no stylesheet, and that is why the browser half exists.

The enquiry desk now asks "is this the right client?" when it cannot tell how a message's client was found. A message can carry a client with nothing recording how that client was chosen. The ticket treated that as if a person had picked the client, so it skipped the "right client?" question that a client guessed from the sender's email domain gets. The details panel also said a person had chosen the client. Measured on the desk before the change: such a ticket asked no question, the domain-matched ticket beside it did, and pressing Read it and draft a reply without choosing anything recorded that a person had chosen the client. It then drafted a reply and offered Send. It now asks the same question a domain match asks. It says, on a hatched background, that we could not tell how the client was found, and pressing Read leaves that unrecorded instead of inventing a choice. Only two kinds of match skip the question: the sender's exact address is in the address book, or a person picked the client. Any other kind, including one added later, asks. These are the same two kinds the unattended mail poller will send on (#1370), and a test holds the two lists together. This is the browser half of that change. It is front end only and live on merge. (#324)

With automation set to send on its own, a quote is no longer emailed to somebody we only guessed was the customer. When a message came from an address we did not know, at a company whose email domain we did, the unattended reply matched it to that company, priced the quote on that company's own rates, and sent it to the sender with nobody reading it. A shared domain, a forwarded email or a new person at a known company all match that way. Measured before the change: a message from an unknown address at a known customer's domain was drafted and sent. It is now drafted and kept, marked as not sent, with the reason written on the quote: the customer was placed only by the sender's email domain, and a person must confirm the client on the desk before it goes out. Only two kinds of match may send on their own — the sender's exact address is in the address book, or a person picked the client — so any new way of matching added later drafts until somebody decides otherwise. A customer recorded on a message with nothing saying how it got there is also drafted, under its own reason, rather than being treated as a person's choice. Draft and approve-without-sending modes are unchanged.

This needs a backend deploy before it takes effect: the change is in the mail poller, and deploy-backend.yml is run by hand, not on merge. Until it is run, the deployed poller behaves as before. (#324)

The code said a published terms version was still being thrown away, four days after it stopped being. Terms and conditions versions are stored by the database and have been since 14 September, and live on the server since 18 September — but three places in the repository still said, in the present tense, that a published version was kept in one browser only and dropped on the next save. One of them was the comment beside the code that reads terms versions off the database; the second was a test suite that quoted the first as corroboration; the third was the triage document a reader consults to find out what is left to do. Measured: two independent-looking sources for a defect that had one source and no longer existed, and a piece of work was scheduled to fix something already fixed and deployed. All three now carry the retired sentence word for word, marked false, naming the change that fixed it and the deployment that made it live — a correction that deletes what it corrects leaves the next reader unable to tell a repaired claim from one nobody ever made. The prose is now checked by machine rather than by somebody remembering: a "not deployed yet" warning naming a collection the database really does store is a failing test, read off the database's own list of collections rather than off a second copy of it. Measured when that check was written, two of the two such warnings in the shipped code were out of date; the second belongs to another piece of work, and is recorded as a known exception that fails the moment it is corrected, rather than quietly excused for ever.

A quote promised prior notice of a fuel levy change and said nothing about how much — now it says what the record says, and is silent where the record is empty. Every estimate carries the line "Fuel levy is subject to change with prior notice.", and until now it was printed regardless of anything the app held. The notice period has been recordable for some time, on Transport Configuration, and the document that makes the promise never read it — so the promise on the page and the figure in the system could not disagree, because the page was not looking. The sentence now reads off that record. Where a period is on file the estimate states it ("That notice is at least 14 days."). Where nobody has set one — which is what ships — the estimate is composed exactly as it was before, word for word: a document going to a customer must not change because a decision has not been taken, and "our own record is empty" is an internal fact rather than a clause to put in front of a client. A period somebody entered that cannot be read is treated the same way on the page and kept apart from an unset one behind it, because they are two different phone calls. The case that was a wrong answer rather than a missing one: a notice period recorded as nought days is a real decision an operator can make, and with it on file the estimate was promising, in writing, notice the business had decided not to give. Both halves are now on the page, the disagreement is named, and it says the two have not been reconciled — never "at least 0 days", which would read as an agreed period that happens to be small. A customer whose agreed rates already include the fuel is told no period at all, since that would be a statement about a charge their estimate does not make; a reprinted estimate answers off what was stamped on it when it was sent, not off today's configuration. No figure on any quote moves, no save is refused, and nothing claims a notice was sent to anybody — sending one is still separate work, and the promise itself is unchanged, because withdrawing a commercial promise is not a decision this software takes.

A time the office retyped on a con note kept the driver's GPS beside it, in green, as though it proved the new time. Every time-based charge Northfleet raises — detention above all — is measured between two stamps on the con note, and the con note's Job flow panel lets the office edit them. It did so silently: the value it replaced was gone, nobody was recorded as having made the change, and the position taken at the moment of the old stamp was carried across and drawn beside the new time in the same colour a driver's own capture gets. A customer asking "who says you were held ninety-five minutes" was answered with a pair of strings that could not say where they came from.

A stamp now says which of four things it is: stamped in the cab (read off the device id the driver's own outbox already writes onto the record, so the cab had to change nothing), recorded in the office, edited in the office — carrying the value it replaced, verbatim — or source not recorded, which is every stamp taken before this shipped and is drawn hatched with the words "this is not a statement that a driver captured it". A carried-over position is kept, because dropping it would destroy evidence of something, and named, because it places the truck at a different time from the one shown; it is hatched rather than drawn in the colour that reads as proof.

Beside each demurrage claim the con note now states what the charge actually rests on, as a count and never a percentage: the start and finish times, the site representative's name, that person's signature and the reason for the delay. A name somebody typed is not counted as a signature somebody took, a flat fee is not marked down for having no measured time to hold, and "we could not read the record" is kept apart from "we read it and there is none" — the second is a real answer and the first is not. On the three charge types nothing captures anything for at all — futile, standby and the collection/delivery fee — it says so by name rather than reporting nothing.

A load nobody had measured used to look exactly like a load measured and found within. Three screens decided the word "permit" from a single tick on the driver's kerbside load check — a box with no deck height, no legal limit and no third answer in it. If the box was ticked they warned; if it was not, they drew nothing at all, which reads as a clearance. The compliance report was worse: its "no permit gaps" line counted only the jobs that had been ticked, so "no permit gaps · 3 checked" over a fleet of three hundred read as three hundred cleared. All three now give three answers, not two. A permit is required, no permit is required, or nobody has recorded either way — drawn hatched, saying in the same breath that it is not a statement that none is needed. The driver's tick still condemns a load and no longer clears one: only a permit decision a named person recorded can do that. Where the office has recorded "not required" over a load the driver measured oversize, it condemns and prints both records, because that disagreement is the recorded incident in miniature — a clearance made against figures that are not what is on the trailer. The driver's docket now says, in red, when our own records say a permit is required for the job and none is attached to it; it deliberately never prints a clearance, because an office clearance read at a roadside intercept off a tablet whose copy of the database may be hours old is the wrong way to be wrong.

An attached permit is archived now, not deleted. Removing a permit, escort order or SWMS from a con note deleted the row outright — no record that it had ever been there — and it identified the row by its position in the list, so with two dispatchers on one con note the document removed was not necessarily the one clicked. That was on the paperwork that proves a load was legally on the road, and the change log cannot always reconstruct an attached document because it is too large to record. Documents now carry an identity of their own, the remove button and the record that answers it use the same one, and removing marks the document as no longer in force while keeping it and naming it on the job. Two refusals rather than a guess: a request that names a position is refused and says so, and where two documents on a job are genuinely indistinguishable the archive is refused rather than picking one — because the one left behind would be the one somebody produces at an inspection. Every refusal is printed in the panel, where it can be read, rather than in a message that slides away.

Both readers now ask the one reader that knows who the freight is for, so the con note screen and the gate cannot disagree. Nothing is flipped into blocking by this: no con note in the shipped data carries an end client, so every answer is unchanged until somebody records one, and recording one can only add a rule. The reason printed beside a held departure says which side matched — endClient:… rather than client:… — because that sentence is frozen into the permanent record a second, deliberate tap writes, and naming the payer’s own rules there would put something in a driver’s file that is not true of the job.

Two settings that existed, were read by the running system, and could not be changed by anybody are now deploy options — and the one that governs an alarm no longer stops saying that nothing is sent. A parameter that exists and cannot be set turned out to be a class rather than an incident, and these were the two real gaps a census of all 44 of them named.

How long a stuck email may sit before the system calls it a problem was declared, read on every poll, and reachable by nothing: the deploy had no box for it, and the deploy is the only way the system is ever updated. So the decision about it could not be taken even by somebody who had taken it. It can be set now. A value it cannot use is rejected by name before anything is built, because the code reads an unusable number as nobody has decided — which would report a setting somebody chose as a setting nobody chose. Leaving the box empty still means nobody has decided, and a deliberate zero means the first minute counts: those are different acts and the log says which one happened.

And setting it no longer quietly removes a warning. While nothing was decided, every poll printed the count, the age, and the words "nobody is being told". That sentence disappeared the moment a threshold was set — exactly when somebody is most likely to assume an alert now reaches a person. It does not: there is nowhere in the system to send it, which is the other half of the same decision and is still not built. All three settled answers now say so in place of that sentence, and a check measures it against the system rather than asserting it, so the day somebody adds a recipient the wording is forced to change with it.

How many days of database backups are kept was the other. Editing the built-in figure could never change a running system, so confirm and set the retention was not doable at all. It is a deploy option now, bounded to what the database itself allows, with two warnings on it: lowering it throws away recovery time that raising it again cannot get back, and the last change to it went out with nobody watching for an interruption. What the live setting is today still cannot be read from here, and that is said plainly rather than reported as the built-in number.

Nothing changes on the live system until somebody runs a deploy and types a value. What changes today is that they can — and the list of settings nobody can reach is now empty and held that way, so a new one arriving fails on the change that adds it rather than being found months later by a fix whose knob does not turn.

The mailbox poller's retry schedule was computed, stored, and obeyed by nothing. When a message could not be filed, the poller worked out how long to wait before trying again, wrote that time onto the record, and showed it on the intake queue screen — and then ignored it. Every message that had failed was re-tried on every poll, which meant the six tries a message is allowed were used up in six polls: one hour, not the two and a half hours the design called for. The two settings that control how long to wait could not change anything at all.

The consequence was the one this queue was built to prevent, arriving from the other direction. If the mailbox is shut, the poller deliberately charges nobody a try, so an outage cannot mark the whole backlog as needing a person. A database outage was not covered by that rule — correctly, because a failed save really is about that one message — so an hour of database trouble gave up on every message in flight at once and handed somebody fifty of them under “we tried six times”, when the truth was “the database was down”.

The poller now reads the schedule before it re-tries anything. A message still inside its waiting period is not re-attempted at all, is not charged a try, and — this is the part that matters — still holds the poller's bookmark behind it, so it is read again on a later pass and cannot be stepped over. A message that has been given up on is never held back, so giving up still releases the bookmark exactly as before. If the schedule itself cannot be read, nothing is held back and the run says so in those words, rather than reporting that nothing was waiting.

Measured: removing the check reddens 16 assertions in the poller's suite and 0 in the queue's own — the queue's checks read source text, and no source read can tell a wired reader from one nothing calls, which is why both suites exist.

A backup that was written and never listed no longer reads as a backup that worked. A capture can end one way that is neither a success nor a failure: the file reaches storage and the entry that would let anybody find it does not. The backups panel on Settings drew that as a plain success, and the card went on saying "No backup has ever been taken" underneath it — the one line on that card stated as an established fact, over a file the browser had just watched being written. It now gets its own hatched notice naming the capture id, which with no catalog entry is the only handle anybody has on the file, saying that the file was written, that the entry that would find it was not, and that nothing on the card can tell you whether that file is still there or what it holds. The notice outlives the button's message and a later successful capture does not clear it, because producing an unfindable file is not undone by taking another backup. While that notice is up, the list below is described as a record of what was written down rather than of what exists. The storage location is still never printed.

The same card no longer claims the fleet's GPS history is covered by the database's own backups. It said so in one clause and then, two paragraphs lower, correctly said it cannot state how far back the database can be restored. Nothing in a browser reads that setting: it belongs to the database cluster, it is not in the site's configuration, and a value in a deployment template is not a reading of the live cluster in any case. The card now states which data is left out of a FleetView backup, says plainly that how far back it can be recovered is not something this page reads or guesses, and warns that no figure here must not be read as an adequate one.

An issue was closed by a sentence saying it was not closed, and the test suite went red until the incident was recorded. The linker that closes an issue when a change says it fixes one reads the words and not their meaning, so a merge message explaining that a change did not resolve something closed it regardless. The issue was reopened within two minutes and nothing about it changed. The ledger of these incidents now carries it, with the part that is new: every earlier instance was in a pull-request description, which is scanned before it is posted, and this one was in the message typed by hand at merge time, which is the second way an issue can be closed and the one nobody checks because it is written last.

The pre-dispatch prior-art check now asks master's own history as well as the branch list, so an issue whose fix already shipped stops reading as an open one. The check that every brief runs before work starts scanned the branch namespace only — it looked for branches and commits that nobody had merged, which it did by excluding master by construction — so a defect that had already been fixed and released came back as "Prior art: nothing found, and that is a measurement", a confident clean bill of health over work that was live. That is the more expensive of the two ways this goes wrong: an unmerged branch costs a session reading somebody else's work, while an issue that was fixed and left open sends somebody to rebuild something customers already have. Measured on 13 September 2026 against the 87 issues then open: 79 are named by at least one commit on master, 66 of them in a commit's own headline, and 24 were being reported as untouched. The check now names those commits, and says where each reference sits — in the headline, in the message body, or only as the pull-request number automatically appended when a branch is merged, which is a different fact and is called out as one, because two numbers that looked like clean finds of this very defect while it was being built turned out to be pull requests rather than issues. It states plainly that a commit naming an issue is evidence that work for it landed and is not a claim the issue is finished: a long-running piece of work is trimmed many times, so the reader is given the commits to read rather than a verdict. And it refuses to answer where it cannot look — a partial copy of the history, an unreadable one, or a missing reference point each get their own wording instead of being reported as nothing found.

A job put on the schedule from the Dispatch Board now lands on its own day, not on today. Both board writers filed every job on today's column, so a job booked for tomorrow and assigned today appeared on today's schedule line while the driver's run sheet had it on tomorrow. Measured on the sample data over eight consecutive days: 135 of 288 crewed con notes are on a day that is not today (10 to 36 of 36 per day). A job saved before jobs carried a day still lands on today, as before. Because the conflict check now asks about the right day, it finds leave that asking about today could not: 52 of 1,280 proposals asked through the board are refused, every one of them a driver on leave or a truck in the workshop on the day the work is on. The earlier "0 of 3,360" figure was measured on today's column and does not survive the fix.

A trailer and a dolly can be the same truck, and the double-booking check used to miss it. The board's conflict check asked only the pool a unit was being offered from. So one physical unit already out as a trailer today raised a clash when somebody tried to hook it up as a trailer again — and nothing at all when the same unit was offered as a dolly, or as a prime mover. Measured on the shipped check: one conflict when proposed as a trailer, zero as a dolly, zero as a prime mover. That is exactly the situation the real asset register produces, because 47 units are typed trailer on the register and also answer the Dollies pool off a word in their description — so the unit a scheduler picks out of the dolly list is routinely one a colleague can hook to another run as a trailer, and neither list admitted it. The check now knows that a prime mover, a trailer and a dolly are one register and one id, so a unit already out in any of those roles is named when it is offered in another, saying which run has it and in which role. Two other places were blind the same way and now agree with it: the timing-overlap check, which reported nothing on two timing-critical runs four hours on top of each other over one unit, and the weekly conflict panel, which grouped each pool separately and so held one entry in each list, clashing with nothing in either, over a day it then called clear.

Dates the app wrote itself were being read back as the wrong month. Twenty-six places in the shared layer stamped a date and time as 07/09/2026, 03:40:00 — day first, as anybody in WA would write it. Handed back to the app's own date reader that is 9 July, because the reader takes a slash date month-first; and once the day of the month is past the 12th it is not a date at all. Measured across a whole month: 30 of the 31 days of August read wrong, eleven of them as the wrong month and nineteen as nothing at all, with exactly one day right by coincidence — the 8th of August, where the day and the month happen to be the same number. Every one of those places now writes the one sortable shape the customer portal was moved onto in v0.154.0.

The one that was not just a date on a screen. A quote's enquiry date is copied onto the job thread when the thread opens, and the thread's date is what the revenue pipeline's monthly buckets and the enquiry list's date filters read. An enquiry raised on the 5th of the month opened a thread dated four months earlier, one raised on the 12th opened a thread dated three months in the future, and one raised on the 13th or later could not be read at all — so the thread was quietly given today instead. That is fixed at the reader as well as the writer, which is why enquiries, quotes and threads raised before this release read correctly too.

Nothing already recorded was rewritten and no data was changed. The reader takes the old shape as well as the new one, so a credential filed last year, a toolbox-talk roll, a signed load check or a demurrage claim keeps exactly the characters it was written with — which matters most for the records kept for seven years. Whether to tidy the old rows up is a decision left for a human.

A stamp we cannot read still says so. Where a date arrives from somewhere else — a permit attached from the cab, a stamp read off a customer's email, a prestart filed on a tablet — a date we can read is tidied into the one shape and a date we cannot is stored character for character, then named as unreadable wherever it is used. It is never quietly turned into today's date and never dropped: "we cannot read this" and "there is nothing here" are two different facts and each keeps its own sentence.

Three separate copies of the day-first rule were also folded into one, so two screens can no longer disagree about when the same enquiry arrived — and a date that does not exist, such as 31 February, is now refused rather than rolled forward into the 3rd of March.