fix(bib): a PubMed entry was reported as having no identifier; it has a PMID (#500)

[sotashimozono]

Refs #500 — the reporting half. Ref::Pmid is blocked on a cross-repo contract; see the end. The issue stays open.

What was wrong

entry has no DOI / arXiv id is accurate about what the parser did and wrong about the entry. A user reading it goes and edits a .bib that was fine, because the sentence puts the deficiency on their side. It is on ours.

An existing test pinned exactly that claim:

fn bibtex_non_arxiv_eprinttype_is_skipped() {
    // eprinttype names a different server → not an arXiv id, and
    // there is no DOI, so the entry has no resolvable identifier.
    let body = "@article{x, eprint = {12345678}, eprinttype = {pubmed}}";
    assert!(matches!(res, Err(ParseError::NoIdentifier { .. })));
}

The entry has a PMID. It is not resolvable by doiget, which is a different statement.

The change

Both PubMed shapes are named: the pmid = {...} field PubMed's own BibTeX export writes, and the BibLaTeX eprint + eprinttype = {pubmed} pair that arxiv_eligible already refused — correctly, and until now silently. pmcid too.

NOT_IMPLEMENTED, not INVALID_REF. The input is valid and the support is absent, and the two codes carry opposite advice: "wait for a release" versus "correct your input". Disposition terminal follows.

An entry with genuinely nothing still reports NoIdentifier, and a DOI alongside a PMID still wins — the check runs only after every supported identifier has been tried, so it cannot divert an entry doiget could have resolved. Both are tested.

ParseError is #[non_exhaustive], so the compiler was no help

Adding the variant compiled everywhere. All three consumers have wildcards, and in the MCP one the new variant would have fallen into Err(_) => "unhandled bibliography parse error" — losing the identifier it had just identified. Explicit arms added at all three, found by reading them rather than by the build.

Why Ref::Pmid is not here

I checked the internal contract before writing any of it, and it is the blocker rather than NCBI.

docs/SAFEKEY.md opens with:

Status: NORMATIVE (shared spec). Binding for both doiget and BiblioFetch.jl. Any change requires a coordinated ADR and an update to the reference test vectors.

and its reference Julia implementation discriminates ref classes as:

raw = startswith(ref, "10.") ? "doi_$ref" : "arxiv_$ref"

A PMID is neither. 9659853 would be keyed arxiv_9659853 by BiblioFetch.jl and pmid_9659853 by doiget — a store one tool writes that the other misreads. Adding the class needs a coordinated ADR, a vectors.json update, and a matching change in another repository, which is not mine to land unilaterally.

NCBI is fine — verified, not assumed

Against the primary documentation (NBK25497) and a live round-trip, before designing anything:

base	https://eutils.ncbi.nlm.nih.gov/entrez/eutils/
rate	3 req/sec without a key, 10 with one
key	optional
tool / email	encouraged; mandatory only to lift an IP block
large jobs	weekends, or 21:00–05:00 ET on weekdays

esearch.fcgi?db=pubmed&term=10.1176/ajp.155.7.895[AID]   →  9659853
esummary.fcgi?db=pubmed&id=9659853                       →  articleids[] doi = 10.1176/ajp.155.7.895

So the resolver #500 proposes does work, and it is the same Coryell 1998 paper #536 was about. Worth noting for whoever picks up step 2: doiget's global cap is 5/sec while NCBI's keyless limit is 3, so it needs a SOURCE_RATE_OVERRIDES entry the way arXiv does — the cap alone would exceed NCBI's published rate.

Local: fmt, clippy -D warnings, workspace suite 47/47, version-bump-gate.sh.

[codecov]

Codecov Report

❌ Patch coverage is 67.83217% with 46 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/doiget-cli/src/commands/verify.rs	0.00%	18 Missing ⚠️
crates/doiget-mcp/src/lib.rs	0.00%	15 Missing ⚠️
crates/doiget-cli/src/commands/batch.rs	0.00%	7 Missing ⚠️
crates/doiget-core/src/refs.rs	94.05%	6 Missing ⚠️

📢 Thoughts on this report? Let us know!