Unify cel editing in the timeline

docs/lane-handoff.md

@@ -1,11 +1,12 @@
 # Lane and cel handoff
 
-Status (2026-09-30): the lane model is implemented through its commands, its
-first two views, and correction authoring. Cels are ordinary nodes with their
-own playback clock; the timeline draws them as one row and the cel sheet draws
-frames down and lanes across. Both views issue the same commands. Rotation and
-position corrections can be authored as Constant, Ramp, or Return motion on a
-lane or cel, survive regeneration, and expose conflicts for removal or retry.
+Status (2026-10-01): the timeline is the one timing interface. Cels are ordinary
+nodes with their own playback clock and appear as blocks on one row per drawing
+lane. Blocks move by mouse; edge drags trim without overlap; Shift-right-edge
+drags ripple every later cel; and the center of a shared cut composes the two
+edge edits into a rolling edit. Linked audio follows picture moves while its
+edges remain independently trimmable. Rotation and position corrections survive
+regeneration and expose conflicts for removal or retry.
 
 The commits beginning at `3d3c1bb` are the argument for the model and are worth
 reading before touching what they did — they are the design record, more than
@@ -53,8 +54,6 @@ on purpose: the layout names the RULE — children follow one another and may no
 overlap — and a group carrying it is called a lane. `node/lane?` is where they
 meet.
 
-The second view is the CEL SHEET, not the exposure sheet.
-
 ## Decisions already made — do not re-litigate
 
 These were each argued out and are load-bearing. Changing one is a design
@@ -86,23 +85,23 @@ decision, not a cleanup.
 - **A cel is not a row.** Rows, expansion and selection are editor state. The
   document has never known about rows and must not learn.
 
+## Current timeline interaction
+
+- Creating a symbol inside an aimed drawing lane creates a one-frame cel at the
+  playhead. Drawing a polygon uses the existing cel there or creates the same
+  one-frame cel when the frame is empty.
+- Dragging a cel body moves it. A linked audio node follows a picture move;
+  moving or trimming the audio itself remains independent.
+- Dragging a right edge changes its endpoint. Growth consumes adjacent spans
+  instead of overlapping them. Shift-drag inserts or removes lane time by moving
+  every later cel by the same delta.
+- At a shared boundary, the left and right hit zones trim one side. The center
+  is a rolling edit: right-edge resize followed by left-edge resize at one frame.
+- Split, trim-in, and trim-out are direct buttons and are disabled without an
+  editable selected span. Movement is a mouse gesture, not a toolbar command.
+
 ## Next steps, in order
 
-The cel sheet now supports rectangular selection by pointer drag, Shift-click,
-and Shift-arrow, plus an editor-local clipboard (Cmd/Ctrl C/X/V). Paste
-overwrites the destination rectangle, including copied gaps, and reuses drawing
-symbols. Partial cels retain their local clocks, playback and corrections.
-Delete clears frames without closing time. Each cut, paste or clear is one
-history transaction. The clipboard belongs to the mounted sheet and current
-document; it is not a system clipboard interchange format.
-
-A selected held cel has a bottom-right resize handle. Dragging previews its new
-extent and commits one ripple edit on release; Escape cancels. Overflow uses
-the existing explicit shot-extension retry. Rectangle edits currently require
-lanes on the sheet's clock and paste must fit within the shot and available
-columns. Insert-paste, moving rectangles, and repeating multi-cel patterns with
-the handle remain future work.
-
 The implemented correction slice and its remaining UI limits are recorded in
 [Correction authoring](correction-authoring-plan.md).