feat(cli): the found-nothing path exits 0 with no trace — report which sources ran, the command that widens the search, and which source is most likely to hold it

[sotashimozono]

The quiet failure is the one with no diagnostics, and it exits 0

Measured on 0.8.9, two paths for the same command:

outcome	exit	trace rows
found but blocked — error[CAPABILITY_DENIED]	3	6 (consulted: … / not consulted (an earlier source answered))
found nothing — metadata-only: no OA PDF available	0	0

$ doiget fetch 10.1137/0117004 ; echo "EXIT=$?"
fetched doi:10.1137/0117004 (metadata-only: no OA PDF available) -> …/doi_10.1137_0117004.toml
     "On the Continuity of the Generalized Inverse" by Stewart, G. W. (1969)  [crossref/closed]
EXIT=0

That line is byte-identical whether the six optional sources were on and had nothing or off and
never asked. I checked both: the found-nothing path prints no trace in either case.

Which is exactly the distinction #413 built the trace for —

"We asked and it had nothing" and "we never asked" are different problems with different fixes, and
were previously the same observable.

— absent on the path where it is most misleading, because that path is not an error and so has no
error[…] block to hang the trace on. #445 extended the trace from NOT_FOUND to the blocked
content leg; this is the third case, and the only one that reads as a result.

Why it matters more than the exit code suggests. A user searching for a paper reads
no OA PDF available as "this paper has no OA copy". With the default profile that sentence means
only "Crossref, Unpaywall and arXiv have nothing" — three of eleven sources. I concluded twice today
that a paper was unreachable on the strength of it, and had to redo the search. A narrow default is
the right design (#413: "the default binary is narrow, rate-capped, provenance-logged and
ToS-clean"); a narrow default that does not say it is narrow is a different thing.

What the failure should return

Three parts, in this order.

1. What was actually consulted this run

The rows already exist on the other two paths. Emit them here too, and make the disabled ones
visible rather than absent — an omitted row and a row saying "off" are not the same message:

no OA copy found for 10.1137/0117004.
  consulted:
    crossref     answered (metadata; oa_status = closed)
    unpaywall    answered: no OA location
    arxiv        answered: no preprint
  not consulted (disabled):
    datacite  doaj  europe-pmc  hal  openaire  core  openalex

2. The command that widens it

Not prose — the line to paste. #478 is the precedent to follow, and its complaint applies here too:
the machine path already computes which flag actually covers the case while the human path prints a
generic suggestion. Here the exact set is known, so:

  to widen the search:
    DOIGET_ENABLE_OPENALEX=1 DOIGET_ENABLE_CORE=1 DOIGET_ENABLE_OPENAIRE=1 \
    DOIGET_ENABLE_HAL=1 DOIGET_ENABLE_EUROPE_PMC=1 DOIGET_ENABLE_DATACITE=1 \
      doiget fetch 10.1137/0117004

with the two that carry an extra prerequisite named as such — CORE (DOIGET_CORE_API_KEY, free)
and OPENALEX (needs --features citation) — so a user does not enable one and silently get a
degraded answer.

#470 is the blocker for doing this per-row: classify_attempt throws the DenialContext away, so an
attempt row cannot carry its own remediation today.

3. Which one is most likely — ranked, never filtered

This is the part that does not exist yet, and the one worth being careful about: a ranking that is
wrong is worse than no ranking, because it makes people stop early. So it must be an ordering of
the full list, never a shortlist, and it must name the signal it ranked on.

The strong case: OpenAlex turns the guess into a lookup. It reports locations directly, and on
the three DOIs I tested today it separates the two situations cleanly:

DOI	OpenAlex locations	truth
10.1098/rspa.2014.0585	5 — incl. Europe PMC PMC4277194 and two Oxford ORA records	free PDF really is at Europe PMC (670 kB, fetched)
10.1007/bf02551288	1 — publisher landing page only	nothing anywhere
10.1137/0117004	1 — publisher landing page only	nothing anywhere

3/3, and n=3 — not a validated heuristic, but the mechanism is not statistical: OpenAlex is listing
the hosts, so with it enabled the answer is "Europe PMC has it", not "Europe PMC might". That makes
DOIGET_ENABLE_OPENALEX the first thing to suggest, and it is cheap: one metadata call, no
retrieval. (Consuming those locations to actually fetch is #461; this issue only asks to report
them.)

The fallback, when OpenAlex is off: rank from metadata already in hand after the Crossref leg —
no extra network. Signals, strongest first:

• DOI prefix → registrant. doiget already maintains a prefix→publisher map for Tier-3 scoping
  (ADR-0041); the same map says whether an enabled-able TDM source covers this prefix at all.
• venue / subject → Europe PMC for anything PMC indexes (and note it indexes well beyond
  biomedical — the Royal Society paper above is in it).
• author affiliation / funder → HAL for a French institution, OpenAIRE for an EU funder.
• CORE last, always present. Its own module doc calls it "the broadest single OA index outside
  Unpaywall and therefore the LAST fallback in the chain" — so it is never the top suggestion and
  never absent from the list.

Rendered:

  most likely to hold it, given "SIAM J. Appl. Math., 1969, prefix 10.1137":
    1. openalex   lists every known location — turns this ranking into a lookup
    2. core       broadest cross-repository index (needs DOIGET_CORE_API_KEY, free)
    3. openaire   European repository aggregation
    …and 4 more, above.
  ranked on: venue, DOI prefix, year. This is a guess, not a report — 1. is not.

That last line matters. Items 2+ are heuristics over metadata; item 1 is a claim about what an index
says. Presenting them in one list without marking which is which would be the failure mode this
whole issue is about.

Scope

Reporting only — no new retrieval, no new source, no change to what gets tried. Adjacent and
distinct: #461 (actually try the repository copies), #470 (the remediation plumbing this needs),
#478 (compute the precise suggestion instead of a generic one), #497 (write down the ceiling that
now holds).

[sotashimozono]

Status, after working through the batch — and this issue got more important, not less.

#517 resolved against widening, which makes this the whole remaining answer

#517 asked whether the fetch path should carry Crossref's publisher link so a closed DOI reaches the publisher instead of exiting 0 in silence. Measured against live Crossref — six DOIs across SIAM, IEEE, AMS, ACM, Springer Nature and the Royal Society, 12 link[] entries, plus the eight captured fixtures — not one entry carries intended-application: unspecified. Every one is text-mining or similarity-checking, i.e. scoped to a licensed programme doiget is not in on that path.

So there is nothing legitimate to follow, the ceiling holds (ADR-0052), and the user-visible complaint #517 opened with is entirely this issue's to fix: the run still exits 0 saying there is no OA copy, and the only thing that can change is what it says.

Two blockers named in this issue are gone

• diagnostics: per-source attempt rows cannot carry a remediation, because classify_attempt throws the DenialContext away #470 is fixed. classify_attempt no longer stringifies a policy refusal — it carries AttemptOutcome::Denied { denial } with the DenialContext intact, which is what remediation::for_denial consumes. So per-row remediation is available.
• bug(cli): the human denial help suggests both trust flags unconditionally, while the machine path computes which one actually covers the host #478's complaint (machine path computes the precise flag, human path prints a generic suggestion) is the same plumbing.

Scope I would ship, and the part I would not

Parts 1 and 2 — yes. The machinery exists and is already pure and tested: blocked_trace_lines in commands/fetch.rs renders exactly the rows this issue wants, and orchestrator::render_attempts / nothing_was_consulted produce them. The NoOaUrl arm of emit_success_line is the one path that does not call any of it. Emitting the consulted / not-consulted-(disabled) rows there, plus the exact DOIGET_ENABLE_* line derived from the profile rather than a generic sentence, is a contained change against code that already exists.

One addition from #517's outcome: when oa_status is closed, the widening line should name the TDM credential route (docs/CONFIG.md §6), because that is now the only supported route for such a work and the section says so.

Part 3 — the ranking — no, not yet. This issue's own caution is the reason: "a ranking that is wrong is worse than no ranking, because it makes people stop early." The strong case rests on OpenAlex locations, and the evidence offered is n=3. The DOI-prefix and venue heuristics behind items 2+ are unvalidated. Shipping an ordering whose top entry is a lookup and whose tail is a guess, in one list, is the failure mode the issue is warning about — and there is no harness that would catch it going wrong, which is #462.

So: parts 1 and 2 as one change; part 3 after #462 exists to measure it against.

[sotashimozono]

Parts 1 and 2 are in #566. Leaving this open for part 3.

Shipped: the NoOaUrl arm now emits the attempt trace (the data was already on FetchPaperOutcome.attempts and simply never read), plus the paste-able widening command derived from the Disabled rows rather than a second registry.

One thing the issue did not anticipate, worth recording here: resolve_metadata_flag returns false when the variable is set but the Cargo feature was not compiled in — it warns through tracing, which nobody sees, and the source still reports Disabled naming a variable the user set an hour ago. Suggesting they set it again would have been the same failure this issue is about, so that case now names the build instead of the config.

Not shipped — part 3, the ranking. The issue's own argument is why: a wrong ranking is worse than none because it makes people stop early, so it has to be an ordering of the full list that names its signal, with item 1 (OpenAlex locations — a lookup) marked as categorically different from items 2+ (heuristics over metadata). That is a design decision with its own review surface, not a rider on a diagnostics change.

The per-row remediation in part 2 is still gated on #470 as you noted; the global widening command is not, which is why it could land now.

[sotashimozono]

Parts 1 and 2 shipped in 0.8.13. Part 3 (ranking) deliberately did not, and that is recorded in the code rather than only here.

The found-nothing path no longer exits 0 with no trace: the attempts trace names which sources were consulted and what each answered, so no OA PDF available is accompanied by the evidence for it.

Part 3 is refused on the issue's own argument. From commands/fetch.rs:

a ranking that is wrong is worse than no ranking, because it makes people stop looking

Everything between them is returned unordered, deliberately. The issue proposes ranking the middle on venue, author affiliation and funder […]

Those three fields do not reach that code. Inventing an order from what is available would produce a ranking that looks authoritative and is not — which is the failure the issue itself warns about. So the middle band is returned explicitly unordered instead of given a plausible-looking order.

Leaving open for part 3, which needs the fields plumbed through before any ordering is honest.