fix(rerank): preserve BM25 fallback order in no-op paths (wrong dict key)

[vinsocci]

Summary

rerank()'s four fallback branches read the wrong dict key, zeroing every candidate's rerank_score whenever the reranker can't run (ollama down, model not pulled, embed failure). The BM25 fallback ordering these branches intend to preserve is silently flattened to a 0.0 tie.

The branches set:

c["rerank_score"] = float(c.get("score", 0.0))

But the in-process caller retrieve.py builds each candidate with the key bm25_score (scripts/retrieve.py:147 → "bm25_score": h["score"]), not score. So c.get("score", 0.0) misses and returns 0.0 for every candidate.

Affected branches in rerank() (scripts/rerank.py):

• ollama unreachable (noop-no-ollama)
• model not pulled (noop-no-model)
• query-embed failure (noop-embed-error)
• per-candidate embed failure (embed-error)

Fix

Read bm25_score first, fall back to score (the standalone-CLI candidate contract documented in the module docstring, line 32), then 0.0:

c["rerank_score"] = float(c.get("bm25_score", c.get("score", 0.0)))

This keeps both callers correct — the retrieve.py module path (bm25_score) and the rerank.py --candidates CLI path (score).

Test plan

Forced the no-op path on macOS by pointing OLLAMA_URL at a dead localhost port, with three candidates keyed bm25_score (12.5 / 3.1 / 7.8):

candidate	before (main)	after
a (bm25 12.5)	rerank_score=0.0	rerank_score=12.5
b (bm25 3.1)	rerank_score=0.0	rerank_score=3.1
c (bm25 7.8)	rerank_score=0.0	rerank_score=7.8

Before: all candidates tie at 0.0 (fallback order lost). After: BM25 order preserved. rerank_source unchanged.

🤖 Generated with Claude Code