Release 0.3.0: six new verbs, and eleven goldens re-captured for the stamp

[ChelseaKR]

What this is

v0.2.0 was released on 2026-09-01. Seventeen commits have landed since, six
of them verbs a reader can run — export, check, history, calendar, load
and reconcile. The theme underneath them is the one this project keeps finding:
a state for what the tool could not decide, kept apart from a clean result.

The part worth reviewing: eleven goldens moved

PARSER_VERSION is held equal to the project version by
test_release_metadata.py, so bumping the release version moves the stamp on
every emitted document. Eleven committed parses went stale at once, across
two separate corpora with two separate regeneration entry points:

corpus	files	regenerated by
tests/golden/	4	make golden
data/parsed/ (watch baselines)	7	make watch-baseline

The first make verify after the bump was red on eleven tests. That is both
corpora doing their job, and it is the reason this is worth a careful read rather
than a rubber stamp: a version bump that silently rewrote committed parse output
would be republishing evidence.

So the recapture is constrained and the constraint is checked:

1. It ran from the seven source PDFs already on disk. Nothing was re-fetched,
   so no upstream utility document could have moved underneath it.

2. Each was first confirmed against its sources.toml sha256 by
   make verify-source — all seven matched, so the bytes parsed now are the
   bytes the existing goldens came from.

3. The whole diff across all eleven files is eleven lines, one per file:

   -  "parser_version": "0.2.0",
   +  "parser_version": "0.3.0",
   

   No price. No date. No coverage figure. No line count. That is quoted in
   CHANGELOG.md rather than merely asserted, because a golden re-captured
   without a stated reason stops being evidence.

A consumer holding a 0.2.0 parse and comparing it against a 0.3.0 one now
gets PARSER_DIFFERENT rather than a silent comparison, which is what that field
is for. diff.py already documents the other half: equal stamps are
PARSER_INDETERMINATE, never proof that the same build read both.

Version statements moved

pyproject.toml, PARSER_VERSION, CITATION.cff (with date-released), the
README's install pin and its verify-tag example, a dated ## [0.3.0] heading,
and uv.lock — which records the project's own version, so the bump invalidated
it and uv sync --locked would have failed. uv lock reported
ca-tariff-parse v0.2.0 -> v0.3.0.

How it was verified

• make verify green: ruff, mypy over 30 source files, 677 passed, 2 skipped.
  Both skips are pre-existing and documented — a construction-time refusal checked
  one layer earlier, and a fixture that emits no charges. Neither is a release
  check that skipped itself into silence, which is the failure mode a green
  release gate hides.
• release.yml's own two checks simulated against this tree: tag-vs-pyproject
  parity matches, and the changelog carries a ## [0.3.0] - 2026-09-07 heading in
  the stricter dated form test_release_metadata.py requires, not just the
  substring grep the workflow uses.

What this does not do

No tag, no release, no PyPI. Nothing in this repository triggers on a tag —
release.yml and publish-pypi.yml are both workflow_dispatch-only, and they
are separate dispatches, so a GitHub Release does not reach PyPI. PyPI remains
blocked on the owner registering the trusted publisher; docs/ROADMAP.md carries
the five fields verbatim.

Prepared with AI assistance; reviewed before submission.