llws ev #144
Merged
chrisp
merged 2 commits from 2026-08-27 17:40:25 +00:00
claude/llws-ev-calculation-bug-30xpxg into main
2 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Claude
|
1e215c3ac9
|
Fix three defects found reviewing the bracket entry-floor work
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
|
||
|
Claude
|
7ec17e417d
|
Fix EV reporting 20 pts for both LLWS 5-6 and 7-8 locked tiers
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 |