|
Render-pipeline step 4: the renderer, reproducing a reviewed artifact byte-for-byte
scripts/render-dc-overlays.py. Two stages, split exactly where forward item F2 froze the interface: `derive` (apex + lib-net.sh -> a per-DC values file) and `render` (values -> overlay text). `render` is PURE -- no apex, no network, no clock -- so it is offline-testable and a future CI job re-runs only `derive`. ORDER INVERTED BY MEASUREMENT. The plan was ruling-3's VIP extraction first. Three read-only agents measured two facts that reversed it: the byte-for-byte reproduction window is still open (the live dc1 overlay is still identical to the frozen fixture) and closes on its own when the R2/R11 reconciliation lands; and the extraction's blast radius is far larger than ruling 3's "2 commits" -- it breaks the phase-01 deploy gate (juju deploy runs only on 11/11/0), the Octavia SAN derivation, preflight in two places, and 8 of 30 harness cases. Better done BY the renderer, so dc0's overlay is a validated output rather than a hand edit. A TEXT emitter, not yaml.dump: a round-tripper destroys the comment header, normalises the quoted vip scalar, and imposes its own key order -- all three are load-bearing bytes. Two things are INPUT rather than invented: the 12-line comment header (lifted verbatim via --from-overlay, so a reproduction run is honest about which bytes the tool actually generates) and the ascending-octet emission order (sorting by name reproduces nothing). The ruled app->octet map is READ with ast out of dc-plane-apex-import.py rather than restated as a second drifting copy. RESULT: output hashes to 3f93ecb3..., identical to both the committed overlay (1634 bytes) and the frozen fixture. PROVEN ABLE TO FAIL, not merely observed passing -- three seeded faults all fail the compare (wrong octet, dropped header, dc0 prefixes against the dc1 artifact). THE ARITY WORK PAID FOR ITSELF WITHIN THE HOUR. The first dual-family output was malformed: the values file stores each v6 /64 base with trailing colons stripped, and the emitter joined with a single colon -- 2602:f3e2:f03:11:50, not a valid address, and it still looks like one. provider-bundle-check, fixed yesterday for exactly this class, rejected all 13 applications. Locked by T13/T13b. End to end: apex -> values -> renderer -> overlay -> gate. The dual-family dc1 render with R11's ruled-but-unbuilt apps produces 13 VIPs, all dual-family, PASSING provider-bundle-check --dc vr1-dc1 including the new hacluster invariant. Nothing committed has been regenerated by it yet. tests/render-baseline gains T6, the reproduction case its README invited -- ADDED, with T1-T5 deliberately not repointed at live, and comparing against the FIXTURE because live is supposed to diverge. T6 proven able to fail by making the renderer sort alphabetically. New harness 17/17; render-baseline 10/10 (was 9); gauntlet ALL GREEN (85) on vcloud, manifest re-recorded after the drift gate correctly caught the addition; repo-lint 0 fail / 608 files scanned. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HvCyrwvYTTcDYnRErfMsNf |
|---|
|
|
| docs/CURRENT-STATE.md |
|---|
| docs/changelog-20260728-vip-arity-gate.md |
|---|
| render/values/vr1-dc1-vips.yaml 0 → 100644 |
|---|
| scripts/render-dc-overlays.py 0 → 100755 |
|---|
| tests/HARNESS-MANIFEST |
|---|
| tests/render-baseline/run-tests.sh |
|---|
| tests/render-dc-overlays/run-tests.sh 0 → 100755 |
|---|