Adopt views-frames 2.0.0 — index type enforcement + CONFORMANCE_FLOOR 2.0.0

[Polichinel]

What changed

views-frames 2.0.0 is the package's first MAJOR. A falsification audit found that the three
frame constructors never type-checked index — they read one attribute off it, n_rows,
and a frame has one. So PredictionFrame(values, another_frame) constructed silently, and the
published assert_summarizer_contract then certified the result: a contract checker
issuing a false pass.

That now raises TypeError. Full decision and migration: ADR-028.

What you need to do

Change the constraint and re-lock. If you pass a real SpatioTemporalIndex — which is what
the type hint has always said — nothing else changes.

What actually breaks

If your code…	Before	Now
passes a SpatioTemporalIndex as index	works	works, unchanged
passes a frame or other object as index	silently constructed	TypeError
passes a non-index to reindex/reindex_fill	AttributeError on _level	TypeError
mutates frame.values in place	silently corrupted buffer-sharing frames	ValueError: read-only
calls map_estimate on inf/NaN draws	bare IndexError	ValueError naming the cause

Only row 4 can plausibly break working code, and ADR-025 already documented that operation as
unsupported. A quick check: grep -rn "\.values\[" src/ — assignments are the ones to look at,
comparisons are fine.

CONFORMANCE_FLOOR moves to 2.0.0

First move since the v1.0.0 freeze. If you assert the floor anywhere, update the expected value.

You are also two releases behind on a real fix

You are pinned to 1.10.2, so you never picked up 1.11.0, which fixed a defect in the
published MAP-containment law: it was wrong on tied draws, failing ~6% of rows on
zero-inflated integer count posteriors — this platform's primary data shape. Moving to 2.0.0
picks that up too.

---

🤖 Filed as part of the coordinated MAJOR bump process (views-frames GOVERNANCE.md, register C-13).

Specific to this repo

pyproject.toml:20:

-views-frames = ">=1.10.2,<2"
+views-frames = ">=2.0.0,<3"

Then poetry lock (your poetry.lock currently pins 1.10.2).

This repo volunteered to adopt the C-88 MAP-containment fix first; that fix shipped in 1.11.0
and this is the release that brings it to you.

[Polichinel]

Pre-flight scan of this repo — this looks like a clean re-lock

Scanned before you start:

✅ No in-place .values mutation

The one row of the migration table that can break working code. Three files mention
.values[:

views_postprocessing/contract/historical.py         reads only
views_postprocessing/contract/frame_extraction.py   reads only
tests/test_hop_b_sink_e2e.py                        reads only

All reads — no assignments. Nothing to change.

✅ No CONFORMANCE_FLOOR assertion

Nothing here pins the floor value, so its move 1.0.0 → 2.0.0 needs no edit.
(views-faoapi does pin it and has one test to update.)

✅ You do not call assert_summarizer_contract

So the checker change does not reach you.

Expected work

1. pyproject.toml:20 → views-frames = ">=2.0.0,<3"
2. poetry lock
3. Run the suite

You also pick up 1.11.0's C-88 fix in the same move — the MAP-containment law was wrong on
tied draws, failing ~6% of rows on zero-inflated integer count posteriors. This repo
volunteered to adopt that first; this is the release that delivers it.

Scanned read-only from views-frames. Nothing in this repo was modified.

[Polichinel]

Blocked upstream — but the risk that mattered is settled

Every published views-pipeline-core release, through the latest 3.1.1, pins views-frames <2.0.0. Measured against PyPI metadata:

3.0.0  views-frames<2.0.0,>=1.10.2
3.0.1  views-frames<2.0.0,>=1.10.2
3.1.0  views-frames<2.0.0,>=1.10.2
3.1.1  views-frames<2.0.0,>=1.10.2

poetry lock refuses the resolution outright. So the pin here is unchanged and this issue stays open — adopting 2.0.0 needs views-pipeline-core to widen first. Two repos changing together, so raising it there is Simon's call.

What was checked meanwhile, so the wait is not wasted

The byte question is answered, and it was the one worth answering first. contract/wire/shard.py emits through views_frames.io.arrow, so a MAJOR could have changed delivered bytes — a three-repo fixture re-vendor, the shape of C-72. Measured in an isolated environment at the pinned toolchain (pyarrow 16.1.0, numpy 1.26.4):

views-frames	emitted shard sha256	equals committed §10 fixture
1.10.2 (control)	203650fd…12c54	yes
2.0.0	203650fd…12c54	yes

All 61 frames-dependent tests pass at 2.0.0 there — including the three byte-parity modules that cannot even run in a drifted local venv.

The other three breaking changes were checked against the code rather than assumed:

change	this repo
index must be a real SpatioTemporalIndex	contract/frames.py passes _pgm_index(...) — safe
frame.values read-only	all three .values[...] sites read; none assigns
reindex type check	not used
CONFORMANCE_FLOOR → 2.0.0	not asserted anywhere

So when the constraint widens this is: change the pin, re-lock, run the suite.

Recorded in tests/fixtures/wire_contract/README.md (#291), beside the existing claim that views_frames is not version-sensitive — which was written for 1.x and now has a MAJOR behind it. So nobody re-opens the byte question later.

Also noted: we are locked at pipeline-core 3.0.1 while 3.1.1 is published. Separate scope, not touched here.