v0.3.1

Answers #1.

The panel was implying the shell changed nothing. DSH reaches for bash far more often than for the editor tools. Measured over eleven real sessions on one machine the split was bash 12, write 3, read 1, with str_replace_editor and edit never called at all. A panel that lists only the editor tools was quietly claiming every one of those bash calls was a no-op.

The count is a count, never a path. A bash tool/result carries no meta at all, where write carries meta.diffs, so which files a shell touched is not knowable from the event stream. Commands that look like writes are counted and the panel says how many are missing, with the button marked incomplete. Paths are never guessed, on the same reasoning that keeps a refused write out of the edit total.

Detection is conservative on purpose, since a notice that fires on every session is one nobody reads. Redirects are matched with quoted spans blanked out, so echo "a > b" does not count, and /dev/null and descriptor merges are excluded. Audited against the real bash calls in those eleven sessions, three flagged and all three wrote, nine quiet and all nine only read.

Also clamps the panel back inside the window when the notice makes it wide enough to run off the right edge. That is the third layout fault here and the third one only a live session could show.

stateVersion goes to 2, so v1 checkpoints are discarded rather than forward-applied without the new field.