# 2026-07-14 -- D-119 OpenTofu rename APPLIED (operator-gated destroying apply)

The `tofu apply` deferred by the D-119 commit. Executed after explicit operator authorization.

## Pre-apply discipline (verify before mutate)

A LIVE re-check immediately before the apply (not the earlier measurement):

    dc1-* / mesh-dc* networks   -> 0 DHCP leases each
    dc1-pool / dc2-pool         -> 0 volumes each
    every libvirt domain        -> none references a dc1-*/mesh-dc* network

Then a fresh `tofu plan`: **11 to add, 0 to change, 11 to destroy** -- all `must be replaced`
(the `moved{}` blocks). Confirmed empty, so the replace is safe (standing lesson 2: an apply
touching a live libvirt object's devices is an outage -- none of these carried anything).

## Result

    Apply complete! Resources: 11 added, 0 changed, 11 destroyed.

Verified ON THE HOST, not just in state:
- state holds all 11 under `vr1_dc0_*` / `vr1_dc1_*` / `mesh_vr1_*`;
- `tofu plan` -> **"No changes"** (repo/state back in sync);
- libvirt shows `vr1-dc0-{provider-public,metal-admin,metal-internal,data-tenant,storage,replication}`,
  `mesh-vr1-dc0-office1`, `mesh-vr1-dc0-vr1-dc1`, `mesh-vr1-dc1-office1`, `vr1-dc0-pool`, `vr1-dc1-pool`;
- ZERO old `dc1-*`/`dc2-*`/`mesh-dc*` network or pool names remain.

## No collateral

Office1 was never in the plan and is untouched: `office1-local`, `office1-wan`, `wan`, the
`office1-opnsense` edge and `voffice1` all present; edge (10.10.0.1) and voffice1 (10.10.0.20)
both reachable after the apply.

## Why this went before Stage 3

Carrying divergent repo/state into Stage 3 would let a Stage-3 `tofu apply` silently bundle this
11-resource rename with real DC provisioning. Applying it now, while the objects are empty, kept
the rename a clean standalone change.

## Revert

The `moved{}` blocks are symmetric; reverting the D-119 code commit and re-applying renames back.
There is nothing to preserve in these objects (they are empty), so a revert is a pure rename.