steveandClaude Opus 4.8
b4f3181aef
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
54 lines
2.9 KiB
SQL
54 lines
2.9 KiB
SQL
-- 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);
|