2026-07-17 -- vcloud post-restart sweep + D-126 base-leg oneshot + D-128 operating model

Trigger: operator asked for a full health/status sweep after the vcloud host patch+reboot, which surfaced a recurring Office1-access break; the fix + operating-model ruling are recorded here. Branch dc-dc-stage3-phase2-dc-substrate. Live-host UNIT INSTALL is still PENDING (operator sudo) -- see below.

vcloud post-restart health sweep (read-only)

The vcloud HOST completed its bookend patch+reboot: running 6.8.0-136, apt upgradable = 0, no reboot-required. Libvirt recovered clean (12 nets + 4 pools active/autostart; voffice1 + office1-opnsense autostart=enable, both RUNNING). Autostart chain proven end-to-end -- all guests + the edge reported ~3h37m uptime matching host boot, i.e. virsh autostart -> LXD boot.autostart self-recovered the whole Office1 stack with zero manual start. In-guest (after access restore): opnsense pf Enabled/80 rules, kea-dhcp4 on 10.10.0.1:67, vtnet0/vtnet1 active, LAN+egress OK; office1-netbox HTTP 302; office1-tailscale online 100.64.0.53 advertising 10.10.0.0/22; both LXD service VMs RUNNING. No repo change; sweep result only.

Finding: the base L3 leg is the un-persisted foundation D-126 never owned

ssh voffice1 / office1-* timed out post-reboot. Root cause (measured): office1-local is an ISOLATED libvirt net (no <ip>/<forward>), so the host's own leg -- 10.10.0.10/24 on the bridge (as-built :41)

• compose route 10.10.1.0/24 via 10.10.0.20 (:88) -- lives nowhere in the libvirt XML and is dropped on every reboot. ip route get 10.10.0.20 fell through to the default lab gw; ping .20 100% loss. D-126 made the layers ABOVE this durable but assumed base reachability existed.

Access restored LIVE (operator sudo, gated) to verify the exact recipe before encoding it: sudo ip addr add 10.10.0.10/24 dev virbr2 + sudo ip route replace 10.10.1.0/24 via 10.10.0.20 dev virbr2 -> voffice1 0% loss, all aliases live. This is AD-HOC (non-persistent) until the unit is installed. Revert: sudo ip addr del 10.10.0.10/24 dev virbr2 (and the route is dropped on next reboot anyway).

NEW: scripts/site-baseleg.sh + tests/site-baseleg/ (D-126 amendment)

Root Type=oneshot systemd unit that re-adds the base leg + compose route at boot, After=libvirtd.service so it runs AFTER libvirt creates the autostart bridge -- which is why it does NOT hit the netplan-vs-libvirt race that made D-126 reject "persist the L3 route" (narrow reopening, base leg ONLY; root because L3 has no rootless equivalent -- the D-126 forward DEPENDS on this leg). Subcommands render|apply|check|install| remove|list. The bridge is DISCOVERED from the stable net NAME (virsh net-info office1-local), never a baked virbrN (lib-net.sh PATTERN-1); apply is idempotent (guarded add + ip route replace) and root-guarded; check is the read-only session-verify. Harness tests/site-baseleg/run-tests.sh 24/24 (offline: unit shape, no-baked-bridge, discovery present, idempotency, root-guard, no baked secret, no inferred DC IP). Gauntlet ALL GREEN (67 harnesses); repo-lint 0-fail. Revert: git rm scripts/site-baseleg.sh tests/site-baseleg/; on any host where installed, sudo bash scripts/site-baseleg.sh remove office1.

Ordering MEASURED (not inferred): this host runs monolithic libvirtd.service (active; virtnetworkd/ virtqemud inactive), so After=libvirtd.service is correct; the unit also orders after virtnetworkd.service for modular-libvirt hosts (harmless no-op here). Type=oneshot has no Restart=, so the 60s bridge poll is the only backstop (documented limitation). ExecStart is the script's ABSOLUTE path -> a repo rename (D-110) breaks the boot unit.

INSTALLED 2026-07-17 (operator sudo); boot-race UNPROVEN. install wrote + enabled /etc/systemd/system/site-baseleg-office1.service; its apply ran at install -> status=0/SUCCESS, check office1 -> ok. That run was POST-boot (bridge already up), so it exercised the apply logic but NOT the After=libvirtd+poll race. Boot durability stays UNPROVEN until an ACTUAL reboot shows ssh voffice1 self-heals -- the next natural reboot is the proof; no separate test reboot forced.

Records: D-126 amendment + D-128 operating model + skill/doctrine

• docs/design-decisions.md: D-126 amendment (base-leg durability + the tool) and NEW D-128 (VR1 operating model -- Claude on the vcloud jumphost; two-plane origin split with Plane 1 on vcloud / Plane 2 executing on voffice1; workstation tailnet is the human path; D-107 left untouched). ASCII-clean (non-ASCII count unchanged at 239). Revert: delete the amendment + the D-128 block.
• .claude/skills/openstack-cloud-ops/SKILL.md: added a routing row (site unreachable post-reboot -> site-baseleg.sh check office1) and the D-128 operating-model INVARIANT in the bootstrap loop. Revert: git checkout the file.
• docs/dc-dc-deployment-workflow.md: added the operating-model bullet to Cross-cutting discipline. Revert: git checkout the file.

Why (evidence trail)

Advisor-conferred on the sweep scope + the base-leg mechanism gap. The operating-model ruling followed a grounded discussion: the tooling FIXES execution hosts by design (outer qemu:///system on vcloud; inner qemu+ssh-from-Office1, R-5), so Claude's host only picks transport -- relocating the session to the workstation would trade away the ONE-session/Remote-Control portability, relocate the gating/secrets contract, and put the riskiest Plane-1 ops over a droppable transport, for a reachability win the base-leg oneshot already delivers.