dedup_citations() silently merges companion articles (Part I / Part II) with distinct, non-missing DOIs

[yuricrbittencourt-design]

dedup_citations() merged two distinct records as an auto pair — companion articles
("...Part I. Design and denominators" / "...Part II. Results and interpretation") with the
same authors, year, journal and adjacent page ranges, but different, non-missing DOIs.
Part II survived; Part I disappeared silently from the deduplicated set.

Two aggravating observations:

1. manual = TRUE does not surface the pair: manual_dedup came back empty — the
   package classified the merge as high-confidence (auto pair).
2. The auto_pairs output shows doi1 and doi2 side by side with different values — the
   information needed to veto the merge was available at merge time.

Companion Part I/Part II pairs are a common publication pattern in oncology and epidemiology,
so this silently removes eligible records from systematic review screening — an error that
propagates into PRISMA counts and cannot be caught downstream without re-reading the raw
exports.

Expected behavior

An auto pair whose two records carry distinct, non-missing DOIs should never be merged
automatically. Suggested rule: route any such cluster to manual_dedup (conservative
direction — a surviving false pair is visible to the reviewer; a silently merged true pair is
not). Clusters where one side has a missing DOI, or where the DOIs differ only in form
(10.x/y vs https://doi.org/10.x/Y), are legitimate merges and should be unaffected.

Environment

• CiteSource 0.2.1 (CRAN); nothing in the 0.2.x/1.0.0 release notes addresses this
• R 4.6.1, Windows 11

Workaround we use

A post-hoc veto: any merged cluster containing >1 distinct non-missing normalized DOI is
un-merged and sent to human review. Happy to share the check if useful.