Surfaced while running mypy across the whole tree for the first time. Two related issues at the same call site, one purely cosmetic (now fixed) and one substantive (left for a follow-up).
Where
cerebra/retrieval/lattice_dedup.py — _pick_winner_scored() and its caller dedup_siblings(), invoked from cerebra/cli/main.py:524 and :755.
Issue 1: type mismatch (resolved in PR #1)
dedup_siblings(scored, query_d1, ...) declared query_d1: str | None, but every call site passes plan.query_d1 which is int | None (D1 categories are integer hex codes 0x0–0xF, see cerebra/cognition/sku_categories.py).
Resolved in PR #1 by changing the parameter type to int | None on both dedup_siblings and _pick_winner_scored. This is the smaller of the two issues.
Issue 2: the comparison never matches (this issue)
Inside _pick_winner_scored:
d1_matches = [
c for c in group
if c.sku_address and c.sku_address.split("::")[0] == query_d1
]The intent is "find candidates whose SKU's D1 category matches the query's D1." Two problems combine to make this dead code:
sku_address strings are produced by SKUAddress.to_hex_string() (cerebra/cognition/sku.py:90), which formats them as D1D2D3D4D5D6.D7D8.D9D10 — period-separated, not ::-separated. So sku_address.split("::") is a no-op that returns [sku_address], and split("::")[0] returns the full address string.- Even after Issue 1's type fix, the comparison is
str == int, which is always False.
Net effect: d1_matches is always []. _pick_winner_scored always falls through to the return _best_composite(group, "composite_score") branch. The SKU-aware routing — which the D2 routing rules docstring describes as the function's purpose — has never fired.
Impact
Behavior-wise: dedup_siblings still works correctly, it just always uses composite-score routing instead of preferring SKU-match candidates. No exception, no data corruption. Quality of retrieval ranking in SKU-classified scenarios is degraded vs. what the design intended.
Possible fixes (not done in this PR)
Some combination of:
- Change the split character to match the actual format:
c.sku_address.split(".")[0] — but then [0] would be the full D1–D6 location string D1D2D3D4D5D6, not just D1. Need to extract the first hex char: c.sku_address[0].
- Coerce
query_d1 (int) into a single hex character for comparison: f"{query_d1:X}" == c.sku_address[0].
- Or restructure
_pick_winner_scored to take an already-resolved D1 hex character rather than the int.
Whichever approach, add a unit test that exercises the SKU-match path and confirms a winner gets returned with routing_basis="sku_match" — the lack of such a test is part of why this never got caught.
Why this surfaced now
This archive repo had broken CI installs from day one, so type-check and tests have never run end-to-end against the whole tree. Pre-commit's mypy hook only checks staged files, not the whole package. PR #1's CI cleanup made these full-tree checks possible for the first time and surfaced ~50 mypy errors of accumulated debt; this is the only one of those errors that points at a real-but-silent logic bug rather than an annotation issue.
Surfaced while running mypy across the whole tree for the first time. Two related issues at the same call site, one purely cosmetic (now fixed) and one substantive (left for a follow-up).
Where
cerebra/retrieval/lattice_dedup.py—_pick_winner_scored()and its callerdedup_siblings(), invoked fromcerebra/cli/main.py:524and:755.Issue 1: type mismatch (resolved in PR #1)
dedup_siblings(scored, query_d1, ...)declaredquery_d1: str | None, but every call site passesplan.query_d1which isint | None(D1 categories are integer hex codes 0x0–0xF, seecerebra/cognition/sku_categories.py).Resolved in PR #1 by changing the parameter type to
int | Noneon bothdedup_siblingsand_pick_winner_scored. This is the smaller of the two issues.Issue 2: the comparison never matches (this issue)
Inside
_pick_winner_scored:The intent is "find candidates whose SKU's D1 category matches the query's D1." Two problems combine to make this dead code:
sku_addressstrings are produced bySKUAddress.to_hex_string()(cerebra/cognition/sku.py:90), which formats them asD1D2D3D4D5D6.D7D8.D9D10— period-separated, not::-separated. Sosku_address.split("::")is a no-op that returns[sku_address], andsplit("::")[0]returns the full address string.str == int, which is alwaysFalse.Net effect:
d1_matchesis always[]._pick_winner_scoredalways falls through to thereturn _best_composite(group, "composite_score")branch. The SKU-aware routing — which theD2 routing rulesdocstring describes as the function's purpose — has never fired.Impact
Behavior-wise:
dedup_siblingsstill works correctly, it just always uses composite-score routing instead of preferring SKU-match candidates. No exception, no data corruption. Quality of retrieval ranking in SKU-classified scenarios is degraded vs. what the design intended.Possible fixes (not done in this PR)
Some combination of:
c.sku_address.split(".")[0]— but then[0]would be the full D1–D6 location stringD1D2D3D4D5D6, not just D1. Need to extract the first hex char:c.sku_address[0].query_d1(int) into a single hex character for comparison:f"{query_d1:X}" == c.sku_address[0]._pick_winner_scoredto take an already-resolved D1 hex character rather than the int.Whichever approach, add a unit test that exercises the SKU-match path and confirms a winner gets returned with
routing_basis="sku_match"— the lack of such a test is part of why this never got caught.Why this surfaced now
This archive repo had broken CI installs from day one, so type-check and tests have never run end-to-end against the whole tree. Pre-commit's mypy hook only checks staged files, not the whole package. PR #1's CI cleanup made these full-tree checks possible for the first time and surfaced ~50 mypy errors of accumulated debt; this is the only one of those errors that points at a real-but-silent logic bug rather than an annotation issue.