paper-fetch

Paper Fetch

If the caller already has the paper — a local .md/.txt/.pdf path, or a direct HTTP(S) PDF URL (path ends in .pdf, ignoring query and fragment) — read it directly before considering any search route. Record source_channel as local_file, local_pdf, or direct_pdf. If the read fails, return not_found and do not fall back to alphaxiv, Semantic Scholar, bioRxiv, or medRxiv.

The pipeline's sole entry point: retrieves a paper and lands it on disk. It checks the cache first, reads already-identified sources (local files, direct PDF URLs) with no search at all, and otherwise uses the fixed fallback (alphaxiv → Semantic Scholar routing → bioRxiv/medRxiv → not_found). Decoupled from literature-engine's literature-research/literature-search/ literature-overview — this SOP holds its own retrieval calls rather than delegating.

Why an already-supplied file still enters through this SOP

Skipping straight to a reading SOP with the caller's own path looks like it saves a step, but 13 downstream SOPs take meta_path and read only section line ranges (star-awarding reads method + results; first-pass-skim's "headings only, never bodies" constraint holds because it is handed shallow ranges). A bare path carries no index, and a bare .pdf carries no extracted text at all.

So the thing to skip is the four-channel search, not the landing and indexing. That is what Step 1 does: no network lookup, same landing step, same output contract. Tactics keep passing paper_ref through unchanged and never learn there was a new input form.

Landed layout

context/papers/<timestamp>-<title-slug>/
  source.md            the paper, as fetched
  source.meta.json     metadata + line-number section index

All landed filenames are lowercase. <title-slug> is lowercased, non-alphanumerics collapsed to hyphens, Windows-illegal characters (: * ? " < > |) stripped, truncated to 60 chars against path-length limits.

Execution

Subagent — spawned via spawn-agent skill.