[Polichinel]

views-frames = ">=1.0,<2" → ">=1.10.2,<2". Lock moves 1.6.0 → 1.10.2.

Why this needed checking rather than just doing

views-frames is on the byte-producing path. wire/shard.py:34 writes every Hop-B shard through views_frames.io.arrow.save, and the §10 golden fixture is generated the same way. A bump there is a candidate ADR-013 contract event — the thing epic #181 held frozen for eleven stories.

Verified, in a clean venv at the pinned pyarrow

Built a throwaway venv with pyarrow 16.1.0 (the pinned version — not this machine's 23.0.1) and views-frames 1.10.2, then re-ran the fixture generator and compared every artifact:

MATCH  fixture_run_0__lr_ged_sb__m000543.arrow.parquet
MATCH  fixture_run_0__lr_ged_sb__m000543.tap.zip
MATCH  fixture_run_0__lr_ged_sb__manifest.json
MATCH  fixture_run_0__manifest.json
MATCH  fixture_run_0__sidecar.parquet

All five byte-identical. SHA256SUMS unchanged, fixture bytes untouched, contract_version still 1.5.

The same venv runs the full suite: 312 passed, 0 failed.

A useful side-confirmation

The five failures seen on this machine are purely pyarrow 23.0.1 against the <17 pin (C-72). At the pinned version they disappear entirely. That has been asserted all session as "known-acceptable, CI authoritative" — this is the first time it has been demonstrated directly rather than inferred from CI staying green.

Compatibility

views-frames 1.10.2 declares pyarrow>=14,<20 for its arrow extra. Our >=16.1.0,<17.0.0 sits inside that. Lock diff is one package plus a docs extra that appeared in the new release's metadata; pyarrow does not move.

Fixture README corrected

It named views_frames 1.0.0 as a pinned tool version — stale (the lock had said 1.6.0 for weeks) and conflating two dependencies. It now says which one is version-sensitive and what evidence supports the claim:

pyarrow is the version-sensitive one; views_frames is not. … the fixture was generated under 1.0.0, CI has reproduced it continuously under 1.6.0, and 1.10.2 was verified to regenerate all five artifacts byte-identically before the pin was raised. Raising it again does not require regenerating the fixture — but it does require proving that, the same way.

That last sentence is ADR-014 §1 applied to the next person doing this.

🤖 Generated with Claude Code