Phantom Phantom · use cases
Review agent work like you wrote it.
Agent speed only helps if review stays cheap. Phantom checkpoints every turn on every seat, gives you per-file and per-hunk accept and reject, and records the decision. Fleet proposals wait in a local inbox until the machine owner applies them.
Interactive review
Every turn has a before and an after.
Before every agent turn, on every seat, Phantom writes a checkpoint ref and writes another after the turn. The Changes pane is a file tree with unified or split diffs, and every control previews before it applies.
Per-turn checkpoints
Checkpoints live under refs/ashlr/checkpoints/<chat>/<turn>/<root>/pre and a matching post ref. A turn with no changed paths gets no checkpoint, and the pane says so.
Accept and reject per file or hunk
Reject restores from the checkpoint; a file reject needs a second click, and a hunk that moved is refused rather than silently applied.
Source: docs/VERSE.md
Undo, rewind and redo preview first
Undo turn, rewind to before turn N and redo always preview; apply is refused if anything changed underneath, and refused while any overlapping chat has a turn running.
Source: docs/VERSE.md
Decisions are recorded
Every checkpoint and decision lands in ~/.ashlr/verse/checkpoints/<chat>.jsonl with 0600 permissions. ASHLR_VERSE_CHECKPOINTS=0 in the server's environment turns checkpoints off entirely.
Source: docs/VERSE.md
Evidence links to source lines
Cited files in a chat open in context: web searches, docs, wiki pages and shared memory appear beside the tools and context the agent reported for the turn.
Source: docs/VERSE.md
Lessons are approved knowledge
A lesson is used only after approval, matched and applied within a 16 KiB cap that drops whole notes. An unmatched lesson changes nothing: prompts stay byte-identical.
Source: docs/VERSE.md, lessons
Fleet review
Proposals wait for the owner. Merges pass gates.
The inbox stays local
Fleet proposals sit in the machine's local inbox until the machine owner reviews and applies them. A teammate's fleet writes only to repos enrolled on their own machine.
Source: docs/TEAM.md
Verified means the exact tree
The fleet's GitHub App posts the ashlr/verify check only when verification passed on exactly the tree it proposes, never on a nearby commit.
Source: docs/STANDING-AUTHORITY.md
“Plan verified” is a bounded claim
It means the outcome's active tasks have verification or explicit gate evidence. It is not an independent proof of the whole desired result, which stays yours to check against your acceptance criteria.
Source: docs/AUTOMATIC-OUTCOMES.md
A different family judges
Gate G6 requires a judge whose family is not the producer family: local work goes to a Grok judge, Grok work to a Claude judge. The same vendor never marks its own homework on the cloud lane.
Honest boundary: review surfaces show what the tools reported and what verification ran. They do not prove intent, and protected paths always go to a human.
Try it
Open a project, run a turn, inspect the diff.
npm i -g @ashlr/phantom phm verse
First turn walkthrough: docs/QUICKSTART.md
Keep going