# Worktrees, verification and results

> Inspect a Crew candidate and its evidence, understand guarded checkout mirroring, and keep saved work, verified completion, integration, and release distinct.

Source: https://kaitoi.io/docs/cli/crew-results/
Section: Kaitoi CLI / Subagents and Crew
Written for: Anyone reviewing or integrating a Crew result.
Prerequisites: A Crew run to inspect
Last reviewed: 2026-10-24

---

A Crew result can contain useful saved work without satisfying the task yet.
Inspect the candidate identity, verification, blockers, and checkout state
before integrating it. This guide covers CLI **0.9.0**.

## Read the report and the evidence

```text
/run status
/run result
/run evidence
```

Confirm the intended run and repository. Look for the run branch and candidate
commit, changed files, exact verification commands, their results, reviewer or
tester findings when configured, and any unresolved blocker or waiver.

A candidate saved from a stopped build can be explicitly **not yet verified**.
Likewise, a successful check covers only the behavior that check exercises.
Read the evidence against the acceptance criteria rather than equating a zero
exit code with a complete product outcome. Review is optional unless configured;
do not assume every run contains an independent reviewer.

## Understand where the work lives

Crew works in a private Git worktree. By default, it can also **mirror changes
into your original checkout as unstaged files**. Mirroring leaves the checkout's
index, HEAD, and branch unchanged; it copies eligible Git-visible new, changed,
or deleted paths, not ignored environments and caches.


Crew's candidate lives in a private worktree. The optional default mirror copies
eligible changes to the original checkout as unstaged files, without moving
HEAD or the index. Each path must still match its base or last mirrored content.
An operator edit or unsafe checkout change stops mirroring while private work
can continue. Earlier copied files may remain. Inspect the mirror notice and
copied-work state before switching branches or discarding files.

The matching empty-state.ts hunk has already copied to both locations. An operator edit changes search.ts in the original checkout, closes the mirror gate and preserves that edit; the private candidate and earlier copied hunk remain.

*Figure: Private work and checkout mirroring are separate. A stopped mirror can have copied some files already.*

The mirror checks each path against the expected base or last copied version.
Your own edit, a new commit, a branch switch, or an unsafe copy can stop the
mirror for the rest of that run. Private work can continue. Read
`checkout_mirror.state`, its notice, and whether work was already copied.
“Stopped” does not mean the original checkout is untouched.

Use `--no-mirror` for a direct run, or disable checkout mirroring in the start
proposal, when you want the result kept out of the original checkout. This
does not cancel work in the private run. Ordinary subagent worktree isolation
has a different lifecycle and no default Crew mirror.

## Inspect preparation and limits too

Verification can depend on dependency preparation, lockfiles, network scope,
and permitted lifecycle scripts. A failure in preparation is different from a
failed product test. Review the effective authority and commands actually used.

Budgets also have practical limits: provider token or cost information may
arrive only after an activity completes, and unknown cost stays unknown.
External engines use their own accounts. Do not infer a guaranteed total charge
from the presence of a token or cost bound.

## Integrate deliberately

Compare the candidate to its base, inspect any mirrored unstaged files, and
preserve your own newer work. Do not blindly switch branches over a partly
mirrored checkout. Use the reported branch and commit as the identity of the
candidate, and resolve overlaps before integration.

Configured verification acceptance, your review, a merge, and a deployment are
different milestones. A completed Crew run does not itself publish a release
or establish that deployed behavior works. Keep the run and evidence available
for follow-up, particularly when a held attempt needs a bounded continuation.