XClock’s controls and guides should agree. This page records the checks behind the current rebuild and their limits. A functional test is not a promise of calibrated accuracy or dependable alarms through sleep.
Environment and scope
| Environment | Evidence | Scope |
|---|---|---|
| Chrome 155 on Windows | Local candidate, checked October 16, 2026. | Real controls, alarms, timers, laps, refresh and sound playback state. |
| Desktop browser responsive viewports | Actual page widths are measured, rather than inferred from a device preset. | Layout checks are not physical iPhone or Android tests. |
| Firefox, Safari, Edge and physical mobile devices | No comparison completed for this rebuild. | We do not claim a pass for those browsers or devices. |
Alarm checks
We set two labeled alarms for the same upcoming local minute. Both entered the ringing state. Stopping the first exposed the second alert; snoozing that alert by five minutes rescheduled it. After refreshing, the future snoozed alarm returned and the expired earlier alarm did not. Temporary entries were cleared after the check.
These observations support the multiple-alarm, queued-alert and future-restoration instructions in the Alarm guide. They do not establish overnight reliability.
Timer checks
We added named 20-second and 35-second timers. Starting and completing the first left the second at 35 seconds. After adding five minutes to the finished first timer, it restarted at five minutes. Stopping and resetting it returned 5:20, because its configured duration includes the original 20 seconds plus the extension.
Both stopped entries remained after visiting the dedicated Stopwatch route and returning to Timer. The Timer guide explains this behavior, including why a restored timer is not an absolute deadline.
Stopwatch and storage checks
In one run, two laps recorded cumulative readings of 1:51.14 and 1:54.52. Stopping and refreshing restored the 1:54.52 reading and both laps. These are observed control readings, not an accuracy benchmark against a calibrated reference. Start, Stop, Lap and Reset were also exercised during responsive checks.
Focused regression checks verify that a dedicated tool preserves saved fields belonging to absent tools, does not start hidden tool types, and does not overwrite state from a non-tool page. See the storage explanation for visitor-facing consequences.
Sound checks
All seven configured media URLs returned HTTP 200 with an audio media type. A local observation harness used the actual shared runtime and real media elements, making their playback state visible for testing. Alarm 1, Alarm 2, Alarm 3, Bell and Rooster were exercised. The short Alarm 3 and Rooster samples reached their normal ends without a media error.
Playback state and successful decoding do not independently prove sound reached a visitor’s speakers. Device output, muting and permission still need to be checked on the device where an alert matters. The sound troubleshooting steps start with preview and output checks.
What has not been established
- Device sleep, operating-system suspension and overnight alarm delivery have not been validated.
- An attempted two-tab check still reported the alarm document as visible; it is not evidence of genuine hidden-tab behavior.
- No calibrated drift benchmark or daylight-saving-boundary test was completed.
- Audible output was not independently confirmed by the automated environment.
- Concurrent edits across multiple tabs are not a synchronized workspace.
How we use failures and corrections
We compare the visible result with the instruction, correct the code or copy, and repeat the affected check. For example, the observed 5:20 Reset result after Add Time was used to correct the Timer guide. We preserve explicit limitations rather than labeling an untested scenario as supported.
Report a reproducible issue through Contact: include the route, browser/device, steps, selected sound and expected versus actual result. Do not send private storage dumps. The About page describes the site’s editorial and correction standards.