# PR#62: after three rounds of RED, werkrevisor asks a human

> **WARNING:** This document describes only the change applied in this PR.
> It may already be outdated once the next PR is merged.
> Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

## The Problem

RED holds a PR until a new commit lifts it; no human can override it.
Since PR#51 and PR#53, Jev can give RED for a very likely risk and a confirmed finding,
and since 2026-10-08 this runs for werkator and werkprobe.
A wrong RED, e.g. from a classifier that misjudges a file, cannot be lifted by the author:
the coding agent commits again and again, and the PR never reaches a human.
The design of 2026-10-08 limits these rounds and then escalates to a human.

## Non-Goals

- No override of RED: after the limit, the PR stays blocked; the human decides how to go on,
  e.g. to restructure the PR, or to fix a wrong classification in its own PR.
- No check whether a commit really lowers the risk; each new head counts as a round.

## The Scenarios

### Feature: after three rounds of RED, werkrevisor asks a human

#### Background

- **Given** `[gate] max_red_rounds = 3` and a human reviewer in `[gate] human_reviewers`

#### Scenario#62.01: the fourth RED in a row asks a human

So that a PR that the author cannot fix does not wait forever.

- **Given** werkrevisor rated the three earlier heads of the PR RED, one after the other
- **When** the review of the new head is RED again
- **Then** the review stays RED
  - **and** a reason says that the automatic rounds end and a human decides
  - **and** werkrevisor requests the review of the human reviewer

##### Verified by

- [test_red_rounds: test_the_fourth_red_in_a_row_asks_a_human](../../tests/test_red_rounds.py)

#### Scenario#62.02: fewer rounds give RED as before

So that the author gets the rounds to fix the PR first.

- **Given** werkrevisor rated two earlier heads RED
- **When** the review of the new head is RED again
- **Then** the review is RED without escalation and without a review request

##### Verified by

- [test_red_rounds: test_fewer_rounds_give_red_as_before](../../tests/test_red_rounds.py)

#### Scenario#62.03: a head without RED starts the count anew

So that an old problem that was fixed does not count against a new one.

- **Given** werkrevisor rated three earlier heads RED, and then one head GREEN
- **When** the review of the new head is RED
- **Then** the review is RED without escalation

##### Verified by

- [test_red_rounds: test_a_head_without_red_starts_the_count_anew](../../tests/test_red_rounds.py)

## The Solution

- `[gate] max_red_rounds`, host only, default 3; 0 never escalates.
- werkrevisor counts the earlier heads of the PR in a row whose own result comment is RED.
- From the limit on, a RED review gets the reason `red_escalated` and requests the human reviewers.
- The README names the key; docs/werkrevisor.werkbaum marks the node as merged.
- werkrevisor 0.29.0.

## Prerequisite PRs

- PR#61: werkrevisor 0.28.1, merged.