llws ev #144

Merged

chrisp merged 2 commits from claude/llws-ev-calculation-bug-30xpxg into main

2026-08-27 17:40:25 +00:00

chrisp commented

2026-08-27 17:33:17 +00:00

Owner

No description provided.

chrisp added 2 commits 2026-08-27 17:33:18 +00:00

Fix EV reporting 20 pts for both LLWS 5-6 and 7-8 locked tiers 7ec17e417d

After an LLWS simulation, a team locked into the 5th-6th tier and one
locked into the 7th-8th tier both showed 20 points EV. They should show
25 and 15.

The simulator and calculateEV were both right. A team locked into the
5-6 tier comes out of llws-simulator at probFifth = probSixth = 0.5, and
against DEFAULT_SCORING_RULES (100/70/50/40/25/25/15/15) that is 25 —
matching calculateBracketPoints, which already knows llws_20 splits 5-8
into two tiers. The Admin -> Expected Values page just wasn't using that
table. It hardcoded its own stale copy:

  const SCORING = [100, 70, 45, 45, 20, 20, 20, 20] as const;

0.5*20 + 0.5*20 = 20 for either tier.

It is not LLWS-specific. Four places carried that same stale table, and
it stayed invisible because a standard single-elimination bracket puts
all four quarterfinal losers in one tier worth avg(25,25,15,15) = 20 —
the same number. It only diverges for the templates that split 5-8
(llws_20, afl_10) and those with a distinct 3rd/4th (llws_20, fifa_48,
where 45/45 should be 50/40). Two of the four *persist* EVs computed
that way, so the wrong values reached the database:

  - expected-values.tsx      displayed EV, the total, and the sort order
  - expected-values.server   manual EV entry, written to expected_value
  - golf-skills.tsx          simulation EVs + snapshots, written
  - surface-elo.tsx          simulation EVs + snapshots, written

All four now use the shared DEFAULT_SCORING_RULES. probability-updater
had a fourth inline copy with the right values; it is folded in too so
there is one table left. The page's 340 total-EV invariant is unchanged
— both tables sum to 340.

A second path collapses the same two tiers, this time in real fantasy
points. calculateBracketPoints falls back to the flat avg([5,6,7,8])
when bracketTemplateId is null, and four call sites resolved the
template by taking an arbitrary scoringEvents row for the sports season
— unordered, and not filtered to rows that actually carry a template. A
season can own several events (a bracket plus schedule events, or a
re-created bracket beside a stale one), so a null row wins at random and
llws_20 is lost. New getBracketTemplateIdsForSportsSeasons in
models/bracket-template.ts filters to events with a template and takes
the most recent, the same rule llws-simulator uses to pick its bracket
event; standings, calculateTeamScore, calculateTeamProjectedScore and
getDraftedParticipantsWithPoints all go through it.

Tests: evFromProbs pinned to 25 / 15 / 20-for-a-single-5-8-tier and the
340 invariant; the new lookup against a mixed set of events; and two
llws-simulator tests that play out a full U.S. side so a team really is
locked into each tier and must come out at exactly 50/50 across it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EmUdy42Rpgx9qZTnpQwirz

Fix three defects found reviewing the bracket entry-floor work

🚀 Deploy / 🧪 Test (pull_request) Successful in 3m14s

Details

🚀 Deploy / ʦ🔍 Typecheck & Lint (pull_request) Successful in 1m18s

Details

🚀 Deploy / 🐳 Build (pull_request) Has been skipped

Details

🚀 Deploy / 🚀 Deploy (pull_request) Has been skipped

Details

1e215c3ac9

All three predate the EV fix on this branch and were surfaced by a review
of the full main..HEAD range.

1. reprocess-bracket skipped its wipe exactly when it was needed.

   The wipe was guarded on `completed.length > 0`, but clear-bracket
   deliberately leaves placements alone and tells the admin to "Run
   Reprocess Bracket after rebuilding to clear the placements those
   results produced". After clear then regenerate nothing is completed,
   so the wipe was skipped and the discarded bracket's finalized
   placements survived — and upsertParticipantResult's never-un-finalize
   guard then stopped the entry floors and the replay from correcting
   them. The advertised recovery path could not work.

   The guard was not arbitrary: seasonParticipantResults is keyed by
   sports season, not by event, so a season-wide delete takes every
   other event's placements with it. Rather than flip the condition,
   narrow the delete. New deleteParticipantResultsForParticipants scopes
   it to the participants the bracket actually holds, which removes the
   collateral damage the guard was defending against, so the delete can
   run unconditionally. The participant set was already being computed
   further down for the elimination pass; it is now built once and
   reused. The qualifying branch keeps its season-wide delete, which is
   deliberate and rebuilds via finalizeQualifyingPoints.

2. Banked entry floors could miss teamStandings.totalPoints.

   generate-bracket recalculated standings only when `toEliminate` was
   empty, assuming markEliminatedAndAnnounce covers every other case. It
   does not — it recalculates only when the event is non-qualifying AND
   somebody was *newly* eliminated, i.e. had no prior result row. So the
   second run of a generation (the first wrote 0 for every non-bracket
   participant) recalculated nowhere, and neither did a qualifying event
   with teams to eliminate. The floors never reached the standings.

   markEliminatedAndAnnounce now returns { markedCount, recalculated }
   and the caller drives off that fact instead of re-deriving it, which
   also covers the case where the announcement threw — the catch
   swallows the error, and a failed recalc is precisely when the
   fallback should run.

3. The NBA mobile pager fell back to index geometry.

   Its BracketTreePaginated was the only one of five call sites not
   forwarding feeders/template, so mobile rendered "TBD" where desktop
   rendered "Winner of ...".

Tests: reprocess wipes on a bracket with nothing played, stays scoped to
the bracket, dedupes and skips empty slots, and leaves the qualifying
path alone; generate recalculates in each of the four gaps above and
still does not double-recalculate; and the NBA layout gives its mobile
pane the same slot labels as desktop. Each was confirmed to fail against
the previous behavior.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EmUdy42Rpgx9qZTnpQwirz