Risk Red-Flagging
Pullminder red-flags a pull request before it merges when the change touches files with a history of trouble, or when an author is changing fragile code for the first time. Unlike Collective Memory (which only displays context), red-flagging contributes to the risk score and can fail the check.
What feeds the red flag
Section titled “What feeds the red flag”Red-flagging adds two deterministic signals to the risk score, both derived from Collective Memory:
Incident history
Section titled “Incident history”Files that have been hotfixed or reverted before raise the score. The signal is weighted by how recently the last incident happened — a hotfix last week counts far more than one last year. This operates at the file level: if a touched file has a prior hotfix or revert in its history, that history contributes to the score.
Author context
Section titled “Author context”A PR raises the score when its author has never touched a file that has prior incidents (no familiarity with fragile code), or when a large change comes from a single author with no second reviewer.
These join the change-shape signals Pullminder already scores: diff size, files changed, sensitive paths, and missing tests. See How risk scoring works.
Category overlap and incident similarity
Section titled “Category overlap and incident similarity”Beyond file history and recency, Pullminder also raises risk when the kind of problem a file had before shows up again. If a file’s past incidents were SQL injection findings and the current change touches SQL, that overlap adds to the score. On paid plans with Collective Memory enabled, Pullminder additionally asks a model whether the specific change risks repeating the prior incident on a troubled file, and surfaces the reason in the Red-Flag block.
The Red-Flag comment block
Section titled “The Red-Flag comment block”When any red-flag signal fires, Pullminder adds a Red-Flag section to its PR comment listing the top reasons, each linking the prior incident PR, and a one-line verdict (Elevated risk / High risk — review before merge). Clean PRs get no block.
Warn vs. fail
Section titled “Warn vs. fail”Red-flagging is tiered per repository via red_flag_fail_threshold:
| Threshold | Behavior |
|---|---|
off | Red-flag signals never fail the check (advisory comment only). |
medium | A medium or high red-flag fails the check. |
high (default) | Only a high red-flag fails the check. |
A failing check blocks merge only where your branch protection requires the Pullminder check.
Overriding a red flag
Section titled “Overriding a red flag”To merge despite a failing red flag, add the pullminder-risk-ack label to the PR. Pullminder re-runs and posts the check as neutral, and records who acknowledged it in your audit log.
Requires Collective Memory to be enabled for the repository — red-flagging reads the same per-file history that also powers the System Map heat overlay.