David F GliddenandClaude Opus 4.8
3f9a89b00c
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds long YAML description lines, strips final newlines. Bodies untouched — verified via full diff classification. From this commit forward, any diff in claude/memory shows only what Basic Memory or the session writes. Trial design: MemPalace untouched as incumbent; git status check on this dir at every wrap; end-of-day evaluation (recall quality, sync robustness, rebuild-from-files, malformed-file behavior). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.3 KiB
name, description, type, originSessionId, permalink
| name | description | type | originSessionId | permalink |
|---|---|---|---|---|
| Articulate toolchain fit before executing conversion or processing work | Before running any conversion/processing tool, surface why this tool is the right one for this input, what its limits are, and where in the broader toolchain it sits. Universal-tool framing is wrong; tools-by-input-type is right. | feedback | a5411fd1-4a96-43e7-aa1a-1a50d8951a8f | claude-memory/feedback-articulate-toolchain-fit-before-executing |
When proposing or executing conversion / processing operations (EPUB → MD, PDF → MD, OCR, transcription, etc.), do not present a single tool as "the" tool. Articulate the toolchain fit first.
Why: Steward's articulation (2026-05-13): "I thought that pandoc was the tool for conversion and document creation. I'd like to know more about where the current toolset is truly ideal for my needs. Now you have enough experience with me to know how I work, and, remember that we haven't even begun with the historical treatises… they could prove more difficult to process."
The contamination-aware reading: I had been treating pandoc as a universal tool and docling as a competing alternative. That framing is wrong. They are complementary, not substitutes — each excels on a different input type. Surfacing "use X" without surfacing "X is right for input-type Y; for input-type Z we'd use W" leaves the steward unable to think strategically about the corpus they actually have.
How to apply:
Before any conversion run, surface:
- What kind of input is this? EPUB, PDF (with text-layer / without), HTML, scan, audio, etc.
- What does the input's structure require? Multilingual? Multi-column? Footnotes? Marginalia? Equations? Historical typography?
- Which tool best matches? Brief rationale, not just a name. (Pandoc for clean structured inputs; docling for modern PDF layout reconstruction; ocrmypdf for missing text-layer; marker for equation-heavy academic PDFs; etc.)
- What does this tool not preserve? Honest about losses (footnote linking, image fidelity, complex layout).
- Where in the toolchain does this sit? Is this one stage of a pipeline (e.g., OCR → docling → manual review) or one-shot?
For the steward's likely future corpus (historical treatises, scanned classics, multilingual sources, varying-age digital editions), there is no single tool. The right answer is a diagnosed pipeline per input class, not a default tool.
Tooling memory anchor:
- pandoc — universal converter for clean structured formats (EPUB, HTML, LaTeX, Markdown). Excellent multilingual. Fast.
- docling (IBM, pipx) — PDF/DOCX/PPTX layout reconstruction. Does NOT handle EPUB. Heavy install (torch + models). Best for modern academic PDFs with text-layers.
- marker — alternative to docling for PDFs, especially equation-heavy academic papers.
- ocrmypdf + tesseract — for PDFs without text-layers or with poor OCR. Pre-processor for docling/marker.
- Calibre's ebook-convert — handles weird EPUB edge cases that pandoc can't.
- Direct text extraction (pdftotext) — fast but loses all structure; useful as a fallback or for quick inspection.
The historical treatises will likely need OCR + docling + manual review per text — not a single automated pass. Treat as research-grade conversion: surface that reality before suggesting a one-line command.