Latency steering is armed nowhere: CARLOS_STEERING_ZONE_ID is unset in every infra root module open
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession a4cbaf89 · claude-code/2.1.278 · DOCS-T1
Found while designing the platform half of #162.
internal/steering writes per-edge latency records only when the deployment arms CARLOS_STEERING_ZONE_ID; unset, the duty "reads nothing and calls no AWS API" (internal/host/steering_loop.go:219). No root module in infra/ sets steering_zone_ids — only modules/region-host declares the variable (infra/modules/region-host/variables.tf:153). So on the flagship today, no host has a latency record, and a host whose record says steering: "latency" gets nothing.
Two consequences worth separating:
For #162, replica placements are inert until this is armed. A replica box mints its alias, serves the account's public host correctly, and receives no buyer, because DNS still names one edge. The spec records it as a deployment prerequisite rather than branch work.
On its own, this means the multi-region latency-routing half of the ingress design is built but not switched on. Anything that assumed "a request lands on the nearest box" — including how #162 was originally framed — is currently untrue on the flagship.
This is an infrastructure change (a hosted-zone id per deployment, and whatever the region-host module needs to receive it), so it wants scoped approval before anyone applies it: AGENTS.md, "Production infrastructure needs scoped approval". Filing it so the prerequisite is visible and not rediscovered.
What would settle it: which hosted zone the apps domain lives in per deployment, whether the flagship wants latency records for every steered host or only opted-in ones, and whether arming it changes anything for hosts that are steered today (there are none, which is what makes this cheap to turn on and worth checking rather than assuming).
claude agent, operated by paul@keymail.devdriven by paul@keymail.devsession 57e315fe · claude-code/2.1.284 · DOCS-T1
Do not arm CARLOS_STEERING_ZONE_ID on the flagship as the code stands. Found while specifying the nearest-region default (spec 2026-10-01-nearest-region-default-design.md rev 4 §13, branch design-nearest-region; Astra round 3, findings R3-1 and R3-2):
Wildcard shadowing. Carloku serves every tenant name from one *.oncarlos.com record that points at Ireland. Once a latency record exists for new.<acct>.oncarlos.com, sibling names under the same parent stop matching that wildcard at the Route53 zone. Static sites already carry steering: latency today, so arming would break unsteered siblings in every account that has a static site, whether or not anything new ships.
One record per AWS region, not per edge. The converger writes one latency record per box. Route53 allows one latency record per region for a name, so two boxes in the same region break every update.
Stuck deletions. A withdrawal over the converger's size limit is refused on every pass, forever. It is never spread across passes.
Wrong zone. The flagship's Route53 oncarlos.com zone is marked staged, not authoritative (dns53.tf). DNSimple still answers the wildcard, so the converger may be writing to a zone nobody queries.
The spec turns these into six invariants that a follow-on latency spec must meet, proven by a randomized test against a fake that enforces Route53's rules. Until that lands, #169 stays unarmed.
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 57e315fe · claude-code/2.1.292 · DOCS-T1
Ruling (Paul, 2026-10-21): keep the converger running on the flagship. This records the state the earlier "do not arm" comment did not know about.
It has been armed since 2026-08-24. CARLOS_STEERING_ZONE_ID=Z04313755ASMHAWD536L is set in host.env on all four flagship boxes (read 2026-10-21). The housekeeper (AU since 2026-09-10) writes 124 latency records for 31 names, bound to the four carlos-steering health checks.
Points 1 and 4 of the earlier comment do not hold on the flagship. Route53 does not apply the RFC 4592 empty-non-terminal rule (measured), so steered names do not shadow their siblings. And oncarlos.com has been delegated to the Route53 zone since 2026-08-11. Points 2 and 3 still stand, and Phase L still owns them.
Since 23:10Z on 2026-10-21, *.oncarlos.com is itself latency-routed across the four edges by tofu (carloku-infrastructure #13, merged). Every unsteered name now enters at the nearest healthy edge. The converger's per-host records take precedence, and they give the same answer. *.dev.oncarlos.com is latency-routed across sophie (eu-west-1) and dennis (eu-west-2). The converger stays unarmed on dev.
Latency baseline (spec §13.3). Measured with curl -w, 30 runs per host, from each flagship box (via SSM, through its own resolver). Medians and p90 in ms, as connect / TLS done / first byte. "Before" was 22:5x and "after" was 23:13, both UTC on 2026-10-21.
printacard-app.bdd answers 503 from the edge itself, so it shows the entry cost alone. On ips.bdn, the time left after TLS is the backhaul to its home box in Ireland. The steered control, website.bes, did not change (about 22 ms to first byte on every box). These are figures from inside AWS, not from real visitors.
claude agent, operated by paul@keymail.devoperated by paul@keymail.devsession 57e315fe · claude-code/2.1.292 · DOCS-T1
Correction to the times above: the before run started at 22:40Z and the after run at 23:17Z. The flagship swap was INSYNC at 23:10Z.
amadan