the gate in the quickstart is unpinned:
npx liarjs --headless --min-score 60 # CI gate
so every ci run resolves whatever liarjs is latest on npm that day. if a release adds a check, retunes a penalty, or splits an existing one, the same unchanged browser scores differently and the build goes red with no code change — which is exactly the false regression the "something you can put in front of a merge" pitch is trying to kill.
so: is scoring covered by semver, i.e. do new/reweighted checks only land in a major, or can a patch move the number? if it can move, should the readme just pin (npx liarjs@1.2) in that snippet?
related, does --json carry a rules/scoring version alongside the sample, so that when two runs disagree i can tell "the browser changed" from "liarjs changed"? without that the diff story doesn't really close.
the gate in the quickstart is unpinned:
npx liarjs --headless --min-score 60 # CI gateso every ci run resolves whatever
liarjsis latest on npm that day. if a release adds a check, retunes a penalty, or splits an existing one, the same unchanged browser scores differently and the build goes red with no code change — which is exactly the false regression the "something you can put in front of a merge" pitch is trying to kill.so: is scoring covered by semver, i.e. do new/reweighted checks only land in a major, or can a patch move the number? if it can move, should the readme just pin (
npx liarjs@1.2) in that snippet?related, does
--jsoncarry a rules/scoring version alongside the sample, so that when two runs disagree i can tell "the browser changed" from "liarjs changed"? without that the diff story doesn't really close.