Merge-risk assessment

This gate answers one question, and only this question: does a human need to be in the loop for this change?

It is not a second code review. It does not look for bugs — the reviewer already did that, and the security gate will do its own pass. Risk is orthogonal to correctness: a perfectly correct change to an authorization boundary is still high risk, and a sloppy typo fix is still low risk. Keep the two apart. A risk assessment that drifts into re-reviewing the code is a risk assessment nobody trusts.

Unlike the other gates, merge-risk is not a hireable role. It is a ritual — run it whether or not any particular role is staffed.

Step 1 — Resolve the change and its head sha

Read sous.config.yaml and backends/code/<configured code host>.md.

Call code.get_head_sha. The verdict is bound to this exact commit. A risk rating for an older commit is worthless: the diff it rated no longer exists.

Step 2 — Dispatch two independent raters

Dispatch both as separate subagents. Do not rate it yourself, and do not let one rater see the other's answer. The whole value is that two different lenses disagree; if they share context they converge, and you have paid for two opinions and received one.

Give each code.get_diff and code.list_files, and exactly one of these briefs:

Rater A — architecture and blast radius

Rate this change low, medium, or high risk based on what it touches and what depends on that, not on whether the code looks correct.

Escalate for: schema or data migrations; authentication, session, or authorization logic; anything that changes who can read or write what; shared code with many callers; public API or contract changes; anything that runs on every request or every startup; destructive or irreversible operations; changes to the gate or merge machinery itself.

Ask: if this is wrong, how much breaks, how loudly, and how fast can it be undone? A change that fails obviously and reverts cleanly is lower risk than a quiet one that corrupts data.

Rater B — change precision

Rate this change low, medium, or high risk based on how surgical the diff itself is.

Escalate for: large diffs; diffs that mix refactoring with behaviour change; changes with no accompanying tests; changes touching many unrelated files; deletions of code whose purpose is unclear; changes that brush authorization, credentials, or destructive operations even incidentally.

Ask: could a reviewer hold this entire change in their head at once? If not, that is itself risk, regardless of how good the code is.

Each rater returns a level and two or three sentences of reasoning. Nothing else.

Step 3 — Reconcile

The joint verdict is the more conservative of the two. A joint verdict is not a vote, and it is not an average. If A says low and B says high, the verdict is high.

This is deliberately asymmetric. The cost of over-escalating is that a human clicks merge on something safe. The cost of under-escalating is an unreviewed change reaching production. Those are not comparable, so do not treat them as if they are.

If the two raters disagree by two levels, say so explicitly in the comment — that gap is usually the most interesting thing in the assessment, and it is often where the real risk is hiding.

Step 4 — Post the verdict

Comment via code.comment with:

• The verdict, and what it means: low means an agent may merge once the other gates pass; medium or high means a human must merge, regardless of what any other gate concludes.
• Both raters' levels and reasoning, attributed, including any disagreement.

End with the marker, rendered per the backend's marker.write:

sous-gate: merge-risk-low sha=<head_sha>

using -low, -medium, or -high as decided.

Then apply labels per config: merge-risk:<level>, plus a blocking needs-human-merge:<level> label for medium and high.

Applicability

There is no not-applicable case for a code change. Every change has a risk level, including a trivial one — that is the point of rating it rather than assuming.

Documentation-only changes may be rated low without dispatching raters. Say that is what you did.

Rules

• Never rate a change you implemented. Dispatch the raters.
• Never round down. When genuinely torn between two levels, take the higher one and say why.
• Never post a marker for a sha other than the current head.
• Do not report bugs here. If a rater spots one, note it as an observation and say it belongs to the reviewer gate — then rate the risk anyway.