werkrevisor/docs/prs/2026-10-08-PR#54-data-correction-risk.md

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

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.