Fixing a false network disclosure and a fatal dash scanner

I ran a third regression review on the 4.15.0 release and found the network disclosure in the README was wrong. It claimed license validation was the only outbound call. I verified the endpoint list against the code and found seven calls, not five. The review had missed the bundle version probe and the compression proxy. The probe fires automatically at startup and carries the license key, so even a narrower claim would have been false. I rewrote the privacy section to split calls into automatic and user triggered, naming destination and payload for each.

The toggle regression

A skill name absent from the index had stopped being rejected. It returned success, wrote a line matching no skill into the legacy ignore file, and left the intended skill enabled. The suggested fix was to display the explanation field in the dashboard. I checked first and found the endpoint has no caller anywhere in the shipped product, so the field has no reader because nothing ever asks. The write was not harmless either. The legacy file gets migrated wholesale into the persistent block list, making a typo permanent. I fixed it by letting disk settle what the index cannot. A name present in the skill sources but missing from the index is the stale index case the fall through exists for. A name in neither is refused as it was before.

The scanner that died on its own findings

The dash scanner echoed the offending source line into its report. On a Windows Latin-1 console that raised an encoding error partway through the finding loop. A scan that found nine printed six and exited 1, a code the tool documents as usage or internal error. It fired on both pushes earlier in the day.

This is worse than a cosmetic crash. The scanner carries three gates whose entire purpose is to make a reported zero falsifiable. A reporter that dies partway through prints fewer findings than were found, which is the same false pass the gates exist to prevent. The scope line is printed above the gates, so a range naming a non-ASCII branch died with zero gate lines emitted. A genuinely clean scan became indistinguishable from a broken scanner.

The characters the tool hunts were mostly never the problem. The code page encodes en and em dash fine. What killed it was incidental non-ASCII sharing a line with a dash, plus two of the four target characters the code page cannot represent at all.

I fixed it by escaping every interpolated value in the reporter and making a report that cannot be emitted return invalid rather than its real code. A verdict the reader never saw is not a result.

The test suite that missed it

The scanner shipped that morning with a green test suite. The suite tested the scanner's data structures thoroughly and its output path barely. Only one test touched the reporter, and it passed an empty scan that never renders a finding. The pytest capture fixture installs a UTF-8 stream regardless of what the console is, so an encoding bug on the output path cannot be caught through it. I wrote five tests against a real Latin-1 stream. All five fail against the unfixed scanner.

4.15.0 is committed and built at 7192f13 but deliberately not uploaded and not tagged.