Blue Team

A defensive fixer loop — the inverse of red-team. The artifact is the target, now writable; the feedback signal is two-part, like optimize-loop: a gate that must hold (nothing that passed before regresses) and a metric that must drop (the count of open failure classes, toward zero). You point it at a set of concrete failed cases and fix them one root-cause class at a time. Each iteration you patch one class, then run tools/verify.py, and keep the patch only if it closes the class with no regression, else revert. You loop until every class is closed (dry) or the budget runs out, then hand the patch set off as a pull request. This is the fix half of a find→fix setup (see Pairing).

The failed cases come from a real source; tools/ingest.py normalizes any of them into one catalogue:

• oracle mode — a red-team failures.jsonl: each case is an input where the target's verdict disagrees with a ground-truth oracle. A case is closed when target and oracle now agree; a regression is a benign <holdout> input that newly disagrees (most often a new over-block).
• tests mode — a CI/CD test-failure report (pytest --junitxml / JUnit XML, or a list of failing node ids): each case is a failing test. A case is closed when its test now passes; a regression is any other test that was passing and now fails.