Container-elim pass -- draft agent prompts (ready to adapt & spawn)

Spawn workers with the Agent tool, model: "sonnet"; administrators with model: "fable". Run each phase's workers in ONE message (parallel). When all return, spawn the administrator. Adapt paths/line-refs against live repo HEAD at run time. Every prompt inherits the COMMON PREAMBLE below.

COMMON PREAMBLE (prepend to every worker prompt)

You are a READ-ONLY planning agent for the container-layer-elimination pass. Repo: /home/jessea123/openstack-caracal-dc-dc. Read docs/audit/container-elim-pass/SCOPE-AND- EXECUTION-PLAN.md first for full context (Model-B container layer; the 10.13 redeploy; "eliminate the container layer + pull layers up one"; the LAYERED module goal = IaC modules + procedure modules). RULES: (1) READ-ONLY -- no mutation, no teardown, no raw substrate commands; findings are logged, not executed. (2) Consult docs/tool-index.md before citing any operation. (3) Never assert an inferred value -- cite path:line or measured output; if you can't verify, say so. (4) WRITE your full findings to the durable file named below; RETURN to me only a BOUNDED SUMMARY (<= 15 lines: key findings + the durable-doc path + top risks). Do not dump full findings into your reply.

COMMON ADMINISTRATOR PREAMBLE (prepend to every administrator prompt)

You are the FABLE ADMINISTRATOR for Phase N of the container-elim pass. Read docs/audit/container-elim-pass/SCOPE-AND-EXECUTION-PLAN.md and the phase's worker docs (passN-w*.md) in full. Your job: SYNTHESIZE the workers' findings into one coherent phase report -- reconcile contradictions, flag gaps/unverified claims, and produce the phase's change-set. Adversarially check the workers (a plausible finding is not a verified one). WRITE passN-admin-report.md; RETURN a bounded summary (<= 20 lines) + the top decisions/risks the orchestrator must weigh before the next phase.

PHASE 0 -- Baseline & target topology (workers write pass0-w*.md)

• W0.1 substrate/tofu map (pass0-w1-substrate-map.md): Map exactly how the container layer is built -- opentofu/main.tf + modules/ + variables.tf (outer root creating vvr1-dcN), and the INNER root that creates node VMs via qemu+ssh inside it. Document disk/pool/cloud-init/ seed-volume dependencies and the outer<->inner apply ordering. Deliver an as-is substrate diagram (text) + every file/module involved.
• W0.2 network/wiring map (pass0-w2-network-map.md): Map the 6 inner plane bridges, the transit leg, br-ex, the MTU/jumbo/geneve-over-v6 budget, SEC-010 forwarding, and the D-124/125/126 paths that ride the containment layer. Identify precisely what "simplify the wiring" touches if the containment VM is removed.
• W0.3 consumer/dependency inventory (pass0-w3-consumers.md): Enumerate EVERY consumer keyed to the container layer -- lib-hosts.sh (VIRSH_POWER_ADDRESS, NIC maps, CARVE_AUX_HOSTS), lib-net.sh, maas-node-power.sh (qemu+ssh power addresses), site-headend-install.sh, dc-rack-net.sh, carve scripts, and the D-128/D-138 execution-host assumptions. For each: what breaks / changes when nodes run directly on vcloud libvirt.
• W0.4 target-topology options (pass0-w4-targets.md): Propose 1-2 concrete "layers-up-one" targets (node VMs on vcloud libvirt directly; where the 6 planes + transit land; the capacity/FIT impact; what breaks; what simplifies). Give tradeoffs + a recommendation. This feeds the operator gate.
• Administrator (pass0-admin-report.md): as-is map + blast-radius inventory + target-topology options with a recommendation. Flag the OPERATOR GATE explicitly.

PHASE 1 -- Planning review (feed in the CONFIRMED target topology)

• W1.1 redeploy/teardown planning: D-143 execution, runbooks/dc-dc-teardown-rollback.md, the dc-dc-phase* runbooks -- what the confirmed target changes.
• W1.2 workflow/gates: docs/dc-dc-deployment-workflow.md + the stage/gate structure vs the layered module framing.
• W1.3 sequencing: teardown->redeploy ordering with no container layer (what steps vanish/ reorder).
• W1.4 module-planning: how the planning artifacts map onto the layered (IaC + procedure) module model.
• Administrator: planning change-set + module-planning implications.

PHASE 2 -- Tools review

• W2.1 tofu roots/modules: what collapses; what becomes reusable IaC modules (D-140-aligned).
• W2.2 lib-hosts/lib-net: containment-keyed values (power addresses, NIC maps, plane CIDRs) for a flat topology + 10.13.
• W2.3 scripts: dc-node-carve, maas-node-power, dc-rack-net, site-headend-install, carve tooling -- what changes.
• W2.4 module decomposition: which tools become procedure-modules; the IaC/procedure layering.
• Administrator: tools change-set + module decomposition.

PHASE 3 -- Tests review

• W3.1 harnesses/gauntlet: which harnesses assume the container layer; what changes.
• W3.2 gates: preflight / cloud-assert / stage gates for a flat topology.
• W3.3 new tests: per-module test-harness requirements (each module ships its tested harness).
• Administrator: tests change-set + per-module test requirements.

PHASE 4 -- Change synthesis & module-workflow design

• W4.1 master change-inventory: consolidate planning+tools+tests into one change-set.
• W4.2 module-workflow design: the layered IaC + procedure module design + how they compose into a repeatable redeploy.
• W4.3 execution sequencing: module invocation order across teardown->redeploy; note where the pre-Roosevelt bare-metal hardware specs plug in.
• W4.4 decision framing: the owed [ARCH] decision (D-123 amendment or new D-number) for the container-elim + module workflow -- options + reconciliation + Roosevelt-delta (operator rules it).
• Administrator (FINAL-PLAN.md): consolidated plan + module design + decision package.
• THEN: orchestrator review -> advisor() (fable) aggregate review (FINAL-advisor-review.md) -> operator-report.md.