steveandClaude Opus 4.8
42246fd6b7
Found by running the real thing: the agent replaced a bed of garlic with cucumbers, Undo restored the garlic correctly — and then said "Nothing left to undo — this was already reversed." The revert response carries the change set commitScope just inserted, and that row has no per-op tally: Counts is populated by the history LIST query, not by the insert. describeUndo treated a zero tally as "nothing happened", so a real undo with eight revisions behind it reported itself as a no-op. Telling someone an action did nothing when it just worked is about the worst thing a safety feature can say, because the obvious next move is to do it again. Fixed on both sides. The client now treats a NULL change set as the no-op signal, which is what the server actually means by it — an empty tally is not the same thing and must not be read as one. And RevertChangeSet now fills in the counts, so the revert response and the list read describe the same change set the same way, and a partial revert can say "2 of 3" from either. The unit test missed it because the fixture I wrote populated counts, so it was testing my assumption about the response rather than its actual shape. The new tests pin the real thing: the service asserts a revert's counts match the fill it undid AND match what the list read reports, and the client asserts an empty tally still reads as "Undone." Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Claude-Session: https://claude.ai/code/session_01H3zbym8Doka2d7D48maSgZ