What
The edit_history table exists in the schema but is never written to. Implement it so the UI (and potentially the bot) can undo/redo mutations.
Changes needed
DB (db/queries.py)
- Write before/after snapshots to
edit_history on every mutation:
upsert_tasks — record old task list as before_json, new as after_jsonupsert_context_entry — record old body / new bodypatch_anchor — record changed fields
- Add
get_edit_history(db_path, table_name?, limit?) query
- Add
rollback_edit(db_path, history_id) — re-applies before_json
API
GET /api/history?table=tasks&limit=20 — return recent editsPOST /api/history/{id}/undo — rollback that entry, broadcast WS update
Frontend
- Undo/redo keyboard shortcuts (Ctrl+Z / Ctrl+Shift+Z) in PlanEditor and ContextEditor
- Or a simple "Undo last edit" button per section
Notes
- Scope to plan tasks and context entries for now (anchors less critical)
- history entries should be scoped to today's session or last N edits — not unbounded
- Bot mutations via
apply_mutations should also write history so bot edits are undoable
What
The
edit_historytable exists in the schema but is never written to. Implement it so the UI (and potentially the bot) can undo/redo mutations.Changes needed
DB (
db/queries.py)edit_historyon every mutation:upsert_tasks— record old task list asbefore_json, new asafter_jsonupsert_context_entry— record old body / new bodypatch_anchor— record changed fieldsget_edit_history(db_path, table_name?, limit?)queryrollback_edit(db_path, history_id)— re-appliesbefore_jsonAPI
GET /api/history?table=tasks&limit=20— return recent editsPOST /api/history/{id}/undo— rollback that entry, broadcast WS updateFrontend
Notes
apply_mutationsshould also write history so bot edits are undoable