diff --git a/.claude/skills/openstack-cloud-ops/SKILL.md b/.claude/skills/openstack-cloud-ops/SKILL.md
index 12d2f29..98a7f74 100644
--- a/.claude/skills/openstack-cloud-ops/SKILL.md
+++ b/.claude/skills/openstack-cloud-ops/SKILL.md
@@ -229,10 +229,26 @@
 would have hurt most -- a missing `-days 730` (openssl defaults to **30 days**) and a dropped
 EKU (one-directional mTLS failure at LB-create time, every gate reading PASS).
 
-**A PER-DC MAAS REGION MIGRATION HAS AN ORDERING THAT IS NOT THE OBVIOUS ONE, AND FOUR OF ITS
-STEPS HAVE NO REPO TOOL (RULED D-132 q1; executed for dc0 2026-07-30).** MAAS cannot move
-machines between regions, so the carve is RECREATED and the machines RE-ENROLLED. Hard-won
-shape: **(i) prove WHICH REGION a profile resolves to before every command** --
+**>>> THE MAAS REGION IS INSTALLED DIRECTLY IN THE DC AT STANDUP. IT IS NEVER MIGRATED. THIS
+IS THE STANDING PATH FOR dc0, dc1 AND EVERY FUTURE DC. <<<** (Operator correction 2026-08-02,
+verbatim: *"MAAS region gets installed directly on the DC, it is not migrated. If you have read
+this somewhere we need to make sure it is corrected so future deployments don't follow a
+regional migration path."*) D-132 q1 ruled a region controller PER DC; at a DC standup you
+STAND ONE UP THERE and the nodes enlist into it from the start. **There is no migration step in
+the workflow, and a session that invents one is following a path this project does not have.**
+
+**THE dc0 MIGRATION OF 2026-07-30 WAS A ONE-TIME HISTORICAL REMEDIATION, NOT A PROCEDURE.** It
+existed for exactly one reason that cannot recur: dc0's machines had ALREADY been enrolled in
+the Office1 region before D-132 q1 was ruled, so those existing records had to be moved. **Any
+DC stood up after that ruling never enters this state.** The block below is retained ONLY as
+(a) the record of what was done to dc0 and (b) a source of MAAS behaviours worth knowing --
+NOT as a workflow to follow. **Do not cite it as a standup step. Do not plan a migration for a
+new DC.** If you find yourself reading it while planning DC3/4/5, you are in the wrong place:
+the standup path is a region installed in the DC.
+
+Retained record -- the dc0 migration's ordering, which was not the obvious one, and four of
+whose steps had no repo tool: MAAS cannot move machines between regions, so the carve was
+RECREATED and the machines RE-ENROLLED. Hard-won shape: **(i) prove WHICH REGION a profile resolves to before every command** --
 `scripts/maas-profile-assert.sh` asserts by RACK-CONTROLLER IDENTITY, because a machine COUNT
 is not proof and against the wrong profile an apply is an idempotent no-op that prints PASS
 while `machine delete` destroys the real record. Repo-wide `MAAS_PROFILE` defaults to `admin`
diff --git a/docs/design-decisions.md b/docs/design-decisions.md
index 3d21ed0..4103081 100644
--- a/docs/design-decisions.md
+++ b/docs/design-decisions.md
@@ -6794,6 +6794,24 @@
 stay PROPOSED for the next deployment. This mirrors the D-104 economy -- single-unit Juju
 controller for VR1, HA deferred to Roosevelt.
 
+**>>> ANNOTATION 2026-08-02 -- THE PARAGRAPH BELOW DESCRIBES THE ONE-TIME TRANSITION OF THE
+TWO DCs THAT ALREADY EXISTED. IT IS NOT THE PER-DC STANDUP PROCEDURE. <<<**
+Recorded per D-117's treatment rule (annotate ratified prose in place, do not rewrite).
+**Operator correction 2026-08-02, verbatim: "MAAS region gets installed directly on the DC, it
+is not migrated. If you have read this somewhere we need to make sure it is corrected so future
+deployments don't follow a regional migration path."**
+The words "re-enrol and re-commission 9 nodes" below are TRUE ONLY for dc0 and dc1, whose
+machines were already enrolled in the OFFICE1 region when this amendment was ruled. **For any
+DC stood up from here on -- and for Roosevelt -- the region controller is INSTALLED IN THE DC at
+standup and its nodes ENLIST INTO IT FIRST TIME. There is no migration, no re-enrolment, and no
+carve to recreate, because nothing was ever carved anywhere else.** A future session must NOT
+read the list below as a standup checklist; the standup path is: install the region in the DC,
+then enlist and commission normally. The `MAAS_PROFILE` / region-target parameters the last
+sentence calls for are still required, because a per-DC region must be addressed explicitly --
+that part generalises; the re-enrolment does not. Cross-reference:
+`.claude/skills/openstack-cloud-ops/SKILL.md` carries the same correction at the head of its
+(retained, historical) dc0-migration block.
+
 **CONSEQUENCE, STATED PLAINLY: this REOPENS the MAAS layer of Stages 3 and 4, both of which
 are CLOSED and MERGED to `main`.** A MAAS region owns its own database; machines, fabrics,
 VLANs, subnets, spaces, reserved ranges, tags, images, DHCP and power configuration do not