Revision history: change sets, revisions, and revert (#48)

The undo substrate. The agent is going to act freely — "empty the garlic bed and
plant cucumbers" runs without a confirmation prompt — and that is only a
defensible default if the result is easy to roll back. So undo lands before the
agent write path, not after it.

The unit of undo is the OPERATION, not the row. A change set groups the
row-level revisions it produced; revert replays their inverses. Emptying a bed
and replanting it touches one object and many plantings, and undoing half of
that is worse than useless.

Two properties shape the rest:

Revert is itself a change set (reverts_id names its target), so history is
append-only and an undo can be undone. git revert, not git reset.

Revert is version-guarded per entity. Every snapshot carries the row's version;
if something edited that row after the change set being reverted, restoring the
old snapshot would silently discard the newer edit, so it is reported as a
conflict and left alone while the rest of the change set still reverts.

The auto-scope is what keeps this invasive but shallow. Service mutations call
record(), which joins the change set on the context if one is open and otherwise
opens a single-op one on the spot. REST handlers needed no edits at all and
every UI mutation lands in history for free; only the agent wraps a whole turn.
Multi-row operations (FillRegion, ClearObject) pass all their changes in one
record call, so a 12-plop fill is one change set with 12 revisions and one undo.

Revisions are buffered and written with their change set in a single
transaction, so an operation that fails partway leaves no half-recorded history.
Recording is best-effort after the fact: the row is already written, so failing
the caller there would report a failure that didn't happen and invite a
duplicate retry. A gap is logged loudly instead.

Two sharp edges handled explicitly rather than by luck:

Deleting an object cascades its plantings away at the FK level, where the
service never sees them. deleteObjectRecording snapshots them first, or the
delete would be listed in history and not actually be undoable.

Restoring deleted rows reuses their ids, and a restored plop needs its object
back first. planRevert runs three explicit passes — restore parents then
children, then updates, then delete created children before their parents —
instead of trusting reverse-seq ordering to happen to be right.

Garden deletion stays out of scope, as designed: the cascade is invisible to the
service and ON DELETE CASCADE would take the history with it. The history UI
will say so rather than pretend otherwise.

Closes #48

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ

internal/store/migrations/0006_revisions.sql

@@ -0,0 +1,53 @@
+-- Revision history: the undo substrate (#48).
+--
+-- The unit of undo is the OPERATION, not the row. "Empty the garlic bed and
+-- plant cucumbers" touches one object and many plantings; undoing half of that
+-- is worse than useless. So a change_set groups the row-level revisions it
+-- produced, and revert replays their inverses.
+--
+-- Two properties this schema is built around:
+--   * Revert is itself a change set (reverts_id points at its target). History is
+--     append-only and never rewritten, so an undo can be undone. git revert, not
+--     git reset.
+--   * Every revision carries full JSON row snapshots INCLUDING version, which is
+--     what the revert guard compares against so a later edit is reported as a
+--     conflict rather than silently clobbered.
+--
+-- JSON snapshots rather than a shadow table per entity: the rows are small,
+-- household scale makes storage a non-issue, and one code path covers all three
+-- entity types.
+--
+-- Deliberate gap: garden DELETION is not revertible. Dropping a garden cascades
+-- its objects and plantings without the service ever seeing them, and the
+-- ON DELETE CASCADE below would take the history with it. The history UI says so
+-- rather than pretending otherwise.
+CREATE TABLE change_sets (
+    id           INTEGER PRIMARY KEY,
+    garden_id    INTEGER NOT NULL REFERENCES gardens (id) ON DELETE CASCADE,
+    actor_id     INTEGER NOT NULL REFERENCES users (id) ON DELETE CASCADE,
+    source       TEXT    NOT NULL CHECK (source IN ('ui', 'agent', 'api')),
+    summary      TEXT    NOT NULL DEFAULT '',
+    agent_run_id TEXT,                                   -- executus run id when source='agent'
+    reverts_id   INTEGER REFERENCES change_sets (id),    -- set when this change set reverts another
+    created_at   TEXT    NOT NULL DEFAULT (strftime('%Y-%m-%dT%H:%M:%SZ', 'now'))
+);
+
+-- The history panel's only query: one garden, newest first.
+CREATE INDEX idx_change_sets_garden ON change_sets (garden_id, created_at DESC);
+
+-- "Has this change set been reverted?" — the list marks reverted entries, so the
+-- lookup by target must not be a scan.
+CREATE INDEX idx_change_sets_reverts ON change_sets (reverts_id) WHERE reverts_id IS NOT NULL;
+
+CREATE TABLE revisions (
+    id            INTEGER PRIMARY KEY,
+    change_set_id INTEGER NOT NULL REFERENCES change_sets (id) ON DELETE CASCADE,
+    seq           INTEGER NOT NULL,                      -- order within the change set
+    entity_type   TEXT    NOT NULL CHECK (entity_type IN ('garden', 'object', 'planting')),
+    entity_id     INTEGER NOT NULL,
+    op            TEXT    NOT NULL CHECK (op IN ('create', 'update', 'delete')),
+    before        TEXT,                                  -- JSON row snapshot; NULL for create
+    after         TEXT                                   -- JSON row snapshot; NULL for delete
+);
+
+CREATE INDEX idx_revisions_change_set ON revisions (change_set_id, seq);