D-139 step 2 (input half): VIP overlay onto GUA; both apex readers learn v6 FAMILY ...

overlays/vr1-dc0-vips.yaml is now fully GUA -- 39/39 v6 VIP legs, zero fd50:. The
renderer reproduces it byte-for-byte and provider-bundle-check PASSES with 13
dual-family VIPs.

Both apex readers had to learn family first. Step 1 creates GUA alongside ULA and step
6 retires ULA, so mid-transition every v6-only plane has two /64s under one (role,kind)
key and both readers could only REFUSE -- measured live: derive --dual-family rc 2, and
the gate "cannot evaluate barbican's dual-family vip". render-dc-overlays gains
--v6-family (refuse on ambiguity kept); provider-bundle-check resolves per application
AND per leg, needing no flag at any call site.

A lossy path was found and NOT taken: a full derive drops the 13 per-app comment fields
(4368 -> 3593 bytes). The values file was edited surgically instead: 26 changed overlay
lines, every comment intact. derive being lossy against its own values file is logged.

PROPERTY TRADED, recorded as a loss not a win: the gate no longer catches a wrong-FAMILY
leg -- a ULA leg in the GUA dc0 overlay now PASSES, graded against the ULA band that
exists until step 6. Necessary (dc1 is legitimately ULA) but it leaves D-139 family
conformance checked by nothing. A ruled-table conformance gate is OWED.

Two bugs I introduced were caught by the harness, not review: family inferred once from
the provider leg (GUA in both worlds -- 7 dc1 cases red), then bands resolved once per
bundle instead of per application.

tests/render-dc-overlays 18 -> 23/23 (3 mutations, restore sha256-identical);
tests/provider-bundle-check 55/55; gauntlet ALL GREEN (96); repo-lint 0 fail / 1 warn.
vr1-dc1 untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf

netbox: office1-record dumper (source separation) + current apex snapshot ...

Operator-directed: one dump script per SOURCE so a credential/URL can never be
confused (the token never travels -- read from env).

- netbox/office1-record-dump.py (NEW): READ-ONLY dumper for the office1-netbox
  RECORD -- the VR1 working apex (10.10.1.10:8000, 4.6.4, v2 token). This is what
  every VR1 system actually consumes (DOCFIX-195) and what the dc0/dc1 buildout
  edited -- i.e. the CURRENT in-cloud NetBox state.
- netbox/prod-draft-dump.py: docstring clarified -- it pulls ONLY the FROZEN v1
  reference (netbox.baldurkeep.com), not the working apex.
- tests/office1-record-dump/run-tests.sh (NEW): offline harness 5/5 (slim /
  prefix-scope rewrite / range key / source-target).
- netbox/draft/vr1-office1-current-20260725.json (NEW): the current snapshot --
  139 prefixes / 11 sites (incl. vr1-dc0/dc1/off1), dc1 bands 10.12.64/68/72.0/22
  present; differs from the 90-prefix frozen reference. For the Chat design
  session (NetBox->deploy coupling) which has no live infra.

READ-ONLY: nothing written to NetBox. repo-lint 0-fail.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUjEb7onHpdqFHUnio6iVw

NetBox sandbox seeded from the upstream draft (129 objects) + the two-phase tooling ...

The Office1 sandbox NetBox was EMPTY, and no seeder existed. The documented loop
(upstream draft -> sandbox -> simulate -> feed back) had no first step.

netbox/prod-draft-dump.py   READ-ONLY dump of the upstream draft -> JSON artifact
netbox/sandbox-seed.py      applies that JSON to a SANDBOX. Dry by default.
netbox/draft/vr1-draft.json the reviewable artifact (90 prefixes, 23 roles, ...)

TWO PHASES, deliberately, rather than one source->dest script:
  - the upstream token never travels (dump runs on vcloud; seed runs on
    office1-netbox, where the sandbox token already lives)
  - 'the sim NEVER writes upstream' becomes STRUCTURAL: the script that writes
    has no upstream credential and no upstream URL, and REFUSES to write to the
    instance the draft was read from (self-configuring via the draft's _source,
    so it keeps working if upstream ever moves -- a hostname denylist would not)
  - the JSON is diffable: you can read what is about to be written

Applied to the sandbox: 129 created, then verified idempotent (0 created / 129
present on re-run). vr1-dc0 -> f02::/48 and vr1-dc1 -> f03::/48, matching the
apex exactly, which is what D-117 exists to guarantee.

TWO BUGS FOUND AND FIXED WHILE BUILDING IT:
  1. The dry run mapped only dcim.site scopes, so REGION-scoped prefixes lost
     their scope -- 17 of 90 upstream, including the ENTIRE VR1 region-scoped
     draft. Caught by a spot-check printing 'site None'. Fixed + reseeded
     (--update), now bound to region VR1.
  2. The upstream-refusal guard sat AFTER json.load() and after the banner: it
     was dead code for any malformed draft and READ as safe. Guards go first.
     The harness now proves it actually refuses.

tests/sandbox-seed/: 18/18 PASS. repo-lint 0 fail.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ZBxzAbmqwLW7jEmMG23Xw