Baselines
bonsai-lint --write-baseline src/Records everything currently above the threshold as accepted. Later runs fail only on scores that got worse, or on units the baseline has never seen. An unknown key is treated as a regression, never as an acceptance. A renamed function is reported rather than silently inheriting someone else’s amnesty.
A baseline also has to tighten, or it rots into a permanent exemption. A scan that covered the whole domain names every entry that rewriting the baseline would drop or lower: a unit that now scores less, one no longer over its threshold, one suppressed with a reason, and one that matched nothing because it was deleted or renamed.
root: src/Checkout.php: Checkout::apply is baselined at 38 but scores 20root: src/Legacy.php: Legacy::run is baselined at 21 but matched nothing in this scanThose lines are warnings. With --strict-baseline, or strict-baseline = true, they fail the
run, so an improvement has to be locked in: once nothing else fails, rewrite the baseline with
--write-baseline over the whole workspace and the run’s other flags. On a subset it would
empty the rest of the baseline (roadmap).
Raising a threshold, or passing --over above the one the baseline was written with, leaves
entries unneeded too. A single file from a pre-commit hook, an editor buffer, --domain or
--lang never judges a baseline, since it cannot see the entries whose units are gone.
Without a bonsai-lint.toml, the directory holding the baseline is the project root, so
bonsai-lint --write-baseline . followed by bonsai-lint src/Foo.php finds the same entries.