The acceptance rule

A patch is kept only when lint hits strictly decrease and the suite stays green. Either condition alone is not enough.

1
2
3
4
5

round 0: 5 lint hits, suite red -> propose a patch
round 1: 2 lint hits, suite green -> keep (2 < 5 and green)
round 2: 2 lint hits, suite green -> drop (2 < 2 is false)
round 3: 0 lint hits, suite green -> keep (0 < 2 and green)
kept 2 of 3 proposed patches; 1 left the tree unchanged

Why the suite is the safety net

Lint checks style and structure, not behavior. Only the test suite observes what the design does.

A patch that silences a check can still break a test. The suite catches that trade, which is why the rule needs both signals.

Patch hygiene

Small disciplines keep the loop honest. They cost little and prevent the worst failures.

• Apply every patch in a scratch copy; the real checkout changes only on a kept patch.

• Give the loop least-privilege file access so it cannot reach outside its directory.

• Keep credentials and secrets out of prompts; share proprietary material only through an account and deployment approved for its data class and task.

• Require human approval before a kept patch leaves the scratch copy.

Common mistakes

Related topics

• Limits and failure modes

• Testbench architecture