Two rules, and I had conflated them. Generation obeys the VAE's 4n+1 — 93, 173 and
333 are whole LongCat segments, which is what the dataset builder and the township
templates use. TRAINING is stricter: SimpleTuner's longcat_video family rounds DOWN
to 8n+1 (frames % 8 == 1) and says nothing about it.

So a job asking for 93 trained at 89, the config recorded 93, and frame_problems()
validated the generation rule and passed it. Three places agreeing on a number that
was not the one being used.

training_frames() now applies the same rounding SimpleTuner does — verified against
its adjust_video_frames() for every count from 0 to 400 — and the job is adjusted
BEFORE validation, so a legal clip length is never rejected for being legal in the
other sense. The adjustment is emitted to the progress stream and the log:

  num_frames 93 -> 89 (8n+1)

frame_problems() now states the training rule and explains why the number looked
valid, rather than asserting a constraint the trainer does not use.

Found by reading SimpleTuner's model.py while answering a question about whether
clips are needed at all — not from a failure. It would have shipped as a quiet
discrepancy between the configured and actual frame count.

23 tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY