package.json version and CHANGELOG.md are stale — repo says 1.0.1, npm has shipped v1.0.2/v1.0.3 with grade-changing rule fixes and no changelog entries

[dmchaledev]

Problem

auto-tag.yml tags main with an incremented patch version on every green CI run, and publish.yml bumps package.json's version inside the ephemeral publish job (npm version "$TAG_VERSION" --no-git-tag-version) before building and publishing to npm. That bump is never committed back to main.

The result, verifiable right now:

• package.json on main still says "version": "1.0.1".
• CHANGELOG.md still ends at ## [1.0.1] - 2025-05-19 and documents only the initial release.
• The actual git tags on the remote are v1.0.2 (→ 608b6f5) and v1.0.3 (→ b2143bb), both already published to npm, and main is currently one commit ahead of v1.0.3 (0ce2274), so a v1.0.4 is imminent.
• Running node dist/cli.js --version from a fresh local clone/build reports 1.0.1 — three releases behind what npm actually serves.

Why this is high-leverage, not cosmetic

This isn't just a version-string nit — the commits that shipped between 1.0.1 and 1.0.2/1.0.3 (undocumented in CHANGELOG.md) include multiple changes that directly change the A–F grade a site receives:

• CSP now requires base-uri and form-action directives, penalizes wildcard/bare-scheme sources across more directives (connect-src, frame-src, worker-src, bare https:), and no longer flags 'unsafe-inline' when 'strict-dynamic' + nonce is present.
• Content-Security-Policy-Report-Only is now recognized instead of scoring 0.
• HSTS max-age=0 (revocation) no longer scores good.
• Referrer-Policy no longer treats no-referrer-when-downgrade as strong.
• X-Frame-Options no longer awards full marks for a permissive frame-ancestors *.
• Cross-Origin-* headers are scored by actual restrictiveness, not just presence.
• fetchHeaders switched from HEAD to GET, which changes which headers are even seen for sites that only emit CSP on full responses.

Any of these can move a real site from A/B down to C/D/F (or vice versa) with zero explanation available anywhere in the repo. Given this tool's flagship use case is a CI gate (security-headers https://staging.example.com || exit 1), a team pinning or updating this dependency has no way to find out from CHANGELOG.md why their gate started failing after an update — they'd have to read the full commit history/diff themselves.

Proposed fix

Pick one (both solve the drift; the second also fixes the changelog gap):

1. Minimal: After npm publish succeeds in publish.yml, add a step that commits the bumped package.json/package-lock.json back to main (e.g. git commit -am "chore: release v$TAG_VERSION [skip ci]" && git push), guarded so it can't trigger auto-tag.yml again ([skip ci] / path filters, or have auto-tag.yml ignore commits authored by the release bot).
2. Better: Require a CHANGELOG.md entry as part of the release, either by having a maintainer/PR add the entry before merge, or by generating one automatically from merged PR titles/labels in the same post-publish step in (1), then committing both files together.

Either way, back-fill the missing ## [1.0.2] and ## [1.0.3] entries now (at minimum listing the grading-relevant rule changes above) and bump package.json to match the latest published tag, so the repo stops lying about its own release state.

Scope

Touches package.json, CHANGELOG.md, and optionally .github/workflows/publish.yml / auto-tag.yml. No source/behavior changes to the library itself.