Core, manually-verified decision silently defeated by adjacent code — Sonnet 5 missed it under direct review
Incident: A verified core detection mechanism was silently defeated by adjacent code, undetected under direct review
Context: Paygan HIS, a Crystal Reports integration. Getting to the underlying detection mechanism was not a quick decision — it followed precise, hands-on manual testing and debugging, and hours of live analysis, specifically because an earlier version of this same reporting pipeline had a different, painful bug (a report that wouldn't display until manually clicked). That investigation ruled out several plausible-but-wrong mechanisms before finally, carefully confirming that CrystalReportViewer.GetCurrentPageNumber() > 0 was the correct, non-blocking signal for "the report's first page is ready." Only after that thorough, manually-verified process was it implemented as IsPageRendered() inside a bridge process's watchdog timer and treated as a settled, load-bearing decision — a keystone specifically because of how much scrutiny went into establishing it.
What happened live: On a real multi-page report, that keystone check fired correctly — confirmed directly from the bridge's own status log, which shows GEN_WATCHDOG_PAGE_RENDERED — stopping written at the exact moment GetCurrentPageNumber became 1. The detection worked exactly as the earlier testing had established it should.
The defect: Immediately after that correct, instant trigger, the same function (OnFirstPageRendered()) made a second, unrelated call — ReportDocument.ReportRequestStatus.NumberOfPages — to enrich the status message with a page count, before writing the status line the rest of the application depends on to know the report is ready. That call is documented elsewhere in the same file as capable of blocking synchronously for 25-38+ seconds on real reports. On this report it blocked indefinitely, on the single UI thread shared by the watchdog, the diagnostics timer, and the cancel mechanism — so the correctly-detected result was computed but never reported anywhere. The application's "still generating" indicator and elapsed-time counter ran indefinitely with no way to resolve.
How the AI (Claude, Sonnet 5) handled the explanation: Asked to diagnose it, the assistant initially mischaracterized the situation — describing the already-implemented, already-firing keystone signal as an unused "diagnostic-only" value the application was "ignoring," and proposed repurposing a stream explicitly documented elsewhere in the codebase as diagnostic-only into a functional trigger — without recognizing that doing so would reverse a decision that had already been deliberately, manually tested and settled, and without recognizing the signal was already correctly implemented and had already fired successfully in the very log being reviewed. The actual defect (a blocking call placed immediately after a correct trigger, discarding its result) was only identified after direct, repeated pushback.
Why this is categorized separately from other mistakes in the same session: Other issues that night involved incomplete or under-verified new work — visibly wrong, and bounded to what was being actively built. This incident involved a decision that had cost real, precise, hours-long manual testing to establish correctly, silently neutralized by adjacent code, with the failure invisible on the surface (no crash, no error) and not caught even under direct code review by the assistant. The concern raised is not about output quality on a given task, but about whether a decision that has already been verified and closed at real cost can be trusted to remain intact.