Zotero metadata-only books TODO — grab PDFs to ingest

When the full-text book pipeline ran on 2026-07-05, 37 of 116 book/bookSection items in the local Zotero SQLite had PDFs on disk. The remaining 79 (turned out to be 33 after dedup — see note) are metadata-only: Zotero has the bibliographic record but the actual PDF is missing.

The cron + dream cycle will pick these up automatically when: 1. You add the PDF to Zotero (drag in, sync, etc.) 2. The Zotero SQLite row's version increments 3. The sensor picks the change up on its next 6-hour run 4. The full-text extractor writes the inbox file 5. The synthesis cron writes the brain page

1. Find the PDF (Project Gutenberg for classics; library or purchase for others) 2. Drag it into Zotero at the same item row (Zotero will attach it as a PDF child of the existing record) 3. Wait for the 6-hourly sensor to detect the version bump, OR run the sensor manually:

Full-text extraction is the foundation. A media/books/<slug> page without the source PDF has no extraction to synthesize from — we'd be writing from metadata only (title + author + abstract), which Garry's pattern explicitly rejects. The synthesis-on-top page needs the receipts.

How it's structured

Why these are split out Full-text extraction is the foundation. A media/books/<slug> page without the source PDF has no extraction to synthesize from — we'd be wr…
Why these are split out The cron + dream cycle will pick these up automatically when: 1. You add the PDF to Zotero (drag in, sync, etc.) 2. The Zotero SQLite row's…
Why these are split out So the TODO is "for each book on this list, find the PDF and drop it into Zotero."
How to satisfy the TODO For each "real personal book" in the list:
How to satisfy the TODO 1. Find the PDF (Project Gutenberg for classics; library or purchase for others) 2. Drag it into Zotero at the same item row (Zotero…
How to satisfy the TODO The whole loop is idempotent — if you've already attached a PDF manually, re-running the sensor is a no-op.