ThinkRail 0.2.0, released on October 18, adds worktree-based receipts for changes made during an AI coding run. The versioned release notes include turn receipts and a continuous review tab, giving developers a direct route from a finished conversation to the files changed during it.
ThinkRail is an IDE around the pi coding agent. Its 0.2.0 README describes workspaces built from Git worktrees, each with its own branch and working directory. The release targets a practical review problem: an agent's recorded editing calls can miss changes made through shell commands. This article examines the release documentation and implementation notes. We haven't run 0.2.0 or verified its interface.
What the receipt can establish
According to the implementation pull request, the host snapshots the worktree at the start of a run and again when it settles. It stores those snapshots as Git tree objects using a scratch index, leaving HEAD, the normal index and the reflog untouched. Comparing the trees produces the receipt and a diff for that turn.
That captures a formatter's edits or a shell command's file writes even when they don't appear as dedicated editing-tool calls. The same implementation notes explain that the earlier file-change chip relied on tool arguments and missed shell writes, formatters and renames. For a developer investigating an unexpected edit, the snapshot comparison supplies a concrete file-level record.
The boundaries matter. A before-and-after worktree diff records changes within that window, so it cannot by itself assign authorship if someone else edits the same worktree during the run. Nor does a file delta establish that the resulting behavior is correct. Those are limits of what this documented comparison measures, rather than findings from a test of the app.
Single-turn review is read-only
The team's release walkthrough says Review turn opens the changed files together in one scrolling Changes tab. But that single-turn view is read-only. The Keep and Revert controls for individual hunks belong to the branch diff, labelled All changes. Developers can inspect one run's output, then use the broader branch view to act on the patch.
In that branch view, a Keep decision follows the hunk's content: it survives shifted line numbers and expires when the agent edits the hunk again, according to the walkthrough. That distinction prevents a previously reviewed chunk from retaining its approval simply because it occupies the same place in a file.
For anyone trying 0.2.0, a useful check is a small task that also runs a formatter: compare the receipt with the resulting worktree diff, then test the behavior separately. The documented read-only turn view leaves a specific development to watch: whether later releases let reviewers act on a single run's changes without switching to the branch diff.