The instruction was unusual: read the code the way a careful lawyer reads an opposing party's pleading. Treat every word as deliberate. Infer meaning from the precise wording — and from what the text conspicuously does not say. Then keep doing it, with a different lens each pass, until a pass genuinely finds nothing.
That ran for a day. Nineteen releases shipped. None of them fixed a fire — the system was working. What they fixed was a class of quieter problem: code that produced a confident, wrong answer and gave no signal it had done so. For a tool whose entire job is preventing a workers'-comp applicant firm from misfiling a document or missing a statutory deadline, the silent-wrong-answer is the one that matters.
The one that mattered most: a deadline off by a day
The deadlines feature reads a QME report's date and counts forward — 30 calendar days for the objection window (8 CCR 31.5), 30 days for the IMR appeal (LC 4610.6). The dates were printed with new Date(ts * 1000).toISOString().slice(0, 10).
toISOString() returns UTC. The firm's machine runs in Pacific time. Any document timestamped after roughly 5 PM Pacific is already the next day in UTC. So a QME report stamped the evening of the 28th printed as the 29th — and the objection deadline computed from it landed one day late.
Reproduced it precisely: a report at 2026-05-28 21:00 Pacific produced an objection deadline of 06-28 instead of the correct 06-27. One day. On a statutory deadline. For an applicant firm, that is the exact category of error this software exists to prevent.
The fix was a local-calendar formatter using getFullYear/getMonth/getDate (which read in the machine's timezone) instead of the UTC slice — applied everywhere a date feeds deadline math. The instant <5s commands and the underlying timestamps were never wrong; only the displayed calendar date drifted, which was enough to corrupt the count.
"No deadline" that meant "the fetch failed"
A second class of silent-wrong: the skills parsed each API response as JSON.parse(body).data || {}. If the response was malformed — an error body, a null data, an unexpected shape — that || {} collapsed it to empty, and an empty result read identically to a legitimate "this case has no QME reports." The skill would report no objection deadline exists when the truth was the fetch broke.
The firm-wide SOL scan had the same shape: a garbled response became "no statute-of-limitations deadlines approaching" across the entire caseload — a false all-clear on the case-ending five-year SOL, for every case at once.
The fix refuses to read a malformed body as empty. An error body or a missing/null data now throws loudly. Only a genuinely-present-but-empty {data:{}} counts as a real zero. The distinction the old code erased — "found nothing" versus "couldn't look" — is now preserved.
The guard that had a hole
The binding guard is the core misfile-prevention mechanism: before a document is filed to a case, the applicant name extracted from the PDF is compared against the case's applicant, and a mismatch refuses the write. Its name comparison allowed a "partial" match for married and hyphenated names — reasonable, so that ROE still matches ROE-SMITH.
But the partial match was a bare substring test. "ANDERS" is a substring of "ANDERSON." Two different people. The guard whose entire purpose is preventing cross-applicant misfiles would have accepted that pair as a match. Tightened to token-aware: a partial now holds only when the shorter name equals a whole hyphen/space/comma-separated component of the other. ANDERS/ANDERSON now correctly refuses; ROE/ROE-SMITH still passes.
An override broader than the operator believed
When a guard refuses a write, the operator can mint a signed, single-use override token bound to specific parameters. The tag-mismatch override bound only the upload id — not the tag set being approved. So a token minted to approve filing a document with tags [A, B] would equally authorize writing it with a completely different set [C, D]. The single-use limit capped the blast radius to one write, but within that write the authorization was wider than the command the operator typed implied. Now the token commits to the exact proposed tag set; a different set on the same upload is rejected.
From fixing bugs to eliminating bug classes
The most durable passes didn't fix a bug — they removed the conditions under which a bug could exist. Two extractors (one for PDFs, one for emails) each had their own copy of the activity-type catalog parser. The copies had drifted: one received a buffer-overflow fix and a name-field fallback the other never did, so on a large catalog the two extractors could silently produce different tag lists from the same firm data.
The first instinct was to sync the copies. But syncing the symptom leaves the cause — two copies drift again. So the parser was extracted into one shared module both extractors import. With one function, there is no second copy to drift from. The class of bug is structurally closed, not patched.
That discipline cut the other way too. The next apparent target was a fetch that appeared in four files — surely more duplication. But reading each use closely showed four different purposes: a token-validation probe, a comment, and two genuinely different parsers. Forcing them into one module would have broken one of them. No refactor was warranted — so none was done. Yet checking the premise surfaced a real bug anyway: one of the parsers was reading field names that did not exist in the response, silently producing blank staff names. Confirming a refactor isn't needed found a defect worth more than the refactor would have been.
What "stronger" honestly means
These were latent defects, not production fires. The system worked yesterday. What changed is the number of ways it can be silently wrong, which dropped sharply — and the worst recurring ones (timezone-dependent dates, empty-versus-failed conflation, parser drift) are now either fixed everywhere or structurally prevented. Six build-time checks now run on every release, making whole categories catchable mechanically: no PDF text-extraction, no content-interpreting regex, no firm data in the package, and live verification that the code's assumptions about the API's field shapes still hold.
It is audited, not proven. The reading discipline's own rule is that until a pass finds nothing, it is not finished — and even a pass built on a wrong hypothesis found something. The honest claim is narrow and worth making: a statutory deadline can no longer be quietly off by a day, a malformed response can no longer masquerade as "nothing to do," and the misfile guard no longer has a hole in the comparison that is its whole reason to exist.