# 2026-07-13 -- the workflow doc's status was materially FALSE

`docs/dc-dc-deployment-workflow.md` is the first thing a fresh session reads. Its status claims
were written 2026-07-09 and never updated, so they had drifted into being **wrong in ways that
would misdirect real work**. Corrected against MEASURED state, not impressions. Docs only; no
code, no live system touched.

## What was false, and what is true

| claim in the doc | reality (measured 2026-07-13) |
|---|---|
| gap #2: "UNVALIDATED -- no `tofu` binary available" | **OpenTofu v1.12.3 IS installed.** The tree validates: root + **10/10 modules**. It has also been **APPLIED** -- 11 resources in state. |
| `opentofu/` "SCAFFOLDED, UNVALIDATED" | VALIDATED and partly APPLIED. But **2 modules were BROKEN and had never been parsed** (DOCFIX-194) -- see below. |
| gap #17: "no per-site ISP-uplink network exists anywhere, for ANY site" | **CLOSED FOR OFFICE1.** `office1-wan` is live (virbr11, NAT, `172.30.1.0/24`); the edge's WAN is on it at `172.30.1.2`, egress verified. The gap's own proposed answer (a dedicated per-site uplink network, NOT a mesh leg) is what was built. **DC1/DC2 still have none** -- `dc1-provider-public` has no IP and no forward. |
| `modules/opnsense-edge` "BUILT, UNVALIDATED (no real boot)" | **BUILT, INSTANTIATED, RUNNING.** Routing, NAT, egress 0.0% loss, serial console, SSH-key managed, Kea DHCP on udp/67. |
| `templates/opnsense-config.xml.tmpl` "BUILT, renderer fully tested" | **SUPERSEDED by D-113(a2)** -- config is REST-API-managed. A full config.xml push would now **CLOBBER** live DHCP. |
| `modules/netem-link` "BUILT, UNVALIDATED" | **WAS BROKEN** (destroy provisioner referencing `var.*` -- could not even `init`). Fixed 2026-07-13 (DOCFIX-194). |
| Stage 2 "RUNBOOK WRITTEN, NOT YET EXECUTED" | **PARTIALLY EXECUTED.** The edge + both Office1 networks are live. The **three headend VMs are NOT built.** |

## The trap this correction removes

Stage 2's gate row said the edge was "blocked on gap #17's WAN-side network." Both halves are
now false, and someone reading it would go build a network that already exists.

Worse, the Stage 2 gate lists "NetBox authoritative" and "GitBucket serving" -- and NetBox and
GitBucket **do** answer, at `baldurkeep.com`. But those are **PRE-EXISTING services, not Office1
headend VMs**. Measured: `office1-opnsense` is the ONLY VM on the vcloud host. It would be very
easy to tick that gate as met and move to Stage 3 with no headend at all. The corrected State
section says so explicitly.

## What remains of Stage 2 (the real critical path)

The three headend service VMs -- MAAS-region, NetBox, GitBucket -- do not exist. Per the runbook
they are blocked on a genuine decision, not on typing: Option A (`modules/cloudinit-vm`) needs
`user_data`/`meta_data`/`network_config` designed and an image source chosen; Option B is manual
`virt-install`, logged as debt. Both `cloudinit-vm` and `base-image` now at least VALIDATE
(DOCFIX-194) -- they never had before.

## Revert

    git revert <this commit>

Restores the stale (false) status claims.