amadan
docs: nearest-region spec rev 4.1, Paul's split ruled as R8
Placement ships on this spec; latency routing (R6) is sequenced to its own follow-on spec, built to the section 13 invariants. The section 18 question is removed, the rollout states that no placement step depends on Phase L, and section 13 notes the #169 arming hazard was posted to amadan carlos/platform #169 on 2026-10-01.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+17
−15
docs/superpowers/specs/2026-10-01-nearest-region-default-design.md+17 −15
diff --git a/docs/superpowers/specs/2026-10-01-nearest-region-default-design.md b/docs/superpowers/specs/2026-10-01-nearest-region-default-design.md| index c29e1ed06..bc6b813e3 100644 |
| --- a/docs/superpowers/specs/2026-10-01-nearest-region-default-design.md |
| +++ b/docs/superpowers/specs/2026-10-01-nearest-region-default-design.md |
| @@ -1,7 +1,7 @@ |
| # Nearest region by default: each app picks its region at creation |
| **Date:** 2026-10-01 |
| -**Revision:** 4. |
| +**Revision:** 4.1. |
| - Rev 1 (7fbc9479) went to Astra (GPT-6, via codex), and the findings are in |
| `CODEX-FINDINGS-NEAREST-REGION-R1.md`. |
| @@ -16,6 +16,7 @@ |
| - **Rev 4 moves latency routing (R6) into a follow-on spec**, because the |
| existing steering converger is not safe to arm (§13). That spec gets |
| invariants to meet, and placement ships first. |
| +- Rev 4.1 records Paul's ruling on that split as R8 and removes the question. |
| **Status:** DRAFT for review. The rulings in §3 are Paul's and are not |
| reopened here. Everything marked *(decision)* is this spec's and open to |
| @@ -134,6 +135,7 @@ Non-goals, each with a follow-up in §20: |
| | R5 | **Done = new apps only, plus moves.** Existing apps keep their region. Relieving Ireland comes from instance moves. An owner-only verb to change an existing app's region is out of scope (a follow-up). | §2, §20 | |
| | R6 | **Latency routing is in scope** for non-home instances, not placement alone. | §13: its invariants and gates, delivered by the follow-on spec | |
| | R7 | **The rollback floor is a runbook rule.** It is documented for release notes and the roll recipe, with no outside guard. | §5.7, §17 | |
| +| R8 | **Split** (Paul, 2026-10-01). Placement ships on this spec. Latency routing (R6) is sequenced to its own follow-on spec, built to the §13 invariants. | §13, §17 | |
| | D1 | The app region is stored console-side and set once at creation. The create door fills an empty `req.Region` from it **before** normalization, the allow-list and the armed checks. Existing apps are backfilled to the home, so behaviour does not change. | §5, §7 | |
| | D2 | The guess works in coordinates: timezone to a point, IP to a point through an operator-supplied MaxMind-format `.mmdb` (`CONSOLE_GEOIP_DB`), then the great-circle nearest eligible region. Home when everything fails. | §6 | |
| | D3 | Surfaces: a new-app picker; names and the guess for external pickers; the CLI as R4. | §9, §10, §11 | |
| @@ -855,13 +857,17 @@ Behind these sits a fourth fact. The flagship's Route53 zone for |
| DNSimple still serves the live answers (`dns.tf`). A converger writing to a |
| zone nobody consults is inert at best. |
| +The arming hazard was posted to amadan discussion carlos/platform #169 on |
| +2026-10-01, so it is on record where the arming decision lives, independent |
| +of this spec. |
| + |
| Three rounds have each found a new fault in this one area. Per the lesson this |
| repo has already paid for, the answer is not another patch to an example. It |
| is an invariant, a design built to it, and a simulation that checks it. |
| That is a spec of its own, about the converger. It is not a section of a |
| spec about choosing regions. |
| -**(decision) Phase L moves to a follow-on spec, and placement ships without |
| +**(ruling R8) Phase L moves to a follow-on spec, and placement ships without |
| waiting for it.** R6 is unchanged: latency routing for non-home instances is |
| still in scope for this work and still binding. It is sequenced, not dropped. |
| This spec now does three things for R6: |
| @@ -1177,26 +1183,22 @@ and `ip` appear in none of: |
| 6. **CLI release.** It is safe in either order (§9.6). |
| 7. **titogo**, in its own repo, adopts `/regions/guess` and the place names. |
| -**Phase L: latency (R6)** is the follow-on spec's rollout, not this one's |
| +No step of Phase P depends on Phase L. Phase P writes nothing to DNS, stamps |
| +no `Steering` field, and needs neither `CARLOS_STEERING_ZONE_ID` nor any |
| +change to the zone. |
| + |
| +**Phase L: latency (R6, R8)** is the follow-on spec's rollout, not this one's |
| (§13.3). Its gate is that spec landing with its simulation passing, plus |
| scoped approval for the infrastructure. Until then, **no deployment arms |
| `CARLOS_STEERING_ZONE_ID`**, including for the static-site steering that |
| -already exists. Take the latency baseline once Phase P step 5 has run. |
| +already exists. The latency baseline is taken once Phase P step 5 has run. |
| +That makes Phase L depend on Phase P, never the other way round. |
| Copy review (§19) happens before Phase P step 3 ships any string. |
| ## 18. Questions for Paul |
| -1. **Sequencing R6.** Do you agree that placement (Phase P) ships on this |
| - spec, and latency routing (Phase L) follows on a spec of its own, built to |
| - §13.2's invariants? |
| - - The alternative is to hold placement until the converger is fixed. |
| - Ireland's disk is the incident, and placement relieves it for new |
| - instances without touching DNS. |
| - - **Recommendation: split.** R6 stays binding on the follow-on spec. It is |
| - sequenced, not dropped. |
| - |
| - This is a sequencing call under R6, which is why it is yours. |
| +None. R8 settled rev 4's sequencing question. |
| ## 19. Copy (pending copy review) |
| @@ -1348,5 +1350,5 @@ The `docs/site/cli.md`, README and release-note additions (§5.7, §11, §12, |
| | former question | disposition | |
| | --- | --- | |
| | Q1: apply R5, titogo separate | adopted (§2, §17 step 7) | |
| -| Q2: implement R6 with the DNS corrections, keep the separate approved Phase L rollout and measurements | adopted in substance. The corrections are larger than a patch, so they move to the follow-on spec with invariants (§13); the sequencing is §18 Q1. | |
| +| Q2: implement R6 with the DNS corrections, keep the separate approved Phase L rollout and measurements | adopted in substance. The corrections are larger than a patch, so they move to the follow-on spec with invariants (§13); the sequencing is ruled by R8. | |
| | Q3: name the exact floor version before activation; keep region-aware reads when disabling | adopted (§5.6, §5.7, §17 step 5) | |