diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index f3071f6..951b3df 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -1006,6 +1006,18 @@ would silently produce a cloud whose compute nodes have no provider egress. It is also a per-DC value that is NOT a NetBox assignment, so it must move into the per-DC overlays for the ruled symmetric shape to be truthful. Logged, NOT fixed (hard rule 1). + **HOME FOR THE DEFERRED NOC POSTURE RULED 2026-07-27 (GA-R5). Question as presented:** does it + get its own D-number, or fold into D-100 -- noting GA-R3's A1 amendment ("Mentioning + Roosevelt, or recording a Roosevelt-era preference, does not qualify; changing what gets built + or how it transfers does") appears to EXCLUDE it from the D-series, and that the session + ledger is the wrong home because GA-R4 caps it at 300 lines and rotates oldest-first (four + times this month). **Operator answer, exact utterance: "use the workflow doc as a named + forward item".** EXECUTED in the same commit: `docs/dc-dc-deployment-workflow.md` gains a + "Forward items -- DEFERRED BY RULING to the next deployment" section carrying **F1** (the + four-step Office1 -> DC0-as-NOC -> remote-push-to-DC1 test), why it is deferred, what already + supports it (D-100's management-only fiber, D-128's Plane-2-on-voffice1 model), and what would + make it D-admissible later (a named executable check that the push came from Office1 against a + DC0 NOC, plus a ruled DC0-first ordering). **No D-number assigned; next-free stays 138.** - Position inside Stage 3: deploy step A EXECUTED 2026-07-19 (6/0/6 exact; convergence zero -- `docs/audit/outer-plan-20260719-postA-converged.txt`). **Deploy step B diff --git a/docs/dc-dc-deployment-workflow.md b/docs/dc-dc-deployment-workflow.md index a7b4a18..827384b 100644 --- a/docs/dc-dc-deployment-workflow.md +++ b/docs/dc-dc-deployment-workflow.md @@ -260,6 +260,58 @@ --- +## Forward items -- DEFERRED BY RULING to the next deployment + +Named forward items live HERE, not as D-numbers. GA-R3 rule 1(b) as amended by A1 is +explicit: "Mentioning Roosevelt, or recording a Roosevelt-era preference, does not +qualify; changing what gets built or how it transfers does." An item below is a +preference for a FUTURE build with no present-tense half, so it is deliberately not in +the D-series. If a later deployment turns one into something that changes what gets +built -- a gate, a bootstrap order, a topology -- it earns a D-number on its own merits +AT THAT TIME. Status tokens do not appear here (GA-R1); this section records intent. + +### F1. Regional NOC posture: Office1 -> DC0-as-NOC -> remote push to DC1 + +**The test this deployment was originally conceived to run**, described by the operator +2026-07-27 and found to exist in NO repo surface (`grep -rniE '\bNOC\b'` over `docs/`, +`runbooks/`, `scripts/`, `bundle.yaml` returned zero hits outside `docs/archive/`): + +1. Office1 stands up first, simulating a real regional office. +2. Dark-fiber connectivity to DC0; the DC0 infrastructure is deployed REMOTELY (it may + be built from vcloud where needed, since in the real world that hardware would have + been racked and set up at DC0 already). +3. Once DC0 is online with a FULL set of OpenStack servers/services bootstrapped, **DC0 + is considered the NOC**. +4. The test proper: simulate a technician at their desk in Office1 connecting to the + NOC and pushing a deployment to DC1. + +**Why it is deferred.** The deployment steps for it were never in this roadmap, and by +the time that was found this deployment had progressed too far to re-sequence. Operator +ruling 2026-07-27 (GA-R5; utterance quoted in `docs/CURRENT-STATE.md`): step away from +the DC0-then-DC1 roadmap for THIS deployment, take the posture on the NEXT one after +this push, configuration and hardening complete. Both DCs deploy from voffice1 by the +same procedure instead, with per-DC overlays. + +**What already supports it, so the next deployment does not start cold.** D-100 rules +the dark-fiber triangle and records that the Office1<->DC fiber carries management +traffic only (MAAS/Juju/operator) -- the exact path step 4 exercises. D-128 already +puts Plane-2 execution (MAAS / NetBox / inner tofu / tenant tests) ON voffice1, so +"a technician at Office1 pushes a deployment" is the operating model this deployment is +ALREADY using; what is missing is the DC0-first ORDER and a gate that proves the push +happened from there rather than from the jumphost. + +**What it would need to become build-changing** (and therefore D-admissible): a named +executable check that the DC1 deployment was driven from Office1 against a DC0 NOC, and +a ruled ordering that makes DC0's full bootstrap a precondition of DC1's start. + +RULING (GA-R5, 2026-07-27). Question as presented: does the deferred NOC posture get its +own D-number, or fold into D-100 as a sub-item -- noting GA-R3's A1 amendment appears to +exclude a Roosevelt-era preference from the D-series, and that the session ledger is the +wrong home because GA-R4 caps and rotates it. Operator answer, exact utterance: **"use +the workflow doc as a named forward item"**. + +--- + ## Cross-cutting discipline (applies at every stage, every session) - **Session bootstrap, every session:** `git pull` -> `bash scripts/repo-lint.sh`