repo-stage-drift-dc0-20260802.txt
=================================
COMPLETE drift picture for `~/repo-stage` on the dc0 RACK (vr1-dc0-rack).
Prep for SWEEP FINDING F1 -- docs/audit/queued-findings-20260802-stage5-edge-fold.txt:18-35.
(NOTE: the runbook-fold register has its OWN F1. This document concerns the SWEEP F1 only.)

READ-ONLY audit. Nothing was copied, moved, edited or created on the rack, on
voffice1, or in the repo. No file content was read from the PKI overlay on any host.

Measured 2026-08-02 by the audit agent.
  vcloud repo:  /home/jessea123/openstack-caracal-dc-dc
                branch dc-dc-stage5-preconditions, HEAD 1cdd607, working tree CLEAN
                ASSUMPTION STATED: because the tree is clean at 1cdd607, plain
                working-tree `sha256sum` IS the HEAD digest. No per-file
                `git show HEAD:<path>` was needed and none was run.
  rack:         reached as `ssh vr1-dc0-rack` (alias + ProxyJump voffice1 from
                ~/.ssh/config.d/vr1-sites; no jump was hand-constructed)
  headend:      reached as `ssh voffice1`; clone measured at
                /home/jessea123/openstack-caracal-dc-dc (`ls -d`), HEAD 48d5ef9

WHY THIS AUDIT EXISTS: under D-138 the dc0 RACK is the juju deploy client. It has NO
git clone -- `~/repo-stage` is a hand-staged copy, so nothing detects when it drifts.


=====================================================================
0. HEADLINE
=====================================================================
(A) present in BOTH, DIVERGED ................  1
(B) repo deploy input, MISSING from rack .....  0 in the Step-4 deploy closure
                                                2 for LATER steps (6 / HA)
                                                1 CONDITIONAL chain (preflight),
                                                  host-pin unruled -- see 4B
(C) rack-only, no repo counterpart ...........  0
(D) present in both, IDENTICAL ...............  13  (12 vs the repo + 1 vs voffice1)

Total regular files under ~/repo-stage: 14 (+4 directories).
`.git` ABSENT -- re-asserted this session, see 1.1. Premise of the whole finding holds.

The ONE diverged file is the one SWEEP F1 already named:
  overlays/vr1-dc0-vips.yaml
No SECOND drifted file exists. No orphan exists. The Step-4 deploy closure is
otherwise COMPLETE on the rack, including `./policies/overrides.zip`.


=====================================================================
1. FULL ENUMERATION OF ~/repo-stage ON vr1-dc0-rack
=====================================================================
Command: ssh vr1-dc0-rack "ls -a ~/repo-stage;
         find ~/repo-stage -printf '%y %m %s %TY-%Tm-%TdT%TH:%TM:%.2TS %p\n';
         find ~/repo-stage -name .git -print;
         cd ~/repo-stage && find . -type f | sort | xargs sha256sum"

1.1 -- `.git` ABSENCE RE-ASSERTED
  `ls -a ~/repo-stage` -> `.  ..  bundle.yaml  overlays  policies  scripts`
     (no dotfiles of any kind, no `.git`, no `.gitignore`)
  `find ~/repo-stage -name .git -print` -> NO OUTPUT.
  Consistent with the 2026-08-01 finding (`find / -xdev -maxdepth 5 -name .git
  -type d` on the rack returned nothing, docs/audit/stage5-juju-client-blocker-
  20260801.txt:253-259). ~/repo-stage remains a provenance-free hand copy.
  NOTE: this audit did NOT re-run the host-wide `find / -xdev` -- absence of a
  clone ELSEWHERE on the rack is CARRIED from the 08-01 measurement, not re-measured.

1.2 -- TYPE / MODE / SIZE / MTIME  (no symlinks; all 14 are regular files)
  TIMESTAMP FORM, stated so no reader has to re-derive it: these come from
  `find -printf` on the RACK and are HOST-LOCAL and UNANNOTATED. The repo/voffice1
  times in sections 2 and 3 are `stat`/`ls` output carrying `+0000`. Do not compare
  the two forms to the minute. Every comparison this document draws (see 4A) rests
  on a gap of ~26 hours, which survives any plausible host clock skew.
  d 775  4096  2026-07-31T12:20:47  ~/repo-stage
  f 664 54351  2026-07-31T17:03:32  ~/repo-stage/bundle.yaml
  d 775  4096  2026-07-31T02:38:23  ~/repo-stage/overlays
  f 664 10479  2026-07-31T20:11:43  ~/repo-stage/overlays/vr1-dc0-machines.yaml
  f 600  4682  2026-07-31T02:38:23  ~/repo-stage/overlays/vr1-dc0-octavia-pki.yaml
  f 664  4368  2026-07-31T19:48:48  ~/repo-stage/overlays/vr1-dc0-vips.yaml
  d 775  4096  2026-07-31T12:20:47  ~/repo-stage/policies
  f 664 12192  2026-07-31T12:20:47  ~/repo-stage/policies/domain-manager-policy.yaml
  f 664  3419  2026-07-31T12:20:47  ~/repo-stage/policies/overrides.zip
  d 775  4096  2026-08-02T06:21:11  ~/repo-stage/scripts
  f 664  3618  2026-07-31T02:33:47  ~/repo-stage/scripts/juju-spaces-check.sh
  f 664 13388  2026-07-31T02:33:47  ~/repo-stage/scripts/lib-hosts.sh
  f 664 15648  2026-07-31T02:33:47  ~/repo-stage/scripts/lib-net.sh
  f 775  4707  2026-08-02T06:21:11  ~/repo-stage/scripts/opnsense-api.sh
  f 775  6659  2026-08-02T06:21:11  ~/repo-stage/scripts/opnsense-bootstrap-apikey.sh
  f 664  2117  2026-08-02T06:21:11  ~/repo-stage/scripts/opnsense-mint-apikey.php
  f 664  8951  2026-08-02T06:21:11  ~/repo-stage/scripts/opnsense-set-iface-v4.php
  f 775 10218  2026-08-02T06:21:11  ~/repo-stage/scripts/opnsense-set-interface-v4.sh

  MODE RE-ASSERTED: overlays/vr1-dc0-octavia-pki.yaml is `600`. SEC-029's
  handling requirement still holds on the rack.

1.3 -- INVENTORY COUNT MOVED SINCE THE PRIOR BASELINE, AND THIS IS ITSELF A FINDING
  The 2026-08-01 audit recorded ~/repo-stage as a NINE-file copy
  (stage5-juju-client-blocker-20260801.txt:256). It is now FOURTEEN.
  The delta is exactly the five `opnsense-*` files, all mtime 2026-08-02T06:21:11,
  staged during the dc0 edge REBUILD and disclosed as LEFT BEHIND at
  docs/audit/dc0-edge-rebuild-20260802.txt:577-579. Their digests there
  (`:259-264`) are byte-for-byte the digests measured here, so they were staged
  from the repo and have not been touched since.
  CONSEQUENCE: the "nine-file copy" phrasing in SEC-029(3) and in the 08-01 audit
  is SUPERSEDED as a count. A reader planning the re-stage from the nine-file
  figure would omit five files -- not a drift, but an inventory blind spot of
  exactly the shape the "a register cannot report what it has no row for" lesson
  names. LOGGED, NOT FIXED (hard rule 1); the count lives in prose, not a gate.

1.4 -- RACK DIGESTS (sha256, FULL)
  4c8a78527a3100f674642cee24cccb60dbc7015deccd2b93bd14ca4333a4e550  ./bundle.yaml
  e3be85e41b4194861bdfd15f717678992d6c32b5b393ba701664bb0e6cbac45e  ./overlays/vr1-dc0-machines.yaml
  5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f  ./overlays/vr1-dc0-octavia-pki.yaml
  ed19d989e80da8dacd9fe8ff79beb739494ea8abc1951267ea8bb8fb7bb9bb33  ./overlays/vr1-dc0-vips.yaml
  64f99b638a1855b02180e907c9535db8bddc5847a502759a9e0d63c513b63077  ./policies/domain-manager-policy.yaml
  02fe1fd7fcf07bfc6088622d4aa8430da53e435d60006d0b81f6b9c2e720a011  ./policies/overrides.zip
  adb9dbd38a27e663083f37b64e17ca98d870180f010b8d499a29f3fbfe7d1d5d  ./scripts/juju-spaces-check.sh
  1a46e949603d52690fd9a42d59e1e46f05522469fca2d4fa149065439b019320  ./scripts/lib-hosts.sh
  3e465ae7de3bf92d44326e12240cd411bb7c4e59c1f5b0bb2dd9de4ac23eb81f  ./scripts/lib-net.sh
  8c2329f87fe72a939cfe48b7fece33685ff8f392949af96b490772453b35c905  ./scripts/opnsense-api.sh
  c1bd904489fe6e819463f1c9db483ea054d15586acd05e08fd85285dbbf1b450  ./scripts/opnsense-bootstrap-apikey.sh
  2a85225dc6329524b86986c0c1ab3ccb1863b0fe0fd522fd7f6c88e1acca0938  ./scripts/opnsense-mint-apikey.php
  ed3c4784e20046aab09b6041030176301bddb5442e2ff4cbb5911390d8bfdc5a  ./scripts/opnsense-set-iface-v4.php
  5dd78f323df0261b4f9bc32cdb8fbf5e7fcc411e58527d49742716ad8a4bb7ef  ./scripts/opnsense-set-interface-v4.sh


=====================================================================
2. REPO-SIDE DIGESTS (vcloud, HEAD 1cdd607, tree clean)
=====================================================================
  4c8a78527a3100f674642cee24cccb60dbc7015deccd2b93bd14ca4333a4e550  bundle.yaml
  e3be85e41b4194861bdfd15f717678992d6c32b5b393ba701664bb0e6cbac45e  overlays/vr1-dc0-machines.yaml
  80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0  overlays/vr1-dc0-vips.yaml
  64f99b638a1855b02180e907c9535db8bddc5847a502759a9e0d63c513b63077  policies/domain-manager-policy.yaml
  02fe1fd7fcf07bfc6088622d4aa8430da53e435d60006d0b81f6b9c2e720a011  policies/overrides.zip
  adb9dbd38a27e663083f37b64e17ca98d870180f010b8d499a29f3fbfe7d1d5d  scripts/juju-spaces-check.sh
  1a46e949603d52690fd9a42d59e1e46f05522469fca2d4fa149065439b019320  scripts/lib-hosts.sh
  3e465ae7de3bf92d44326e12240cd411bb7c4e59c1f5b0bb2dd9de4ac23eb81f  scripts/lib-net.sh
  8c2329f87fe72a939cfe48b7fece33685ff8f392949af96b490772453b35c905  scripts/opnsense-api.sh
  c1bd904489fe6e819463f1c9db483ea054d15586acd05e08fd85285dbbf1b450  scripts/opnsense-bootstrap-apikey.sh
  2a85225dc6329524b86986c0c1ab3ccb1863b0fe0fd522fd7f6c88e1acca0938  scripts/opnsense-mint-apikey.php
  ed3c4784e20046aab09b6041030176301bddb5442e2ff4cbb5911390d8bfdc5a  scripts/opnsense-set-iface-v4.php
  5dd78f323df0261b4f9bc32cdb8fbf5e7fcc411e58527d49742716ad8a4bb7ef  scripts/opnsense-set-interface-v4.sh
  ABSENT-IN-REPO  overlays/vr1-dc0-octavia-pki.yaml   <- BY CONSTRUCTION, see section 3

Repo mtimes for the diverging/deploy-critical files:
  bundle.yaml                     54351  2026-07-31 16:43:15 +0000
  overlays/vr1-dc0-machines.yaml  10479  2026-07-31 20:04:04 +0000
  overlays/vr1-dc0-vips.yaml       4316  2026-08-01 21:29:43 +0000
  policies/overrides.zip           3419  2026-07-10 19:24:12 +0000


=====================================================================
3. THE PKI OVERLAY -- ITS OWN ROW, COMPARED TO voffice1, NOT TO THE REPO
=====================================================================
`overlays/vr1-dc0-octavia-pki.yaml` carries the Octavia controller CERT and its
PRIVATE KEY (security-ledger SEC-029). It is GITIGNORED (`.gitignore:46`
`overlays/*octavia-pki.yaml`) and is ABSENT from the vcloud repo tree BY
CONSTRUCTION. A mechanical repo-diff would therefore mis-file it as class (C).
IT IS NOT CLASS (C). Its comparison target is voffice1's clone.

VERIFIED BY sha256 ONLY. Its contents were NOT read, printed, quoted or copied on
any host, and no content-touching command (file/head/grep/cat) was pointed at it.

  rack      vr1-dc0-rack:~/repo-stage/overlays/vr1-dc0-octavia-pki.yaml
            5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f
            4682 bytes, mode 0600, mtime 2026-07-31T02:38:23  (the COPY time)
  headend   voffice1:~/openstack-caracal-dc-dc/overlays/vr1-dc0-octavia-pki.yaml
            5fc117f1883320422f1854b4a82c9c8025dd912326b25fa6ad95686dad40227f
            4682 bytes, mode 0600 (-rw-------), mtime 2026-07-30 07:01

  VERDICT: **IDENTICAL.** Class (D).

  The voffice1 path was NOT guessed: `creds-manifests/vm-secret-locations:90`
  registers the headend copy as `<repo>/overlays/vr1-dc0-octavia-pki.yaml` and
  `:127` registers the rack copy at its measured path; `<repo>` on voffice1 was
  resolved by `ls -d ~/openstack-caracal-dc-dc` (exists), not inferred.

  HYPOTHESIS TESTED AND NEGATIVE: SEC-029 warns that `octavia-pki.sh reissue`
  "must now update BOTH copies, or the rack will deploy a superseded cert", and a
  reissue DID run 2026-07-30 (docs/audit/octavia-reissue-executed-20260730.txt).
  The rack copy is dated 2026-07-31, i.e. AFTER that reissue, and the digests
  agree. The superseded-cert hazard is NOT realized today. It remains OPEN as a
  standing hazard for the NEXT reissue -- nothing enforces the dual update.

  voffice1's clone is at HEAD 48d5ef9 (one commit behind vcloud's 1cdd607). That
  is IRRELEVANT to this comparison: the overlay is gitignored, so it is not
  carried by any commit and its currency is independent of the clone's commit lag.


=====================================================================
4. CLASSIFICATION
=====================================================================

--------------------------------------------------------------------
(A) PRESENT IN BOTH, DIGESTS DIVERGED  --  1 file
--------------------------------------------------------------------
  overlays/vr1-dc0-vips.yaml
    rack  ed19d989e80da8dacd9fe8ff79beb739494ea8abc1951267ea8bb8fb7bb9bb33
          4368 bytes, mtime 2026-07-31T19:48:48
    repo  80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0
          4316 bytes, mtime 2026-08-01 21:29:43
    This is exactly the divergence SWEEP F1 measured; the digests reproduce.
    CAUSE (from F1): the 2026-08-02 session re-rendered the VIP overlay onto GUA
    (26 of 39 v6 legs moved off the retired ULA /64s to f02:20::/f02:21::). The
    rack holds the PRE-GUA version. The rack copy is 52 bytes LARGER and OLDER --
    both consistent with it being the older render, not a rack-side edit.
    CORROBORATION ADDED HERE: voffice1's clone ALSO holds
    80d861560a6b3c52d96f1ca0857924d249a72b41c7e6f32423ca52b36d2d16a0, so the rack
    is the ONLY host in the chain still carrying the pre-GUA overlay.
    NO OTHER FILE DIVERGED. Class (A) is a set of exactly one.

--------------------------------------------------------------------
(B) REPO DEPLOY INPUT, MISSING FROM ~/repo-stage
--------------------------------------------------------------------
The closure was worked out from the artifacts, not assumed. Three tiers.

TIER 1 -- the `juju deploy` closure for vr1-dc0 (runbook Step 4.1/4.2,
          dc-dc-phase4-juju-bundle-per-dc.md:566-571):
    juju deploy ./bundle.yaml \
      --overlay overlays/vr1-dc0-vips.yaml \
      --overlay overlays/vr1-dc0-octavia-pki.yaml \
      ...
  plus every LOCAL path referenced from inside the MERGED input -- which is
  bundle + overlays, not the bundle alone, because a juju overlay can carry its
  own `resources:` block with a local path. The scan was re-run UNCHAINED
  (`grep -nE '(^|[^A-Za-z0-9_])\.{0,2}/[A-Za-z0-9._/-]+' <file>` plus
  `grep -n -A4 'resources:' <file>`) so a path-shaped value that is not a `.zip`
  could not be filtered away, and it was run over ALL THREE scannable merge inputs.

  bundle.yaml -- exactly ONE local file reference:
      bundle.yaml:227-228   resources: { policyd-override: ./policies/overrides.zip }
  (the only other `/`-shaped hits are `:69` prose and `:619` `osd-devices: /dev/vdb`,
  a guest block device, not a client-side file.)

  overlays/vr1-dc0-vips.yaml and overlays/vr1-dc0-machines.yaml -- ZERO local file
  references and NO `resources:` block in either (`grep -n -A4 'resources:'` exits
  1 on both). Every `/`-shaped hit is either a COMMENT (`vips:5`, `:27`;
  `machines:95`, `:110`, `:128`) or a remote apt source
  (`machines:138-180`, sixteen `deb http://10.12.8.4/cloud-archive ...` values --
  the dc0 mirror, a NETWORK endpoint, not a client-side file to stage).
  These two files were NAMED EXPLICITLY on the grep command line; no `overlays/*`
  glob was used, so the PKI overlay could not be swept into a content-reading grep.

  overlays/vr1-dc0-octavia-pki.yaml -- DELIBERATELY NOT SCANNED, and it does not
  need to be: SEC-029 states it carries the Octavia controller CERT and its
  PRIVATE KEY INLINE, so it references no external local file. This is a stated
  exclusion with a reason, not a silent hole in the closure.

  | Tier-1 input                          | on rack? | verdict            |
  |---------------------------------------|----------|--------------------|
  | bundle.yaml                           | YES      | identical (D)      |
  | overlays/vr1-dc0-vips.yaml            | YES      | DIVERGED (A)       |
  | overlays/vr1-dc0-octavia-pki.yaml     | YES      | identical to voffice1 (D) |
  | ./policies/overrides.zip              | YES      | identical (D)      |

  >>> TIER 1 HAS ZERO CLASS-(B) ROWS. <<<
  In particular `./policies/overrides.zip` -- the dependency a prior deploy failed
  on -- IS staged, at the repo's digest 02fe1fd7...e720a011, and the relative path
  `./policies/overrides.zip` resolves correctly from `~/repo-stage` because
  `policies/` was staged as a sibling of `bundle.yaml`. The rack additionally
  holds `policies/domain-manager-policy.yaml` (identical to the repo); bundle.yaml
  does not reference it, so it is a harmless extra, not a missing input.

TIER 2 -- rack-side scripts the runbook invokes, and their transitive `source` deps.
  Computed mechanically (`grep -nE '^\s*(source|\.)\s+'` over every staged script):
    scripts/juju-spaces-check.sh:17  ->  . "$SCRIPT_DIR/lib-net.sh"     STAGED, identical
    lib-hosts.sh / lib-net.sh        ->  source nothing further
  So the Step-3.x spaces gate is CLOSED on the rack: no staged script sources an
  unstaged library. (lib-hosts.sh is staged and unsourced by juju-spaces-check.sh;
  the runbook's own CHECK blocks at :84-85 and :197-198 source both, so its
  presence is correct, not surplus.)

  CONDITIONAL ROW -- `scripts/preflight.sh` AND ITS ENTIRE CHAIN ARE NOT STAGED.
  Runbook Step 3 (`:380`) runs `DC="$DC" bash scripts/preflight.sh`. preflight.sh
  is ABSENT from ~/repo-stage, and so is every gate it shells out to:
      repo-lint.sh, provider-bundle-check.py, channel_assert.py,
      pre-flight-checks.sh, creds-matrix.py, octavia-pki.sh, osd-blank-check.sh
  (`scripts/preflight.sh:12-21,118,155-158,220-239`). preflight.sh also `cd`s to a
  repo root (`:32-33`), which ~/repo-stage is not.
  WHY THIS IS CONDITIONAL AND NOT ASSERTED AS A (B) ROW: the runbook pins Step 3
  to voffice1 -- EVERY block in phase4 is labelled `-- voffice1 --` (`:187, :240,
  :334, :355, :406, :425, :435, :562, :638, :642`), and `:394-397` states outright
  that preflight runs on voffice1 "which is another reason this runs on voffice1"
  because two of its gates fail on vcloud by design. D-138 moved the CLOUD-FACING
  half into the DC. Whether the repo-side gate moved with it is UNRULED: the
  2026-08-01 audit (stage5-juju-client-blocker-20260801.txt:240-249, finding G1)
  recorded these voffice1 pins as STALE w.r.t. D-138 and explicitly declined to
  edit, owing a DOCFIX sized against every voffice1-pinned juju reference.
  I DO NOT RULE IT HERE either. Stated as the fork it is:
    - if Step 3 stays on voffice1, preflight is NOT a rack input and this is a
      non-row (voffice1 has the full clone);
    - if D-138 moves it to the rack, staging preflight.sh alone is INSUFFICIENT --
      it needs a repo root, i.e. a real clone, not more hand-staging.
  `scripts/dc-egress-check.sh` is deliberately NOT a (B) row: preflight `:354` and
  runbook `:487` PIPE it to the rack (`ssh <rack> 'bash -s -- check <dc>' < scripts/
  dc-egress-check.sh`), so it is never expected to be resident.

TIER 3 -- inputs for LATER steps, absent from the rack (genuine (B) rows, low urgency):
  These are the digests a re-stage must land on the rack:

  overlays/dc-dc-ipv6-family-matrix.yaml   3749 bytes
    3ef96844f9d2a2ca4df8b971c03943dc47be2d0316900efd39b25ca0678010ca
    consumed by Step 6 (`:776-780`) -- DRAFTED 2026-07-10, NOT APPLIED to any
    live model (`:767`).
  overlays/dc-ha-scaleup.yaml              13146 bytes
    5f2e7c993143496a64b3a6f17ddf173c2682acd65e14f4b228461ace1330f7a9
    consumed by the later HA step; DELIBERATELY excluded from Step 4 (`:538-541`).
  Neither blocks Step 4. Both WILL be needed on the rack under D-138 and neither
  is on any register that would notice. Recorded so the re-stage can decide
  whether to stage the full overlay set or only the Step-4 set.

--------------------------------------------------------------------
(C) PRESENT ON THE RACK WITH NO REPO COUNTERPART  --  0 files
--------------------------------------------------------------------
  NONE. All 14 staged files resolve to a repo path, and 13 of them to a repo file
  with a matching digest. The one file with no vcloud counterpart --
  overlays/vr1-dc0-octavia-pki.yaml -- is gitignored BY CONSTRUCTION and is
  filed in section 3 against voffice1, not here. There is no stale artifact, no
  hand-made file, and no orphan under ~/repo-stage.
  (Scope note: this class covers ~/repo-stage ONLY. The dc0 edge rebuild left
  other non-repo artifacts in the rack's HOME -- ~/d112c-console-dc0-rebuild.py,
  its log, ~/.ssh/known_hosts.* backups, ~/d112c-bootstrap.php.b64 -- all
  disclosed at dc0-edge-rebuild-20260802.txt:565-585. They are OUTSIDE
  ~/repo-stage and outside this audit's scope; they were not re-measured.)

--------------------------------------------------------------------
(D) PRESENT IN BOTH, IDENTICAL  --  13 files
--------------------------------------------------------------------
  bundle.yaml                          4c8a78527a3100f6...4333a4e550
  overlays/vr1-dc0-machines.yaml       e3be85e41b419486...0e6cbac45e
  overlays/vr1-dc0-octavia-pki.yaml    5fc117f188332042...dad40227f   (vs voffice1)
  policies/domain-manager-policy.yaml  64f99b638a1855b0...c513b63077
  policies/overrides.zip               02fe1fd7fcf07bfc...c2e720a011
  scripts/juju-spaces-check.sh         adb9dbd38a27e663...9f3fbfe7d1d5d
  scripts/lib-hosts.sh                 1a46e949603d5269...439b019320
  scripts/lib-net.sh                   3e465ae7de3bf92d...4ac23eb81f
  scripts/opnsense-api.sh              8c2329f87fe72a93...453b35c905
  scripts/opnsense-bootstrap-apikey.sh c1bd904489fe6e81...85dbbf1b450
  scripts/opnsense-mint-apikey.php     2a85225dc6329524...8e1acca0938
  scripts/opnsense-set-iface-v4.php    ed3c4784e20046aa...1390d8bfdc5a
  scripts/opnsense-set-interface-v4.sh 5dd78f323df0261b...7ad8a4bb7ef
  (full digests in sections 1.4 / 2 / 3; truncations here are for reading only)

  Two of these are worth naming: bundle.yaml 4c8a7852 and vr1-dc0-machines.yaml
  e3be85e4 still MATCH, reproducing what SWEEP F1 recorded at the 08-02 close.


=====================================================================
5. ADJACENT FINDING RAISED BY THE ENUMERATION -- NOT FIXED, NOT MINE TO FIX
=====================================================================
`overlays/vr1-dc0-machines.yaml` EXISTS (repo and rack, identical, e3be85e4),
but runbook dc-dc-phase4-juju-bundle-per-dc.md:527-528 states:
    "Do not interpolate a machines overlay path for `vr1-dc0` -- there is no
     `overlays/vr1-dc0-machines.yaml`"
and the Step-4 dc0 deploy command (`:566-571`) passes only vips + pki. The file
was created 2026-07-29 (its own header, `overlays/vr1-dc0-machines.yaml:3`)
PRECISELY to close a silent-skip hole, and `scripts/preflight.sh:144-145`
unconditionally folds `overlays/${DC}-machines.yaml` into the merged input it
validates when the file is present.

CONSEQUENCE: the P2 gate now validates `bundle.yaml + vips + machines + pki`
while the runbook's Step-4 command deploys `bundle.yaml + vips + pki`. That is
the gate validating a DIFFERENT input than the deploy uses -- the exact defect
preflight's own comment block (`:134-137`) says it was rewritten to eliminate.
The overlay is `applications:`-only and retags nothing (its header), so the
practical blast radius may be nil -- but "may be nil" is not measured, and the
gate/deploy asymmetry is real either way.

NOT DIAGNOSED FURTHER AND NOT FIXED (hard rule 1: findings are logged, not
executed mid-step). It is DOCFIX-shaped and probably shares a bundle with the
D-138 voffice1-pin DOCFIX already owed from the 08-01 audit's G1. Grep for the
next-free DOCFIX-NNN before assigning a number. Do NOT resolve it by deleting
the file or by adding another `[ -f ]` guard -- the file exists to close a guard.


=====================================================================
6. WHAT WAS NOT MEASURED (stated rather than left as a silent gap)
=====================================================================
1. `overlays/vr1-dc0-octavia-pki.yaml` CONTENT. sha256 + size + mode only, on
   both hosts, by instruction and by SEC-029. No line of it was read anywhere.
2. The RACK-side digests of the two tier-3 overlays -- they are ABSENT from the
   rack, so there is nothing to compare. Their REPO digests ARE recorded in 4B.
3. Whether a git clone exists ELSEWHERE on the rack outside ~/repo-stage. Only
   `find ~/repo-stage -name .git` was run this session. Host-wide absence is
   CARRIED from the 2026-08-01 `find / -xdev` measurement, not re-measured.
4. Rack artifacts OUTSIDE ~/repo-stage (section (C) scope note). Not enumerated.
5. dc1's `~/repo-stage`. Out of scope; SEC-029 records dc1's PKI overlay as NOT
   yet copied, and that claim was NOT re-measured here.
6. voffice1's clone was measured for the PKI overlay, the four Step-4 inputs and
   HEAD only. Its full tree was not diffed against vcloud's; its HEAD 48d5ef9 vs
   vcloud's 1cdd607 (one commit) was NOT investigated for content impact beyond
   confirming the four Step-4 digests agree.
7. NO command in this audit was refused by the permission layer. Nothing was
   retried in an altered shape.


=====================================================================
7. DELIVERY NOTES FOR WHOEVER COMMITS THIS FILE
=====================================================================
7.1 -- `bash scripts/repo-lint.sh` FAILS on the pending change set, and this file
  is named in the failure:
    [FAIL] L10 pending change set modifies state-bearing surface(s)
           [docs/audit/: docs/audit/maasdb-pgdump-integrity-dc0-20260802.txt,
            docs/audit/repo-stage-drift-dc0-20260802.txt]
           without touching docs/CURRENT-STATE.md -- GA-R1 rule 8 (C1): a
           status-changing commit updates CURRENT-STATE.md in the SAME commit
    FAIL: repo lint (1 fail, 1 warn, 655 files scanned)
  (The 1 WARN is the known L1 legacy non-ASCII carve-out in
  docs/design-decisions.md, not this file. This file is ASCII + LF.)
  NOT ACTIONED HERE: this audit is READ-ONLY by instruction and does not edit repo
  files. Satisfying L10 is a CURRENT-STATE.md edit in the committing session --
  it is a real obligation, not lint noise, and it must not be worked around.

7.2 -- THE WORKING TREE WAS CLEAN AT 1cdd607 WHEN THIS AUDIT STARTED AND IS NOT
  CLEAN NOW. Concurrent work (not this audit's) has since appeared:
    M  .claude/skills/openstack-cloud-ops/references/platform-traps.md
    M  .claude/skills/openstack-cloud-ops/references/script-authoring.md
    M  scripts/preflight.sh
    ?? docs/audit/maasdb-pgdump-integrity-dc0-20260802.txt
    ?? docs/changelog-20260802-queued-items.md
  This audit created ONLY `docs/audit/repo-stage-drift-dc0-20260802.txt` and
  modified NOTHING.
  DOES THIS INVALIDATE THE DIGESTS? NO, and it was checked rather than assumed.
  None of the files whose sha256 appears in sections 1.4 / 2 / 3 / 4B is in the
  modified list, so every recorded repo digest IS the HEAD-1cdd607 digest.
  `scripts/preflight.sh` IS modified and IS cited by line number in section 4B
  and section 5 -- `git diff -U0` shows the ONLY hunk is `@@ -369 +369,7 @@`, in
  the P6 reminders tail. Every line this document cites (`:12-21, :32-33, :118,
  :144-145, :155-158, :220-239, :354`) is BELOW 369 and byte-identical in HEAD
  and the working tree. The citations stand.

END.
