# PR#54: a change that can corrupt persisted data needs 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

The risk categories of PR#46 ask about security, transactions, migrations and more,
but not whether a mistake in the change would leave wrong data behind.
A mistake in code that only reads data disappears with the fix, unless it handed out data of others.
A mistake in code that writes data can corrupt many records before anyone notices;
an audit log helps, but many corrections of data are tedious.

## Non-Goals

- No ORANGE for this category: it says that a mistake would be expensive, not that there is one.
- No such category for the TypeScript frontend; there, `form_data_integrity` covers wrong data sent to the backend.

## The Scenarios

### Feature: a change that can corrupt persisted data needs a human

#### Scenario#54.01: a change that very likely writes persisted data gives YELLOW

So that a human checks a change whose mistakes would need corrections of existing data.

- **Given** the risk template for Java or Kotlin backends
- **When** Jev rates a changed main-code file as very likely to write data that would need corrections after a mistake
- **Then** the review is YELLOW
  - **and** the reason names the category and the file

##### Verified by

- [test_risk: test_a_change_that_very_likely_writes_persisted_data_gives_yellow](../../tests/test_risk.py)

## The Solution

- `jvm-spring-backend` gets the category `data_correction` with `action = "yellow"`, `yellow_min = 0.85` and no `orange_min`.
- The README names the category; docs/werkrevisor.werkbaum marks the node of this PR as merged.
- werkrevisor 0.26.0.

## Measurement

On 2026-10-08 Jev answered two candidate questions for each main-code file of the 25 merged hs.hsadmin.ng PRs #281 to #316,
for about 0.01 USD.
The question "would the effect of a mistake remain after the fix" never reached 0.8, so it is not used.
The question of this PR rated the files that write data highest:
the import of the bank directory (#307, 0.90), the table of the bank directory (#302, 0.86),
the grants of the RBAC system in SQL (#310, 0.85; #289, 0.84), and a deployment tool (#306, 0.91).
Files that only read data, tools, build files and documentation stayed low, e.g. a repository query in #300 with 0.07.

From 0.85 on, 4 PRs need a human: #306 and #310, which needed one before, and #302 and #307, which did not.
The question does not separate the critical PRs of 2026-10-06 from the others,
since those were labelled by security and weakened checks, not by data that a mistake could corrupt.

## Additional Changes

- docs/werkrevisor.werkbaum: two planned nodes for the statistics dashboard, as asked on 2026-10-08:
  the tables per day, week and month count pull requests and show the cost per pull request,
  and a trend chart between each heading and its table shows the cost per period, the cost per pull request
  and the number of pull requests.
- docs/werkrevisor.werkbaum: the cause of the slow reviews, found with the seconds per phase of PR#51,
  and a planned node to keep MiniMax M3 within its timeout.
- tests/test_risk.py, tests/test_doccheck.py and tests/test_risk_with_issue.py:
  the test classes added after the `__main__` block move before it, so that a direct run of the file executes them.

## Prerequisite PRs

- PR#53: werkrevisor 0.25.0, merged.