Releases: sjh9714/dsh-what-changed
Release list
v0.4.0
Finishes #1.
Reads the workspace against HEAD. Counting the shell writes in 0.3.1 was the honest floor. Naming the files is what was actually asked for, and that needs a different source than the session log, because a shell's tool/result carries no file information at all.
The two readings stay separate on purpose. They disagree in both directions and each disagreement is information. git sees what a shell wrote and the fold cannot. The fold sees a write that was later reverted, and a refusal, and git cannot. One merged number would hide both.
The projection stays a pure fold. This is a host service and one route, POST /what-changed/worktree, behind the same fences dsh-git-graph puts on its own: loopback only, POST only, application/json only, and the browser-named path canonicalized and matched against the workspace registry before git runs anywhere. It only ever reads.
Porcelain fixtures are transcribed from real git output, not guessed. Under -z a rename spends two status fields, the new path in the record and the old path bare after it, and numstat prints an empty inline path for a rename and spends two more. A binary file's - counts are dropped rather than reported as zero, since zero would say it did not change.
Verified in a live session. The agent ran echo > NOTES.md, sed -i and rm README.md, all through bash. The panel admits three unnameable shell writes, and git names README.md deleted, greet.js modified +1 -1, and NOTES.md untracked. The route's fences were exercised against the running server: a path outside the registry is refused, GET is 405, a non-JSON content-type is 415.
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.
v0.2.2
First release verified in a real dsh web session against a real model.
What the live run confirmed
- the button mounts in the session header and the count tracks the agent live
- the numbers match what the agent actually did
- restarting
dsh weband reopening the session gives the same counts, so the fold is recomputed from the persisted log - the expanded view shows the hunk the tool actually applied, not the call arguments
- switching the language setting reskins the button and panel on the spot
Fixed, all three found only by running it
- the panel had no positioned ancestor, took the flex header's static-position corner and floated off the top of the window
- right-anchored at 680px it then ran under the workspace sidebar and clipped the paths
- the English summary read "1 files · 1 edits"
Added
- zh/en dictionaries through the shell's locale seat, with zh as the key-set source of truth and en typed against it
- CI on Linux, macOS and Windows, which immediately caught a Windows-only build failure (
await importof an absolute path readsd:as a URL scheme) - a build assertion that every import surviving in the host bundle is declared, after
zodshipped as a devDependency and broke a barenpm install