What it does
Subprocess-calls each agent-tool-* CLI in sequence per book listed in books.json. Source PDF → Marker OCR → figure scan → strip pipeline (back-matter, marker-artifacts, clean-markdown) → LLM proofread → book-builder PDF + Obsidian export.
The pipeline is boring on purpose. Each tool is a CLI that can run by hand. The harness just lines them up, threads outputs into inputs, and writes a manifest so I can rerun any single stage without redoing the rest.
Pipeline
Artifacts shipped
Every run drops three artifacts into ./runs/<timestamp>/. Source goes in; reading and writing surfaces come out.
A run, end to end
Drop a PDF and a books.json entry. The harness writes everything into a timestamped run folder — intermediates, logs, the final PDF + markdown.
Why it's split this way
Every stage that could be deterministic is a non-LLM CLI. Marker handles OCR; strip-marker-artifacts, strip-back-matter, and clean-markdown handle the predictable cleanup. The LLM only sees text that's already been combed.
The proofreader runs with a verifier subagent: every proposed fix is reviewed before it's applied, and a persistent memory of known false positives accumulates between runs. It's the slowest, most expensive stage by design — it earns it.
Books in flight
Composes
agent-tool-scrape-sources— optional ingest from the webagent-tool-figure-scanner— pre-flight figure/table auditagent-tool-marker-cleanup— three-stage strip pipelineagent-tool-llm-proofreader— verified fix proposalsagent-tool-prose-quality— readability signalsagent-tool-book-builder— final typeset PDF + Obsidian exportagent-tool-pdf-builder— library, used by book-builder
"The harness comes first. The model comes last."
What's next
Second book through the pipeline. A pass on the figure scanner so missing references get reported in the final manifest instead of as warnings. And — eventually — a way to run a folder of books overnight, unattended.