command.batch kept its steps in one interaction of the document active
when it began and journaled itself by committing that interaction. A
step that opened, closed or reverted a document broke both: the switch
cancelled the interaction (throwing away the steps so far), and the
commit then ran in the new document, which had none, so the batch was
never journaled and a replay was missing the new document. An error
after the switch rolled back only the active document.
- Each step runs inside an interaction of the document active when it
starts; a switch leaves it open while a batch runs, so every document
the batch edits gets one undo step when it succeeds.
- The batch journals itself, whichever document it ends in.
- On error everything rolls back: documents the batch opened close, the
ones it closed or reverted come back (Session::batch_stash), each
one's interaction is undone, and the active document and the
Untitled-N count go back too.
- DocState::keep_interaction / undo_interaction share the undo-step and
rollback code with commit_interaction / cancel_interaction.
- Tests: a batch that opens a new document is journaled, replays to the
same documents and keeps one undo step in each; a failed batch closes
the document it opened and restores the one it closed; a failed batch
brings back a document it reverted.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Session::note_journal only kept values noted by the top-level command, so
a command run as a step of command.batch lost them: a save in a batch
stamped File Info's modified date from the clock without recording it,
and object.scale's strokes/corners came from the preferences again on
replay. Replaying such a journal a second later (or with other
preferences) gave a different document.
- Session::execute_step runs a batch step with its own journal notes
(note_depth) and returns its params with what it noted; command.batch
writes those params into its step of the batch's journal entry (steps
that note nothing stay as given).
- journal_for_action strips the replay-only dates from a batch's steps
too, so an action recorded with one still dates the document when it
plays.
- Tests: a save in a batch records its date and a replay with the
recorded date moved lands on it, while an action leaves it out; a scale
in a batch records Scale Strokes & Effects and replays alike with the
preference off.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
File Info's dates come from the clock, so documents made or saved a second
apart differed: journal_replay_reproduces_document and
rich_fixture_satisfies_invariants_and_undoes_to_blank failed at random.
One approach for every clock-derived date: it is a command input that
defaults to now, and the journal records the value used.
- file.new takes created? and document.save / file.saveAs take modified?
(Unix seconds, or null for none; default now), through date_param /
clock_date on the one save path (save_with), so Save, Save As and the
UI's save stamp alike; Save a Copy still leaves the dates.
- Their journal entries always record the date used, so replaying the
journal makes the same document whenever it runs. Actions recorded from
the journal (Session::journal_for_action) leave those dates out, so
playing an action later dates the document then.
- Test fixtures date their documents fixtures::CREATED, and the MCP
property test dates its local document as the headless one, so
documents built at different moments compare equal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
