Review agent changes with Kranz

Start with the approved scope

Open the mission’s plan and acceptance criteria before reading the diff. Identify the behavior the change should deliver and any boundaries you set: files, dependencies, interfaces, or commands. This gives you a basis for spotting both missing work and additions you did not ask for.

For a health endpoint, for example, the review should cover the response status, JSON shape, and integration test. An unrelated authentication rewrite is a separate scope decision, even if the worker describes it as cleanup.

Compare the diff with the result you wanted

Inspect the mission branch’s actual changes. Follow the code path from input to output, check error handling, and read the tests alongside the implementation. Pay particular attention to changed dependency files, configuration, and permission boundaries.

Then compare the completion report with the diff. Every claim that matters to acceptance should have supporting code or evidence. If the report says a behavior was tested, find the corresponding check and its result.

Read the checks and reviewer findings

Kranz runs contract commands and uses fresh validator sessions to judge milestone work. Scrutiny examines the implementation against the contract; functional review judges captured command results and the relevant criteria. Failed rounds and repairs are part of the record.

Look for the command that actually ran, its outcome, and any missing or skipped checks. A successful process exit is weak evidence if the test filter selected zero relevant tests. For user-facing changes, also check whether the intended interaction was exercised.

Use the validation evidence guide to distinguish command results, reviewer judgments, and missing artifacts.

Check which agents did the work and review

Claude Code is Kranz’s default backend. Codex CLI and other runtimes can be selected by role, subject to model and containment requirements. Run kranz config show to inspect the effective configuration and kranz ready before starting a mission.

A fresh reviewer session does not by itself guarantee a different model family. If you require that separation, configure reviewerIndependence before creating the mission. Approval pins that policy; the runtime checks it against recorded worker attempts.

Containment is a separate constraint. Kranz’s enforced worker sandbox modes currently support the Claude backend. Validators have additional containment requirements, and an unsupported pairing blocks by default. Read the backend guide and reviewer independence policy when choosing roles.

Make the merge decision

When the mission is complete and the evidence supports acceptance, use the dashboard’s Merge action. Kranz reads merge policy from the pinned live base, creates a scratch integration of the mission branch, and runs the applicable checks against that result.

A failure, conflict, or moving branch stops the merge. The worker cannot weaken the checks judging its own change by editing its copy of the merge policy. The base advances only to the tested integration commit.

The merge decision remains yours. Check the merge gate reference when setting repository policy, and keep your normal review and push process around the result.