Fast Screencasts That Fit the Run
Quick replay clips now scale their length to the size of the run they show.
Gantry can replay one of its own build runs as a screencast — a short, fast-forwarded video of the work scrolling past. The quick-capture path, `record-fast`, always produced a clip of one fixed length, whichever run it was recording. A run of a couple of sprints and a run of many got the same number of seconds, so a large run felt rushed and a small one dragged.
This job taught the fast path to size the clip to the run. When the operator has not pinned the timing themselves, the recorder now reads how many sprint-sized units the recorded run contained, multiplies by a per-unit rate carried in the timing profile, and clamps the result into a sensible band — a longer run gets a longer clip. The fixed length stays as the fallback for when adaptive scaling is switched off or the unit count cannot be read, and any explicit timing choice still wins outright.
Build
The work split into a standalone, deterministic length calculation and the command wiring that consumes it — so the calculation could be proven in full isolation before any recording path depended on it.
The dividing line the plan drew ran between the arithmetic and its use. The first sprint added the adaptive keys to the timing profile and a single function that turns a unit count into a clamped target length, with nothing calling it yet. Because that function takes a count and returns a number, it could be tested exhaustively — floor, ceiling, middle, zero units, an absent per-unit rate, one-sided bounds, even an inverted min/max — without a recorder, a run, or a video in existence. Fixing the calculation as deterministic and fully covered first meant the second sprint could rely on it without re-checking the arithmetic.
The second sprint connected that calculation to the `record-fast` command, where the harder question is not the arithmetic but the precedence: adaptive scaling must apply only when the profile enables it and the operator supplied neither an explicit fixed-seconds value nor an explicit timing profile, and a missing, unreadable, malformed, disabled, or zero-unit read must fall back to the fixed path rather than fail the recording. That is a table of override rules, and it was written against a calculation whose behaviour was already pinned, so the sprint's tests could concentrate on which path wins rather than on whether the target came out right.
Both sprints went through execute, gate, and review with no repair and no re-plan. The ordering is why the run stayed clean: the second sprint never had to find a defect in the first, because the first shipped with its own proof. The cut placed the part that reasons about run state and operator intent behind a component whose numbers were already trustworthy, which is exactly the piece a fresh agent could build without holding the rest in its head.
Feature
Fast screencast recording now derives clip length from the recorded run's unit count, with the old fixed length demoted to a fallback; the profile keys, the calculation, and the command routing are all still in place at HEAD.
Before this job, `record-fast` had one duration for every run: the fixed target length in the fast timing profile. A recording could not reflect how much work it was showing, and there was no way to ask it to, short of passing an explicit seconds value each time.
The answer is in three parts, and all three are present in the tree today. The `fast` profile carries new keys — a per-unit rate and an optional lower and upper band — documented in place with a note that omitting the rate restores the old fixed behaviour. The timing module parses those keys as ordinary optional scalars and exposes an adaptive-target helper that returns a clamped length from a unit count, or nothing when scaling is off or the count is zero. The command layer reads the resolved run's sprint count, asks the profile for a target, and routes the computed length through the same temporary-profile path already used for a fixed seconds value, so no second recording mechanism was introduced.
The precedence and fallback the design promised are visible in the command's own tests: an explicit seconds value beats adaptive scaling, an explicit timing profile bypasses it, and a read failure or a zero-unit run falls back cleanly. The usage text and the screencast documentation both describe the adaptive default and its overrides, and both still read that way at HEAD. Nothing later folded this into a larger recording path — the fast clip's length is still computed exactly where this job put it.