# Runbook fold register -- bringing the VR1 DC-DC runbooks up to the ruled state

**Opened 2026-08-02** on the operator ruling to fold before exercising: *"1 fold first"*,
*"3 start at 2"*, *"4 yes, all DC come up with and in their own region"*.

## Why this exists

Every decision ruled since Stage 4 closed (2026-07-27) was **retrofitted onto a running
build**. None of it went back into the runbooks. Measured 2026-08-02:

| Runbook | per-DC region | D-138 client | GUA / v6 | oob | one artifact strategy | egress gate |
|---|---|---|---|---|---|---|
| `dc-dc-phase2-tofu-dc-substrate` | 0 | 0 | 1 | 0 | 0 | 0 |
| `dc-dc-phase3-maas-enlist-deploy` | 0 | 0 | 0 | 0 | 2 | 0 |
| `dc-dc-phase4-juju-bundle-per-dc` | 1 | 0 | 3 | 0 | 5 | 1 |

`D-138` and `D-139` appear in **no runbook at all**. Nothing in the chain builds a per-DC
MAAS region, a snap proxy, or the GUA carve.

**The consequence, stated plainly:** running the deployment chain as written today would
rebuild the *pre-D-132/D-138/D-139* shape -- a DC enrolled in Office1's MAAS region,
ULA-addressed, with no snap proxy and the juju client on the wrong host -- and would then
fail at exactly the points already fixed by hand. **The runbooks are the primary deliverable
(MINIMIZE DELTA TO ROOSEVELT); a runbook that has only ever been retrofitted is not a runbook
that works.**

## Severity classes -- fix in this order

**Class A -- ACTIVELY WRONG.** The runbook states something that is no longer true. A session
following it does the wrong thing and does not stop. This is worse than an omission and is
fixed first.

**Class B -- MISSING BUILD STEP.** The chain does not build something the ruled design requires.
A session following it stops, or silently produces a DC of the wrong shape.

**Class C -- MISSING GATE.** The step exists but nothing verifies it.

## Register

| # | Class | Item | Ruled by | Lands in | Status |
|---|---|---|---|---|---|
| F1 | **A** | "Both DCs deploy from the Office1 headend by the SAME procedure" (`phase4:14`, restated `:158`). D-138 moved every cloud-facing tool INTO the DC. | D-138 | phase4 header + every run-location callout | **DONE 2026-08-02** |
| F2 | **B** | No runbook builds a per-DC MAAS region. dc0's was a MIGRATION executed by hand; the ruling makes it a BUILD property, so nobody should ever repeat that migration. | D-132 q1 + operator 2026-08-02 ("all DC come up with and in their own region") | phase2 (region VM) + phase3 (enlist against the DC's OWN region) | OPEN |
| F3 | **B** | No runbook carves GUA IPv6. The apex push, the MAAS `/64`s and the node statics are all absent. | D-139 ruling B | phase2 (apex) + phase3 (MAAS subnets, node statics) | OPEN |
| F4 | **B** | The family matrix (which planes keep IPv4) appears nowhere. | D-139 ruling A + the 2026-08-01 "B plus C" narrowing | phase3 | OPEN |
| F5 | **B** | The `oob` plane -- ruled dual-stack, `10.12.40.0/22` dc0 / `10.12.88.0/22` dc1, `:f0::/64` v6 -- exists in no runbook and in no MAAS. | D-139 amendment 2026-08-01 (a)+(b) | phase2 + phase3 | OPEN |
| F6 | **B** | `lb-mgmt` has never been carved anywhere, in either family. | D-139 step 5 | phase3 | OPEN |
| F7 | **B** | No runbook builds a snap proxy. Its absence is what broke the 2026-07-31 deploy. | D-135 items 2-3 gap | phase3 | OPEN |
| F8 | **B** | Two artifact strategies branch per DC. The 2026-08-02 amendment converges on the proxy at rebuild, so the chain can carry ONE. | D-135 amendment 2026-08-02 | phase2 + phase3 | OPEN |
| F9 | **C** | Nothing gates DC egress at build time. A 19-hour outage was invisible to every gate. | this session | phase2 (edge first comes up) -- phase4 Step 3.9 and restart Stage 0 already DONE | PARTIAL |
| F10 | **C** | Nothing compares D-139's ruled family/GUA tables to the artifact. `dc-node-v6-verify` asserts NIC-against-MAAS and its own header says explicitly NOT against the ruled table. | -- | a new gate, or an extension of an existing one | OPEN |
| F12 | **A** | `SKILL.md` -- the always-loaded routing layer -- stated "Plane 2 EXECUTES on `voffice1`" with **ZERO mentions of D-138**. More dangerous than any runbook instance: every fresh session reads it BEFORE any runbook. | D-138 | `.claude/skills/openstack-cloud-ops/SKILL.md` | **DONE 2026-08-02** |
| F11 | **B** | The edge rebuild path (D-112(c) console bootstrap + D-113(a2) key mint + addressing) is documented across a changelog and a runbook section rather than as one followable procedure. Exercised three times now (dc0 twice, dc1 once). | D-112 / D-113 | phase2 | OPEN |
| F13 | **A** | `phase-02-vault-bringup.md` (vault init/unseal/authorize) is VR0-shaped -- `-m openstack` and run-location "jumphost" on every line; VR1 needs `-m vr1-dc0` on the DC rack (D-138), head-substituted on the 2026-08-05 dc0 run. `-m openstack` is a non-existent VR1 model (fails closed, but a wrong-model foot-gun). **Scope stretch, stated: this register is scoped to the DC-DC phase2/3/4 runbooks; phase-02-vault-bringup is a VR0-track runbook reused for VR1 vault init -- F12 (SKILL.md) is the precedent for stretching beyond that set.** = D-142 R1. | D-138 / D-142 R1 | `runbooks/phase-02-vault-bringup.md` (model + run-location legend) | OPEN |

## Out of scope for this fold, deliberately

- **D-140** (OpenTofu management of the Juju layer) is PINNED to the end-of-deployment review
  by operator ruling. It is a REMAINING TASK, not fold work.
- **Phase 0 / Phase 1** (vcloud prep, Office1 standup) are shared and healthy. The exercise
  starts at Phase 2 by operator ruling, so these are not folded now.

## How this register closes

Each row closes when the runbook change is committed AND the change is exercised by the dc1
Phase-2 rebuild. A row marked DONE on the edit alone is a **ruled-but-not-built** claim of the
exact class this project keeps finding -- the exercise is what proves it.
