Same-line and disable-next-line forms silence rules per occurrence so
known false positives don't need a project-wide disable. Recognises
'-- sql-guard: disable=W001,W003' (SQL) and '# sql-guard: disable=...'
(Python). Bare 'disable' with no rule list silences every rule on the
line, mirroring '# noqa' from flake8/ruff.

Loader walks up from cwd looking for .sql-guard.yml (or .sql-guard.yaml).
Recognises disable, ignore, include_python, severity. Returns an empty
Config when no file is present so callers don't have to None-check.
CLI flags merge with and override config values.

PyYAML promoted from optional to a runtime dependency.

Calls git diff --name-only against the working tree (or against a base
ref via --changed-base) and intersects with the discovered file list.
Falls back to a full scan with a warning when the cwd isn't a git repo
or git is unavailable. Speeds up pre-commit hooks on large codebases.

Builds a SARIF document compatible with the
github/codeql-action/upload-sarif action so findings render inline on
PRs in the GitHub Files Changed view. The full rule catalogue ships in
the tool descriptor; results carry rule id, level, file, line, and the
suggestion appended to the message text. Lines below 1 are clamped to 1
to satisfy the schema.

- --config / -c PATH overrides automatic .sql-guard.yml discovery
- --changed-only filters discovered files via git diff (with optional
  --changed-base REF). Empty diff exits cleanly without a 'no issues'
  scan banner.
- --format sarif emits a SARIF 2.1.0 doc to stdout, or to a file via
  --output / -o.
- --disable rule IDs are uppercased so 'w001' and 'W001' both work.
- Config file disable / ignore / include_python merge with CLI flags.

Key Numbers updated to 37 rules / 143 tests / v0.6.0. Rule tables grow
to include E007, E008, W017, W018, W020, T005. New Configuration
sections cover .sql-guard.yml, inline disable comments, --changed-only,
and SARIF output (with a copy-paste GitHub Actions snippet).

CHANGELOG covers the 6 new rules, inline disable directives,
.sql-guard.yml config, --changed-only flag, SARIF reporter, and the
PyYAML dependency promotion. P005 / W016 entries that were sitting in
[Unreleased] are folded into the 0.6.0 release notes.

v0.6.0 declares pyyaml as a runtime dependency. micropip's resolver
sometimes fails to install it cleanly because the only PyYAML build
that works under Pyodide is the bundled one served from
pyodide-cdn.s3, not the PyPI sdist. Pre-loading via
loadPackage(['micropip', 'pyyaml']) takes the bundled emscripten
build directly and unblocks the subsequent micropip.install('sql-sop').

Also reordered: install sqlparse first (so the sql-sop resolve doesn't
fan out and re-download it as a transitive dep) and dropped the
trailing standalone sqlparse install since it now happens earlier in
the chain.

Status messages updated to surface the new two-stage init.

The catch-block error message used '\'t' (escaped backslash + apostrophe)
inside a single-quoted string literal. JS parsed the backslash as a
literal backslash, then took the apostrophe as the string terminator,
then choked on 't start the Python runtime' as an unexpected identifier.

Devtools showed it as: Uncaught SyntaxError: Unexpected identifier 't'
at sql-guard/:125

A SyntaxError on any line of an inline script kills the whole script
before any of it executes. So boot() never ran and the page sat at the
initial HTML strings ('Loading Python runtime...', 'Waiting for Pyodide
to load...') forever, regardless of CDN state, regardless of what
fixes we'd pushed elsewhere in the file.

Replace the contraction with 'Could not' to sidestep the apostrophe
entirely. Less fragile than re-escaping.

pypistats.org/packages/sql-sop confirms 530 downloads in the last 30
days as of 2026-04-26 (vs 222 in the last 7 days, 2.6k all-time per
pepy.tech). The 195+ figure was several months stale; rounding down
to 500+ stays conservative and verifiable.

Resolves Pawansingh3889#7. (Issue title says W017 but W017 is now leading-wildcard-like
in v0.6.0; W019 is the next free ID before W020.)

Warns on COUNT(DISTINCT col) without a WHERE, GROUP BY, or LIMIT in the
same statement -- forces a full sort + distinct pass and is a frequent
perf surprise on prod.

- 'SELECT COUNT(DISTINCT user_id) FROM events;' -> fires
- 'SELECT COUNT(DISTINCT user_id) FROM events WHERE event_date >= ...' -> passes
- 'SELECT tenant_id, COUNT(DISTINCT user_id) FROM events GROUP BY tenant_id;' -> passes
- 'SELECT COUNT(*) FROM events;' -> not flagged

Updated:
- sql_guard/rules/warnings.py: new CountDistinctUnbounded rule.
- sql_guard/rules/__init__.py: registered in ALL_RULES.
- tests/test_new_rules.py: 6 new test cases covering hit, WHERE, GROUP
  BY, LIMIT, whitespace handling, and plain COUNT non-firing.
- tests/test_rules.py: bumped expected ALL_RULES count 32->33 and
  warning count 22->23.
- CHANGELOG.md: Unreleased entry.

Co-authored-by: Matt Van Horn <[email protected]>

Single-rule patch release. W019 lands count-distinct-unbounded from
PR Pawansingh3889#29 (mvanhorn). Bypass list recognises WHERE / GROUP BY / LIMIT
plus T-SQL TOP / FETCH FIRST / FETCH NEXT.

Surface counts refreshed: 38 rules (33 SQL + 5 Python), 149 tests.
Trusted Publishing will fire on the v0.6.1 tag push.