Reviewing Changes

An agent that edits your files is only as safe as your ability to see what it edited. Qubis gives you two things for that: a thread diff that shows what changed in the thread's git working tree, and worktrees that keep a thread's work off your checkout entirely.

The thread diff

⌘D / Ctrl+D opens it, on a thread whose folder is inside a git working tree. Outside one there is no diff to show.

It is read from git: every file whose working-tree content differs from the base commit, with both sides' text. That has two consequences worth knowing:

• However it was changed. A rename or a deletion run as a shell command shows up like any other change, and so does an edit you made yourself in the editor. Untracked files count; ignored ones do not.
• It is per working tree, not per thread. Two threads on the same checkout see the same changes. To keep a thread's work separate, give it its own worktree.

The base is the merge-base of your branch with its base branch, not that branch's tip, so commits landing on the base after you forked do not read as reverted. Qubis picks the nearest trunk — the remote's default branch, or a branch named in prism.trunk — and Change base in the bar overrides that for the branch you are on.

Committing does not clear the diff: it is measured from the base commit, so work you have already committed on this branch stays in it. That is the point — it answers "what does this branch change", not "what is uncommitted".

How to actually review

The diff is not a receipt to glance at. A short checklist that catches most of what goes wrong:

1. Files you did not expect. A change outside the area you asked about is the single strongest signal something went sideways.
2. Numbers. Units, magnitudes, signs. The agent will confidently write 500 where you meant 500e3.
3. Deletions. Anything removed that you did not ask to have removed.
4. Config the solver reads. A boundary condition, a material, a mesh refinement level — these decide the answer, and a plausible-looking wrong value produces a plausible-looking wrong result.

Worktrees

When the workspace is a git repository, a thread can work in its own git worktree — a separate checkout on its own branch, in a sibling directory — instead of on your working copy.

Turning it on

The worktree toggle appears in the composer of a new, empty thread that is grounded in a git repository. It is not available once the thread has messages — the root is fixed by then — nor on a thread that already has one.

Click it to arm. The chip beside it shows the base branch the worktree will cut from; click that to pick a different one. Qubis resolves a sensible default — the remote's declared default branch if it has one, otherwise main, master, or your current branch — so repositories that default to something else work without surprise.

The worktree is created when you send the first message. Until then nothing has happened, and the toggle resets after that send: it is a deliberate per-thread opt-in, not a sticky preference.

After it exists

Once provisioned, the branch chip becomes an inert label. A worktree's fork point cannot change after the fact, so there is nothing to click.

The thread's root now points at the new checkout. Everything the agent does — edits, commands, solves — happens there. Your original working copy is untouched, and you can keep working in it in another thread.

Cleaning up

Deleting a worktree-backed thread prompts before removing anything, with the option to also remove the worktree and delete its branch. Declining leaves the checkout in place, so work you have not merged is not thrown away by a thread deletion.

When to use one

Use a worktree when:

• You want the agent working on a repository you are also editing.
• You want one thread's changes reviewable on their own. The diff is per working tree, so threads sharing a checkout share a diff; a worktree gives the thread its own.

If something went wrong

• Interrupting does not undo. ⌃C stops the turn; files already written stay written. Check the diff.
• Uncommitted work is not recoverable from Qubis. There is no undo for Git: Discard Changes, and the agent does not keep its own backups. Commit before handing a repository to an agent in a permissive mode.
• A clean checkout is the cheapest safety net. Commit, then let the agent work; git diff and git checkout . remain available whatever happens in the app.