# FINAL advisor review -- container-layer-elimination pass (aggregate)

**Reviewer:** the advisor (`advisor()` tool; recorded as "the advisor" -- no model name asserted,
per operator instruction). **Date:** 2026-08-09. **Input:** the full pass transcript (all worker
bounded summaries, the five administrator reports, `FINAL-PLAN.md`).

## Verdict: SOUND

Nothing in the aggregate overturns the pass's three load-bearing conclusions:
- **Option 1** (flat node VMs on vcloud libvirt + a small per-DC `vr1-dcN-client` VM) as the target;
- **Root topology (B)** (shared-outer + per-DC-flat roots) as the recommended tofu shape;
- **New D-144** (superseding D-123 Model B) as the decision form, with the D-143 precedent.

The plan is honest about its open items and its recommendation-grade items pending live re-measure.
The advisor raised TWO follow-up gaps -- both the SAME failure shape (an attachment object is
deleted; a survivor is glossed "unchanged" when its attachment point no longer exists). Both were
VERIFIED against the full pass docs by the orchestrator this session. Neither changes the plan's
direction; each becomes a NAMED open item.

## Follow-up 1 -- MAAS power-dial REACH (distinct from authorization scope). CONFIRMED, fold into DEC-15.

The pass covered the power-key AUTHORIZATION concern thoroughly (both DCs' region VMs dial one vcloud
`qemu:///system`; the #11 mitigation / DEC-15 scopes it). It did NOT resolve REACHABILITY: how an
in-plane `vr1-dcN-maas-01` gets an L3 path to vcloud's own libvirtd at all. Model B dialed the
containment VM at an in-plane metal-admin address (`10.12.x.2`); flat, the target is vcloud's own
libvirtd, and vcloud by design holds no address on any DC plane. The naive fix -- give vcloud an
address on the metal-admin bridge -- is EXACTLY "a host address on a plane bridge", which W3.3's (a)-control
fixture treats as a failure-to-catch. Evidence: `pass2-w3-scripts.md:184-201` and `pass4-w3` B.6.1/B.6.2
assume "one endpoint reachable from BOTH DCs' region VMs" without spelling out the reach path.
**Disposition:** DEC-15's framing is AMENDED -- the power-key mechanism ruling must decide REACH and
AUTHORIZATION together (the reach path and the (a) control's no-host-on-plane-bridge rule must be
reconciled, not left to a delivery-time improvisation). Does not block the D-144 package; sharpens DEC-15.

## Follow-up 2 -- the dc0<->dc1 mesh leg's post-flatten consumer + cross-DC Ceph path. CONFIRMED, NEW open item DEC-24.

Verified precisely: the containment VMs attach ONLY to the two Office1-TRANSIT mesh legs
(`opentofu/main.tf:192-193` region-end, `:430`/`:554-555` DC-end) -- which the pass reassigns cleanly to
the `vr1-dcN-client` VM's transit NIC (`pass2-w1-tofu-modules.md` row `mesh-link`; `pass4-w3` B.1.4). But
the **dc0<->dc1 leg** is a DIFFERENT segment: `bridge virbr5` (`main.tf:356`), the netem target
(`main.tf:334-356`), designed as the cross-DC **Ceph replication** carrier (D-100 mesh-not-star rationale
`design-decisions.md:2235`; D-108 rbd-mirror/radosgw-multisite rides the IPv6 replication plane
`:3051`; `dc0<->dc1 stays replication-only` `:4993`). `pass2-w1` graded it "untouched either way" -- true
for the BRIDGE's existence, but it does NOT define what attaches the (now vcloud-level) replication plane
to virbr5 and routes cross-DC traffic THROUGH netem once the containment layer is gone.
**Disposition:** NEW open design item **DEC-24** (Tier 1-adjacent, pairs with DEC-14 the (a)-control):
"who holds the dc0<->dc1 mesh-leg endpoints and how does the flat-topology replication plane route
cross-DC Ceph traffic through netem (WAN fidelity) without violating the (a) control." Nuance carried
honestly: this is PARTLY pre-existing -- cross-DC replication was never built (dc1 HELD, rbd-mirror blocked),
so the flat design must DEFINE this path, it is not a regression the flattening introduces into a working path.
Roosevelt-delta: on bare metal the dark-fiber dc0<->dc1 leg is real (`design-decisions.md:2235`), so this
routing must be defined regardless -- the flat rehearsal is the right place to design it.

## Report mechanics (advisor-directed, executed by the orchestrator)

1. This file (`FINAL-advisor-review.md`) captures the review. [done]
2. `operator-report.md` leads with the Tier-1 decisions (DEC-01 first; DEC-15 as the sharpest execution
   blocker, now carrying the reach dimension; DEC-24 added), carries W4.4's evidence-grounded ledger verbs
   (D-122 AMENDS, D-127 AMENDS-deferred -- NOT the tasking shorthand), and marks the recommendation-grade
   items (DEC-08/09 rack retirement, FIT/capacity) as pending live re-measure. It situates Part A: the
   teardown presumes the dc0 checkpoint wrap-gates (cloud-assert BOM, controller backup, verify-live Ceph)
   close first -- still owed per the ledger.
3. Durability: commit + push the pass folder; repo-lint first (24 worker-authored docs risk non-ASCII);
   update CURRENT-STATE's "CONTAINER-ELIM PASS SCOPED ... NOT YET RUN" line to point at FINAL-PLAN.md +
   operator-report.md IN THE SAME COMMIT (GA-R1 C1). The full session bookend (savegame) stays the operator's call.