# render-baseline -- frozen reproduction fixtures for the per-DC overlay renderer

**Captured 2026-07-27, deliberately, BEFORE the value reconciliation that destroys them.**

## Why this exists

The strongest available test of a generator is: *does it reproduce a known-good artifact
byte-for-byte?* When the per-DC overlay renderer (D-136) is built, that test needs a
known-good artifact to diff against.

Right now one exists. `overlays/vr1-dc1-vips.yaml` is hand-authored, reviewed, passes
`scripts/provider-bundle-check.py`, and is consistent with `bundle.yaml` octet-for-octet.
So is the VIP set inline in `bundle.yaml` (the pre-extraction dc0 baseline).

**Both are about to stop existing in this form.** The ruled changes ahead:

- **R11** (D-020 AMENDMENT, 2026-07-27) adds `vault` at octet `.61` and `designate` at
  `.62` -- 11 applications become 13.
- **R2** (D-101 ruling note, 2026-07-27) makes every VIP DUAL-FAMILY -- each three-address
  string becomes six.
- The 2026-07-25 symmetric-overlay ruling extracts dc0's VIPs out of `bundle.yaml`
  entirely, so the base bundle becomes VIP-free.

After those land there is **no known-good artifact left to diff a renderer against**, and
the renderer's first output would be its own first draft -- unverifiable. That is precisely
the objection D-136 raises against its option (A): "its first output has nothing to diff
against."

So the validation window is open now and closes at reconciliation. These files hold it open.

## What is frozen

| Fixture | Content | Provenance |
|---|---|---|
| `fixtures/vr1-dc1-vips.v4-11app.yaml` | byte-identical copy of `overlays/vr1-dc1-vips.yaml` | `cp`, hash-verified equal to the live file at capture |
| `fixtures/bundle-vips.v4-11app.txt` | the 11 `app -> vip` rows inline in `bundle.yaml` | extracted via `yaml.safe_load`, not by grep -- so YAML semantics, not text shape |

`SHA256SUMS` pins both.

Live-source hashes **at capture time** (a historical fact -- these WILL diverge, by design,
and divergence is NOT a failure):

```
3f93ecb3205cea8b303f5b2cbbbde343a2762156575277ca84684369da8bf896  overlays/vr1-dc1-vips.yaml
7d6261c55d50f36261bda751bd2159a8508c9c3696313fbc37fafabd6728b219  bundle.yaml
```

**`bundle.yaml`'s hash above is now HISTORY and will not re-verify** -- ruling 3's VIP
extraction (2026-07-29) removed all 11 inline `vip:` lines and dropped `placement`'s
then-empty `options:` block. That is the divergence this section says is by design; the
values themselves moved intact to `overlays/vr1-dc0-vips.yaml` and are unchanged, proven
by `provider-bundle-check` returning a line-for-line identical verdict across the move.
The `vr1-dc1-vips.yaml` hash is still live-current and IS reproduced by the renderer (T6).

## How the renderer is meant to use these

Two-step validation, in this order. The point is that only DATA changes between the steps,
never renderer code, so any diff is attributable:

1. **Reproduction.** Feed the renderer a values file derived from TODAY's literals. It must
   emit `fixtures/vr1-dc1-vips.v4-11app.yaml` byte-for-byte. This proves the mechanical path
   -- template, ordering, quoting, comment handling -- against a known answer.
2. **Evolution.** Feed it the reconciled dual-family 13-application data. Now the output is
   new, but the machinery that produced it has already been proven against a known answer.

Doing step 2 without step 1 is how you ship a renderer whose output nobody can check.

## What the harness asserts, and what it deliberately does NOT

`run-tests.sh` asserts the **integrity of the frozen fixtures themselves** -- that they still
match `SHA256SUMS` and are still structurally what they claim to be.

It deliberately does **NOT** assert that the fixtures match the live `overlays/` or
`bundle.yaml`. They are a historical snapshot; live is *supposed* to move away from them.
An assertion against live would turn this harness red the moment the reconciliation lands
-- punishing the very change it exists to support. That trap is on the record here: a test
that asserts a literal finding string turns the gauntlet red when the finding is remediated
(`tests/creds-matrix` T24). When the renderer lands, ADD its reproduction case; do not
repoint these assertions at live files.

## Shelf life

The fixtures are permanent. Their *usefulness* as a reproduction target ends once the
renderer has been proven against them -- after that they are provenance, showing what the
pre-dual-stack v4 artifact looked like and that the renderer could reproduce it.

Do not "update" them to match new artifacts. If a new baseline is wanted, add a new fixture
alongside with its own date and app-count in the filename.