Add additional regex to resolve issue in Volunteer backlog ticket #146

[linhtpham09]

No description provided.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[CLAassistant]

All committers have signed the CLA.

[grossir]

@claude review

[grossir]

Hi @linhtpham09 . Thanks for the contribution. Do check the required CLA.

Can you add some tests to illustrate what is gained.

If possible, negative tests are nice too, showing that the regex doesn't pick up strings that shouldn't be picked up.

[claude]

🟡 CHANGES.md adds a fully-formed **2.7.9 - 2026-8-04** entry under the ## Current (released) heading, but pyproject.toml still declares version = "2.7.8", so the changelog and package version are now out of sync. This entry likely belongs under the existing empty ## Upcoming section instead (version bumps in this repo are handled in dedicated release commits/PRs), or the version bump should be reconciled with pyproject.toml.

Extended reasoning...

CHANGES.md introduces a new, fully-formed release heading, **2.7.9 - 2026-8-04**, directly under the ## Current section (lines 18-27), with Features/Changes/Fixes stubs and the actual fix description. ## Current is documented as containing the released version, as opposed to ## Upcoming, which is explicitly described in the file as "not yet released, but code complete." Meanwhile pyproject.toml:9 still reads version = "2.7.8", and nothing else in this PR touches that file.

Looking at the git history, every prior release entry under ## Current is added in lockstep with a pyproject.toml version bump, typically in its own dedicated commit/PR (e.g. chore: Bump version to 2.7.8 and update changelog, merged as version-bump-v2.7.8, and the analogous 2.7.7/2.7.6 bumps). That convention exists precisely so the changelog's top entry and the package version always agree. This PR breaks that pattern for the first time: it manufactures a new "2.7.9" version heading under ## Current without any corresponding version bump.

Concretely, the repo's ## Upcoming section right above it is empty and exists exactly for this situation — a code-complete, unreleased fix. The correct place for this tokenizer fix (the trailing-letter law-citation regex change) is under ## Upcoming, not as a premature ## Current release entry with a version number and date that the maintainers haven't actually cut.

Impact is limited to documentation/versioning hygiene rather than a runtime defect: pyproject.toml is what actually determines the packaged version, and this repo's PyPI publish workflow is tag-triggered, so merging this PR alone won't ship anything mislabeled. But if a maintainer merges as-is and later does a routine version bump, they now have to notice and reconcile a "2.7.9" entry that was never validated against a real release, rather than simply appending under ## Upcoming as intended.

Proof: (1) pyproject.toml:9 → version = "2.7.8". (2) CHANGES.md diff adds **2.7.9 - 2026-8-04** directly below the ## Current heading (line 18), above the existing **2.7.8 - 2026-07-01** entry. (3) git log shows the 2.7.8 bump was its own commit touching both files together, confirming the established convention this PR departs from. (4) The file's own ## Upcoming section header text says entries there are "not yet released, but are code complete" — exactly the state of this PR's fix.

Suggested fix: move the fix description into the existing ## Upcoming section (leaving ## Current at 2.7.8 until a maintainer does the real version bump), or, if a 2.7.9 release is genuinely intended now, bump pyproject.toml to 2.7.9 in the same PR.

[linhtpham09]

@claude review