[earakely-scale]

What changes

FD-5477 (HB1.7). Most of what it scoped already landed with FD-5476 (#649), or turned out not to be needed; this is what was left.

• A clockless env is refused saying what to do. Arming an env whose card offers no clock/v1 set_time, as a computer deployed alone, failed with env 'desk' does not offer 'set_time' on urn:agentenv:clock/v1. It now says the env has no clock to arm, that a computer deployed alone follows no clock, and to deploy it in a multi env, whose gateway it follows (Q12). The arm call raises EnvCapabilityUnsupported for a record that kept no card or card URL too, an older deploy that has a gateway: that one is told its record keeps no card and to deploy it again, not to deploy a multi env. Both are StepContextErrors, as fix(task_step): sync_env_clock raises StepContextError for a server that can't take the clock the task asks for #632 made sync_env_clock's other refusals of a task's clock.

The rest of FD-5477's scope

Already in place since #649:

• A computer that can't reach the gateway (Q7). sync_env_clock calls each computer's sync_time right after arming, and it waits up to 10 s for the computer's clock follower to show the gateway's current version, then refuses naming why, e.g. "it can't reach the gateway at : ". So an unreachable computer already fails the step at arm time, and arming needs no wait_followers_s of its own.
• A computer's zone that differs from the task's (Q9). Refused by the computer's sync_time, naming computer_settings.timezone.
• An MCP server whose sync_time takes no zone. Refused by sync_env_clock.
• The follower's config. Core writes it when the multi env deploys the computer, with the gateway's watch URL as the computer's sandbox reaches it.

Not needed:

• Handing a computer the gateway's time URL as its sandbox reaches it. The computer's sync_time doesn't use the URL (its follower has its own), and the apps on a computer get universe time from the clock library as session programs, so none calls sync_time (none of synthetic-pipelines' computer apps does).
• Refusing routed sites' certificates that don't cover the universe. Since FD-5480 they're valid from 1950 to 9999.
• Refusing a computer the gateway wasn't told about. The gateway declares as a follower every child whose card serves clock/v1 sync_time, so a computer that follows can't be left out.

Testing

Test	What it shows	Result
sync_env_clock_test.py	an env whose card has clock/v1 without set_time, a computer deployed alone, is refused before any request, saying to deploy it in a multi env (replacing the test that expected the bare EnvCapabilityUnsupported); a record that kept no card is refused saying so, with no mention of a multi env	45 passed
The task step and env unit tests		5,523 passed; one macOS-only disk recipe test fails locally, as on main

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issues were found.

Summary

sync_env_clock now explains why an env's clock cannot be armed.

• Clock-arm refusals tell users how to deploy the environment.

_{Reviews (7) · Last reviewed commit: "Merge origin/main; a record that kept no..." · Reviewed by Greptile}