fix(verify_pdf): --ascii-dates needs digit boundaries around the year (#512)

_YEAR matched (19|20)\d{2} anywhere, so `2000` inside `120000` or `12000`
made a budget or throughput range typed with `--` read as an en-dashed
date range: "Grew budget DKK 120000-200000" and "12000-15000 events/s"
both failed /apply Step 5d, and the agent was sent to fix a date argument
that does not exist. The guide promises a numeric range with no year is
left alone.

Bound the year with (?<!\d) and (?!\d). "2016-2024" next to a longer
number is still caught. Two new cases; the numeric one fails on the
unbounded pattern.
This commit is contained in:
Ayobami Adegoke authored and GitHub committed 2026-10-03 19:33:48 +02:00
1 parent 27a9b4a91d
commit 52f84e0f82
3 files changed
+21 -1

No files matched your search

+8
View File
@@ -15,6 +15,14 @@ per-file diff commands.
### Fixed
- **`verify_pdf.py --ascii-dates` no longer reads a year-like run inside a longer number as a
date** - the year pattern had no digit boundaries, so `2000` inside `120000` or `12000` made
`Grew budget DKK 120000–200000` and `12000–15000 events/s` fail `/apply` Step 5d as
en-dashed date ranges, and the agent was sent to fix a "date argument" that does not exist.
The guide promises a numeric range with no year is left alone; now it is. `2016–2024` next to
a longer number is still caught. Two new `test_verify_pdf.py` cases; the numeric one fails
on the unbounded pattern.
- **`check_framework_version.py`'s git diff read no longer crashes on non-ASCII framework-file
content** (`tools/check_framework_version.py`) - `run_git()` called
`subprocess.run(text=True)` without an explicit `encoding`, so output decoded via the host