FINAL PLAN -- container-layer elimination + layered module workflow (Phase-4 consolidated plan)

Author: the Phase-4 administrator (multi-agent container-elim pass, SCOPE-AND-EXECUTION-PLAN.md Section 4; no model name asserted, operator instruction). Date: 2026-08-09. Inputs read in full this session: SCOPE-AND-EXECUTION-PLAN.md; the four prior administrator reports (pass0-admin-report.md .. pass3-admin-report.md); the four Phase-4 worker docs (pass4-w1-master-change-inventory.md, pass4-w2-module-workflow-design.md, pass4-w3-execution-sequencing.md, pass4-w4-decision-framing.md). READ-ONLY planning synthesis -- no mutation performed; every owed artifact below is LOGGED, not built (hard rule 1). All recommendations are graded "recommend," never "ruled" (GA-R5). This document is the input to the final advisor review (FINAL-advisor-review.md) and the operator report.

1. The confirmed target + as-is -> to-be

Target (operator-confirmed at the Phase-0 gate, 2026-08-09 -- a DIRECTIONAL PLANNING CONFIRMATION, not yet the GA-R5 [ARCH] ruling; that ruling is Section 5's package):

• Option 1: flat node VMs on vcloud libvirt + one small non-hypervisor vr1-dcN-client VM per DC (metal-admin + transit legs) carrying the D-138 client role and that DC's credential residencies.
• Cross-DC adjacency handling (a): accept co-residency + a NEW vcloud-level host isolation control (SEC-010's nftables pattern one layer up) with a mechanical --check gate and its own SEC row.
• MAAS region stays on vr1-dcN-maas-01 (.6, D-132 addendum -- no change).

As-is (Model B, D-122/D-123): vcloud (outer libvirt) -> vvr1-dcN (containment VM = inner libvirt) -> node VMs. Two tofu roots per DC + a bash bootstrap gate between them; a qemu+ssh provider dial from voffice1 into the containment VM (D-126 keys, D-128 Plane 2); D-125 bridge-in WAN plumbing (modules/wan-bridge, IP-less uplink NIC, br-vr1-dcN-wan); SEC-010 FORWARD-drop on the containment VM's transit leg; nesting depth 4.

To-be (Option 1, flat 10.13): vcloud (libvirt) -> node VMs directly -- depth 2 (VR0-proven). Per DC: six planes + DC edge + 12 node VMs (9 D-121 role + juju-01/.5 + maas-01/.6 + tailscale-01/.7) + the new vr1-dcN-client VM (recommended .8, ~4 vCPU / 8192 MiB / 80 GiB, non-hypervisor), all siblings in ONE flat apply per DC. Eliminated outright: the containment VMs + inner libvirtd, the two inner roots AS roots, the bootstrap gate's --host-nodes duty (~134 lines), the qemu+ssh dial + D-126 per-env keys (no successor), modules/wan-bridge + netplan bridge (edge WAN attaches directly to the per-DC site-wan NAT). Preserved unchanged: the mesh triangle + netem link, plane CIDRs/families/MTU (D-139/D-143 own the values -- the removal changes NO byte budget), Office1/voffice1 wholesale (D-114 -- a DIFFERENT, KEPT containment pattern), Stages 6-7.

What the flattening costs, carried honestly: D-122's one-command site-down (virsh destroy vvr1-dcN) is lost -- re-earned via the root-scoped teardown primitive (owed #1) + emergency lever (#6). Three NEW isolation exposures are created and each gets its own control (Section 5 / the three concerns): (i) cross-DC plane-bridge co-residency on vcloud's one kernel, (ii) the SEC-010 transit-drop successor on the new endpoints, (iii) the MAAS power-key blast radius (each DC's region key would open virsh control over EVERY vcloud domain -- SEC-012/SEC-016's per-DC separation becomes vacuous without the

#11 mitigation).

Both changes ride one redeploy, two attributable axes: [D-143] (10.12->10.13 value substitution, ruled) vs [CE] (container-elim shape change, ruled by Section 5's package); four confirmed dual-cause items carry [both] (G17; D-124 transit bearer; R7 revocation; the juju execution-host/overlay step), per pass1 check 5.

2. The master change-set (W4.1 -- 104 rows; summarized here, full table in pass4-w1-master-change-inventory.md)

The three critical-path chains (W4.1 Section 2, verbatim import -- the sequence in Section 4 must and does honor all three):

• Chain A (power-key, owed #11 -- the single largest blocker): DEC-15 mechanism choice -> SEC row -> SC-11 artifact -> HN-C4 harness (itself a PRECONDITION, not just coverage) -> lib-hosts re-derivation + maas-region-power-key shape -> call-site literals -> A4/A5 harness edits (TOGETHER, same session -- hazard H1) -> A9/A11b -> P5 row. Six test/tool edits are frozen until DEC-15 rules; the interim RED on A4/A5 is the desired fail-loud state, never something to "fix" early.
• Chain B (the (a)-control invariant, owed #2): DEC-14 -> SEC row -> SC-10 -> HN-C2 -> Stage-1 gate installed + --check-verified -> MUST PRECEDE the first flat apply of EITHER per-DC root (fork-robust under any DEC-11 outcome) -> A11a re-verify at each apply's close -> re-verified at Stage-5 live traffic.
• Chain C (R7 + MAAS-release before destroy): SC-12 R7 revocation checklist + SC-13 MAAS record-release/rack-decommission run BEFORE any substrate destroy (revoking after the hosts are gone degrades to "assume it's moot"); then inner-root destroys, then outer. Governs the CURRENT 10.12 teardown; largely independent of DEC-11.
• Cross-cutting: the DEC-11 root-topology fork gates the largest single cluster of "ready once ratified" rows -- ratify it EARLY (with the decision package, Section 7).

3. The layered module-workflow design (W4.2 -- full design in pass4-w2-module-workflow-design.md)

The backbone (adopted from pass1 W1.4, populated by pass2/pass3):

L0  Host & inter-site substrate      (IaC)        -- Stage 1   [mesh triangle, pools, office1-net, base image]
L1  Site/edge nodes                  (IaC)        -- Stage 2/3 [voffice1 (D-114, untouched), DC edges, THE CLIENT VM]
L2  DC substrate: planes + node VMs  (IaC)        -- Stage 3   [modules/dc-site composing pool -> planes -> edge -> node-vm x12 -> client VM; ONE flat root/state per DC]
L3  Enlist/commission                (procedure)  -- Stage 4   [MAAS carve/power/tags -- bodies unchanged, values re-derive]
L4  Juju/OpenStack deploy            (procedure)  -- Stage 5-7 [D-140 PINS as procedure for this redeploy]
L5  Verify/gate                      (cross-cutting, re-invoked at every layer boundary)

The load-bearing rule: each layer's input is the layer below's OUTPUT only; the IaC<->procedure boundary is IDENTITY (a MAC, an IP, a hostname), never orchestration (a state-file read, a cross-host provider dial). The container layer was the ONE place this rule was violated (the inner root's qemu+ssh dial into the outer root's own output) -- Option 1 removes the violation structurally: L2 becomes IaC end to end, and the first live dial into anything L2 produced is L3's MAAS commissioning, exactly where the boundary belongs.

Placement of the pass's key objects (W4.2 Section 6): client VM = L1 instance (same cloudinit-vm module type as voffice1/edges), apply-grouped with its DC's flat root; the (a) control = L0-scoped L5 gate (procedure, NOT a tofu module); SEC-010 successor = L1-scoped procedure on both transit endpoints (client VM + voffice1, one role-agnostic installer); power-key mitigation = L3-scoped credential control with an L3/L4-split gate (P4 dependency + A11b standing); teardown primitive = L2/L5 boundary (procedure wrapping a root-scoped tofu destroy, verified by an L5-style completeness check).

Design principles (each grounded in an existing repo pattern): site-token parameterization, never hardcoded DC identity; every module ships its tested harness from the same commit (per-module harness contract, pass3 Section 6); idempotence at every layer; no layer reaches past the one directly below; findings logged at their true layer; D-140 is a distinct future axis (a later -juju root consumes dc-site outputs without reshaping L0-L3).

Roosevelt transfer, judged per layer (the operator's "module deployment project" lens): L0 does NOT transfer (mesh/netem are virtualization shims); L1's client-VM PATTERN is the direct pre-Roosevelt D-138 bastion deliverable; L2 transfers as CONTRACT ("booted object with correct MAC-per-NIC identity"), not as libvirt mechanism; L3 and L4 transfer verbatim -- they ARE the module deployment project's payload; L5 mostly transfers, EXCEPT the (a) control and the power-key mitigation, both artifacts of vcloud's single-hypervisor co-residency with no bare-metal analog in the same shape (flagged so no future session assumes parity).

4. Execution sequencing (W4.3 -- full step tables in pass4-w3-execution-sequencing.md)

Part A -- teardown of the current 10.12 Model-B checkpoint (today's tooling tears down today's shape; unchanged by the target): A.1 state backups both roots/both hosts -> A.2 MAAS census (two lenses) -> A.3 R7 credential revocation (Chain C -- BEFORE any destroy) -> A.4 MAAS record release/delete + rack-controller decommission -> A.5/A.6 plan destroys (inner first, then outer, -targeted -- mesh/netem EXCLUDED) -> A.7 apply destroys (each individually operator-approved, never batched -- hard rule 3) -> A.8 drift gate -> A.9 NetBox decommission -> A.10 repeat/batch per DC.

Part B -- redeploy on flat 10.13 (Option 1): B.1 prerequisites (B.1.1 FIT/capacity HARD GATE -- extended calculator + fresh vcloud measurement, closes before any apply; B.1.2-B.1.4 NetBox apex re-carve, lib-net 10.13 literals, D-124 transit re-point) -> B.2 vcloud/Office1 prep -> B.3 the (a) control installed + --check-verified (Chain B HARD GATE, before ANY flat apply) -> B.4 the flat apply per DC (dc-site composition; client VM; B.4.3 MAC re-measurement before anything trusts a MAC) -> B.5 surviving duties re-targeted (rack-retirement recommend + owed live re-measure; D-131 retire-with-evidence; artifact-service sizing via B.1.1's numbers; SEC-010 successor both ends) -> B.6 MAAS enlist/commission/carve (B.6.1 power-key mitigation closes, harness green, BEFORE the B.6.2 lib-hosts edit -- Chain A) -> B.7 juju/bundle from the client VM + verify-live (Ceph-v6, geneve assert, the (a) --check RE-RUN under real traffic) -> B.8 close-out (NetBox registration; B.8.2 the [ARCH] decision record -- the redeploy is NOT "done" while it is owed).

Critical-path invariant verification (W4.3 Section 0, re-checked this synthesis -- Appendix A.2): all three chains are honored -- (a)-control B.3 before B.4 (Chain B);

#11/B.6.1 before B.6.2 (Chain A); R7/A.3-A.4 before A.5-A.7 (Chain C); every step carries its axis tag (invariant 4). One harmonization this synthesis adds (advisor-reviewed): W4.3 places the DEC-15 mechanism CHOICE at B.6.1 (its last responsible moment); W4.2's composition needs the ruled key shape at its Stage 3.5.3. Both honor Chain A; the plan's recommendation is that DEC-15 (with DEC-14 and DEC-11/12) be RULED up front with the decision package (Section 7), so no operator ruling is discovered mid-Part-B inside a live teardown window -- B.6.1 then marks where the built artifact + C4 harness must be green, not where the ruling happens. This matches W4.1's own "ratify DEC-11 early" note.

Pre-Roosevelt bare-metal plug-in points: hardware specs (owed "within days") plug into B.1.1 (FIT re-derivation), B.4.1/B.4.2 (sizing + provider target -- same module composition), B.4.3/B.6.4 (real NIC MACs via enlistment -- the re-measurement discipline transfers, the injection mechanism does not), B.5.3 (artifact-service disk). B.1.2/B.1.3, B.6.5, and B.7 are hardware-agnostic; the module INVOCATION ORDER itself (B.1->B.8) is the reusable deliverable. B.5's placement should be RE-DECIDED for bare metal, not carried blindly. The (a) control and #11 mitigation likely do NOT transfer as-is (flagged explicitly).

5. The decision package (W4.4 -- framed for the operator, GA-R5; nothing here is ruled)

5.1 The core recommendation: mint a NEW D-number (next-free D-144, re-grep at mint)

The GA-R3 admission test fires on all three prongs independently (each verified across the passes): (1) architectural consequence beyond the stage -- Stage 3 restructured wholesale, D-128's own definition amended, a D-124 clause re-caused, D-125 terminated, D-131's standing-pattern status reopened, D-132-addendum premise mooted, a D-134 map addition, D-138's concrete host changed; (2) Roosevelt-delta (A1 test) -- operator-stated: the layered module workflow is the pre-Roosevelt deliverable a future build session would grep before touching substrate shape; (3) supersession -- D-123's core Model-B ruling is directly reversed. The precedent is D-143 itself (header verified verbatim this session: "AMENDS D-115 premise; TERMINATES D-101 v4-inherit clause" -- yet minted as its OWN number): a new entry states its verb against each affected decision rather than the affected decision being edited to absorb the reversal. A third D-123 amendment reversing D-123's own central ruling would have the entry amend itself out of existence; append-only discipline is better served by a fresh entry naming D-123 SUPERSEDED. Alternative presented for completeness (not recommended): amend D-123 in place -- one canonical entry, but it fights the D-143 precedent and requires rewriting D-123's body to point at the new shape anyway.

D-144's body would need, at minimum (W4.4 Section 4): (a) the D-123 supersession; (b) the D-125 termination + D-124 sizing re-cause as named consequences; (c) the accepted power-key blast-radius tradeoff named explicitly in the body (flattening knowingly voids SEC-012/016's per-DC scoping, mitigated by the #11 SEC-row control -- burying this only in a SEC row nobody greps before touching architecture would repeat the failure class A1 exists to prevent); (d) pointers to the amendments filed alongside.

5.2 The seven ride-alongs (W4.4 Section 2 -- classifications, all recommendation-grade)

Net: 0 new D-numbers beyond D-144; 3 amendments filed with the package (D-128, D-134, D-131) + 1 deferred amendment (D-127's client-VM autostart row, filed once DEC-22 rules the value -- a reconciled note this synthesis adds: W4.4's "3 amendments" count and its own D-127 ledger row are consistent only when the D-127 amendment is stated as DEFERRED, see Appendix A.5); 2 findings folded into D-144's body (D-125 termination, power-key tradeoff); the rest is SEC/changelog/runbook work.

5.3 The reconciliation ledger (D-144 -> every touched decision; verb vocabulary = D-143's)

(One divergence between this ledger and the Phase-4 tasking prompt's shorthand is logged at Appendix A.6 -- the worker document, grounded in the pass evidence, governs.)

6. OWED artifacts (13) + OWED live measurements

6.1 The 13 owed artifacts (pass2 Section 5 spec; harness dispositions per pass3 -- all LOGGED, none built)

Every net-new artifact ships its tests/<name>/run-tests.sh FROM THE SAME COMMIT (per-module harness contract), with changelog + revert, repo-lint clean.

6.2 OWED live measurements (read-only where pre-build; NONE performed by this pass)

Before the recommendation-grade rulings are ratified: (1) current-day primary_rack/rackd state, BOTH DCs (gates DEC-08/DEC-09 -- the pass2 cites are 2-10 days old, instrument-currency #20/#25); (2) vcloud's LIVE polkit/libvirt access config (input to DEC-15's mechanism design).

Before/at build: (3) fresh vcloud host-capacity measurement + (4) exact FIT for the flat 12+1-VM/DC roster (until then "~176 GiB freed" stays DIRECTIONAL only -- B.1.1 hard gate); (5) post-build geneve/jumbo live assert on the vcloud-level planes (analytically unchanged, live proof owed); (6) MAC re-measurement post-apply (B.4.3); (7) the client VM's transit NIC name (dc0's live was enp1s0, not mgmt -- before any SEC-010-successor rule is written); (8) D-131 dig-evidence per fresh region (owed #13); (9) gap-#20 verdict re-verify post-build (its own expiry clause triggers).

7. >>> OPEN DECISIONS FOR THE OPERATOR <<<

Two tiers. Nothing below is ruled by this pass (GA-R5). The 23 DEC rows of the master inventory partition exactly into these tiers + already-covered ledger rows (Appendix A.3).

Tier 1 -- the [ARCH] decision package (rule together, BEFORE Part B's Stage 3 ever runs)

1. DEC-01 -- THE ruling: adopt the container-elim as new D-144 (recommended) or as a D-123 amendment. This is the single most important decision in the plan: it is the root every ride-along hangs off, W4.2's composition names it a PRECONDITION for the first flat Stage-3 apply, and per SCOPE Section 7 the redeploy is NOT done while it is owed.
2. DEC-02 / DEC-13 / DEC-09 -- the three amendments filed with it: D-128 (Plane-2 shrink), D-134 (.8 client VM), D-131 (retire-with-evidence -- only after owed live measurement (1)). D-127's amendment (DEC-22, autostart value) is deferred until ruled.
3. DEC-15 -- the power-key mitigation mechanism (restricted SSH key / per-DC virsh wrapper / polkit ACL) + its SEC row. The sharpest EXECUTION blocker: six test/tool edits are frozen until it rules (Chain A). Recommended: rule it WITH this package, not mid-sequence (Section 4's harmonization). AMENDED by the advisor review (Section 8, follow-up 1): the mechanism must decide REACH as well as authorization -- how an in-plane vr1-dcN-maas-01 reaches vcloud's own libvirtd at L3 without putting a host address on a plane bridge (which the (a) control forbids). Reach + auth ruled together.
4. DEC-14 / DEC-16 -- the (a) control's concrete nftables mechanism + SEC row; the SEC-010-successor row disposition (new row vs SEC-010 amendment) + endpoint ratification (client VM + voffice1, recommended).
5. DEC-11 / DEC-12 / DEC-23 -- ratify root topology (B) shared-outer + per-DC-flat (recommended; state-isolation only -- it mitigates NONE of the three concerns), root naming (vr1-dcN-flat vs reserving -substrate), and the state-blast-radius weighing that rides it. Unblocks the largest cluster of "ready once ratified" rows.
6. DEC-08 -- rack-controller retirement ratification (recommended; gated on owed live measurement (1)).
7. DEC-24 -- the dc0<->dc1 mesh-leg consumer + cross-DC Ceph replication path (NEW, from the advisor review, Section 8 follow-up 2). Who holds the dc0<->dc1 mesh leg (virbr5, netem target) endpoints post-flatten, and how the flat-topology replication plane routes cross-DC Ceph traffic (D-100/D-108) THROUGH netem without violating the (a) control. Pairs with DEC-14. Partly pre-existing (cross-DC replication never built -- dc1 HELD), so the flat design must DEFINE this path; it is not a regression into a working path. OWED: a design + its gate; not a blocker for the D-144 package.

Tier 2 -- delivery-grade rulings (needed before their specific rows, not before the package)

• DEC-10 artifact-service (.4) placement + sizing -- ruled WITH the #7 FIT numbers.
• DEC-22 D-127 client-VM autostart value (unblocks harness A1's new case + the deferred D-127 amendment).
• DEC-21 NetBox-migration design (rename-in-place vs concept retirement, shapes A6).
• DEC-20 A11's home (fold into cloud-assert.sh vs a dedicated isolation-assert.sh).
• DEC-17 wan-bridge module directory: delete vs leave-unreferenced (append-only bias).
• DEC-18 SEC-013 maas-vm-host retire-or-keep (flagged to its owner, not this pass).
• DEC-19 maas-fabric-prune.sh/maas_fabric_classify.py harness gap: build vs accept-as-named-exception (pre-existing, container-elim-ADJACENT only).
• DEC-03..DEC-07 are covered by the package's reconciliation ledger (they are the named consequence-notes inside/alongside D-144, not separate operator forks).

Also owed from the operator (SCOPE Section 8, unchanged)

Pre-Roosevelt hardware specs ("within a few days" -- plug-in points mapped in Section 4); any external "module deployment project" artifacts (none identified in-repo at any phase).

8. Advisor-review follow-ups (added post-synthesis; full text in FINAL-advisor-review.md)

The advisor reviewed the aggregate and returned verdict SOUND -- Option 1, root (B), and the D-144 framing all stand. It raised TWO follow-up gaps of the same shape (an attachment object is deleted; a survivor glossed "unchanged"), both VERIFIED against the full pass docs this session:

• Follow-up 1 (folded into DEC-15): the MAAS power-dial REACH path (in-plane maas-01 -> vcloud's own libvirtd) is assumed, not designed, and collides with the (a) control's no-host-address-on-a-plane-bridge rule. The DEC-15 mechanism ruling must decide reach + auth together. Sharpens DEC-15; does not block the package.
• Follow-up 2 (new DEC-24): the dc0<->dc1 mesh leg (virbr5, netem target) is the cross-DC Ceph replication carrier (D-100/D-108); the pass reassigned the Office1-transit legs cleanly to the client VM but left the dc0<->dc1 leg's post-flatten consumer + netem routing undefined. Partly pre-existing (dc1 HELD -> never built), so the flat design must DEFINE it. Own open item.

Neither changes the plan's direction; each is now a named open item (Section 7 DEC-15 / DEC-24).

Appendix A -- cross-consistency check results (this synthesis's adversarial pass)

Verdict: CONSISTENT -- zero contradictions across the four Phase-4 dimensions; six reconciled notes, enumerated below. No manufactured contradiction survives into this plan.

A.1 W4.1 rows <-> W4.3 sequence steps. Every Part-A/Part-B step that invokes a change-artifact resolves to a W4.1 inventory row (spot-mapped: A.3=SC-12, A.4=SC-13, A.9/B.8.1=SC-18, B.1.1=SC-16, B.3.1=SC-10/GT-01/SEC-01/HN-C2, B.4.1=TF-12/TF-13, B.4.3=SC-17, B.5.1=DEC-08/SC-05, B.5.2=SC-15/HN-C5, B.5.4=SC-04/GT-03, B.6.1=DEC-15/SC-11/ HN-C4/SEC-02, B.6.2=LB-01, B.6.3=SC-01, B.7.3=SEC-04/GT-06, B.7.5=SC-19/GT-02, B.8.2=DEC-01). Reconciled note 1: W4.3's B.1.2/B.1.3a (NetBox apex re-carve; 10.13 naming-collision DOCFIX) are NOT W4.1 rows -- correctly so: they are D-143's OWN owed-execution items (D-143 axis), and W4.1's LB-03 explicitly quarantines that axis. By-design separation, not a gap.

A.2 The three critical-path chains vs the sequence. All honored: Chain B at B.3-before- B.4 (fork-robust "before ANY flat apply", not merely "before the second DC's"); Chain A at B.6.1-before-B.6.2 (with A4/A5 edited together, same session); Chain C at A.3/A.4-before-A.5-A.7. Reconciled note 2 (elevated into Section 4): W4.2's Stage 3.5.3 needs the #11-ruled key shape earlier in its composition than W4.3's B.6.1 choice-point -- no invariant is violated (both keep the ruling before B.6.2/any literal), but the plan recommends DEC-15 be ruled with the up-front package so the choice never lands mid-window.

A.3 W4.4's decision list <-> W4.1's 23 DEC rows. Not identical, and correctly so: W4.4 frames the [ARCH]-relevant subset -- DEC-01 (core), DEC-02..09/13 (ride-alongs + ledger rows), DEC-10..12, DEC-14..16, DEC-22 (via the D-127 ledger row), DEC-23 (rides DEC-11) = 18 of 23. The remaining five (DEC-17, 18, 19, 20, 21) are OPS/delivery-grade decisions with clean provenance in pass2 Section 6 / pass3 Section 7 open lists -- no invented rows, no dropped [ARCH] item. Reconciled note 3: the FINAL-PLAN unions them as Tier 2 (Section 7) so the operator sees all 23.

A.4 W4.2's modules <-> W4.1's 13 TF rows. Full coverage both directions: every W4.2 layer-table IaC artifact maps to a TF row or a confirmed-unchanged note (mesh-link x3, netem-link, office1-network -- deliberately not itemized; maas-vm-host dead/orthogonal -> DEC-18); every TF row appears in W4.2's design. Reconciled note 4 (cosmetic): W4.1's TF IDs skip TF-11 (TF-01..10, 12, 13, 14) -- the count of 13 rows is CORRECT; the gap is a numbering artifact only. Flagged so no future reader "finds" a missing row.

A.5 The D-144 package's internal soundness. GA-R3 three-prong argument checked against the pass evidence -- each prong independently grounded (Section 5.1); the D-143 precedent verified VERBATIM against docs/design-decisions.md:8083 this session; next-free D-144 re-verified this session by direct grep (highest = D-143), next-free SEC-034 re-verified (highest = SEC-033) -- both re-grepped again at mint time per numbering discipline. Reconciled note 5: W4.4's summary line "3 existing-decision amendments (D-128, D-134, D-131) filed separately" is consistent with its own D-127 AMENDS ledger row only when the D-127 amendment is stated as DEFERRED on DEC-22's value ruling -- Section 5.2 states it that way ("3 filed + 1 deferred").

A.6 The reconciliation ledger vs decision statuses. No contradiction found between W4.4's ledger and any decision's verified status (D-128/D-138/D-131/D-134/D-123 texts were direct-read by prior admins at cited lines; D-122/D-123/D-125/D-131/D-140/D-143 headers re-confirmed present this session). Reconciled note 6: the Phase-4 tasking prompt's shorthand ("D-122 ... preserved"; D-127 omitted) DIVERGES from W4.4's evidence-grounded ledger (D-122 = AMENDS -- the site-down literal regresses; D-127 = AMENDS-deferred). The worker document governs; this plan carries W4.4's verbs. Named explicitly so a later reader cannot manufacture a contradiction from the prompt text.

A.7 Count arithmetic (lesson #25: show the addition, don't assert it). 23 (DEC) + 13 (TF) + 3 (LB) + 19 (SC) + 6 (DC) + 5 (RB) + 10 (GT) + 21 (HN) + 4 (SEC) = 104. Harness decomposition 9 + 5 + 7 = 21 matches pass3 exactly; 13 distinct owed-artifact tags all appear; the three no-double-count folds (rack decommission -> #5; artifact-service sizing -> #7; SEC-010-writer extraction = #3's shape) carried intact.

A.8 Two-axis separation, end to end. Every W4.1 row and every W4.3 step carries [CE]/[D-143]/[both]; lib-net is quarantined to D-143 (grep-verified at pass2); the four dual-cause items are dual-labeled, never folded. HOLDS.

A.9 Read-only / logged-not-built. All eight input documents state READ-ONLY with no mutation; this synthesis performed only reads + greps of repo files and writes only this planning document. All 13 owed artifacts remain LOGGED, none built; all mutations in Section 4 are PLANNED steps for later gated execution (hard rules 1/3 respected).

A.10 Remaining inferred/uncited-claim sweep. None found beyond items already marked OWED by their sources. Recommendation-grade items still needing a live re-measure before ratification: rack retirement (DEC-08/09) and FIT/capacity (Section 6.2 items 1-4). Standing doc-currency nits carried, not fixed here: CLAUDE.md "98 harnesses" vs 103; the workflow doc's stale "~416 GiB"; maas-node-power cosmetic URI fixture.

Verification note

Author = "the administrator" (no model name asserted, operator instruction). Direct measurements THIS session: grep -nE '^## D-1(22|23|25|31|40|43)' + grep -oE 'D-1[0-9]{2}' | sort -u | tail on docs/design-decisions.md (D-143 header verbatim incl. the AMENDS/TERMINATES precedent; highest D = D-143 -> next-free D-144) and grep -oE 'SEC-0[0-9]{2}' on docs/security-ledger.md (highest = SEC-033 -> next-free SEC-034). Everything else rests on the four Phase-4 worker docs and the four prior administrator reports, read IN FULL this session, whose own verification notes record the underlying direct reads/greps -- their citations were relied upon as verified there, not re-derived wholesale here; no claim was upgraded beyond its source's stated grade. READ-ONLY; findings LOGGED only; nothing executed against the cloud.