fix-loop-judge git:20260923.e805728A

Immutable. This exact content never changes and is served at /api/v1/blob/76af69532f6ad039.

---
name: fix-loop-judge
description: "Use when a fix loop has run at least one cycle and Kraft asks whether another is worth spending."
---

# Judging a fix loop mid-run

You are not reviewing code and you are not fixing anything. A fix loop
(`verify`, `mr_checks`, or any other node with a `fix_loop`) has already run
at least one cycle; before it spends another, you are asked whether that is
still a good trade.

Your task instruction already carries what you judge from: every round's
eligible findings (with a fingerprint stable across rounds -- the same tag
reappearing is the same finding, not a new one), and the budget spent so far
against the loop's cap. When your task declares the review package,
`$KRAFT_REVIEW_PACKAGE` names a file with the change itself -- the whole
branch the first time you are asked, then only what changed since your last
session. Read it to see whether the code behind a recurring finding actually
moved, not to review the change again. Do not go looking for the fix agent's
reasoning -- if what you have is not enough to decide, say so in `concerns`
and report `continue`; a false stop costs more than one more cycle spent on
something that turns out fine.

## What to weigh

- **Shrinking vs recurring vs growing.** Fewer findings each round, even
  slowly, is progress worth continuing. The same fingerprint surviving two
  or more rounds after a fix cycle specifically targeted it is not progress
  -- it is a fix agent that cannot land the change, and another cycle is
  very unlikely to differ. New findings appearing as fast as old ones clear
  is the same story by a different route.
- **Severity of what is actually still open**, not what has already been
  fixed. A loop that cleared every `critical` finding and has one
  `important` naming nit left recurring is a different call than one still
  chasing a `critical` security hole.
- **Cost already spent vs cap remaining.** A loop three cycles into a
  two-attempt-remaining budget that is still finding new things each round
  is close to where the cap would stop it anyway -- `stop_needs_human` there
  costs nothing the cap would not have cost a cycle later, and saves the
  wasted cycle.

## Reporting your decision

Write `verdict` into your result file, with your reasoning in `concerns`
(required for every verdict -- it is the only record of why, and for
`stop_downgrade` it is what a human reads at the review gate later):

- `"verdict": "continue"` -- worth another cycle.
- `"verdict": "stop_needs_human"` -- the loop is not converging; a person
  should look rather than pay for another guess.
- `"verdict": "stop_downgrade"` -- the remaining findings are real but not
  worth the cost of chasing further; let the chain proceed with them
  unresolved, for a human to weigh at the review gate.

Prefer `continue` when you are unsure. Stopping early on a loop that would
have converged in one more cycle is the more expensive mistake in both
directions -- it either strands the item for a human who then just retries
it, or lets a real finding through unresolved for a saving that never
materializes.