A contrast checker that printed 4.50 and passed could have been wrong, and the boundary is exactly where it mattered. The WCAG threshold is a comparison, not a display value, and antislop-human rounded the ratio to two decimals before comparing it. A pairing computing to 4.4983:1 printed as 4.50 and passed 4.5:1 while failing it.
The ratio is rounded for the reader, not for the verdict
The number that gets printed is still rounded to two decimals. The pass or fail decision now reads the unrounded value, in both implementations at once: the MCP server and the script, which the guardrail already holds to the same formula, so the two cannot drift apart on this again.
The case that exposed it is #777777 on #070707. It computes to 4.4983:1, prints as 4.50, and fails 4.5:1. It has a row in the reference table now, beside the other near-threshold pairing, because a table listing only cases comfortably on one side of a boundary teaches nothing about where the boundary sits.
The selftest carries that pairing and asserts against the unrounded value, so a return to comparing the rounded number fails a test rather than a document.
Also in this release:
- Rule 4 of
antislop-human, which states the formula, now says to compare unrounded and round only for display, so the written rule matches what the code does. - Every version-bearing file moved to 3.2.21 together, which includes the install sample in the guide and the contributors image in the README.
Updating is unchanged:
npx antislop-ai --updateSkills load when a session starts, so start a new one afterwards. Full detail is in the ROADMAP.