Development record

A Team Shares One Bibliography Without Sharing Anyone's Corpus

intentdraftsminorstandaloneitd-126

Press Release

Citation data travels through the repo; corpora never do. Alice works from a personal sources corpus (itd-76, which this intent refines); their teammate Bob has their own, or none. abcd source share writes a public source's citation data into the repo's committed CSL-JSON references store — .abcd/development/research/references.csl.json, the store the acknowledgements list already reads (maintainer ruling, 2026-08-16: one committed bibliography, not a second exchange file) — and refuses any confidential: true entry mechanically. abcd source ingest imports the repo's shared entries into the local corpus. Documents and influence ledgers never travel — only bibliography.

"I just ingest the repo's shared references," said Bob, "and every public source Alice worked from is in my own local store, ready to consult."

Why This Matters

A repo is a team surface even when every corpus is personal. Without a mechanical share path, the public slice of a bibliography is copied by hand and drifts; with one, a whole team builds on one reference list while each member's corpus — and everything confidential in it — stays private by construction. The refusal of confidential entries at the share boundary is the adr-41 trust rule exercised at the team seam.

Acceptance Criteria

Seeded by the itd-76 planning session, unconfirmed — the planning interview must walk these with the maintainer.

Given a public entry in Alice's corpus, when they run abcd source share, then its citation data is written into .abcd/development/research/references.csl.json and nothing else — no document, no ledger line — enters the repo.
Given a confidential: true entry, when share is attempted, then the refusal is mechanical and names the gate, not the source's identifying strings.
Given shared entries in the repo, when Bob runs abcd source ingest, then they enter their local corpus as public entries.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the sources-provenance SOTA note.

Provenance has a sanctioned home. CSL-JSON forbids unknown top-level keys and reserves custom for "additional information that does not have a designated CSL JSON field" (CSL-JSON input schema), so who shared an entry, from which repository and when ride in custom and render in no style.
Conflicts are decided at item level in the field. Zotero sync asks "which version you'd like to keep" when one item changed in two places and merges non-conflicting edits automatically; its duplicate merge is the field-level form, a person picking a master item and each surviving field (Zotero sync and duplicate-detection documentation).
Keys are owned by the store, not recomputed. Better BibTeX generates keys deterministically against the keys already present and resolves a clash with a letter postfix; a changed pattern touches only later items.
A committed JSON array merges badly in git. Sorting entries by id and refusing a share whose key exists with different content moves the conflict from git's textual merge to a refusal that names the key.
The team-library services share the wrong thing. Zotero groups hold separate copies of items and attachments against one owner's quota; a corpus-free share needs the committed file, as the maintainer already ruled.
Path 2: native share and ingest over references.csl.json, provenance in a custom.shared block (repository handle, source repo, date, corpus key; never a person's name or mail), first-sharer key ownership with a field-level diff on refusal and --replace as the deliberate overwrite. The entry stays pure CSL-JSON, so a later Zotero or CFF export is a projection. No Go dependency. The independent fit-challenge runs at plan time.

Open Questions

Conflict shape when two teammates share the same source with divergent metadata — last-write, merge, or key-ownership. (Moved here from itd-76 at its planning; deliberately unresolved.)
Whether ingest should mark provenance on imported entries (who shared, from which repo) so a team bibliography stays auditable. (Moved here from itd-76.)
The references store carries hand-curated entries (the acknowledgements baseline) and will carry shared ones; whether share appends blindly or respects the store's admission criteria (verified metadata, resolver links) needs a ruling before planning.
(SOTA 2026-10-23) Does a shared entry that fails the baseline's admission criteria (no resolver link, unverified authors) enter marked custom.shared.verified: false, or is the share refused until the sharer completes it?
(SOTA 2026-10-23) What identifies the sharer in custom.shared.by without a personal name or mail reaching a committed file: the repository's handle, the machine's identity block, or nothing beyond the source repository?

Audit Notes

Empty. Populated by intent-fidelity-reviewer when intent moves to shipped/.

Frontmatter

id	itd-126
type	intent
lifecycle	drafts
kind	standalone
severity	minor

.abcd/development/intents/drafts/itd-126-a-team-shares-one-bibliography-without.md
open on GitHub ↗ · commit history ↗

References1

itd-76abcd Lets You Consult Sources You Cannot Cite — and Remembers Every Debtbuilds on

Referenced by6

adr-41Documents and ledgers never leave the user tier; a public citation requires both gatesrelated
iss-2610262031350187itd-126 drives the sources corpus through a source verb, while the brief keeps the corpus under /abcd:libraryrelated
iss-2610262034102286draft itd-126 names `abcd source ingest` for importing shared references into the corpus; the library surface retired `source` and keeps ingest for the memory store, which registers nothingrelated
iss-2610262038595637itd-126 adds abcd source share and abcd source ingest; the surfaces register folds the old source command into libraryrelated
iss-2610262042473980Ingest means importing shared bibliography entries in itd-126 and storing a source's text in itd-2609292108089653related
iss-2610262043322187itd-126 adds abcd source share and abcd source ingest; itd-2610090831227812 merged the source family into library with no aliasrelated

mentions8

consult-freely-cite-deliberatelyConsult Freely, Cite Deliberately
dcn-26081600000000072026-08-16 — itd-76 planned at the live interview (spc-31 minted, `intent ready` exit 0). The itd-84 hand-run rendered SPLIT, confirmed: itd-76 narrows to the personal core (source add / ledger / sync-banlist / cite-check + guards); team share/ingest files as itd-126 and paper reconstruction as itd-127 (both `refines` itd-76, seeded criteria marked unconfirmed); the trust rule extracts to adr-41 (proposed) + brief invariant 9 — documents and ledgers never leave the user tier, a public citation requires both gates — which the intents cite rather than declare; the stance files as the consult-freely-cite-deliberately principle. Interview rulings: the share surface is the existing `.abcd/development/research/references.csl.json` research store, not a second `.abcd/work/references.json` exchange file (one committed bibliography — resolves the store clash the sources-plan adversarial review flagged); the draft's "Dogfood (already running)" claim was stale and is rewritten as target (no corpus on the development machine); multi-machine ledger ownership explicitly deferred until a second machine exists; persona Maya corrected to Alice. Seven Given-When-Then criteria authored and accepted in full. Rejected: planning the monolith (both remaining open questions gated only the share/ingest part), and holding for itd-77 (the corpus default path works without relocation). Hand-run graded into the decomposition-calibration note.
dcn-26092500000000282026-09-25 — The build's open-question check reads the record's own settled convention and stays fail-closed (lane implementer, autonomous run A, fix round 1 of the loop lane, on iss-2609252053576085; the lane's first ruling, that every list item under `## Open Questions` is a question whatever it says, lived only in its report and refused intents the record had settled). `intent.OpenQuestions` recognises exactly two markers, learned from the 12 planned intents that carry list items there. A section whose first non-blank line is an italic `_All resolved …_`, with at most one count word (`_All four resolved …_`), is settled whole (itd-111, itd-93); `_All but one resolved_` is not. An item explicitly marked resolved or deferred is not a question: a bold span opening with the word (`**Resolved — …**`, `**Deferred**`, `**Deferred to a follow-up intent**`, `**explicitly deferred**`, `**explicit deferral**`) or the word as a label (`resolved:`, `RESOLVED:`, `Deferred:`), anywhere in the item including its continuation lines. Everything else stays a question: an item led `**Open` whatever it goes on to say (itd-60's "Open, and not gating scope"), an item that only points to another record (itd-76's "travel with itd-126"), `**Out of scope …**`, and a question that merely mentions deferral. With the rule, itd-111 and itd-93 pass the check; itd-7, itd-60, itd-65, itd-66, itd-76, itd-82, itd-117, itd-131, itd-2609170822093401 and itd-2609211116005482 still refuse, each on an item the record does not mark settled. Relabelling those items is the product thinker's call through the planning interview, not the loop's.
iss-321persona pronoun discipline itd-79 is violated by gendered pronouns in seven intent records including a shipped intent
iss-338Seven registry personas are given he/she/his/her pronouns across intents/drafts (itd-92,97,98,108,126,128) and intents/shipped (itd-100), violating the they/them persona discipline (itd-79); review-enforced convention with no mechanical gate, concentrated in one 2026-08 authoring batch — a cosmetics-batch cleanup
iss-2610301822150004abcd has no comprehensive, deterministic system for acknowledging prior art. ACKNOWLEDGEMENTS.md is one hand-edited file that many agent sessions append to at once, so it conflicts on merge (the one-writer-per-file principle names a multi-writer single file as a merge hotspot), and nothing decides what qualifies for an entry: on 2026-10-30 three intents' cited papers and tools were found never credited. The product thinker proposed one file per acknowledged source in a folder under .abcd/development/, a root file regenerated only when a release is cut, and clear deterministic rules for what qualifies. The state-of-the-art check of 2026-10-30 (.abcd/development/research/notes/2026-10-30-acknowledgements-sota.md) supports all three, with one change: the root file should be a real generated file, not the proposed symlink, since Go module zips omit symlinks, core.symlinks=false checks them out as text, and GitHub and GitLab show the link path instead of the content. Related: itd-163 (citation closure and the acknowledgements mirror gate), itd-126 (one shared bibliography).
itd-2610141646126492A librarian turns sources into a quoted reading pack
spc-31source-provenance-ledger