Ratify RULE G and RULE N; the CLI on cw; RULE G's compile half

[thorwhalen]

628 tests on 3.12, 545 on 3.10. Both owner questions ratified, the CLI lands on cw, and RULE G's compile half is built.

Ratified 2026-09-02

• RULE G — burns stays separate and gains a looks-backed ffmpeg backend. looks owns the compile side; burns samples its BurnsPath and runs the argv. Dependency points burns → looks, legal because looks is stdlib-only; the reverse stays forbidden.
• RULE N — looks owns normalisation, exactly as already shipped in Look.target.

looks.motion — RULE G's compile half

Keyframes in, an ffmpeg fragment out. No easing, no sampling, no camera decisions, and no burns import — a window is anything with .x/.y/.w/.h in burns' normalised convention, so the structural type is the seam.

$ looks motion 0:0,0,1,1 2:0.25,0.25,0.5,0.5 --output 1920x1080 --fps 30
zoompan=d=1:s=1920x1080:fps=30:z='1/(1+(-0.5)*min(...))':x='iw*(...)':y='ih*(...)'
$ looks motion 0:0,0,1,1 2:0.25,0.25,0.5,0.5
this path zooms, so it compiles to `zoompan`, which needs output and fps. …
$ echo $?
1

A recorded fleet fact, overturned by measurement

muvid._crop_filter's docstring — propagated by two of this package's own research notes into a warning aimed at the burns owner — says "Not zoompan: its expression vocabulary has no t at all, and it duplicates frames on video input."

Both premises are true. The conclusion does not follow:

claim	measured on ffmpeg 8.1
no t	true — and in_time/it both work. ffmpeg -h filter=zoompan lists no variables at all, which is likely how the fact came to be half-complete
duplicates frames	true at the default d (1800 out for 20 in), exactly 1:1 at d=1

Meanwhile the filter the notes recommended instead cannot do the job: t is not in scope for crop's w/h and the filter refuses to configure — reproduced in three invocation forms. That is stronger than this repo's own earlier note, which recorded it as "evaluated once … produced 60 frames of unchanged size". Nothing renders. A Ken Burns path is a zoom by definition, so it has exactly one compilable form.

muvid's own code is fine — it compiles a pan, the case where crop is right and simpler. Filed as reeleehq/muvid#68; the burns adapter is reeleehq/burns#12.

Three more traps, each a silent wrong answer

Which is why each is a refusal rather than a doc note:

• x/y are in original input pixels, not zoomed — the two readings score 60.5 dB and 6.3 dB against a crop+scale reference. The first implementation here had it wrong, and it configured cleanly.
• fps silently retimes — fps=25 on a 10 fps source keeps all 20 frames and turns a 2.0 s clip into 0.8 s, so a frame-count check passes. Required, never defaulted.
• zoom is clamped at 10 — z=10 scores 54.4 dB, z=12 scores 13.2: not a worse rendering of the window asked for, a correct rendering of a different one.

The tests ask ffmpeg, not the strings

String equality passes for a fragment ffmpeg refuses and for one that renders the wrong picture — both happened here. So each fragment is built a second way by hand and compared with ffmpeg's own psnr: a static window is bit-identical to the crop it names, a zoom is >45 dB from its crop+scale equivalent, and the two filters' clocks agree frame for frame. The threshold isn't a knob — correct pairings score 54–60 dB, nearest wrong ones 6–13.

Full transcript: docs/research/00f_motion_filters_evidence.md.

The CLI is cw

MIT, dependencies = [], and — verified in a fresh interpreter — import cw pulls in nothing beyond stdlib. So looks neither imports the LGPL package nor hand-rolls argparse.

cw could not read Sequence[str] (argh recognises list and nothing else), so looks check scale eq lut3d bound one token — quietly, since the parser builds and --help looks right. Fixed upstream in i2mint/cw#36: modern_decode now reads the collections.abc interfaces, with str/bytes excluded by construction (matching on typing.get_origin, which is None for both) rather than by special case — they are registered Sequences, so an issubclass test would have made every string parameter variadic.

Two of this package's own guards caught me

• test_every_runtime_extra_has_a_ledger_row refused the new [cli] extra: "an extra is a conveyance decision, not a convenience list." cw has a ledger row now, with both observations dated.
• The pin over §5.7's table refused a silently-grown ledger, so the row is in the decisions document too.

Reading the declaration on both legs

CI went red on 3.10: tomllib is 3.11+. The obvious fix — skip — is what the other guard already did, and finding that is what made this a real fix: the guard that refuses an undeclared conveyance had been reporting "skipped" on half of CI since it was written. A skip reads as a pass.

looks/tests/_pyproject.py reads the file on every version. It is deliberately not a TOML parser — a hand-rolled reader is normally a liability, agreeing with the real one until the day it quietly doesn't. What removes that is test_pyproject_reader.py: on every interpreter that has tomllib (one of CI's two legs, every run) the reader is checked against it over the real file, every table and every key, in both directions. Never trusted, only checked — against the same bytes the 3.10 leg reads.

importlib.metadata was the tempting alternative and is wrong: measured, it reports Provides-Extra: ['dev', 'docs'] — no cli — because an editable install's dist-info is a snapshot of install time. A licence guard reading that would have said the extra does not exist.

Verified on a real 3.10 interpreter: both guards now run there.

Also

__version__ resolves on first access (PEP 562). Eager resolution cost 50 ms of import time — importlib.metadata pulls in email.parser — for a value most callers never read. 54.5 ms → 38.6 ms, pinned by a test asserting email.parser is absent after import looks.

https://claude.ai/code/session_01CnXLihXKG9jfvygHvgKVpX