# Session changelog 2026-07-31 (part 2) -- snap proxy apply + IPv6 scoping

GA-R2: ONE changelog per session. This is a SEPARATE session from
`docs/changelog-20260731-prefer-ipv6-research.md` (same date, different session);
that file is closed and is not appended to here.

Branch `dc-dc-stage5-preconditions`. Status claims live ONLY in
`docs/CURRENT-STATE.md`; nothing here is a status claim.

---

## Item 1 -- FINDING: the `dc-snap-proxy.sh` review's SIMPLIFICATION PLAN was never
## landed on any surface and is LOST

**What.** No artifact change. A finding, recorded because the next action in the
prior session's close-out cannot be executed as written.

`docs/session-ledger.md:296` gives the next step as "apply the review cuts,
re-run the mutation pass (S8 invalidates it)", and
`docs/audit/queued-findings-20260731-stage5-deploy.txt:145-146` (N2) says "The
dc-snap-proxy simplification plan is NOT applied. Applying it REQUIRES re-running
the mutation pass -- S8 invalidates M32-M39, M42-M47, M49-M52 as evidence."

**MEASURED: the plan those `S`-numbers refer to exists nowhere in the repo.** A
repo-wide grep for `\bS8\b` over `*.md` / `*.txt` / `*.sh` returns exactly two
live hits -- the ledger line and the N2 line above, both of which CITE the plan
without containing it -- plus three unrelated 2026-07-07 archive hits
(`docs/archive/script-quality-findings-20260707.md`, an S1-S8 consolidation
proposal set about `KEYSTONE_VIP` and D-003 FIP bounds, a different subject
entirely). The mutation IDs it invalidates ARE recorded
(`docs/audit/stage5-snap-proxy-measurements-20260731.txt:505,516,523`); the
simplification items themselves are not.

**So N2's wording understates it.** "NOT applied" reads as deferred work that is
waiting somewhere. It is not deferred -- it lived only in the review agent's
transcript and was lost at the session boundary. This is the repo's own
top-tier failure mode (a finding that exists only in a transcript), landing on a
finding ABOUT losing findings.

**DECISION, and the reasoning stated so it can be overturned:** the
simplification is NOT re-derived. It was quality-only work on a tool that is
about to be applied for the first time; re-deriving a lost plan and then re-running
a 53-mutation pass to restore evidence for it is precisely the record-churn the
2026-07-30 standing operator directive shuts down ("Further hardening, auditing,
or record repair is OUT OF SCOPE next session unless it directly blocks the
deploy"), and it is the GA-F06 circuit-breaker case. **Consequence that follows
and is NOT a loss:** because S8 is never applied, its invalidation of
M32-M39/M42-M47/M49-M52 never fires, so the prior session's 53/53 mutation
evidence STANDS unchanged for every assertion this session did not touch.

**Revert.** Nothing to revert (no artifact changed). To reverse the decision,
re-derive the plan from scratch against the current file and re-run the full
mutation pass -- the old S-numbers are not recoverable and must not be cited.

---

## Item 2 -- FIX BUG-4: `dpkg -s squid` gates replaced by a BINARY assertion, at
## BOTH sites (`check` AND `install`)

**What.** `scripts/dc-snap-proxy.sh` (the `check` package gate and `do_install`'s
prereq) + `tests/dc-snap-proxy/run-tests.sh` (the `dpkg` PATH fake removed, a real
binary seam added, T41 re-pointed, T41b and T20b NEW).

**Why.** BUG-4 from the independent review
(`docs/audit/queued-findings-20260731-stage5-deploy.txt:64-66`): `dpkg -s squid`
exits 0 for `Status: deinstall ok config-files`, so a PURGED squid reports as
present. The existence-vs-content class this repo already has a scar from.
`[ -x /usr/sbin/squid ]` is shorter and strictly stronger.

**The review named ONE site; there are TWO.** The same gate sat at `do_check`
AND at `do_install`'s prereq. Fixing only `check` would have left `install`
false-passing its prereq on a purged package and then dying confusingly at
`squid -k parse` or at unit start -- a worse failure than the one being fixed,
because it surfaces further from its cause. Both are fixed.

**Written through the EXISTING test seam, not around it.** The assertion is
`[ -x "${SYSROOT}/usr/sbin/squid" ]`. `SYSROOT` is empty in every production
invocation, so the live path is byte-identical to `/usr/sbin/squid`; the harness
points it at its mktemp tree. This is the script's own documented idiom
(`DC_SNAP_PROXY_SYSROOT`, with in-repo precedent in `maas-region-power-key.sh`,
`creds-audit.sh`, `cloud-snapshot.sh`) and it keeps the assertion drivable in
BOTH directions, which the `dpkg` fake also was -- the fix does not cost a
failure direction.

**Test cases, and why each exists.**
- **T41** (re-pointed): binary absent -> FAIL. The old case drove `dpkg.mode`.
- **T41b** (NEW): the path is present but NOT executable -- the exact `deinstall
  ok config-files` residue shape. **This is the case the OLD assertion could not
  fail on**, i.e. the one that makes the fix mean something. Without it the fix
  would be untested in its own direction.
- **T20b** (NEW): `do_install` is never EXECUTED by this harness (it needs root
  and a real rack), so its half of the fix would otherwise carry NO assertion at
  all. Asserted structurally, following T18's established precedent of scoping a
  grep to a function body: zero `dpkg -s` gates anywhere in the file, AND
  `INSTALL_BODY` carries the `[ ! -x ... ]` form.

**Mutation-proven (this repo's rule: an assertion nobody can turn red is
decoration).** Three mutations, each neutering a PREDICATE, script restored and
sha256-verified byte-identical after each:
- `check`'s binary predicate -> `if true` : **T41 AND T41b both red** (53/2).
- `install`'s prereq -> `if ! dpkg -s squid ...` : **T20b red** (53/1).
- `install`'s prereq -> `if false` : **T20b red** on its second branch (53/1).

**Revert.** `git checkout -- scripts/dc-snap-proxy.sh tests/dc-snap-proxy/run-tests.sh`
(reverts items 2-4 together; they are edits to the same two files).

---

## Item 3 -- FIX BUG-1: the probe ACL was DEAD, and it is now asserted

**What.** `gen_squid_conf`'s `acl snap_probe src 127.0.0.1/32` -> `src ${LISTEN}/32`,
its comment block rewritten to describe the real mechanism, + T23b NEW.

**Why.** BUG-1: squid binds `${LISTEN}:${PROXY_PORT}` only, so nothing can ever
arrive on loopback -- the rule matched nothing. The probes were actually admitted
by `snap_clients` (because `LISTEN` lies inside `CLIENT_CIDR`), and the comment
misdescribed its own mechanism. **The hazard was live, not cosmetic:** anyone
narrowing `CLIENT_CIDR` would break `check`, and the rule they would reach for to
fix it would not have helped.

**Why the stronger fix was taken rather than a comment-only fix.** The obvious
minimal action was to correct the comment and leave the dead rule, on the grounds
that changing generated content pulls fixtures with it. **Measured, it does not:**
the harness renders its fixtures by calling the script's OWN generators
(`render gen_squid_conf`, `run-tests.sh:312-318`), never by copying config text
into the test file, so generated-content changes cost nothing in fixture
maintenance. That removed the only argument for the weaker fix.

**Safe in both directions by construction** -- stated because the source-selection
step is REASONED, not yet measured on the rack (hard rule 2). A host connecting to
one of its own local addresses is expected to select that address as the source,
so `${LISTEN}/32` is the expected match; if that is wrong, the probe still falls
through to `snap_clients`, because `LISTEN` is inside `CLIENT_CIDR`. So the change
cannot regress `check`, and the first live run's access log will say which rule
actually admitted the probe.

**T23b (NEW)** asserts the RENDERED artifact -- the probe ACL is the LISTEN
address and is NOT a loopback rule -- never the comment that describes it.
BUG-1's real defect was that a comment and its code disagreed, so an assertion on
prose would repeat the defect.

**Mutation-proven.** Reverting the ACL to `127.0.0.1/32` turns **T23b red** (54/1);
script restored sha256-identical.

---

## Item 4 -- BUG-3 DOCUMENTED IN THE SCRIPT, deliberately NOT "fixed"

**What.** A new block in `scripts/dc-snap-proxy.sh`'s header, under the existing
"READ THIS BEFORE TRIAGING A REFUSE" section. No behavior change.

**Why not fixed.** BUG-3 is that the DENY probe's expected string
`CONNECT tunnel failed, response 403` was MEASURED from a **port** deny
(`deny CONNECT !SSL_ports`), never from the **dstdomain** deny (`deny !snap_store`)
that the probe actually exercises. It cannot be fixed in the repo, because the
correct value is a fact about a live squid that nobody has yet observed --
inventing one would be exactly the fabricated-value failure this repo calls the
cardinal sin. Guessing a second plausible string would be worse than the bug.

**Why it is not merely cosmetic.** If squid answers a dstdomain denial
differently, that branch falls to `refuse` -> exit 3, and `check` can then NEVER
PASS. Under GA-R6 a gate that cannot PASS blocks a stage close exactly as hard as
one that cannot fail, so this is a real gate defect and not a probe nicety.

**The protocol is now IN THE FILE** rather than in a queued-findings entry the
next reader will not open: a REFUSE on the deny probe at first run is the
EXPECTED, HANDLED path; read the actual output; re-point the assertion to the
MEASURED shape; keep the three-outcome structure so an unrecognised result still
REFUSES; prove the new assertion can fail. This is also the answer to the
close-out's "confirm BUG-3's deny shape once" -- it is a byproduct of the first
real `check`, not separate work.

**BUG-2 NOT FIXED, unchanged from N4.** `| grep -q` under `set -o pipefail` is
INHERITED and present identically in `dc-mirror.sh:278,281` and
`dc-cache-proxy.sh:234,252,255`. A three-script sweep is out of scope under hard
rule 1 and under the standing directive. Its direction is fail-closed (a false
MISS, never a false OK), which is why it can wait.

---

## Item 5 -- OPERATOR APPROVAL RECORDED: the agent's rack permissions

**What.** No artifact change. Recorded because it relaxes the scope of hard rule
3 for one task and must not be inferred later from silence.

**Presented to the operator, verbatim as put:** `.claude/settings.local.json`
carries `Bash(ssh vr1-dc0-rack *)` in **allow** -- an unrestricted wildcard onto
the dc0 rack, auto-added by an approval on 2026-07-30 and flagged in that
session's sweep (F1) as "worth review". Its consequence, stated at the time of
asking: a background agent can mutate the dc0 rack (including
`sudo bash -s -- install dc0`) with NO permission prompt reaching the operator,
so hard rule 3's individual gating does not fire for rack commands. The operator
was offered a narrowing.

**Operator answer, exact utterance: "The agent permissions are approved".**

**CONSEQUENCE, scoped deliberately narrowly.** This authorises the snap-proxy
install agent to operate on the dc0 rack under the existing allow rule. It is
NOT a general standing relaxation of hard rule 3, it does not extend to dc1, and
it does not cover the bundle deploy -- the agent's mandate explicitly stops
before `add-model` / `deploy` / any `juju model-config`. A future session must
not read this as blanket approval for unsupervised cloud mutation.

**Not a GA-R5 ruling and deliberately not recorded as one:** it is a harness
permission decision, OPS under GA-R3 (no architectural consequence beyond this
stage, no Roosevelt delta), so it takes no D-number. The gitignored
`settings.local.json` is unchanged by this session.

**Revert.** Remove `Bash(ssh vr1-dc0-rack *)` from `allow` in
`.claude/settings.local.json` and replace it with a targeted `ask` rule pinned to
the invocation shapes actually needed. Note the 2026-07-30 lesson that applies
directly here: quoting style and the profile token are BOTH part of the match, so
a narrowing rule that pins the wrong quote form silently fails to match and falls
through to the classifier.

---

## Gate results at time of writing

- `bash tests/dc-snap-proxy/run-tests.sh` -- **55 passed, 0 failed** (52 -> 55:
  T20b, T23b, T41b added; T41 re-pointed).
- `bash scripts/run-tests-all.sh` -- **GAUNTLET: ALL GREEN (94 harnesses)**.
  HARNESS-MANIFEST NOT re-recorded and deliberately so: no harness was added or
  removed, only cases within an existing one, so the manifest is unchanged and
  the R15(2) re-record reason does not apply.
- `bash scripts/repo-lint.sh` -- **0 fail, 1 warn** (the expected L1 legacy
  non-ASCII carve-out in `docs/design-decisions.md`).
- Four mutations run across items 2-3; **all four killed**; script restored and
  sha256-verified byte-identical after each.

---

## Item 6 -- THE dc0 SNAP PROXY IS INSTALLED, RUNNING AND GATE-VERIFIED

**What.** No repo artifact changed. A LIVE MUTATION on the dc0 rack, executed by a
delegated agent under the operator approval recorded in item 5. Capture:
`docs/audit/dc0-snap-proxy-install-20260731.txt` (739 lines, ASCII/LF).

**NAMED GATE, GA-R6:** `dc-snap-proxy.sh check dc0` = **PASS, EXIT 0, 16 assertions**.
**RE-RUN INDEPENDENTLY** from the main session after the agent reported, rather than
taken on its word: squid 6.14 bound to `10.12.8.4:3129` SPECIFICALLY (not wildcard),
both units active AND enabled, packaged `squid.service` neither active nor enabled,
all five owned artifacts matching their generators BY CONTENT, and all three
behavioral probes green (store API with `channel-map` + `sha3-384`, CDN tunnel
allowed, non-allowlisted destination DENIED).

**The before-state was captured and it FAILED (exit 1) on a real rack** -- so the
gate is proven able to fail somewhere other than a fixture. It was NOT uniformly
failed: three OK lines (virsh-resolved bridge, rack route table) prove the
instrument was on the RIGHT HOST. That distinction is the recorded wrong-host trap
for these per-DC scripts, where a jumphost run reports every item MISS.

**MAAS's squid was untouched throughout** -- same pid (1871633) before and after,
still holding `*:3128` / `*:8000`. Net-layer idempotence with
`dc0-mirror-net.service` verified: virbr2 addresses and the default route are
byte-identical before and after, which is the D-135 coexistence property this
script was built to honour.

**A REAL SNAP PAYLOAD WAS FETCHED THROUGH THE PROXY** -- HTTP 206, and the first
bytes are `hsqs`, the squashfs magic of the genuine `core` snap. 4 bytes of ~110 MB
read and discarded; nothing installed. **This is what moves the tool from
FIXTURE-green to end-to-end proven**, and it is the specific claim the prior
session was careful to say it could not make.

**STILL NOT PROVEN, stated because the deploy depends on it:** no charm LXD
container was tested. All nine dc0 nodes are shut off (measured via virsh), so the
"containers source from metal-admin" premise underpinning `CLIENT_CIDR` was NOT
re-proven and is carried forward from the prior session's measurement. snapd's own
consumption is unproven and out of scope (the juju keys are unset, so `node`'s
`/etc/environment` assertion FAILS as expected). dc1 untouched.

**Revert.** `ssh vr1-dc0-rack 'sudo systemctl disable --now dc0-snap-proxy.service
dc0-snap-proxy-net.service'`, then remove the five generated artifacts named in the
script header. The packaged `squid` remains installed and disabled; MAAS's squid is
unaffected either way.

---

## Item 7 -- BUG-3 RESOLVED BY MEASUREMENT: the deny shape is CONFIRMED, no
## assertion changed

**What.** No change. The confirmation BUG-3 was waiting for.

The dstdomain deny (`deny !snap_store`) produces a shape BYTE-IDENTICAL to the port
deny the assertion was originally written from: **curl exit 56,
`CONNECT tunnel failed, response 403`, http_code 000**, with squid logging
`TCP_DENIED/403 ... HIER_NONE`. Measured by hand with stderr both merged and
unmerged, not inferred from `check`'s own say-line -- which matters, because
reading the gate's verdict to confirm the gate's assumption is circular.

**MECHANISM, so this is not re-opened later:** curl reports the CONNECT
**response status**, and squid renders 403 for ANY `http_access deny` regardless of
which ACL fired. The two shapes coincide by construction, not by luck.

**CONSEQUENCE:** BUG-3's protocol steps (b) and (c) were correctly NOT performed,
and `scripts/dc-snap-proxy.sh` + its harness are sha256-identical to their
pre-install state. The header block added in item 4 stays as the record of why the
question existed and how it was settled. `check dc0` can now be cited as a gate.

---

## Item 8 -- MY BUG-1 FIX WAS WRONG, AND THE MEASUREMENT REFUTES IT (FINDING 9a)

**What.** `tests/dc-snap-proxy/run-tests.sh` T23b gains a prominent in-file
annotation. `scripts/dc-snap-proxy.sh` deliberately NOT changed.

**Item 3 changed `acl snap_probe src 127.0.0.1/32` to `src ${LISTEN}/32` and stated
the source-selection step as REASONED, NOT MEASURED. The measurement says it is
wrong.** Measured on the dc0 rack, and re-run independently from the main session:

    $ ip route get 10.12.8.4
    local 10.12.8.4 dev lo src 10.12.8.2

`.4` is a **SECONDARY** on virbr2 (primary `.2`), and **Linux does not auto-select a
secondary address as a source**. Squid's own access log attributes every rack-side
probe to `10.12.8.2`. So the rule is STILL DEAD -- BUG-1's fix corrected the
mechanism DESCRIPTION and landed on the WRONG ADDRESS.

**Nothing is broken.** The probes are admitted by `snap_clients` exactly as before,
and `check dc0` passes. What remains unconnected is the rule's stated PURPOSE: that
narrowing `snap_clients` must not silently break `check`.

**NOT FIXED NOW, and the reason is not laziness.** `check` diffs the generated
config against the rack's LIVE file, so any edit to `gen_squid_conf` turns the live
dc0 gate RED until `install` is re-run. That makes it a LIVE MUTATION on a
just-verified surface, out of scope under hard rule 1 and against the standing
directive. The correct value is the rack's primary metal-admin leg (dc0
`10.12.8.2`; dc1's `10.12.68.2` is already recorded MEASURED in `lib-hosts.sh`),
and it wants a site-keyed row. **Fix the script and T23b TOGETHER at the next
install -- dc1 is the natural point, so both DCs land in one pass.**

**T23b is annotated rather than deleted or re-pointed**, per the standing rule that
a test asserting a finding must be REPLACED with the new invariant and never
deleted to go green. Editing its expected string to `10.12.8.2` today would turn
the harness red against the live config; leaving it unannotated would let a future
session "fix" the test to match a value that is itself wrong. The annotation states
the measurement, the correct value, and why the change is deferred.

**GENERALISABLE, and it is the reusable half:** a secondary IPv4 alias is never the
kernel's chosen source address. Any ACL, firewall rule or allowlist keyed to a
service's ALIAS address -- which is exactly what the D-134 utility `.4` band is on
both racks -- will not match that host's own outbound traffic. This applies equally
to `dc-mirror.sh` and `dc-cache-proxy.sh`, which share the `.4` alias pattern.

**Revert.** `git checkout -- tests/dc-snap-proxy/run-tests.sh`.

---

## Item 9 -- FOUR FURTHER FINDINGS FROM THE INSTALL, logged not fixed

1. **The script header's CDN aside is WRONG (finding 8a).** It records that `core`'s
   download URL "came back on api.snapcraft.io, not a CDN host -- so the CDN entry
   may be unused." That measured only the FIRST HOP: the URL **302-redirects to
   `canonical-bos01.cdn.snapcraftcontent.com`**. The `.snapcraftcontent.com` entry
   is **LOAD-BEARING, not speculative**, and the same run proves squid's dot-prefix
   wildcard admits a subdomain appearing in NO probe and NO config line. DOCFIX
   material against the header.
2. **`apt-get install squid` leaves a FAILED but still ENABLED unit (9c)** that
   would fight for 3128 at the next boot -- the header's predicted
   `FATAL: Unable to open HTTP Socket ... listening port: 3128` was observed
   VERBATIM. `install` closes it; an operator who installs the package and stops
   there does not.
3. **The packaged unit rests `failed`+`disabled`, not `inactive` (9e).** `check` is
   right to pass, but `systemctl --failed` shows red on a healthy rack, which is
   quiet triage-poisoning. `systemctl reset-failed squid` is the remedy; NOT
   applied (a live mutation outside the mandate).
4. **>>> NO JUJU CLIENT EXISTS ON THE JUMPHOST, AND THE dc0 JUJU VM REJECTS THE
   CONFIGURED KEY (9d). <<<** `ssh vr1-dc0-juju` -> `Permission denied (publickey)`.
   Not a permission-harness refusal and NOT retried in an altered shape. **This
   blocks the next phase**, which is `add-model` + spaces + `deploy` under D-138
   (cloud-facing clients run from INSIDE the DC). Owed before that phase starts.

---

## Item 10 -- D-139 RULING B's DECIDING REASON IS REFUTED. Ruling FLAGGED, not amended.

**What.** `docs/audit/gai-conf-rfc6724-verification-20260801.txt` (NEW) +
`docs/CURRENT-STATE.md`. No script, no cloud change, and **no edit to D-139 itself**.

**Why it was checked at all.** D-139 ruling B was recorded WITH its own unverified premise
named in the entry: "UNVERIFIED and owed before the carve is executed: the deployed jammy
image's own `/etc/gai.conf`, which can override the RFC 6724 default table that ruling B's
deciding reason rests on." Closing that owed item is what produced this. **The discipline of
naming an unverified premise at ruling time is the only reason this was caught before the
carve rather than after it.**

**MEASURED, in two steps, neither inferred.**
1. jammy's `libc-bin` **2.35-0ubuntu3** ships `/etc/gai.conf` with **ZERO active lines** --
   every line commented. So the node image applies NO override and glibc's compiled-in table
   governs. (noble/vcloud measured identically.)
2. glibc 2.35's `default_precedence[]`, fetched in full from sourceware at tag `glibc-2.35`
   and read rather than recalled, carries glibc's OWN comment `/* See RFC 3484 for the
   details. */` and is: `::1/128 -> 50`, `2002::/16 -> 30`, `::/96 -> 20`,
   `::ffff:0:0/96 -> 10`, `::/0 -> 40`. **There is NO `fc00::/7` entry.**

**THE INVERSION.** ULA has no precedence entry, so it falls through to `::/0` = **40** --
identical to GUA. IPv4-mapped is **10**. So on the node image **ULA = GUA = 40, both
outranking IPv4 = 10**. Ruling B was declared on "ULA loses to IPv4 (3 vs 35), GUA wins (40
vs 35)" -- the **RFC 6724** table. RFC 6724 obsoletes RFC 3484 and does define those values;
**glibc 2.35 does not implement it.** The claim is correct about the RFC and wrong about the
software this cloud runs.

**The `fc00::/7` entry that DOES exist is in `default_labels[]` (label 6)**, beside
`fec0::/10` (5) and `2001::/32` (7), under glibc's comment "The next two entries differ from
RFC 3484". Labels drive SOURCE-selection rules 5/6 -- a different mechanism from destination
precedence, and not what the ruling cited. Recorded so the two are not later conflated into
"glibc does handle ULA specially, so the argument stands".

**This is the citation class again, third instance.** A citation is an EXISTENCE claim; only
its CONTENT is evidence -- and here the citation (RFC 6724) was real, current and correctly
quoted, yet still wrong for this deployment because **nobody had checked whether the
implementation follows the RFC**. That is a NEW variant worth naming: it is not enough to
open the source and check its status and dates; for a standards citation you must also check
that the software actually implements it.

**WHAT SURVIVES, and why the ruling is not simply withdrawn.** Three of ruling B's four
reasons are untouched: conformance with Willamette (a REAL site) and VR0 DC0, both full GUA;
MINIMIZE DELTA TO ROOSEVELT, whose `2602:f3e2:103::/48` is GUA with no ULA and no plane carve
yet; and isolation being unaffected either way because containment lives at the FORWARDING
layer. Those are the governing-constraint arguments and are independent of the refuted one.

**FLAGGED, NOT AMENDED, and this is deliberate.** GA-R5 makes a ruling the operator's. They
answered a question whose stated DECIDING reason no longer holds, so the honest action is to
put the refutation back to them -- not to silently keep the ruling because I still like the
answer, and not to silently reverse it. D-139's text is UNCHANGED; CURRENT-STATE carries the
refutation and the flag. **Nothing of D-139 is executed, so nothing is half-built in either
direction and the reconsideration costs nothing but the exchange.**

**Revert.** `git rm docs/audit/gai-conf-rfc6724-verification-20260801.txt` and drop the
CURRENT-STATE paragraph. Note that reverting does not un-refute the measurement.

---

## Item 11 -- D-139 ruling B RECONSIDERED and CONFIRMED; the refuted rationale is STRUCK

**What.** `docs/design-decisions.md` -- D-139's deciding-reason paragraph replaced by a STRUCK
block, plus a new `### RULING NOTE 2026-08-01 -- D-139:` at the end of the entry +
`docs/CURRENT-STATE.md` (flag cleared). No script, no cloud change.

**Question as presented.** The RFC 6724 precedence argument given as ruling B's DECIDING
reason is refuted for this deployment (item 10); on jammy's glibc 2.35, ULA and GUA are
behaviourally EQUAL. Three reasons survive independently. Does ruling B stand on those alone?
Nothing of D-139 is executed, so reversal costs only the exchange.

**Operator answer, exact utterance: "Deciding to hold to gua does not cost anything
operationally and the case for ULA over gua is not very strong. Let's stay with gua".**

**RULED: ruling B STANDS, unchanged in substance.** The GUA carve table is confirmed, the ULA
`/48` stays RETIRED for VR1, the D-101/D-111 amendments hold, and Phase-2 execution is
UNBLOCKED.

**The refuted argument is STRUCK IN PLACE rather than deleted.** D-139's original text is
quoted inside the strike block, with the measurement that kills it and a pointer to the
capture. Deleting it would have been the easier edit and the wrong one: a future session
would have no way to know the argument had been considered and refuted, and would be free to
re-derive it. The strike block says explicitly **DO NOT CITE IT**, and separately warns
against the near-miss rescue -- glibc 2.35 DOES carry `fc00::/7` in `default_labels[]`
(label 6), which drives SOURCE-selection rules 5/6 and is a DIFFERENT mechanism from
destination precedence. Someone finding that entry could easily conclude the struck argument
survives after all. It does not.

**The rationale of record is now narrower, and that is recorded as a CONSEQUENCE rather than
buried.** Ruling B rests on two project-constraint arguments -- conformance (Willamette and
VR0 DC0 are already full GUA; VR1 was the outlier) and MINIMIZE DELTA TO ROOSEVELT -- plus the
operator's own reasoning that GUA costs nothing operationally. **Made explicit because it was
NOT visible before: on glibc 2.35, GUA buys no address-selection advantage on the two
dual-stack planes; ULA would have won equally at precedence 40.** A later session reasoning
"GUA was chosen so v6 would beat v4" is reasoning from the struck argument.

**NEW STANDING RULE, added to D-139's note because it generalises past this decision.** The
repo's citation rule is "a citation is an EXISTENCE claim; only its CONTENT is evidence" --
open it, check STATUS and DATES. That was FOLLOWED here and was NOT ENOUGH: the citation was
real, current, correctly quoted and correctly understood, and still wrong, because nobody
checked whether the IMPLEMENTATION follows the standard. **For a STANDARDS citation, add a
third check: confirm the deployed software implements it, at the deployed version. An RFC is
not a description of your system.**

**Revert.** `git checkout -- docs/design-decisions.md docs/CURRENT-STATE.md` restores both
the original deciding-reason paragraph and the flag. Reverting does not un-refute the
measurement, and the ruling note quotes an operator utterance -- so a revert would DESTROY a
GA-R5 record and must not be done casually.

---

## Item 12 -- THE "JUJU CLIENT BLOCKER" IS NOT ONE. Correction to item 9's finding 9d.

**What.** `docs/audit/stage5-juju-client-blocker-20260801.txt` (NEW, 391 lines) +
`docs/CURRENT-STATE.md`. No script, no cloud mutation, no key moved.

**Item 9 recorded finding 9d as "BLOCKS the next phase". That was WRONG and is corrected
here.** The juju client exists, is registered and is live -- on the dc0 RACK, which is
exactly where D-138 places it. **Stage 5 can reach `add-model` today.** Verified from the
main session rather than accepted from the agent: juju `3.6.27-genericlinux-amd64` at
`/snap/bin/juju`; controller `vr1-dc0-controller*` admin/superuser on cloud `vr1-maas`; the
`controller` model reading **"Last connection: just now"**; and client credentials listing
**exactly one** entry.

**Root cause of the ssh refusal, measured ON THE MACHINE.** The alias is correct in every
part. `subtle-grouse`'s `authorized_keys` holds exactly two lines, both Juju's -- so the
`office1_svc_ed25519` the alias offers is genuinely absent, and the refusal is right. **The
obvious hypothesis was REFUTED rather than assumed:** the machine booted AFTER the 2026-07-30
region key import and still received only Juju keys, because deploy-time `cloud-config.txt`
carries `Juju:juju-client-key` alone and `juju ssh-keys -m controller` reports none. `juju ssh
-m controller 0` already works, so operator ssh is convenience, not requirement.

**A NEGATIVE FINDING WAS TIED TO IDENTITY BEFORE IT WAS TRUSTED** -- machine 0's two addresses,
hostname and host key were all matched to what `ssh -v` actually reached. This repo's standing
instrument rule is that a confident negative needs proof the instrument was pointed at the
right thing; here it was, and it is recorded.

**SEC-026 control (1) discharged by measurement on BOTH sides:** the rack lists ONE credential
while voffice1 lists two, so the forbidden whole-store copy did not happen. **No new
credential residency and NO new ledger row is owed** -- every location the fix touches is
already in `creds-manifests/vm-secret-locations`.

**Only hygiene is owed:** a dangling `current-model: admin/vr1-dc0` (the model destroyed
2026-07-31) makes bare `juju status` error; `juju switch controller` clears it. Measured NOT
to be an `add-model` precondition -- the runbook's own guard shape works regardless. **NOT
EXECUTED** (hard rule 3; it is a state change on the live client, presented not taken).

**FOUR GAPS LOGGED NOT FIXED**, in consequence order:
- **G4 -- the `openstack` CLI is MISSING ON THE RACK** (three instruments agree). A D-138
  definition-of-done gap that blocks `phase-03`+. **Same item as F1 from the 2026-07-30
  sweep**, now re-confirmed on the D-138 host rather than on voffice1 -- so it has survived two
  sweeps and should stop being re-discovered.
- **G3 -- preflight CANNOT PASS on vcloud by construction.**
  `overlays/vr1-dc0-octavia-pki.yaml` is gitignored PKI material (0600 on the rack, absent from
  the vcloud tree) and `scripts/pre-flight-checks.sh:161` hard-`fail`s on it. Code-cited, not
  executed. This is a gate that cannot pass on one host and can on another -- the
  host-dependence class this repo already records for `dc-mirror.sh` and P5/P7.
- **G2 -- the D-138 client host's deploy input has NO PROVENANCE.** `~/repo-stage` on the rack
  is a hand-staged 9-file copy with **no `.git`**; 8 of 9 are byte-identical to the repo by
  sha256, so it works today. It is a THIRD copy beside the two clones the 2026-07-31 entry
  verified at `c58bf95` before trusting any gate output, and the 2026-07-27 stale-clone hazard
  is precisely why that verification existed.
- **G1 -- `runbooks/dc-dc-phase4-juju-bundle-per-dc.md:379,398` still say "voffice1"** for the
  add-model and spaces steps, stale against D-138. Measured: voffice1 HAS the binary but
  `juju controllers` returns "No controllers registered", so the runbook as written FAILS.
  DOCFIX owed, deliberately not numbered mid-flight.

**DECLARED UNMEASURED, with the reason:** whether MAAS user `juju-vr1-dc0` has an imported ssh
key -- the DISTAL half of the root cause. There is no usable maas CLI profile anywhere
(vcloud has none; voffice1's `~/.maascli.db` is ZERO BYTES with no `profiles` table, the inert
residue already recorded 2026-07-30). It does not change the fix, because the proximate cause
was measured on the machine directly. **The PreToolUse guard refused a command that would
print the MAAS API key (DOCFIX-016) and it was NOT retried in an altered shape** -- so
`~/vr1-dc0-creds/` and the rack's profile state are unenumerated, and SEC-028's distribution
claim is carried from the ledger rather than re-measured. Both the guard firing and the
non-retry are the correct outcomes and are recorded as such.

**Revert.** `git rm docs/audit/stage5-juju-client-blocker-20260801.txt` and drop the
CURRENT-STATE paragraph. Nothing live was changed, so there is nothing else to undo.

---

## Item 13 -- BUILD: the D-139 apex carve tool, DRY-RUN ONLY (nothing pushed)

**What.** `netbox/d139-gua-carve.py` (232 lines) + `tests/d139-gua-carve/run-tests.sh` (151) +
`tests/d139-gua-carve/stub-apex.py` (100, an offline NetBox stand-in) +
`docs/audit/d139-carve-dryrun-20260801.txt` (97) + `tests/HARNESS-MANIFEST` 94 -> 95.

**Why.** D-139 ruling B execution step 1. **Dry-run is the DEFAULT and the write path is
explicitly opted into**; nothing was written to NetBox in this session.

**Live dry run, both DCs: `CREATE 22 | EXISTS 6 (untouched) | RETIRE-REPORT 18`.** The
`f0X:10::/60`, `f0X:10::/64` and `f0X:11::/64` provider-public rows already exist and are
correctly skipped rather than recreated.

**THE REPORT-ONLY PASS EARNED ITS KEEP: it surfaced 52 DEPENDENT ip-addresses** living inside
the retiring ULA `/64`s -- 26 per DC, in `:220`/`:221` and `:320`/`:321` -- which a later
delete would ORPHAN. Those are the v6 VIP legs. 0 dependent ip-ranges. Retirement is
REPORTED, never executed, so this is a finding rather than an incident.

**Proof no write occurred, asserted on CONTENT rather than on the tool's own say-so:** apex
prefix count **139 before and 139 after**, and none of the 22 CREATE rows exists in the apex.

**Mutation-proven, 5 mutations, each turning a NAMED test red; tool restored and
sha256-verified byte-identical after each:** storage hextet `0x40`->`0x41` (T07/T08 red, and
the `/60`-alignment guard REFUSEs); `UA = "curl/8.5.0"` removed (T15 red, plus 42 others --
the stub 403s exactly as the real apex does); the `SANDBOX_HOSTS` refusal neutered (T04 red,
"did not refuse the baldurkeep upstream"); the retire predicate widened from the ULA `/48` to
a GUA `/36` (T10 red, all 9 rows); read-back `gone = []` (T17 red).

**Credential hygiene held:** only `vr1-netbox-sandbox.env` was sourced, never printed, and the
tool hard-REFUSES any host outside `{localhost, 127.0.0.1, 10.10.1.10}`, naming DOCFIX-195
when it does. The two NetBox instances stayed separate throughout.

**Charter compliance, since it was a graded requirement:** 232 lines, of which a **12-line
docstring** and **5 comment lines in the entire file** (longest block 2 lines). Zero
re-argued rationale, zero worked examples, zero alternatives-considered. The length is code --
refusals, conflict detection, read-back, the write path -- not prose. **One soft criterion
missed and declared: `main()` is ~90 lines, so "one screen per function" does not hold there.**

Harness 65/65; gauntlet ALL GREEN (95); repo-lint 0 fail.

**Name deviation, deliberate:** `d139-gua-carve.py`, not `-import.py`. The D-NNN family in
`netbox/` is 3/3 without the suffix (`d115-office-carve.py`, `d120-compose-bands.py`,
`d124-transit-seed.py`); `-import` belongs to the `dc-*` family.

**Revert.** `rm netbox/d139-gua-carve.py; rm -rf tests/d139-gua-carve` then
`bash scripts/run-tests-all.sh --record-manifest`. Nothing in the cloud or the apex changes
either way.

---

## Item 14 -- D-139 RULING A IS NOT ACHIEVABLE AT THESE CHARM REVISIONS. Ruling B unaffected.

**What.** `docs/audit/v6-only-charm-viability-20260801.txt` (355 lines) +
`docs/CURRENT-STATE.md`. No artifact changed, nothing actioned.

**Method, and it is the one this repo learned the hard way:** the charms were DOWNLOADED and
READ. `prefer-ipv6` was researched the same way on 2026-07-31 and the research inverted its
own premise; the same discipline is why this result is trustworthy rather than plausible.

**RE-VERIFIED INDEPENDENTLY by the main session** against the shipped `ceph-osd` rev 953
artifact, because it is the claim that decides the ruling -- `hooks/utils.py:203-217`:
`get_host_ip()` returns `get_ipv6_addr()[0]` when `prefer-ipv6` is set, else runs
`socket.inet_aton(hostname)` and on failure `dns.resolver.query(hostname, 'A')` -- an
IPv4-ONLY lookup -- under the charm's OWN comment *"...just let it kill the hook"*.

**So `ceph-osd` fails on a v6-only plane in BOTH directions**, which is what makes it a block
rather than a config question: `prefer-ipv6: false` -> `inet_aton` raises on a v6 literal ->
NXDOMAIN on an `IN A` lookup (LP #2109798, `New`, whose reporter's only workaround is
"forcing the ipv4 cidr"); `prefer-ipv6: true` -> bare `get_ipv6_addr()` (also
`ceph_hooks.py:547`, WITHOUT `dynamic_only=False`) which returns DYNAMIC/SLAAC addresses only,
while every VR1 node holds a MAAS **static** v6. That is LP #2061836 -- `Fix Committed` on
`charm-ceph-mon`, **`New` and never fixed on `charm-ceph-osd`**, confirmed absent from rev 953.

**The other two families are reported from the capture and NOT re-verified here** -- recorded
as strong sourced observations, not as measured-here facts: `metal-internal`'s mysql/mysql-
router bare `user:pw@addr` URIs (invalid for an unbracketed v6 literal) and `hacluster`'s
corosync `ip_version: ipv4`, hard-written in 2.4/stable rev 166 released 2026-06-29 even
though LP #2111852 is `Fix Committed` (**Fix Committed is not Fix Released** -- a distinction
this repo has been bitten by before); and OVN documenting the encap column as *"The IPv4
address of the encapsulation tunnel endpoint"* with zero v6 encap values anywhere in OVN
24.03's test suite.

**Two things counted locally to size it:** `metal-internal` appears **273 times** in
`bundle.yaml` across ~44 applications, so it is the most pervasive binding in the deployment;
and **`rabbitmq-server` is deployed by the bundle but ABSENT from `PREFER_IPV6_CHARMS`** --
the only mismatch across all 33 bundle pairs, on which invariant 9a would emit a factually
false message.

**CONSEQUENCE, stated as a decision rather than actioned:** ruling A's five-plane v6-only
scope is blocked by UPSTREAM CHARM DEFECTS, not by anything in this deployment. **Ruling B is
ORTHOGONAL and STANDS** -- GUA-versus-ULA is independent of whether a plane keeps v4 -- so item
13's tool is unaffected and a GUA DUAL-STACK carve is achievable today.

**THREE ITEMS OWED.** (a) The foundational measurement is STILL NOT TAKEN: **does
`network-get` return a v6 address on a v6-only bound space?** Whatever survives of the
storage/replication verdict rests on it. (b) **D-139's "remove the v4 subnets LAST, after each
is proven" is UNSATISFIABLE as written** -- per-plane conversion is atomic, so no state exists
in which a plane is proven v6-only while still holding v4. That clause needs rewriting under
any ruling. (c) The `rabbitmq-server` mismatch above.

**PROCESS FAILURE, OWNED, AND THE MOST REUSABLE PART.** This research was written to
`/tmp/v6research/FINDINGS.txt` and **would have been lost at the session boundary**. The
agent was scoped read-only and given NO repo path for its findings -- **my error in writing
the mandate, not the agent's**. Rescued and sha256-verified identical. **Standing consequence:
every agent mandate must NAME A REPO PATH for its findings.** A read-only mandate still
produces a durable artifact; "read-only" constrains what it may CHANGE, not where it may
RECORD.

**Revert.** `git rm docs/audit/v6-only-charm-viability-20260801.txt` and drop the
CURRENT-STATE paragraph. Nothing was actioned, so there is nothing else to undo.

---

## Item 15 -- RULING: D-139 ruling A amended to a bounded experiment + upstream fix ("B plus C")

**Operator answer, exact utterance: "B plus C".** Options as presented: (a) carve GUA
dual-stack now and defer v6-only; (b) v6-only on `replication` alone as a bounded experiment;
(c) pursue the upstream fix (LP #2061836's `ceph-osd` change is ONE WORD, already merged on
`ceph-mon`). **(a) not selected.**

**INTERPRETATION STATED SO IT CAN BE CORRECTED:** ruling B's GUA carve is unaffected and
proceeds; ruling A's five-plane v6-only scope narrows to the experiment; `metal-internal`,
`data-tenant` and `lb-mgmt` stay DUAL-STACK pending upstream fixes. Recorded as an
interpretation, not as the utterance.

## Item 16 -- I SCOPED THE EXPERIMENT WRONG. Ceph couples `storage` and `replication`.

**MEASURED against shipped `ceph-osd` rev 953, `ceph_hooks.py:544-553`:**

```
if config('prefer-ipv6'):
    cephcontext['ms_bind_ipv4'] = False        # GLOBAL
    cephcontext['ms_bind_ipv6'] = True
    dynamic_ipv6_address = get_ipv6_addr()[0]
    if not public_network:  cephcontext['public_addr']  = dynamic_ipv6_address
    if not cluster_network: cephcontext['cluster_addr'] = dynamic_ipv6_address
```

**`prefer-ipv6` is ONE switch setting `ms_bind_ipv4 = False` globally**, so it governs Ceph's
PUBLIC network (`storage`) and CLUSTER network (`replication`) TOGETHER. **There is no state
in which Ceph runs cluster on v6 and public on v4.** I recommended `replication` alone as
"smallest blast radius" -- that is not achievable, and the real experiment is `storage` +
`replication` as a PAIR, with a correspondingly larger blast radius than I represented.

**A PATH THE EARLIER ANALYSIS MISSED, and it partly rescues v6-only for Ceph.** The buggy bare
`get_ipv6_addr()` (LP #2061836, dynamic/SLAAC-only, never fixed on `ceph-osd`; our nodes hold
MAAS **statics**) is reached ONLY under `if not public_network:` / `if not cluster_network:`.
**Setting `ceph-public-network` and `ceph-cluster-network` to the v6 CIDRs means that call is
never used for address selection** -- the dynamic-only defect becomes AVOIDABLE BY CONFIG
rather than blocking. Same lever LP #2109798's reporter pulled in the opposite direction
("forcing the ipv4 cidr for the ceph-cluster-network and ceph-public-network options").

**CONFIDENCE, stated because it changes what may be built on it: this is a CODE READING, NOT
A MEASUREMENT.** It has not been run, and it does NOT address the `get_mon_hosts()` /
`get_host_ip` race (LP #2109798), which fires in any window where `ceph-public-address` is not
yet published. **Still owed before the experiment: does `network-get` return v6 on a v6-only
bound space?** -- still not taken.

## Item 17 -- REVIEW PASS on `netbox/d139-gua-carve.py` (independent second agent)

**What.** `netbox/d139-gua-carve.py` + `tests/d139-gua-carve/run-tests.sh` edited;
`docs/audit/d139-carve-review-20260801.txt` (NEW, 364 lines). Per the operator's standing
instruction that every new script gets a review-and-streamline pass after delivery.

**Verdict: not "no change needed", but close.** The tool was already at charter prose weight
(5 comment lines in 232). **4 real defects FIXED, 4 reported-not-fixed, 1 declared charter
miss UPHELD.**

**D1, the consequential one, and it is the mandate's own named class "a refusal that does not
refuse":** an unreachable apex produced a **raw traceback and EXIT 1** -- which the tool's own
header defines as a write/read-back error -- **on a dry run that wrote nothing**. `_req`
caught only `HTTPError`, so `URLError` walked past the handler that exists to make this
REFUSE. Measured pre-fix (`ConnectionRefusedError [Errno 111]`, `RC=1`); two-line
`except OSError` -> REFUSE(2).

**D2** a comment asserted ruling B was "FLAGGED for operator reconsideration" -- already FALSE
at commit time (`bbc0330` confirmed it 35 minutes earlier). Replaced with a bare citation.
**This is the charter's "cite, never re-argue" earning itself: prose in a script rots against
governance state; a citation cannot.** **D3/D4** replaced two greps over the tool's OWN SOURCE
TEXT (existence, not content) and two vacuous-negative assertions with behavioural coverage.

**`main()` decomposition DECLINED, and the argument is reusable:** the `if not a.commit:
return 0` guard sits ADJACENT to the write block; extracting `commit_writes()` would split
that safety proof across two places, for a script whose entire claim is that the write path is
opted into. **Line count is not the criterion -- whether a reader verifies a safety property
in fewer places is.** The charter's "one screen per function" is a heuristic for that, not the
goal itself.

**R1 IS A REAL SECURITY FINDING, MEASURED NOT REASONED: urllib carries the `Authorization`
header across a CROSS-HOST redirect** -- proven with a loopback probe in which the target
received the token verbatim. `SANDBOX_HOSTS` gates the SUPPLIED url, not a redirect FROM it.
LOW severity (requires the approved apex to redirect hostilely) and a redirect handler is
untested code on a control path, so logged not executed. R2 unwrapped read-back, R3 `errs`
double-count (tally only), R4 `subnet_of` equality (measured not to occur live).

**Verification: harness 65/65 -> 71/71. ALL 5 ORIGINAL MUTATIONS RE-RUN on the edited tool and
all still stand**, plus 3 new (M6 reverting the D1 fix -> T18 red; M7 zero-scope guard; M8 a
print-format drift invisible without the new guard). Tool restored from a pristine snapshot
rather than `git checkout` (shared clone), sha256-verified after each. Gauntlet ALL GREEN (95).
**Dry-run body DIFFED BYTE-FOR-BYTE against the committed capture** -- asserted on content, not
counts -- apex prefix count 139 before and after, `--commit` never passed.

**QUALIFICATION THE REVIEWER DECLARED RATHER THAN LEFT IMPLICIT:** a byte-identical dry run
proves the READ/PLAN path unchanged, because a dry run executes zero POSTs by construction.
**D1 also changed the WRITE path's failure semantics** -- a connection error during a POST is
now caught and counted, so the loop CONTINUES instead of aborting, and `errors=N` is reachable
with nothing transmitted. Deliberate, out of scope to undo, **UNTESTED**.

**PROCESS FAILURE REPEATED AND OWNED.** The review mandate REQUIRED a `docs/audit/` capture and
FORBADE touching `docs/CURRENT-STATE.md` -- jointly unsatisfiable against repo-lint L10. The
agent correctly left the tree RED and SAID SO rather than working around it, which is the
right behaviour. Same class as the `/tmp` loss earlier today. **Standing fix, now twice
learned: an agent mandate must name a repo path for findings AND leave the committer able to
satisfy L10.**

**Revert.** `git checkout netbox/d139-gua-carve.py tests/d139-gua-carve/` restores the
pre-review tool; note that D1 was a real defect and reverting reinstates it.

---

## Item 18 -- IPv6 VERIFIED WORKING on the dc0 node planes; G17's role-node half captured

**What.** `docs/audit/g19-ipv6-node-plane-verify-20260801.txt` (NEW, 97 lines) +
`docs/CURRENT-STATE.md`. A live experiment: operator-approved MAAS deploy of TWO storage nodes
(`t7ymp6`, `fg6gxm`, jammy) purely to open a boot window, issued INDIVIDUALLY rather than in a
loop. **Region asserted before any MAAS call** -- `vr1-dc0-region` -> one rack controller
`hot-kid`; `admin` -> the three Office1 racks. `maas-profile-assert.sh` is MISSING on voffice1
(its clone is behind HEAD), so the same property was asserted inline rather than skipped.

**A1 -- addresses come up. PASS.** Six global v6 addresses live on the NICs, matching MAAS
exactly, 0 tentative / 0 dadfailed, on-link `/64` routes present, no v6 default (expected).
**Asserted on the INTERFACE, never on MAAS**, and this is the first time it has been checked on
a ROLE NODE at all.

**A2 -- the plane carries v6 between two nodes. PASS on all six, 0% loss, every neighbour
REACHABLE.** Designed to catch one specific thing and it did the opposite: **the risk I flagged
is REFUTED for this path.** Every plane bridge measures `multicast_snooping=1` /
`multicast_querier=0`, a known source of ND failure. The neighbour table was **COLD**, so the
first solicitation had to go out as MULTICAST -- and resolved on all six planes. **HONEST
RESIDUAL:** this proves ND from cold; it does not prove behaviour across long idle periods
where snooping entries age out. A minutes-long test cannot show that.

**A3 -- G17's role-node half, OPEN since 2026-07-30, is captured. PASS.** The earlier dc0 G17
capture was taken on the CONTROLLER VM and said so. From a role node: the mirror's real package
path returns exit 0 / HTTP 200 / 269219 bytes with all four body fields. **And the 2026-07-31
deploy blocker is confirmed FIXED FROM A REAL NODE -- all four suites answer 200,
`jammy-backports` included**, where it was 404 and put 22 units into `hook failed: "install"`.
The D-135 backports amendment is BUILT, not merely ruled.

**A4 -- THE HEADLINE, and it inverts the framing this whole document has used: the node's time
source is ALREADY IPv6.** `ServerName` = `fd50:840e:74e2:220::6`, `ServerAddress` decodes as
family **10 = AF_INET6**, and `timesync-status` shows Stratum 3, root distance 57.327ms, poll
interval backed off to 2min 8s -- a healthy sustained sync -- with `ntp.ubuntu.com` unused as
fallback. G17 assertion (2) passes (MAAS-served, not the DC edge, per D-129(iv)), **and
separately IPv6 is not a future state here: it is a live operational dependency that predates
every line of this verification work.** Every prior surface discusses IPv6 as something to be
built; one of it is already carrying production traffic.

**G17's own text re-confirmed defective:** it names `chronyc sources` and chrony is NOT on the
MAAS jammy image, so the gate as written can only ever REFUSE. DOCFIX still owed.

**F7 CLOSED IN PASSING:** the 2026-07-31 sweep recorded "STILL UNVERIFIED: that a redeploy
applies the new hostname". **It does** -- both machines report their ruled names from
`hostname` on the running OS, not merely in the MAAS record.

**SCOPE, stated not glossed.** These are **ULA** addresses, the PRE-D-139 carve; D-139 moves
every plane to GUA, so the ADDRESSES are superseded by design. **The PROPERTY tested is
family-agnostic and transfers unchanged.** Nothing here tests a charm, a container,
`network-get`, or Ceph -- those remain the untested rungs, and this result must not be read as
covering them.

**THE NODES ARE DELIBERATELY LEFT `Deployed`.** The G19 gate script is still being built, and
leaving the window open lets it run against a LIVE node instead of shipping fixture-green --
the snap proxy's harness was green for a week before anything was proven end to end. Release is
owed once the gate has run.

**Revert.** `maas vr1-dc0-region machine release t7ymp6` and `... fg6gxm` return both to
`Ready` (`enable_disk_erasing_on_release=false`, so it takes minutes); `git rm` the capture and
drop the CURRENT-STATE paragraph. Nothing else was mutated.

---

## Item 19 -- BUILD G19: `scripts/dc-node-v6-verify.sh`, the IPv6 plane gate

**FOLDED IN FROM `docs/changelog-20260801-g19-node-v6-verify.md`, which the build
agent wrote as a separate file and which is REMOVED here.** GA-R2/D1 is ONE changelog
per SESSION, never per topic -- two files means two review surfaces. The session
crossed midnight, which is why the agent dated a new one; that does not start a new
session. Original text preserved verbatim below the rule.

### (folded) G19 build -- agent-authored text, verbatim

**What.** New named executable gate answering two DIFFERENT questions: do the DC
nodes actually bring their IPv6 statics UP on every plane (asserted on the
INTERFACE, never on MAAS), and does a plane CARRY IPv6 between two nodes
(reachability to a peer plus the `ip -6 neigh` state that ping alone cannot
distinguish from a lie). Plus a rack-side diagnostic that reports each plane
bridge's multicast snooping/querier state so a red data-path result can be triaged
in one step.

**Files added**

| Path | Role |
|---|---|
| `scripts/dc-node-v6-verify.sh` | the gate: `plan` \| `node` \| `bridges` |
| `tests/dc-node-v6-verify/run-tests.sh` | 55-case harness, both directions driven |
| `docs/audit/g19-ipv6-plane-gate-build-20260801.txt` | build capture, live readings, mutation results |

**File changed:** `tests/HARNESS-MANIFEST` (+1 line, `dc-node-v6-verify`).
R15(2) requires a deliberate re-record with a stated reason: **a new harness
directory was added.** Without it the gauntlet's drift gate FAILS with "present but
UNPINNED" -- the gate working correctly.

**Governing decisions.** D-139 (VR1 goes IPv6-only east-west; whole plane carve
moves to GUA), D-101 (IPv6 unless IPv4 is necessary), D-134 (node octets).
Rationale lives there and in the capture, not in the script.

**The prefix constraint, and how it is resolved.** D-139 retires the VR1 ULA `/48`
and moves every plane to GUA, so a site table of prefix literals would be correct
today and wrong on carve day. **There is no v6 prefix literal in this tool.**
`plan` derives the expectation from live MAAS and emits a per-machine SPEC;
`node` takes that SPEC as input and knows no prefixes of its own. Harness T3
enforces the absence on non-comment lines; T14 drives the same green `plan` case
with a ULA fixture and a GUA fixture.

**Scope of a green, stated in the script header too:** this asserts the NIC against
MAAS, not against D-139's ruled GUA table. MAAS-vs-ruling belongs to
`dc-node-v6-carve.py check` and `tests/d139-gua-carve`.

**Gates.** Harness 55/55. Gauntlet ALL GREEN (96 harnesses). `repo-lint`: **1 fail,
1 warn.** The warn is the pre-existing legacy `D-001..018` non-ASCII carve-out. The
fail is **L10 only** -- this change set adds a `docs/audit/` file without touching
`docs/CURRENT-STATE.md`, which this session was instructed not to edit because the
operator owns the G19 gate row. It clears when that row lands, in the same commit.

**Mutation pass** (each predicate neutered alone, harness re-run, restored,
`sha256sum` verified identical -- `3ea87ced...c251ca` before and after; the
pass was re-run in full after the last message edit):

| Mutation | Predicate | NAMED test that went red |
|---|---|---|
| M1 | `node` contradiction branch `[ "$prc" -eq 0 ]` | T37, T38 |
| M2 | `node` extra-global catcher `[ -n "$extra" ]` | T31 |
| M3 | `plan` plane-set identity `s != modal` | T15 |

**Live, read-only, this session.** `bridges` was run over the intended
`ssh <rack> 'bash -s -- bridges <site>'` path on BOTH racks: all six plane bridges
plus the WAN bridge read `multicast_snooping=1 multicast_querier=0` on dc0 AND
dc1, independently confirming and extending the dc0 measurement this gate was
commissioned against. `plan` was exercised on `vr1-dc0-maas` and correctly returned
**REFUSE / exit 3** (no MAAS profile for the ssh user) -- the three-outcome contract
proven on a real host. No cloud state was mutated.

**Two open checks, both in the capture, neither red today.** (a) The
sole-global-per-NIC predicate would FAIL on whichever node holds a v6 HA VIP *if*
D-139's ruled provider-public VIP `/64` lands as a secondary on the same netdev as
the node static. No exemption was built -- there is nothing to measure one against.
(b) `LOWER_UP` on an OVS-internal `br-ex` is the one `ip` output shape this build
never saw; no reachable host carries a br-ex. One `ip -o link show dev br-ex` on the
first node that has one settles it.

**Carried, not closed.** No node currently carries these addresses up, so
assertion (2) has never run against real traffic; this is a fixture-and-diagnostic
green, not a plane that has been proven to work. And `plan`'s use of
`machines read -> interface_set[].links[].subnet.cidr` is corroborated by
`carve-host-interfaces.sh:120,293` but not yet seen live -- one `plan` run from a
shell with a logged-in profile closes it. Both are in the capture.

**Also logged, NOT executed** (hard rule 1): `dc-node-v6-carve.py` pivots on "the
interface already carries a v4 static", which selects nothing on the five planes
D-139 strips of IPv4. It will silently under-carve after the v4-removal step. G19
does not inherit the defect -- `plan` pivots on the link's subnet being v6.

**Revert.** `git rm scripts/dc-node-v6-verify.sh tests/dc-node-v6-verify/run-tests.sh
docs/audit/g19-ipv6-plane-gate-build-20260801.txt docs/changelog-20260801-g19-node-v6-verify.md`
then `bash scripts/run-tests-all.sh --record-manifest`. Nothing else consumes these
files: no runbook, no `preflight.sh` sub-gate and no other script references them,
so removal is self-contained.

---

## Item 20 -- next steps executed: nodes released, D-139 execution list replaced, LP draft written

**(1) Test nodes RELEASED.** `t7ymp6` / `fg6gxm` -> `Ready` / `owner=None`, released
individually and read back. Nothing stranded. G19 was run live before the window closed, which
was the whole reason for holding them.

**(2) `docs/design-decisions.md` -- D-139 gains a `CORRECTION NOTE 2026-08-01` replacing its
EXECUTION list.** **Neither ruling is touched.** The original list is preserved verbatim inside
the note rather than silently overwritten -- the same reason the struck RFC 6724 rationale was
kept: a later reader must be able to see what was wrong, or they will re-derive it.

Three defects, in consequence order:
- **SILENT FAILURE (the reason this could not wait):** `dc-node-v6-carve.py` assigns v6 "on
  every plane **where it already carries IPv4**", keys the subnet off "the SAME MAAS vlan as
  that v4 link", derives the host part from the v4 octet, and its loop body is
  `if not v4: continue`. Run after v4 removal it carves **four fewer planes per node and exits
  clean**. The original list's "remove v4 LAST" wording actively invited that ordering.
- **UNSATISFIABLE:** "remove v4 LAST, after each is proven" -- per-plane conversion is atomic,
  so no such state exists. It read like caution and could not be executed.
- **UNSAFE STEP FUSION:** apex CREATE and RETIRE in one step, with 52 dependent ip-addresses
  (the v6 VIP legs) inside the retiring ULA `/64`s.

Replacement is 7 steps: CREATE-only apex push; MAAS GUA carve ALONGSIDE the ULA; node statics
re-carved **while v4 is still present**; Octavia SAN reissue + `lib-net.sh`; `lb-mgmt` carve;
re-home the 52 VIPs THEN retire; and **v4 removal as a SEPARATE experimental step**, scoped to
`storage` + `replication` TOGETHER per "B plus C" -- together because `ceph-osd`'s `prefer-ipv6`
sets `ms_bind_ipv4=False` globally. Step 7's prerequisite (`network-get` on a v6-only bound
space) is stated as unmet.

**(3) `docs/audit/lp-draft-20260801-ceph-osd-ipv6-static.md` (NEW).** The "C" half of the
ruling. **A COMMENT on the existing LP #2061836, not a new bug** -- the ceph-mon task is
already `Fix Committed` and only ceph-osd remains `New`. Every code claim quoted from the
downloaded rev-953 artifact, not from a repo note. **Claude does not post to Launchpad; the
operator files it**, per the `lp-draft-20260721` precedent.

Two things deliberately written INTO the draft's operator notes rather than left implicit:
**do not cite LP #1590598** (`Fix Released`, about IPv6-only host interfaces not being bridged
-- citing it would be the inverted-citation class this repo has twice been bitten by); and
**this bug does not block us locally**, because setting `ceph-public-network` /
`ceph-cluster-network` to the v6 CIDRs bypasses the buggy call. Overstating our dependence on
an upstream fix would be a bad-faith way to raise its priority.

**Revert.** `git checkout -- docs/design-decisions.md docs/CURRENT-STATE.md` (restores the
defective execution list -- note that reverting reinstates a silent-failure ordering);
`git rm docs/audit/lp-draft-20260801-ceph-osd-ipv6-static.md`. The node release is reversed by
re-deploying, not by git.

---

## Item 21 -- POST-BOOKEND: both DC containment VMs 416 -> 480 GiB; 128 GiB swap; P8 drift gate

**NOTE ON ORDERING:** the GA-R4 bookend (`4b8ba3c`) was committed BEFORE this work, so the
ledger's close summary and the sweep do NOT describe items 21. Recorded here and in
CURRENT-STATE; the ledger line is amended in the same commit rather than left stale.

**Why now, operator's reasoning:** *"If there was any time to add more resources is now while
the cost and risk is very low. Once we bring systems online within the host then the risks
begin to expand."* Correct, and the measurement agreed -- dc0's rack was running its inner
guests at **402 GiB in a 409 GiB host, 98.3%**, leaving 7 GiB for the rack OS, mirror, snap
proxy and page cache.

**SIZING RULED BY OPERATOR: +64 GiB each ("Option 2"), i.e. 416 -> 480 GiB per DC, WITH swap
added first.** I had recommended +48 and was overruled with a reason -- tenant testing is
coming. **The arithmetic I put up was the deciding input:** at +64 each, allocation is 994 GiB
against a 1007.4 GiB host, leaving **13.4 GiB** while the host's OWN measured footprint is
**18.0 GiB** -- a 4.6 GiB deficit if every guest went fully resident, with only 1 GiB of swap
free. Swap is what makes +64 defensible, which is why it was sequenced first.

**SWAP (operator-run; `sudo -n` is NOT available on vcloud, so this half could not be
automated).** `/swap2.img` 128 GiB, `600 root:root`, `swapon` live, fstab line added.
Verified: **135 GiB total swap** (8 + 128), 0 used. Effective cushion 13.4 + 135 GiB.

**TOFU IS THE ONLY CORRECT PLACE FOR THIS CHANGE.** `var.vvr1_dc0_memory_mib` /
`vvr1_dc1_memory_mib` (`main.tf:415`/`:542`). A `virsh setmaxmem` would have been reverted by
the next apply. **The derivation now lives IN the variable comment** -- 402-in-409, overhead
32 -> 96 GiB -- so the config explains its own number instead of the reason living only here.

**PLAN ASSERTED ON CONTENT, not eyeballed, because of the 2026-07-20 precedent** (an in-place
apply silently regenerated 9 node MACs). Per DC: 1 in-place, **0 create/destroy/replace, 0 MAC
changes**, and `memory` the only changed attribute.

**A THIRD RESOURCE APPEARED IN THE PLAN AND WAS RESOLVED BEFORE APPLYING, NOT AFTER.**
`module.office1_opnsense` showed `~ id = 2 -> 11`. The distinction that settles it is tense:
**"has changed outside of OpenTofu" (drift OBSERVED) versus "will be updated in-place" (action
PLANNED)**. libvirt's domain `id` is a runtime value that changes on every guest restart.
office1-opnsense was NOT touched by either apply.

**dc1 FIRST AS THE CANARY** (idle; only its edge running) -- the repo's standing pattern.
It answered the open question: **the in-place update BOUNCES the guest.** Domain id 9 -> 12,
qemu restarted, guest uptime 0 min. Exactly the recorded "in-place bounces the guest" trap.
Guest sees **472.2 GiB** (480 minus firmware reserve).

**>>> A FINDING THAT WOULD HAVE MADE THE dc0 BOUNCE LOOK CATASTROPHIC, CAUGHT BY CHECKING
FIRST: `vr1-dc0-maas-01` (the MAAS region) and `vr1-dc0-juju-01` (the juju controller) have
`autostart=disable`. <<<** Only the edge auto-recovers. Had I applied dc0 without checking,
the rack would have returned with no region and no controller. Both were started by hand and
verified. **The rack's own services (`dc0-snap-proxy`, `dc0-snap-proxy-net`,
`dc0-mirror-net`, `nginx`) are all `enabled` and did return unaided.**
**LOGGED, NOT FIXED (hard rule 1): a host reboot leaves dc0 with no MAAS region and no juju
controller.** That is a standing exposure, not a consequence of this change.

**RESULT, MEASURED.** Both VMs at 480 GiB; each rack now has ~71 GiB for its OS instead of 7.
**Host: used 809 -> 63 GiB, available 197 -> 944 GiB** -- because restarting both guests also
released the stranded RSS (vvr1-dc1 354 -> 12 GiB, its 6.6 GiB of swap freed). Recovery
verified end to end: MAAS region API **000 -> 502 -> 200** (a genuine boot progression, not a
flat failure), snap proxy listening, mirror 200, and `juju models` reporting the controller
model with *"Last connection: just now"*.

## Item 22 -- BUILD: preflight gate P8, substrate drift

**What.** `scripts/preflight.sh` (new P8) + `tests/preflight/run-tests.sh` (a `tofu` fixture
seam + T34-T38). No new harness, so `HARNESS-MANIFEST` is unchanged.

**Why.** Answering the operator's question -- does tofu need updates logged, or is it dynamic?
-- produced a measurement: **`preflight.sh` and `pre-flight-checks.sh` contained ZERO
`tofu plan` checks**, and a real drift had been sitting unseen until this session's plan
surfaced it. Substrate changes are genuinely RARE, which is exactly why nobody looks.

**THE DESIGN POINT: `-detailed-exitcode` returns 2 for BOTH a pending change and a harmless
observation.** The exit code alone cannot decide, so P8 asserts on CONTENT -- a pending ACTION
FAILS, an observed-only drift WARNS. **A gate that is permanently red on benign drift gets
ignored, which is the failure being prevented.**

**It REFUSES rather than fails when it cannot look.** The outer root lives on vcloud (D-128
Plane 1), so "not the substrate host" is a legitimate state, not a missing gate -- P4/P5's
fail-closed shape would be wrong here. Absent tofu, or absent outer-root state, WARN.

**Mutation-proven, three mutations, each killing a NAMED test; script restored and
sha256-verified byte-identical:** neutering the pending-action predicate -> T34 red;
making the unrecognised-shape branch pass -> T36 red; making the cannot-look branch silent ->
T35 AND T38 red. Note M1/M2 turned tests red on the MESSAGE while the exit code was still
right -- content-checking earning its place.

**T38 EXERCISES THE ABSENCE THE SAFE WAY, and the comment says why.** It removes the fixture's
STATE, never the fake `tofu` from `fakebin` -- the real tofu is on the system PATH, so a
"closed" PATH would fall through to it and touch the LIVE substrate. That is this session's
ninth instrument-currency instance applied prospectively rather than after the fact.

**PROVEN LIVE, NOT FIXTURE-GREEN:** run against the real outer root, `tofu exit=0`,
pending-actions=0, observed-drift=0 -> **P8 verdict `[ok] zero diff`**. The substrate is fully
converged after both applies, and the office1-opnsense drift is gone because the applies
refreshed state.

**Harness 33 -> 38 PASS, 0 FAIL.** Baseline proven by stashing: the 7 failures my first draft
caused were MINE, not pre-existing (`PASS=33 FAIL=0` with the change stashed).

**Revert.** `git checkout -- scripts/preflight.sh tests/preflight/run-tests.sh`.
For item 21: set both variables back to `425984` and re-apply (this bounces both guests
again); `sudo swapoff /swap2.img && sudo rm /swap2.img` and drop the fstab line.