What's New in v1.6.0
Baseline Rename Protection
Renaming or moving a file no longer makes --fail-on-new treat its existing violations as new.
- AllyCat detects renames via git history and matches violations to the file's new path automatically.
- After a rename, AllyCat reminds you to re-run --save-baseline to keep things in sync — your baseline file is never
modified automatically. - Existing baseline files keep working unchanged.
Fixed
- --fail-on-new could incorrectly report existing baseline violations as new after unrelated edits elsewhere in the file
— including page-level rules like html-has-lang and document-title - Baselines saved on Windows now work correctly when checked on Linux CI (and vice versa) — paths are compared
consistently across operating systems - A corrupted allycat-baseline.json no longer crashes --fail-on-new — AllyCat now warns and skips the check, same as a
missing file - A broken allycat.config.json (e.g. null, an array, or plain text) no longer crashes the scan — AllyCat falls back to
defaults and leaves your file untouched - Hand-edited configs with missing fields no longer crash allycat scan — missing fields are filled in with defaults
automatically - Config migration no longer crashes on a read-only allycat.config.json — AllyCat warns and retries on the next run
- Invalid config values (e.g. an unsupported standard) are no longer silently accepted — AllyCat validates, warns, and
falls back to the default. The scan banner now shows the full standard name (e.g. WCAG 2.1 AA)
Upgrade Notes
- No breaking changes. Existing baselines and config files keep working without re-saving.
- In CI, rename detection requires git history — see the CI/CD Integration Guide (docs/ci-integration.md) for
fetch-depth / GIT_DEPTH settings. - No allycat init re-run needed.
Full changelog→ CHANGELOG.md