chore(deps): lift the views-frames cap to <4 — measured, not assumed (#324)

pyproject.toml

@@ -17,7 +17,25 @@ python = ">=3.11,<3.15"
 # import the SDK unguarded. Without the extra the FAO delivery fails **at import**, not
 # at runtime, and inside a dependency rather than in our own code. Register C-07.
 views-pipeline-core = {version = ">=3.0.0,<4.0.0", extras = ["appwrite"]}
-views-frames = ">=2.0.0,<3"
+# Widened from `<3` on 2026-11-02 (#324, filed from views-models). The cap was not
+# harmless: views-models' pod runners require views-frames >= 3.0.0, so `<3` meant this
+# repo could not be installed alongside the ensemble lane that produces its input.
+#
+# Why 3.x is safe for us is recorded ONCE, in `tests/fixtures/wire_contract/README.md` —
+# the home of the byte question, already carrying the 1.10.2 and 2.0.0 measurements in the
+# same series. Short version: the MAJOR's behavioural change is in `views_frames_reconcile`,
+# which this repo does not import, and the arrow writer is byte-identical across the
+# boundary. **Read that file before raising this pin again.** It names the check to run and
+# the control that tells you the check is working — the first draft of this change offered
+# a pathspec that silently matched nothing.
+#
+# **views-frames 3.x is not reachable alone:** pipeline-core 3.3.0 caps
+# `views-frames <3.0.0`, so the lock moves pipeline-core 3.3.0 -> 3.4.0 with it. Both are
+# inside the ranges already declared here. The floor stays at 2.0.0 and pipeline-core's at
+# 3.0.0 deliberately — (frames 2.x + pipeline-core 3.3.x) is still a coherent resolution.
+# The lock moves rather than staying at 2.0.0 so CI asserts this ceiling instead of
+# leaving it a claim.
+views-frames = ">=2.0.0,<4.0.0"
 pyarrow = ">=16.1.0,<17.0.0"
 
 # pytest was never declared here; it arrived transitively through pipeline-core, which

tests/fixtures/wire_contract/README.md

@@ -46,6 +46,34 @@ fixture — but it does require proving that, the same way.
 equal the committed fixture (`203650fd…12c54`) — measured in an isolated environment at the
 pinned toolchain (pyarrow 16.1.0, numpy 1.26.4), where all 61 frames-dependent tests also
 pass at 2.0.0. So the views-frames 2.0.0 adoption (#286) is **not** a fixture re-vendor. It
-is blocked only by views-pipeline-core, every published release of which (through 3.1.1)
-pins `views-frames <2.0.0`. Recorded so the byte question is not re-opened when that
-constraint widens.
+was blocked only by views-pipeline-core, every release published at the time (through
+3.1.1) pinning `views-frames <2.0.0`. Recorded so the byte question is not re-opened when
+that constraint widens.
+
+**That constraint has since widened, and the byte question was re-opened and answered the
+same way (2026-11-02, #324).** Regenerating with `scripts/build_wire_fixture.py` under
+**views-frames 3.0.0** at the pinned toolchain (pyarrow 16.1.0) reproduces **all five
+artifacts byte-identically** — `SHA256SUMS` is unchanged and the arrow shard still hashes
+`203650fd…12c54`. Expected, because `views_frames/io/arrow.py` is byte-identical between
+`v2.0.0` and `v3.0.0`, and because the 3.0.0 MAJOR's behavioural change is confined to
+`views_frames_reconcile`, which this repo does not import. (The MAJOR does also touch
+`views_frames/conformance/__init__.py`, which moves its published `CONFORMANCE_FLOOR` to
+3.0.0 — inert here, since nothing in this repo reads that constant.) The full suite passes
+at that version on Python 3.11 — 527 passed, 3 skipped, 41 xfailed, 0 failed — with the
+lock also moving views-pipeline-core 3.3.0 -> 3.4.0, since 3.3.0 was the release that
+still capped `views-frames <3.0.0`. So 3.0.0 is not a fixture re-vendor either, and the
+pin is now `>=2.0.0,<4.0.0`.
+
+**If you are the next person raising this pin, run the check like this.** views-frames
+uses a **src layout**, so the pathspec needs `src/`:
+
+```
+git -C <views-frames> diff v2.0.0..v3.0.0 -- src/views_frames/io/     # empty  -> arrow.py is unchanged
+git -C <views-frames> diff v2.0.0..v3.0.0 -- src/views_frames/        # NOT empty -> the control
+```
+
+**Run the second one too.** `git diff` prints nothing and exits 0 for a pathspec that
+matches no file in either tree, so `-- views_frames/io/` (no `src/`) comes back empty
+whatever changed, and reads exactly like a pass. The first draft of this very paragraph
+quoted that form as its proof. The control line is what tells you the command can still
+speak — if it is also empty, your pathspec is wrong, not the tree.