[earakely-scale]

What changes

FD-5482 (HB1.11), the CI test of the computer's clock across jumps in a multi env, built as a lean extension of computer_clock_test, so it adds seconds to CI, not a deploy.

That test already deploys a multi env with the ubuntu-24.04 desktop and an MCP server and arms its clock with sync_env_clock. On the same deploy, it now also takes the gateway's clock:

• a day on and a week on (advance), and a month back (set_time);
• to a rate of 10, frozen (rate 0) and running again (set_rate);
• 8 hours on after its follower is killed, and through a reset, as before.

After each change, once the follower has acknowledged it (each write waits for it with wait_followers_s, as #672 is deferred), it checks that the session's clock is within 1 s of the gateway's, at the rate of 10 too. At the rate of 10 and frozen, it also checks that the session's clock runs at 10 and stands still. The old check allowed 5 s.

How it stays reliable. Each reading is taken inside the computer, in one command: real time, the session's time, then real time again, each a fresh date, the first and last on real time (AGENTENV_REAL_TIME=1). Driver and exec latency are outside the bracket. The gateway's state is read from the test, bracketed by real time the same way, and carried at its rate to the computer's real time. Either reading is taken again, up to five times, until half its bracket at the clock's rate is at most 0.25 universe seconds (READING_S): 0.5 s of real time at rate 1, 0.05 s at rate 10. The two readings' error then stays within 0.5 s of the 1 s bound, and the rate over 2 s is known to within about 2.5%.

Why a rate of 10. A rate change reaches the session's clock as late as the follower is slow to react, and that delay is carried at the old rate until the next jump. On a loaded host, at rate 60, that was 67 ms. At rate 10 the follower would have to be about 100 ms late to reach the 1 s bound. Jumps set the clock outright, so they carry no such offset.

Left out of FD-5482's scope, and where each part is covered

FD-5482 asked for	Covered by
date, Python, Chromium's Date.now and the driver on universe time across many jumps, a rate change and a freeze; input and screenshots after each jump	clock_desktop_test (30 jumps; the clock page written as the follower writes it)
Live sites at far universe dates through the egress proxy	chromium_universe_test, egress_test
A routed site at far universe dates	clock_desktop_test
Clock-time timers firing at the jump, waits, TLS	the tst/clock gates
MCP servers agreeing with the gateway	they read the gateway's get_time on every call
A LibreOffice document's date	LibreOffice isn't in the base; the app lives in synthetic-pipelines
A non-UTC zone and a daylight-saving crossing	not covered: the items MCP server's sync_time takes no zone, so the multi env can't be armed in one; the zone is glibc's localtime over the universe's UTC
The prototype's soak numbers (1,337 requests, 150 input rounds, 750 timers)	not repeated here: they'd cost minutes on every run

Testing

On the x86 host (local Docker):

Run	Result	The test's own time (pytest call)
main's version	passed	46.7 s
this version	passed; skews 1–10 ms, 62 ms at rate 10; rate 10.0002; frozen 0.0	51.4 s
this version, every core busy	passed; skews 8–21 ms, 177 ms at rate 10; rate 10.0003; frozen 0.0	63.4 s
earlier versions (rate 60, unscaled brackets): three runs, and one with every core busy	passed; skews up to 67 ms after the rate of 60, which led to the rate of 10	49.7–50.1 s; 61.3 s

So it adds about 5 s to the test, against its roughly 300 s in CI, most of which is the deploy.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge.

Summary

Extends the existing computer clock test across jumps, rate changes, freezing, follower recovery, and reset.

• The computer clock test checks gateway changes within one second.

_{Reviews (8) · Last reviewed commit: "test(computers): each clock reading's br..." · Reviewed by Greptile}