v0.19.3 — markers land where you asked

Fixed — markers on trimmed clips landed early by the in-point

A marker's start is in its host clip's local time, which begins at the host's start (source in-point), not at zero. Every writer path except auto_at_cuts dropped that term: a marker written "at 12s" onto a clip trimmed 2s into its source sat at 10s in Final Cut Pro. The parser handed the same raw value back to list_markers, snap_to_beats, diff and the HTML preview, so the round trip through this server agreed with itself and nothing noticed.

• _find_spine_clip_at_seconds returns start + (target - offset)
• Marker gains timeline_start (resolved by the parser for clip and connected-clip markers) and a position property, which every reader now uses
• scenes_to_markers inherits the fix
• tests/test_marker_time_frame.py covers write, parse, round trip, interval markers, and a mutation check that an old-convention marker now reads 2s early

Changed — autopush covers every write

FCP_MCP_AUTOPUSH=1 was documented as "every write also imports into Final Cut Pro" and wired into four handlers. It now lives on the journal seam: journal.finish() returns the FCPXML outputs a request actually wrote, and each is pushed — through flat and grouped calls alike, for all write handlers. push_to_fcp is never pushed twice; CSV/JSON/mp4 outputs are recorded but not imported.

Verification

1675 tests across 60 suites. Four passes: mcp floor 1668 pass / 7 skip · mcp 2.x 1669 / 6 · FCP_MCP_INDEX=off 1644 / 31 · no ffmpeg on PATH 1650 / 25.

Deferred to the next minor (planned, not patched in)

xfade crossfade compilation and lane compositing in preview_render; splitting server.py's flat handlers into tools/; an operation Protocol shared by XML and Live; Timecode → TimeValue unification.