_board_index in analysis/draft_value.py keys the board by name_normalized::player_type. When two genuinely distinct same-type players share a normalized name (e.g. the two active 2026 Max Muncys, both hitters; or two hitters named "Will Smith"), it keeps only the higher-VAR row under that key and drops the other. If the dropped namesake was drafted, the pick later joins to the kept player's board row (VAR, positions, projected line), so run_draft_value grades that pick against the wrong player's projections -- a silently wrong number that can drive keeper/trade decisions.
Today this is only surfaced by a logger.warning (PR #172, M6) -- the interim mitigation. The same missing concept underlies M11: _assign_pick_types cannot distinguish a genuine two-way player from two distinct same-name players of different types, and now raises on an ambiguous two-way keeper note as its interim guard.
Root cause (shared by M6 and M11): the draft reconstruction has no per-pick / per-keeper stable identity (Yahoo/mlbam id) to disambiguate namesakes; it falls back to normalized name + claim order.
Real fix (deferred, feature-scale): thread a per-pick/per-keeper mlbam (or Yahoo) id through reconstruct_draft and the board join so namesake resolution is identity-based, not name-based. This is also the long-term fix the group-review M6/M11 items named, and it connects to the existing resolve_name_collision consolidation issue (bare-name collision heuristics scattered across keepers.py / board.py / projections).
Low immediate severity: the current 2026 collision (two Muncys) is only a latent mis-grade -- it bites only if one of the colliding namesakes was actually drafted. Surfaced by the loop-review high-effort code-review on PR #172.
_board_indexinanalysis/draft_value.pykeys the board byname_normalized::player_type. When two genuinely distinct same-type players share a normalized name (e.g. the two active 2026 Max Muncys, both hitters; or two hitters named "Will Smith"), it keeps only the higher-VAR row under that key and drops the other. If the dropped namesake was drafted, the pick later joins to the kept player's board row (VAR, positions, projected line), sorun_draft_valuegrades that pick against the wrong player's projections -- a silently wrong number that can drive keeper/trade decisions.Today this is only surfaced by a
logger.warning(PR #172, M6) -- the interim mitigation. The same missing concept underlies M11:_assign_pick_typescannot distinguish a genuine two-way player from two distinct same-name players of different types, and nowraises on an ambiguous two-way keeper note as its interim guard.Root cause (shared by M6 and M11): the draft reconstruction has no per-pick / per-keeper stable identity (Yahoo/mlbam id) to disambiguate namesakes; it falls back to normalized name + claim order.
Real fix (deferred, feature-scale): thread a per-pick/per-keeper mlbam (or Yahoo) id through
reconstruct_draftand the board join so namesake resolution is identity-based, not name-based. This is also the long-term fix the group-review M6/M11 items named, and it connects to the existingresolve_name_collisionconsolidation issue (bare-name collision heuristics scattered across keepers.py / board.py / projections).Low immediate severity: the current 2026 collision (two Muncys) is only a latent mis-grade -- it bites only if one of the colliding namesakes was actually drafted. Surfaced by the loop-review high-effort code-review on PR #172.