Background
sci-brain builds knowledge bases (.knowledge/ with rendered frontmattered Markdown, INDEX.md, references.bib, gitignored .raw//.figures/) via its own fetch/render pipeline. papis users already curate their literature in papis libraries (folder-per-document info.yaml + files) and get its ecosystem: publisher downloaders, papis doctor, papis-zotero, papis-ask. We rejected papis as sci-brain's storage backend (#30 records why). The inverse integration remains open: a papis-side plugin so papis-native users can produce/refresh sci-brain KBs from their libraries — papis owns acquisition and curation; sci-brain owns the agent-facing contract. Motivation and full papis analysis: #30.
Objective
Explore and, if the maintainers approve the repo, implement papis-scibrain: a pip-installable papis plugin providing one-way export/sync from a papis library into a sci-brain KB.
Interface (Input → Output)
In: papis -l <library> scibrain sync <kb-path> [--query <papis query>] — a papis library (or query subset) and a target KB directory.
Out: for each selected papis document: a rendered <id>_<slug>.md with sci-brain frontmatter (ids mapped from papis doi/eprint/isbn fields, full_text per available files), a references.bib entry using the document's papis ref as cite key, PDFs/sources copied into .raw/; INDEX.md regenerated. Re-runs are idempotent (unchanged docs produce no diff). One-way only: the plugin never writes back into the papis library.
Technical recommendations (non-binding)
Separate repo (papis-ecosystem convention: entry-point plugin, own PyPI package) — QuantumBFS/papis-scibrain or personal, maintainers' call. Vendor or import sci-brain's render/index helpers rather than reimplementing the contract; treat sci-brain's SKILL.md-documented KB layout as the normative spec. Decision points to settle in this issue before implementation: repo home, whether PDF→markdown rendering happens plugin-side (pymupdf4llm dep) or is delegated to a sci-brain checkout, and Zotero flow (papis-zotero → papis → this plugin could replace researchstyle's Zotero path).
Verification
Once implemented (staged roadmap — commands are concrete, runnability follows implementation):
- Scratch papis library with two documents added by
papis add --from arxiv 1806.08734 --batch and papis add --from doi 10.22331/q-2018-08-06-79 --batch; run papis -l <lib> scibrain sync $KB → KB contains two frontmattered .md files, two bib entries keyed by the papis refs, and an INDEX.md listing both — and kb_doctor.py --kb $KB (companion issue) exits 0, which proves contract conformance by the standing linter rather than by eyeball.
- Idempotency: immediate re-run →
git status --porcelain over the KB is empty.
- Negative control: a papis document with no files and no identifiers → the sync emits a
WARN and renders a stub entry rather than crashing or silently skipping; the summary line counts it.
Assumes
- Repo home and ownership (QuantumBFS vs personal) — settled in this issue's discussion before code.
kb_doctor (companion issue) lands first; it is the conformance oracle for verification step 1.
Dependencies
Part of #30. Verification depends on the kb_doctor child issue.
Out of scope
Two-way sync (KB→papis); making sci-brain's own pipeline depend on papis (see the optional-downloaders child instead); replacing sci-brain's fetch pipeline for non-papis users.
🤖 Generated with Claude Code
Background
sci-brain builds knowledge bases (
.knowledge/with rendered frontmattered Markdown,INDEX.md,references.bib, gitignored.raw//.figures/) via its own fetch/render pipeline. papis users already curate their literature in papis libraries (folder-per-documentinfo.yaml+ files) and get its ecosystem: publisher downloaders,papis doctor, papis-zotero, papis-ask. We rejected papis as sci-brain's storage backend (#30 records why). The inverse integration remains open: a papis-side plugin so papis-native users can produce/refresh sci-brain KBs from their libraries — papis owns acquisition and curation; sci-brain owns the agent-facing contract. Motivation and full papis analysis: #30.Objective
Explore and, if the maintainers approve the repo, implement
papis-scibrain: a pip-installable papis plugin providing one-way export/sync from a papis library into a sci-brain KB.Interface (Input → Output)
In:
papis -l <library> scibrain sync <kb-path> [--query <papis query>]— a papis library (or query subset) and a target KB directory.Out: for each selected papis document: a rendered
<id>_<slug>.mdwith sci-brain frontmatter (ids mapped from papisdoi/eprint/isbnfields,full_textper available files), areferences.bibentry using the document's papisrefas cite key, PDFs/sources copied into.raw/;INDEX.mdregenerated. Re-runs are idempotent (unchanged docs produce no diff). One-way only: the plugin never writes back into the papis library.Technical recommendations (non-binding)
Separate repo (papis-ecosystem convention: entry-point plugin, own PyPI package) — QuantumBFS/papis-scibrain or personal, maintainers' call. Vendor or import sci-brain's render/index helpers rather than reimplementing the contract; treat sci-brain's SKILL.md-documented KB layout as the normative spec. Decision points to settle in this issue before implementation: repo home, whether PDF→markdown rendering happens plugin-side (pymupdf4llm dep) or is delegated to a sci-brain checkout, and Zotero flow (papis-zotero → papis → this plugin could replace researchstyle's Zotero path).
Verification
Once implemented (staged roadmap — commands are concrete, runnability follows implementation):
papis add --from arxiv 1806.08734 --batchandpapis add --from doi 10.22331/q-2018-08-06-79 --batch; runpapis -l <lib> scibrain sync $KB→ KB contains two frontmattered.mdfiles, two bib entries keyed by the papisrefs, and anINDEX.mdlisting both — andkb_doctor.py --kb $KB(companion issue) exits 0, which proves contract conformance by the standing linter rather than by eyeball.git status --porcelainover the KB is empty.WARNand renders a stub entry rather than crashing or silently skipping; the summary line counts it.Assumes
kb_doctor(companion issue) lands first; it is the conformance oracle for verification step 1.Dependencies
Part of #30. Verification depends on the kb_doctor child issue.
Out of scope
Two-way sync (KB→papis); making sci-brain's own pipeline depend on papis (see the optional-downloaders child instead); replacing sci-brain's fetch pipeline for non-papis users.
🤖 Generated with Claude Code