[aranculleton]

What changed

Two independent audits looked at everything unreleased since 0.2.0. Every finding they confirmed is fixed in its own commit, each with a test that fails before the fix.

First audit (nine findings)

• The cache:
  • A body cut short is never kept.
  • The folder keeps to its caps on every write, and on a run where every answer was a 304.
  • A kept answer goes only to a request with the same address and Accept, and the caller's size limit is respected.
  • configure(cache_dir=...) refuses anything that is not text or a path.
• JSON-LD: a script wrapped in comment lines is read in linear time.
• Pay:
  • salary_period keeps the count a board gives.
  • One posting's odd pay shape gives no figure, never an exception.
  • A range written high to low comes out lowest first.
• Ids and dates:
  • job_id(job.url) gives back job.id.
  • A placeholder written as a date is no date.

Second audit

• Speed:
  • A full cache folder is pruned to 90% of its cap. Before, every write rescanned it: 200 writes into a full folder of 20,000 files took 21.1 s, and now take 0.23 s.
  • A page's JSON-LD scripts are found in one linear pass. Before, a hostile 5 MB page could hold a fetch for hours; it now takes at most 0.11 s. On 200,000 generated pages, the same blocks are found as with the old regular expression.
  • The memory store keeps a running total. Before, 20,000 inserts took 39 s; they now take 0.03 s.
  • html_to_text is linear on hostile input, and its output is identical.
• Cache behaviour:
  • A plain body with no length and no chunking is not kept, because nothing shows it arrived whole.
  • An answer request() cannot parse is not kept, so a board answering non-JSON costs one request a run, not two.
  • An answer kept with only a Last-Modified date is asked about conditionally for at most 24 hours from its last full read (MODIFIED_MAX_AGE). That bounds staleness on a host whose date does not move with its data.
  • The docs say the cap is about 500 MB per process, and why.
• Readers:
  • Rippling pay ranges are read only when they are a list.
  • Every reader reads each posting field only in the shape it expects. One posting's odd field no longer stops a board being read. 17 of the 20 new fuzz cases raised before.
  • A posting whose id or title cannot be read is left out. Before, it came out as gh-None or with an empty title.
  • JSON nested deeper than Python can follow is treated as unreadable JSON. It raises BoardError or gives no posting, and the MCP server returns a parse error instead of stopping.
• Ids and docs:
  • Every Workday posting keeps exactly the id 0.2.0 gave it: same on 2,978 generated paths. The one input where job_id(url) cannot equal job.id is documented.
  • The false comparison with extruct is removed (nothing was borrowed).
  • The CHANGELOG's "Fixed" section lists only what a 0.2.0 user could have hit.

The version is still 0.2.0, so merging publishes nothing. The 0.3.0 release follows in its own PR.

How it was checked

• Tests: 369 pass on Python 3.13 and 3.9, and ruff check . is clean.

• Compatibility with 0.2.0:

  • main's 266 tests and 0.2.0's 141 run against the fixed source. The only failures are fakes that send no Content-Length; that is the intended change.
  • Every reader's to_dict() over main's suite (349 jobs) and 0.2.0's (311 jobs) is identical, apart from the four new keys.

• Leak scan: the branch diff has 0 findings against the maintainer's five denylists. The tree's findings are the same as main's (the author attribution).

• Not tested: any live board. Timings were measured on one machine.

• pytest and ruff check . pass

• No runtime dependency added; works on Python 3.9

• robots.txt and the request limits are respected

🤖 Generated with Claude Code

https://claude.ai/code/session_01LrnN33G65kWMuv8y7xpUk4