video-mode: snap a sliver of selector lead-in forward to the first highlight (main CI flake)

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5

[mmkal]

Follow-up to #40, which fixed the after case. Main still flakes on reveals an expanding textarea one line at a time at its final geometry (1/2 on main's latest run, 3/3 on #39) with the mirror case.

Diagnosed from the CI run's own artifacts (gh run download): the selector trim start lands a sliver before the first highlight (36ms / 92ms / 54ms across the three attempts), so the render opens with ~1 frame of raw footage before the waitFor hold. On a slow runner the screencast starts so late that its very first frames already show the fill's result — the CI raw video is 2.0s long with text present at t=0.04s — so that opening frame is the filled, expanded textarea, one frame before the reveal's empty still:

First six rendered frames from the failing CI run — frame 0 is the filled, expanded textarea; frames 1-5 are the hold with the empty textarea:

A lead-in shorter than the existing fill stabilization window (max(0, timelineOffset) + 3 frames) isn't worth keeping and can't be trusted on a lagging recorder, so the start now snaps forward to the first highlight. Longer lead-ins are untouched; #40's after-case clamp stays.

Runner-timing-specific like #40 — this PR's CI run is the verification. Blocks #39.

🤖 Generated with Claude Code

Session: b7f6f792-6606-44be-9ec3-207eb762c4b6

---

Note

Medium Risk
Changes rendered video trim boundaries for selector-based starts on slow runners; scoped to short lead-ins but affects pixel-accurate video assertions if they depend on exact first frames.

Overview
Extends selector trim start correction in video-mode render finalization: after the existing clamp when trim start lands after a highlight (#40), it now handles the mirror case when trim start sits a short sliver before the first highlight.

If sourceRange.start is within the fill stabilization window (max(0, timelineOffset) + 3 frame durations), it snaps forward to firstHighlightStart instead of keeping ~1 frame of raw screencast. That avoids opening on lagging-recorder frames that already show post-fill UI (e.g. expanded textarea) before a fill-reveal hold.

Longer lead-ins are unchanged; only sub-tolerance gaps are adjusted.

^{Reviewed by Cursor Bugbot for commit 52054c5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[pkg-pr-new]

Open in StackBlitz

pnpm add https://pkg.pr.new/middlewright@41

commit: 52054c5