[foxnne]

Part of fizzy's plans/RECORDING_PLAN.md (fizzyedit/plans#17): step 5's pixi half, which step 6's export needs. Builds against SDK 0.2.29 (historyLine / historyGoTo have been on the document vtable since 0.2.27).

What changes

• historyLine: each step's id (the ones history: pixel changes are recorded as steps, and play back exactly #45 added) and a title from its kind ("Draw", "Reorder Layers", "Rename Layer", …), the undo stack then the redo stack, and how many are applied. version moves with every append, undo and redo, so fizzy asks again only when the line moved.
• historyGoTo(id): undoes or redoes until that step is the last applied (0: before any).
  • It moves quietly, with no "Undo: …" toast for each step on the way (History.quiet). A plain undo or redo still shows its toast.
  • The person's selected layer and sidebar stay as they were. Each undo on the way would otherwise select the layer it touched and switch the sidebar, so an export's rewind left the person on another layer.
  • It refuses while the person has a stroke or a transform open (error.PersonBusy), as pixi.draw waits one out: an undo under an open stroke would leave that stroke's record of what it drew over wrong.
  • A step on the way that fails puts the sprite back where it began, as far as it can, and logs why, rather than leaving it part way.
• line walks the id lists and stacks to the shorter of the two, so a stack pushed to outside append reads short rather than crashing. Clearing the history moves version too.

What it gives a sprite:

• Fizzy's transport (app: undo and redo show a document's transport fizzy#472): undo and redo show the bar, its line scrubs, a held key goes further.
• Exporting its track as a tape (app: a document's track exported as a tape, and played fizzy#478): the export takes the sprite back to where its track began through historyGoTo, writes the file, and comes forward again.

Verified

• zig build against the pinned SDK 0.2.29 and zig build test (4/4).

• After review: the sprite round trip rerun (strokes, a fill, an undo, a stroke, then export, save and play) gave 4 steps, replayed to identical pixel rows.

• In a running fizzy (Debug, fizzy#478's branch, its own profile, driven through the agent plugin's bridge):

  • a 32×32 sprite saved to a file, then two strokes, a fill, an undo, another stroke, and an undo and redo;
  • the transport showed "Draw 3 / 3" with its ticks;
  • fizzy.tracks.export wrote a 646-byte tape of 7 steps;
  • played on the demo stage after saving, the replayed sprite's pixels matched the original's (pixi.read, every layer).

  For that run pixi was built with min_sdk_version lowered to the branch's 0.2.28 and the change reverted: the branch predates SDK 0.2.29.

• Not done: "Layer" and "Animation" name both adding and deleting one; which it is depends on how the change's action reads on each stack, worth getting right in its own change. line/stepsTo/goTo have no tests: History needs pixi's runtime, which zig build test doesn't have.

• Noticed: the agent's "the person changed this sprite" note (commands: an agent hears what the person changed since its last call #46) counted the export's rewind as the person undoing and redoing 4 steps. The rewind runs through undo and redo. It's harmless (it only asks the agent to look again), and the note could ignore moves made while quiet if that matters.

🤖 Generated with Claude Code