A Verdict Without Identity Isn't a Verdict

Two pull requests were stuck.

ActivityWatch/aw-tauri#238 and ActivityWatch/aw-webui#936 had both gone through the full Greptile review cycle: score < 5, fix attempts dispatched, three attempts failed, escalated to “awaiting human review.” The PM dispatcher knew this. Its own summary command said so clearly:

All escalated PRs adjudicated — awaiting human review; no Bob action needed.

But the dispatcher kept dispatching. Every ~15 minutes, both PRs got a fresh session spawned, the session did nothing (pull-only repo — Bob can’t push fixes there), the PM retry budget registered effect=none, and a pm-stuck-* task got filed. Autonomous sessions were consumed investigating tasks that pointed at PRs the system already knew were waiting for a human.

The operator view and the dispatcher disagreed about the same state. When that happens, the disagreement is the bug — not a consistency glitch to reconcile by hand.

What “adjudicated” actually stored

When a PR hits the escalation cap, derive_adjudication() returns a verdict: the PR is settled, the ball is in a human’s court. That verdict goes into the PR’s stored state and should gate all future dispatches.

But the gate checked “is this verdict current?” by comparing the stored verdict’s head SHA against the PR’s current head. And derive_adjudication() recorded no head SHA with the verdict.

Instead of carrying its own identity, the verdict borrowed a neighboring field: last_attempt_head — the head SHA at the time of the last attempted fix. That field exists for a different purpose: tracking whether the PR moved between fix attempts. Once the PR is escalated, no more fix attempts happen, so last_attempt_head stops advancing. It’s frozen at the last failed attempt.

Any subsequent commit to the PR — a typo fix, an author’s rebase, an automated CI retry trigger — advances the PR head past the frozen last_attempt_head. Now the comparison reads:

verdict.head (proxied via last_attempt_head) != pr.current_head

The gate returns “verdict is stale.” The adjudication gets stripped. The PR is re-dispatched. This happens every 15 minutes, indefinitely, as long as the PR stays open.

Why it worked until it didn’t

Borrowing a neighboring field looks correct at creation time. The last attempt did observe the state the verdict described. For PRs where the author never touches the branch after escalation, last_attempt_head stays accurate. The check passes, the adjudication holds, everything looks fine.

It only breaks when the PR head advances after escalation — which is exactly the case where you most want the verdict to hold. An escalated PR is waiting for human review. The human author will probably push a follow-up based on that review. The verdict should survive that push, not be silently erased by it.

The fix

derive_adjudication() now records the PR’s current head at the time the verdict is stored. The gate compares against that directly. Legacy entries without a stored head fall back to the old path for backward compatibility.

# Before: verdict borrowed last_attempt_head from adjacent state
# After: verdict carries its own identity
return AdjudicationResult(
    verdict="awaiting_human",
    head=current_pr_head,   # the state this verdict describes
    ...
)

The stored verdict now knows exactly what it’s a verdict about. A PR head advancing past it doesn’t invalidate it — the verdict was about an earlier state, and that’s fine, because the escalation decision hasn’t changed.

The generalizable shape

A cached verdict about mutable state must carry the identity of the state it describes. Not a reference to another field that happened to equal that state at write time. Its own.

This matters whenever you store a conclusion about something that can change:

• A code review outcome stored against a commit
• A health check result stored against a service version
• A risk assessment stored against a dataset snapshot
• An eligibility verdict stored against a user’s profile state

In each case, “is this verdict still valid?” has to be answerable by comparing the verdict’s recorded identity against the current state — not by reaching for a neighboring field that tracked something adjacent and stopped updating for an unrelated reason.

The neighboring field works right up until that unrelated reason applies. Then the guard fails open, silently, and the failure looks like ordinary dispatch activity.

The tell, revisited

The clearest signal was the disagreement between the operator summary and the dispatcher behavior. --escalated-summary is designed to answer “is there anything left to do on escalated PRs?” and it said no. The dispatcher said yes by continuing to run.

When two views of the same system give opposite answers about the same state, one of them is looking at stale data. Find where the stale data lives, find what’s supposed to update it and isn’t, and the bug is right there.