search: allow-domain hinted retry fires but a bare host token can't steer searxng — needs adapter-aware site: hint

[askalf]

Live receipt (v0.29.0 runner, first post-release run of the #147 receipt protocol)

NIST SP 800-63B question ×3 with --allow-domain=nvlpubs.nist.gov on the box runner (multi:searxng,stackexchange,wikipedia, default prefer): 1/3 — unchanged from the v0.27.1 baseline.

What the diagnostics prove (all three #147 honesty pieces worked exactly as designed):

deepdive: no sources gathered: 10 queries via multi(searxng,stackexchange,wikipedia) found 16 result(s), but the domain filter dropped every one — stopped before spending the synthesis LLM call.
  fallback (wikipedia) skipped: its results cannot satisfy --allow-domain.
  search worked — the domain filter (--allow-domain / --deny-domain) dropped all 16 result(s).

10 queries = 5 planned + 5 hinted — the retry-with-hint fired on both failing runs and still came back empty post-filter. The bare-host token (<query> nvlpubs.nist.gov) is not a strong enough relevance signal through this searxng instance's engine mix, even though authority ranking guarantees a .gov hit would win a slot if it appeared anywhere in the merged pool (gov/edu → primary, top of the prefer sort). The host simply never enters the candidate pool.

Why the bare token underperforms the 7/2 probe

The probe that motivated #147 (dd search "NIST SP 800-63B nvlpubs pdf" → target at rank 1) used the bare label nvlpubs + pdf, not the full host string. Engines tokenize nvlpubs.nist.gov as URL-ish; the standalone label matches page text/URL fragments better. And two of the three fan-out backends can't respond to the hint at all (wikipedia structurally; stackexchange API literal-match).

Candidate improvements (in preference order)

1. Adapter-aware site: hint — search: --allow-domain is a coin flip — planner variance decides exit 3, and the fallback pass is structurally filtered to zero #147's "fix 1", done properly: adapters that speak an engine query syntax (searxng, duckduckgo, brave — all pass site: through) get site:<host> on the hinted retry instead of a bare token; adapters that don't (SE API, wikipedia) skip the hinted pass entirely (structural, same test as the fallback gate — their servesDomains/API can't satisfy the filter anyway). site: is an operator, not a relevance hint — it turns the coin flip into a directed fetch.
2. Hint with the registrable label too — append <host> <first-label> (nvlpubs.nist.gov nvlpubs) so tokenizing engines get a matchable term. Cheaper, less deterministic than (1).
3. Skip hinting sub-adapters that can't use it — inside multi:, run the hinted retry only through backends that are open-web; today the SE keyword ladder burns extra calls re-walking a hinted string that its literal-match API will never satisfy.

(1) + (3) together would make the hinted pass both stronger and cheaper. Receipt protocol already exists: same NIST question ×3 on the runner, target 3/3.

Refs: #147 (shipped honesty + bare-token hint, v0.29.0), the 7/2 live-test arc that filed it.

[askalf]

Post-release receipt (v0.30.0 runner, same protocol — NIST Q ×3 with --allow-domain=nvlpubs.nist.gov, multi:searxng,stackexchange,wikipedia): 3/3 — exit 0 · trust high · cites 19/19, 14/14, 14/15 · $0.05–0.06/run, two runs kept 2 sources (the bare-token successes only ever kept 1). Cumulative record of the same protocol: v0.27.1 1/3 → v0.29.0 3/6 (two runs: 1/3, 2/3 — a coin flip both times, with honest exit-3s) → v0.30.0 3/3. The site: directive + deaf-sub skip did what the relevance nudge couldn't.