Changelog 2026-07-09 -- OpenTofu network/pool scaffold (DOCFIX-142)

First OpenTofu content in the repo, addressing the largest item in the tooling gap register (docs/dc-dc-deployment-workflow.md gap #2). Executed under blanket approval; no live infrastructure touched -- this is unapplied IaC source only, and no live cloud/vcloud-host mutation occurred or was attempted. Ratification note: D-100..D-110 (which this code encodes the mechanics of) remain ALL PROPOSED (Stage 0 of the workflow doc); nothing here bakes in a specific unratified value as fact -- CIDRs/MTU/paths are either required inputs with no default, or DC1's already-inherited-from-DC0 values (D-101), never an invented DC2 or netem specific.

Items

1. DOCFIX-142 -- opentofu/ network + storage-pool scaffold

FILES (new): opentofu/versions.tf, opentofu/variables.tf, opentofu/main.tf, opentofu/README.md, opentofu/modules/dc-planes/*, opentofu/modules/mesh-link/*, opentofu/modules/dc-storage-pool/*.

WHAT: the six per-DC plane segments (D-052/D-100) and the D-100 dark-fiber mesh triangle (DC1<->DC2, DC1<->Office1, DC2<->Office1), each as an isolated libvirt_network resource (no forward/ips/dhcp block -- NetBox is the IPAM apex per skill hard rule 3, not libvirt DHCP); plus a directory-backed libvirt_pool per DC/Office1 for future node-VM disks. Root module wires DC1 (using its DC0-inherited CIDRs, D-101) and Office1; DC2 is written but commented out pending its NetBox CIDR assignment (D-101 open sub-item).

WHY: opentofu/ had zero files before this -- the single largest item in the 2026-07-09 tooling gap register, and a hard blocker for buildout-design Stage 1-2 (vcloud host prep, Office1 headend, per-DC substrate creation).

SCHEMA VERIFICATION (read opentofu/README.md for the full account): the dmacvicar/libvirt provider's current schema (confirmed against its actual docs/resources/*.md, tag v0.9.8, fetched this session -- NOT taken from training-data memory of older provider versions, which materially differs) turned out to nest network isolation under forward.mode rather than a top-level mode argument, and to have restructured libvirt_domain into a ~40-argument schema mirroring raw libvirt XML. The forward.mode accepted value enum could not be confirmed from the reachable docs this session; this scaffold sidesteps the ambiguity by omitting the forward block entirely (documented native-libvirt isolated-network behavior) rather than guessing a value. Flagged prominently in opentofu/README.md as the first thing to re-check if tofu validate objects.

DELIBERATELY NOT BUILT, and why (see opentofu/README.md "Scope of this delivery" for the full list): libvirt_domain (node VMs) and libvirt_volume (disk images) -- the domain schema's nested devices block (disks, interfaces, filesystems, graphics, etc.) could not be verified with enough confidence this session to author safely; DC2's plane networks -- CIDRs not yet assigned; tc netem WAN-simulation application -- an OS-level tc qdisc setting with no equivalent libvirt_network argument, needing a provisioner or companion script not yet written, and whose parameters are themselves a Phase-0 open item (D-100); OPNsense/MAAS-region/NetBox/GitBucket service VMs -- all depend on the deferred domain module.

HARNESS: scripts/opentofu-validate.sh (fmt-check + init + validate wrapper, BASH_SOURCE-self-locating, no hardcoded repo name) + tests/opentofu-validate/ (2/2 green -- only the guard-clause paths this environment can exercise without a tofu binary; the fmt/init/validate path itself is UNTESTED here, logged not hidden). Also extended scripts/repo_lint.py's L1 (ASCII/LF) file extension set to include .tf (it did not cover Terraform/OpenTofu files at all before this, since none existed) -- verified this introduces no new findings (the new .tf files are plain ASCII/LF) and the 34/34 repo-lint harness still passes.

REVERT: git rm -r opentofu/ scripts/opentofu-validate.sh tests/opentofu-validate/; revert the one-line exts change in scripts/repo_lint.py and its harness counterpart if reverting fully (not recommended -- .tf coverage is a real gap otherwise, independent of whether this specific scaffold survives).

2. Workflow doc + visual tracker updated to match

FILES: docs/dc-dc-deployment-workflow.md, the companion Artifact (same URL, redeployed) -- Stage 1/3 authoring-status notes, gap register item 2, and the status summary table all updated to reflect the scaffold's existence and its UNVALIDATED state, per the "update this as stages close" standing instruction on that doc.

REVERT: git checkout HEAD~ -- docs/dc-dc-deployment-workflow.md.

Next actionable step (logged, not actioned)

On a machine with the tofu binary and registry network access: run bash scripts/opentofu-validate.sh, then tofu providers schema -json against the initialized provider, and read the actual libvirt_domain/libvirt_volume schema directly before authoring the node-VM module -- do not proceed from memory or from a doc-summarization pass a second time.