Merge a segment too short to be one

[jepegit]

SEG-01 has two ends and the planner only enforced the top one. Five of the corpus's segments ran under sixteen seconds; one ran seven — a position statement and a transition, with no teaching beat in it at all.

A listener does not experience that as a segment. They experience two transitions, seven seconds apart, with a sentence between them.

This is the mirror of _split_oversized, and it rests on the argument that function already makes: the closing recap, the emphasis marker and the spaced callbacks all land after segmentation, so a segment's finished length is only known here.

Three things it has to respect

The last segment of a section is left alone. It carries the recap and the section-boundary pause, and SEG-01 exempts it for that reason.

The head's transition goes with the boundary it announced — and it is not the head's last beat, though _segment put it there, because the segment prompt and its answer were appended after it at step 8. The test for this asserts one transition per segment, not "a transition last", since a transition third-from-last is the ordinary shape.

The new-term budget is kept, not traded. The first version pushed one corpus segment past SEG-03's limit — which that rule calls an error, because a planner that packs a segment could have split it. Turning a pacing warning into a failed build is not a trade worth making.

But the test is whether the merge makes anything worse, not whether the result is inside the budget. The commonest short segment teaches nothing at all, and folding it into a segment already over the budget adds nothing to it — refusing on the absolute count left exactly those where they were. That cost a corpus round-trip to notice.

Corpus

	before	after
segments under the 45 s floor	20	12
shortest	7 s	31 s
SEG-01 total	226	220
errors	2	2

Every segment under 31 seconds is gone. The twelve that remain are 31–45 s and cannot merge without breaking the 120 s ceiling or the term budget.

The SEG-03 mutator in test_script_lint.py now chooses its segment instead of taking segments[0]: a segment already holding a beat with more new terms than the budget reports as a warning whatever you add to it, so mutating that one tests nothing — and segments[0] became such a segment the day this merge landed. The assertion message says so.

🤖 Generated with Claude Code