fix: filter variant=0 in scouting queries to exclude boosted stats (#58) #62

Claude · 2026-04-08T10:34:16Z

Claude commented

2026-04-08 10:34:16 +00:00

Closes #58

Summary

Scouting reports were pulling all battingcardratings / pitchingcardratings rows without filtering by variant. Once refractor variant rows (variant > 0) exist in the database, those boosted stats would be included in scouting calculations, making players appear stronger than their base card.

Changes

Added variant=0 client-side filter on the API response in all four scouting data-fetch paths:

scouting_batters.py — get_scouting_dfs(): filters vl_vals and vr_vals
scouting_pitchers.py — get_scouting_dfs(): filters vl_vals and vr_vals
pd_cards/core/scouting.py — get_batting_scouting_dfs(): filters vl_vals and vr_vals
pd_cards/core/scouting.py — get_pitching_scouting_dfs(): filters vl_vals and vr_vals

The filter uses .get("variant", 0) == 0 so it is safe even if the API response does not include a variant field (defaults to 0 = base card).

Test results

No test suite. Changes verified by reading back modified files — the filter list comprehensions are applied before the existing processing loops in all four locations.

Other observations

Pre-existing Pyright type errors exist in scouting_batters.py, scouting_pitchers.py, and pd_cards/core/scouting.py (unrelated to this fix, not modified).

Closes #58 ## Summary Scouting reports were pulling all `battingcardratings` / `pitchingcardratings` rows without filtering by variant. Once refractor variant rows (variant > 0) exist in the database, those boosted stats would be included in scouting calculations, making players appear stronger than their base card. ## Changes Added `variant=0` client-side filter on the API response in all four scouting data-fetch paths: - `scouting_batters.py` — `get_scouting_dfs()`: filters `vl_vals` and `vr_vals` - `scouting_pitchers.py` — `get_scouting_dfs()`: filters `vl_vals` and `vr_vals` - `pd_cards/core/scouting.py` — `get_batting_scouting_dfs()`: filters `vl_vals` and `vr_vals` - `pd_cards/core/scouting.py` — `get_pitching_scouting_dfs()`: filters `vl_vals` and `vr_vals` The filter uses `.get("variant", 0) == 0` so it is safe even if the API response does not include a `variant` field (defaults to 0 = base card). ## Test results No test suite. Changes verified by reading back modified files — the filter list comprehensions are applied before the existing processing loops in all four locations. ## Other observations Pre-existing Pyright type errors exist in `scouting_batters.py`, `scouting_pitchers.py`, and `pd_cards/core/scouting.py` (unrelated to this fix, not modified).

Claude added 1 commit 2026-04-08 10:34:17 +00:00

fix: filter variant=0 in scouting queries to exclude boosted stats (#58 ) 7b40af6547

Closes #58

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Claude referenced this pull request

2026-04-08 10:34:24 +00:00

bug: scouting reports must filter variant=0 to exclude boosted stats #58

Claude added the

ai-reviewing

label 2026-04-08 11:49:58 +00:00

Claude reviewed 2026-04-08 11:51:10 +00:00

Claude left a comment

AI Code Review

Files Reviewed

scouting_batters.py (modified)
scouting_pitchers.py (modified)
pd_cards/core/scouting.py (modified)

Findings

Correctness

No issues found. The filter is applied at the right point — before the for x in vl_vals: and for x in vr_vals: loops that destructively mutate each item. All eight filter points are covered (vL + vR for batting and pitching, across both the legacy scripts and the CLI-path module). The .get("variant", 0) pattern correctly handles API responses that pre-date the variant field.

Security

No issues found.

Style & Conventions

No issues found. The f-string quote normalization (outer double, inner single) is a clean incidental fix.

Suggestions

The log_time("end", ...) count line logs api_data[0]["count"] + api_data[1]["count"] — the pre-filter total — not the number of rows actually processed. Once refractor variants exist in production this will overstate the scouting input size in logs. Not a blocker, but worth noting for future observability.

Verdict: COMMENT

LGTM. Filter logic is correct and applied consistently across all four fetch paths. Safe to merge.

Automated review by Claude PR Reviewer

## AI Code Review ### Files Reviewed - `scouting_batters.py` (modified) - `scouting_pitchers.py` (modified) - `pd_cards/core/scouting.py` (modified) ### Findings #### Correctness No issues found. The filter is applied at the right point — before the `for x in vl_vals:` and `for x in vr_vals:` loops that destructively mutate each item. All eight filter points are covered (vL + vR for batting and pitching, across both the legacy scripts and the CLI-path module). The `.get("variant", 0)` pattern correctly handles API responses that pre-date the variant field. #### Security No issues found. #### Style & Conventions No issues found. The f-string quote normalization (outer double, inner single) is a clean incidental fix. #### Suggestions - The `log_time("end", ...)` count line logs `api_data[0]["count"] + api_data[1]["count"]` — the pre-filter total — not the number of rows actually processed. Once refractor variants exist in production this will overstate the scouting input size in logs. Not a blocker, but worth noting for future observability. ### Verdict: COMMENT LGTM. Filter logic is correct and applied consistently across all four fetch paths. Safe to merge. --- *Automated review by Claude PR Reviewer*

Claude added

ai-reviewed

and removed

ai-reviewing

labels 2026-04-08 11:51:32 +00:00

cal approved these changes 2026-04-08 12:25:43 +00:00

Dismissed

cal left a comment

Approved via pd-pr

cal approved these changes 2026-04-08 12:25:46 +00:00

cal left a comment

Approved via pd-pr