Update SQL

SQL

@@ -1,38 +1,521 @@
- Revise the plan before executing.
+Here is Claude's plan:                                                                                                                                            ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ batter_prop_outcomes — Staged Fix Plan                                                                                                                            
 
-The immediate Plan A is close, but there are still two safety issues that must be fixed before edits:
+ ---
+ Framing
 
-1. Do NOT rebuild batter_prop_outcomes from the existing bloated backup using DISTINCT ON as the primary rebuild path.
-That backup is already contaminated by duplication/join-multiplication, so choosing one “latest” row per (game_pk, batter_name, market) can preserve incorrect slot/pitcher/odds metadata from a bad duplicated row.
+ There are two distinct problems. This plan separates them:
 
-Revise Stage 4 so the preferred rebuild path is:
-- rebuild from the corrected current pipeline / corrected audit source after Fixes 1–6 are deployed
-OR
-- rebuild from a freshly deduplicated audit extraction after the read_recommendation_audit_view fix is in place
+ Plan A (immediate): Stop batter_prop_outcomes from growing, fix it safely, and add a
+ UNIQUE constraint. Does NOT modify the semantic grain or constraints on recommendation_logs
+ or recommendation_outcomes. Treats those tables as opaque historical sources.
 
-You may keep the backup-only DISTINCT ON insert as an emergency fallback, but not as the primary recommended rebuild path.
+ Plan B (later): Audit and redesign the upstream source tables after a full downstream
+ consumer proof. Not in scope for the current execution.
 
-2. Fix the audit-view dedup/join logic so it is future-safe for multiple markets.
-Your latest_outcomes CTE deduplicates on (game_pk, batter_name, slot, market), but the final JOIN only uses:
-- game_pk
-- batter_name
-- slot
+ ---
+ Why batter_prop_outcomes Is Exploding (Confirmed Root Causes)
 
-That can reintroduce duplication if multiple markets exist.
-Revise the query so either:
-- the JOIN includes market where appropriate, or
-- the view is explicitly scoped to the market(s) actually needed by batter_prop_outcomes right now and documented as such.
+ Root Cause 1 — Source table join explosion (Layer 0→1)
 
-3. Update validation to test the actual deduplicated audit view, not the old raw join.
-Your Stage 3 validation query still uses the raw recommendation_logs LEFT JOIN recommendation_outcomes pattern, which does not verify the fixed read_recommendation_audit_view behavior.
-Replace it with validation that directly checks the corrected audit view output for a target game_pk.
+ recommendation_logs and recommendation_outcomes are written every 3 seconds by a
+ @st.fragment(run_every=3) fragment with no idempotency guard. A 3-hour game produces
+ ~10,800 rows in recommendation_logs and ~3,600 rows in recommendation_outcomes for the
+ same (game_pk, batter_name, slot) triple.
 
-4. Keep the rest of Plan A structure:
-- dedup/latest-row strategy in read_recommendation_audit_view
-- game_pk filter in Step 3
-- dedup at batter_prop_outcomes build stage
-- scoped delete/read/write per game_pk
-- manual button must not append
-- unique index on batter_prop_outcomes only after clean rebuild
+ read_recommendation_audit_view() (db.py:481–532) LEFT JOINs both tables on
+ (game_pk, batter_name, slot) with no WHERE clause:
+ FROM recommendation_logs l
+ LEFT JOIN recommendation_outcomes o
+   ON l.game_pk = o.game_pk AND l.batter_name = o.batter_name AND l.slot = o.slot
 
-Do not edit yet. Return the revised final execution plan with these corrections.
+ When both sides have duplicates, this is a Cartesian product per triple:
+ - 10,800 log rows × 3,600 outcome rows = 38,880,000 rows for one batter in one slot
+ - For 3 batters across 3 slots: ~350M rows returned from the audit view for a single game
+
+ Root Cause 2 — Step 3 reads full history with no game_pk filter (Layer 2)
+
+ analytics/game_completion.py:492:
+ audit_df = read_recommendation_audit_view(conn)   # returns ALL rows, all games, fully inflated
+ insert_batter_prop_outcomes(conn, prop_df)         # naked INSERT, no conflict guard
+
+ Every game completion appends the entire inflated multi-game history into batter_prop_outcomes.
+
+ Root Cause 3 — Step 4 does not compress (Layer 3)
+
+ Step 4 reads ALL rows, re-grades them, then replaces the entire table with the same inflated
+ count. It reduces nothing. Only runs when statcast is available.
+
+ Root Cause 4 — Retry fires Step 3 repeatedly (Layer 4)
+
+ @st.fragment(run_every=300) re-fires on_game_complete() for pending games.
+ _completed_pks session guard resets on restart. Each retry appends another full audit view blob.
+
+ ---
+ Evidence / SQL Diagnostics
+
+ Run these before making any changes:
+
+ -- Prove join explosion: check duplication factor in source tables
+ SELECT game_pk, batter_name, slot,
+        COUNT(*) AS log_rows
+ FROM recommendation_logs
+ GROUP BY game_pk, batter_name, slot
+ ORDER BY log_rows DESC LIMIT 10;
+
+ SELECT game_pk, batter_name, slot, market,
+        COUNT(*) AS outcome_rows
+ FROM recommendation_outcomes
+ GROUP BY game_pk, batter_name, slot, market
+ ORDER BY outcome_rows DESC LIMIT 10;
+
+ -- Prove Cartesian expansion: join row count for worst game
+ -- Replace 'WORST_GAME_PK' with top result from above
+ SELECT COUNT(*) AS audit_view_rows_for_game
+ FROM recommendation_logs l
+ LEFT JOIN recommendation_outcomes o
+   ON l.game_pk = o.game_pk AND l.batter_name = o.batter_name AND l.slot = o.slot
+ WHERE l.game_pk = 'WORST_GAME_PK';
+ -- Should be enormous (millions) if flooding is confirmed
+
+ -- Quantify batter_prop_outcomes inflation
+ SELECT COUNT(*) AS total_rows FROM batter_prop_outcomes;
+
+ SELECT COUNT(DISTINCT game_pk || '|' || batter_name || '|' || market) AS correct_grain_rows
+ FROM batter_prop_outcomes;
+ -- Ratio = duplication factor
+
+ SELECT game_pk, batter_name, market, COUNT(*) AS cnt
+ FROM batter_prop_outcomes
+ GROUP BY game_pk, batter_name, market
+ ORDER BY cnt DESC LIMIT 10;
+
+ ---
+ Plan A — Immediate Safe Remediation
+
+ Goal: Stop batter_prop_outcomes growth. Make Step 3 idempotent. Add UNIQUE constraint.
+ Does not impose UNIQUE constraints on recommendation_logs or recommendation_outcomes.
+ Does not truncate or alter recommendation_logs or recommendation_outcomes.
+
+ ---
+ Fix 1 — Dedup both sides of the audit view JOIN before returning (database/db.py)
+
+ File: database/db.py:485–532, function read_recommendation_audit_view()
+
+ Replace the current flat JOIN query with a CTE that takes the latest row per grain from each
+ source before joining. This eliminates Cartesian multiplication without altering the source tables.
+
+ Market scoping: latest_outcomes is scoped to market = 'hr' (the only current market in
+ recommendation_outcomes). This prevents future duplication if additional markets are added —
+ the JOIN would otherwise multiply one latest_logs row against multiple market rows. The WHERE market = 'hr' constraint is documented inline. When additional      
+ markets are supported, this view
+ must be revised.
+
+ query = """
+ WITH latest_logs AS (
+     SELECT DISTINCT ON (game_pk, batter_name, slot) *
+     FROM recommendation_logs
+     ORDER BY game_pk, batter_name, slot, created_at DESC NULLS LAST
+ ),
+ latest_outcomes AS (
+     -- Scoped to market='hr' (only current market); prevents JOIN multiplication on future markets
+     SELECT DISTINCT ON (game_pk, batter_name, slot) *
+     FROM recommendation_outcomes
+     WHERE market = 'hr'
+     ORDER BY game_pk, batter_name, slot, graded_at DESC NULLS LAST
+ )
+ SELECT
+     l.created_at,
+     l.game_pk,
+     l.away_team,
+     l.home_team,
+     l.status,
+     l.slot,
+     l.batter_name,
+     l.pitcher_name,
+     l.ev90,
+     l.hit_prob,
+     l.hr_prob,
+     l.tb2p_prob,
+     l.fair_hit_odds,
+     l.fair_hr_odds,
+     l.fair_tb2p_odds,
+     l.book_hit_odds,
+     l.book_hr_odds,
+     l.book_tb2p_odds,
+     l.hit_edge,
+     l.hr_edge,
+     l.tb2p_edge,
+     l.adjusted_edge,
+     l.hit_bet_ev,
+     l.hr_bet_ev,
+     l.tb2p_bet_ev,
+     l.confidence,
+     l.confidence_bucket,
+     l.recommendation_tier,
+     l.priority_score,
+     l.reason_tags,
+     l.starter_stays_next_batter_prob,
+     l.starter_stays_next_inning_prob,
+     l.bullpen_entry_prob,
+     o.realized_hit,
+     o.realized_hr,
+     o.realized_tb2p,
+     o.graded_at,
+     o.outcome_source
+ FROM latest_logs l
+ LEFT JOIN latest_outcomes o
+   ON l.game_pk = o.game_pk
+  AND l.batter_name = o.batter_name
+  AND l.slot = o.slot
+ ORDER BY l.created_at DESC
+ """
+
+ Why this is safe for all consumers:
+ - Returns the latest recommendation snapshot per (game_pk, batter_name, slot) — one row each
+ - Market scoping ensures the LEFT JOIN is strictly 1:1 (one log row → at most one outcome row)
+ - Audit metrics tables GROUP BY tier/confidence/edge — deduplicated data is more accurate
+ - Debug page shows tail(20) — no functional change
+ - Source tables are untouched; DISTINCT ON is read-only
+
+ Row count after this fix (per game): at most distinct(batter_name) × distinct(slot) rows,
+ typically 3–10 batters × 1–3 slots = 9–30 rows per game.
+
+ ---
+ Fix 2 — Filter audit_df to current game_pk in Step 3 (game_completion.py)
+
+ File: analytics/game_completion.py:492
+
+ # Change:
+ audit_df = read_recommendation_audit_view(conn)
+ # To:
+ audit_df = read_recommendation_audit_view(conn)
+ audit_df = audit_df[audit_df["game_pk"].astype(str).str.strip() == str(game_pk)]
+
+ After Fix 1, the audit view returns at most ~30 rows for a typical game. After Fix 2, only rows
+ for the completing game are processed. Together: Step 3 operates on exactly the right set of rows.
+
+ ---
+ Fix 3 — Dedup prop_df before inserting (batter_prop_grader.py)
+
+ File: analytics/batter_prop_grader.py, end of build_batter_prop_outcome_rows_from_audit()
+
+ Adds a final safety net to ensure one outcome row per (game_pk, batter_name, market) regardless
+ of what the audit view returns (e.g., if the same batter appeared in two different slots):
+
+     df = pd.DataFrame(rows)
+     if df.empty:
+         return df
+     df = (
+         df.sort_values("created_at", ascending=False, na_position="last")
+           .drop_duplicates(subset=["game_pk", "batter_name", "market"], keep="first")
+           .reset_index(drop=True)
+     )
+     return df
+
+ ---
+ Fix 4 — Scoped delete before Step 3 insert (game_completion.py + database/db.py)
+
+ Makes Step 3 idempotent: re-running for the same game_pk removes that game's rows first,
+ then inserts exactly the right set.
+
+ Add to database/db.py:
+ def delete_batter_prop_outcomes_for_game(conn, game_pk: str) -> None:
+     conn.execute(
+         text("DELETE FROM batter_prop_outcomes WHERE game_pk = :pk"),
+         {"pk": game_pk},
+     )
+
+ analytics/game_completion.py:497, change:
+ # Change:
+ insert_batter_prop_outcomes(conn, prop_df)
+ # To:
+ from database.db import delete_batter_prop_outcomes_for_game
+ delete_batter_prop_outcomes_for_game(conn, str(game_pk))
+ insert_batter_prop_outcomes(conn, prop_df)
+
+ ---
+ Fix 5 — Scope Step 4 to current game (game_completion.py + database/db.py)
+
+ Stops the full-table DELETE + re-INSERT churn. Step 4 now only reads and re-grades the rows
+ for the completing game.
+
+ Add to database/db.py:
+ def read_batter_prop_outcomes_for_game(conn, game_pk: str) -> pd.DataFrame:
+     ensure_batter_prop_outcomes_table(conn)
+     return pd.read_sql(
+         text("SELECT * FROM batter_prop_outcomes WHERE game_pk = :pk"),
+         conn,
+         params={"pk": game_pk},
+     )
+
+ analytics/game_completion.py:507–515, change:
+ # Change:
+ batter_prop_df = read_batter_prop_outcomes(conn)
+ ...
+ replace_batter_prop_outcomes(conn, graded_df)
+
+ # To:
+ from database.db import read_batter_prop_outcomes_for_game, delete_batter_prop_outcomes_for_game
+ batter_prop_df = read_batter_prop_outcomes_for_game(conn, str(game_pk))
+ if not batter_prop_df.empty:
+     graded_df = build_batter_realization_rows(
+         batter_prop_outcomes_df=batter_prop_df,
+         statcast_df=statcast_df,
+         graded_at=utc_now_iso(),
+     )
+     if not graded_df.empty:
+         delete_batter_prop_outcomes_for_game(conn, str(game_pk))
+         insert_batter_prop_outcomes(conn, graded_df)
+         logger.info("[game_completion] step 4 done: %d realized rows", len(graded_df))
+
+ ---
+ Fix 6 — Fix manual debug button (app.py)
+
+ File: app.py:2691–2700
+
+ Change insert_batter_prop_outcomes(conn, outcome_df) to replace_batter_prop_outcomes(conn, outcome_df).
+
+ The manual button now does a full-table replace instead of append. Idempotent: clicking it twice
+ produces the same result. It still reads the full audit view (which Fix 1 has deduplicated).
+
+ ---
+ Fix 7 — Add UNIQUE constraint to batter_prop_outcomes (applied post-rebuild)
+
+ File: database/db.py, ensure_batter_prop_outcomes_table(), after the CREATE TABLE call:
+
+ conn.execute(text("""
+     CREATE UNIQUE INDEX IF NOT EXISTS uq_batter_prop_outcomes_grain
+     ON batter_prop_outcomes (game_pk, batter_name, market)
+ """))
+
+ This is the hard backstop. Any future bug that attempts a duplicate insert will fail loudly
+ rather than silently inflating the table.
+
+ Apply AFTER the table is rebuilt clean (Stage 4 below), not before.
+
+ ---
+ Plan A — Staged Execution Order
+
+ Stage 1 — Run diagnostics (read-only, no changes)
+
+ Execute the SQL diagnostics above. Confirm:
+ - Log rows per (game_pk, batter_name, slot) are in the hundreds/thousands
+ - Audit view join expansion is massive for worst-case games
+ - batter_prop_outcomes correct grain count vs. actual count
+
+ This is a gate — proceed only after confirming the pattern.
+
+ ---
+ Stage 2 — Deploy code (Fixes 1–6, no schema changes)
+
+ One push. All changes are backward-compatible:
+ - Fix 1: read_recommendation_audit_view uses dedup CTE (read-only query change)
+ - Fix 2: game_pk filter at call site (game_completion.py)
+ - Fix 3: dedup in build_batter_prop_outcome_rows_from_audit (batter_prop_grader.py)
+ - Fix 4: delete_batter_prop_outcomes_for_game helper + call in Step 3
+ - Fix 5: read_batter_prop_outcomes_for_game helper + scoped Step 4
+ - Fix 6: manual button uses replace
+
+ No UNIQUE constraints are added in this stage. No source tables are modified. The code is
+ safe to deploy and roll back if needed.
+
+ ---
+ Stage 3 — Validate: run one game cycle and confirm no new duplicates
+
+ After deploy, wait for the next game to complete (or trigger one manually).
+ Then run these checks against the corrected audit view logic directly:
+
+ -- A. Verify the fixed audit view produces no multiplication for a target game
+ -- Use the same CTE logic as the updated read_recommendation_audit_view
+ WITH latest_logs AS (
+     SELECT DISTINCT ON (game_pk, batter_name, slot) *
+     FROM recommendation_logs
+     ORDER BY game_pk, batter_name, slot, created_at DESC NULLS LAST
+ ),
+ latest_outcomes AS (
+     SELECT DISTINCT ON (game_pk, batter_name, slot) *
+     FROM recommendation_outcomes
+     WHERE market = 'hr'
+     ORDER BY game_pk, batter_name, slot, graded_at DESC NULLS LAST
+ )
+ SELECT l.game_pk, l.batter_name, l.slot, COUNT(*) AS rows_in_view
+ FROM latest_logs l
+ LEFT JOIN latest_outcomes o
+   ON l.game_pk = o.game_pk AND l.batter_name = o.batter_name AND l.slot = o.slot
+ WHERE l.game_pk = '<GAME_PK_FROM_LAST_COMPLETION>'
+ GROUP BY l.game_pk, l.batter_name, l.slot;
+ -- Expected: all rows_in_view = 1; total rows ~ 9–30
+
+ -- B. batter_prop_outcomes: new rows for last completing game must each appear once
+ SELECT game_pk, batter_name, market, COUNT(*) AS cnt
+ FROM batter_prop_outcomes
+ WHERE game_pk = '<GAME_PK_FROM_LAST_COMPLETION>'
+ GROUP BY game_pk, batter_name, market
+ ORDER BY cnt DESC;
+ -- Expected: all cnt = 1
+
+ ---
+ Stage 4 — Back up, truncate, and rebuild batter_prop_outcomes
+
+ Step 1 — Back up (preserve for audit/emergency only; do NOT use as primary rebuild source):
+ CREATE TABLE batter_prop_outcomes_backup_20260321
+ AS SELECT * FROM batter_prop_outcomes;
+ SELECT COUNT(*) FROM batter_prop_outcomes_backup_20260321;
+
+ The backup is contaminated — it contains rows inflated by join multiplication from the old
+ query. Picking DISTINCT ON rows from the backup risks preserving metadata (slot, pitcher, odds)
+ that came from a bad duplicated row rather than a clean source. Use the backup for inspection
+ only. It is NOT the primary rebuild path.
+
+ Step 2 — Truncate:
+ TRUNCATE TABLE batter_prop_outcomes;
+ SELECT COUNT(*) FROM batter_prop_outcomes;  -- must be 0
+
+ Step 3 — Rebuild via the corrected pipeline (primary path):
+
+ With Fixes 1–6 deployed, the corrected audit view now returns clean deduplicated rows.
+ Trigger a rebuild using the existing pipeline functions — this is equivalent to clicking the
+ "Build Batter Prop Outcomes" debug button after Fix 6 is deployed:
+
+ # Equivalent to grade_batter_prop_outcomes_from_audit() after Fix 6
+ # Run this from a Python shell or admin script connected to production:
+
+ from database.db import read_recommendation_audit_view, replace_batter_prop_outcomes
+ from analytics.batter_prop_grader import build_batter_prop_outcome_rows_from_audit
+ from utils.time_utils import utc_now_iso  # or however utc_now_iso is imported
+
+ audit_df = read_recommendation_audit_view(conn)    # returns clean deduplicated rows
+ prop_df = build_batter_prop_outcome_rows_from_audit(audit_df, graded_at=utc_now_iso())
+ # prop_df is already deduped on (game_pk, batter_name, market) by Fix 3
+ replace_batter_prop_outcomes(conn, prop_df)        # DELETE ALL + INSERT clean rows
+
+ This produces exactly one row per (game_pk, batter_name, market) for all historical games.
+ Rows will have grade_status = 'pending' and outcome_source = 'pending_batter_prop_grade'
+ for historical games where realized outcomes haven't been re-applied. That is acceptable —
+ the table is clean and correctly sized; future games will have realized outcomes applied by the
+ corrected Step 4.
+
+ Step 4 — Verify row count is sane:
+ SELECT COUNT(*) FROM batter_prop_outcomes;  -- expected: hundreds to low thousands
+
+ SELECT game_pk, COUNT(*) AS rows_per_game
+ FROM batter_prop_outcomes GROUP BY game_pk ORDER BY game_pk DESC LIMIT 10;
+ -- Each game_pk should have a small number of rows (1 per distinct batter with a rec)
+
+ Emergency fallback only — backup-based DISTINCT ON (if corrected pipeline rebuild fails):
+ INSERT INTO batter_prop_outcomes
+ SELECT DISTINCT ON (game_pk, batter_name, market)
+     created_at, graded_at, game_pk, away_team, home_team, slot,
+     batter_name, pitcher_name, market, fair_hr_odds, book_hr_odds,
+     adjusted_edge, confidence, recommendation_tier,
+     realized_hit, realized_hr, realized_tb2p, grade_status, outcome_source
+ FROM batter_prop_outcomes_backup_20260321
+ ORDER BY game_pk, batter_name, market, graded_at DESC NULLS LAST;
+ Use only if the corrected pipeline rebuild is blocked for operational reasons. Metadata quality
+ in this path is not guaranteed since rows came from a multiply-contaminated table.
+
+ ---
+ Stage 5 — Apply UNIQUE constraint to batter_prop_outcomes (Fix 7)
+
+ CREATE UNIQUE INDEX uq_batter_prop_outcomes_grain
+   ON batter_prop_outcomes (game_pk, batter_name, market);
+
+ Verify it was created without error, then ensure it shows in:
+ SHOW INDEXES FROM batter_prop_outcomes;
+
+ ---
+ Stage 6 — Final validation
+
+ -- 1. No duplicates per grain (must return 0 rows)
+ SELECT COUNT(*) FROM (
+     SELECT COUNT(*) AS c FROM batter_prop_outcomes
+     GROUP BY game_pk, batter_name, market HAVING COUNT(*) > 1
+ ) t;
+
+ -- 2. Row count is sane
+ SELECT COUNT(*) FROM batter_prop_outcomes;   -- expected: hundreds to low thousands
+
+ -- 3. Grade status distribution looks correct
+ SELECT grade_status, outcome_source, COUNT(*)
+ FROM batter_prop_outcomes GROUP BY 1, 2;
+
+ -- 4. After next game completion: only that game's rows were added/modified
+ SELECT game_pk, COUNT(*) FROM batter_prop_outcomes
+ GROUP BY game_pk ORDER BY game_pk DESC LIMIT 5;
+
+ ---
+ Plan B — Later: Upstream Source Table Redesign
+
+ Do not execute until Plan A is stable and at least 5 game completion cycles are validated.
+
+ What needs to be determined first (open questions)
+
+ 1. Are repeated timestamped rows in recommendation_logs intentional? (e.g., to track how odds
+ evolved as a batter stayed in On Deck across multiple pitches)
+ 2. Is any downstream consumer using the full history of recommendation_logs (e.g., time-series
+ analysis of confidence drift per batter per game)?
+ 3. Are batter_audit_metrics results more accurate with the full log history or with the
+ deduplicated snapshot?
+ 4. What is the intended data retention for recommendation_logs? Should old rows ever be purged?
+
+ What Plan B would include (if proof shows repeated rows are not intentional)
+
+ - Add _upsert_on_conflict and _insert_ignore DB-level helpers to db.py
+ - Change insert_recommendation_logs to upsert on (game_pk, batter_name, slot) with DO UPDATE
+ to keep latest model features
+ - Change insert_recommendation_outcomes to insert-ignore on (game_pk, batter_name, slot, market)
+ - Deduplicate existing recommendation_logs and recommendation_outcomes (CREATE AS SELECT DISTINCT ON
+ → TRUNCATE → INSERT back)
+ - Add UNIQUE indexes to both tables
+ - Revert Fix 1 (dedup CTE in audit view) since it would become unnecessary
+
+ What Plan B does NOT do (regardless of outcome)
+
+ - Does not change read_recommendation_audit_view column list
+ - Does not remove slot from either table
+ - Does not change the batter_prop_outcomes schema
+
+ ---
+ Critical Files for Plan A
+
+ ┌──────────────────────────────────────┬───────┬──────────────────────────────────────────────────────────────────────────────┐
+ │                 File                 │  Fix  │                                    Change                                    │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ database/db.py:485–532               │ Fix 1 │ Replace flat JOIN with DISTINCT ON CTE in read_recommendation_audit_view     │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ analytics/game_completion.py:492     │ Fix 2 │ Add game_pk filter on audit_df                                               │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ analytics/batter_prop_grader.py      │ Fix 3 │ Add dedup on (game_pk, batter_name, market) before return                    │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ database/db.py                       │ Fix 4 │ Add delete_batter_prop_outcomes_for_game() helper                            │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ analytics/game_completion.py:497     │ Fix 4 │ Scoped delete before Step 3 insert                                           │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ database/db.py                       │ Fix 5 │ Add read_batter_prop_outcomes_for_game() helper                              │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ analytics/game_completion.py:507–515 │ Fix 5 │ Scoped read/delete/insert for Step 4                                         │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ app.py:2691–2700                     │ Fix 6 │ Manual button uses replace instead of insert                                 │
+ ├──────────────────────────────────────┼───────┼──────────────────────────────────────────────────────────────────────────────┤
+ │ database/db.py                       │ Fix 7 │ Add CREATE UNIQUE INDEX IF NOT EXISTS in ensure_batter_prop_outcomes_table() │
+ └──────────────────────────────────────┴───────┴──────────────────────────────────────────────────────────────────────────────┘
+
+ What Is NOT Changed in Plan A
+
+ - recommendation_logs — no schema changes, no TRUNCATE, no UNIQUE constraints
+ - recommendation_outcomes — no schema changes, no TRUNCATE, no UNIQUE constraints
+ - insert_recommendation_logs — unchanged
+ - insert_recommendation_outcomes — unchanged
+ - _bulk_insert — unchanged
+ - build_recommendation_log_rows — unchanged
+ - build_recommendation_outcome_rows — unchanged
+ - All table column names and types — unchanged
+ - replace_batter_prop_outcomes — unchanged
+╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
+
+ Claude has written up a plan and is ready to execute. Would you like to proceed?
+
+ ❯ 1. Yes, clear context (61% used) and auto-accept edits
+   2. Yes, auto-accept edits
+   3. Yes, manually approve edits
+   4. Type here to tell Claude what to change