fplkit 2.7.0__tar.gz → 2.7.1__tar.gz

{fplkit-2.7.0 → fplkit-2.7.1}/.agents/TOOLS.md

@@ -39,7 +39,7 @@ with `2>/dev/null` without losing the table, whichever command it runs.
 | `player` | Look up a player's stats, xG, ownership and fixture run. Before GW10 `quality_score` blends last season's pedigree in and JSON `metadata.warnings` says so (`early_season_prior_informed`, or `early_season_small_sample` when history could not be loaded), same as `fpl stats --value`; `understat_team_unmatched` joins it for any club Understat carried no players for, whose whole squad loses xG enrichment. JSON includes `ep_next` (predicted pts next GW) and `ep_this` (current GW), emitting `null` when FPL has no projection; panel shows `xPts` (ep_next) when available, omits the segment when FPL has no projection. `--detail` (`-d`) shows GW-by-GW performance and, for FWD/MID with sufficient history, xGI sustainability (per-match GI-xGI divergence -> form modifier). With `custom_analysis`: JSON adds `info.adjusted_npxg_per_90` (fixture-adjusted) and `info.raw_npxg_per_90` (Understat season avg); panel shows `adj. npxG/90: X.XXX (raw: Y.YYY)` | Yes | General | No | direct-api |
 | `stats` | List players with filtering and sorting. `--value` adds quality/value per £m columns; `--window N` sets rolling lookback (3-10) for `rolling_pts_per_m`. Before GW10, `--value` quality scores blend last season's pts/90 pedigree with this season's observation and the command says so (stderr notice quoting the observation's weight band; JSON `metadata.warnings` code `early_season_prior_informed`); when last season's history cannot be loaded they are pure observation and the notice says that instead (`early_season_small_sample`, before GW6). `understat_team_unmatched` is raised once per club Understat carried no players for, whose whole squad scores without xG. GK ceilings scale with the calendar-possible sample, reaching full scale at GW6. Sortable by `ep_next`/`ep_this` (FPL predicted points; `ep_this` is only meaningful before the gameweek's first kickoff — FPL rolls it forward to `ep_next` as each player's match finishes); both in JSON output (emit `null` when FPL has no projection; table renders `—`). Players with no projection sort to the bottom in either direction | Yes | General | No | direct-api |
 | `history` | Show historical player performance across seasons. A provider that refuses exits 1 in both output formats, carrying the upstream's own reason: the error envelope used to say only `Failed to fetch historical data` while the cause went to stderr, and table mode printed the cause to stdout and exited 0 | Yes | General | No | direct-api |
-| `league` | Show live league standings for Classic and Draft leagues | No | General | No | direct-api |
+| `league` | Show live league standings for Classic and Draft leagues. Classic positions are competition-ranked from cumulative totals — managers level on points share a place and the next distinct total skips the places they consumed — matching `fpl review` and the league history ledger rather than the standings API's sequential rank, which splits such a tie on fewest transfers season-to-date, a figure no column shows. Draft keeps the league's own rank, which already applies the head-to-head points-for tie-break | No | General | No | direct-api |
 | `fdr` | Analyse fixture difficulty - easy runs, blanks, doubles. Three payloads, not one: the default call runs the agent and returns the full analysis plus `data.ratings_warning` (the team-ratings quality verdict, and with `--my-squad` also `data.predictions_stale` / `data.prediction_warnings` / `data.squad_exposure`); with custom analysis off it returns raw 1-5 FPL API difficulty (`data.easy_fixture_runs` only, `metadata.custom_analysis: false`, no ratings and so no warning); `--blanks` bypasses the agent for a schedule-only payload carrying neither the FDR analysis nor `ratings_warning`. `--blanks` mixes confirmed fixtures with predictions; when those predictions are stale, table mode warns on stderr and JSON adds a `fixture_predictions_stale` entry to `metadata.warnings` | Yes | General | No | via-agent |
 | `xg` | Analyse underlying stats: xG, xA, overperformers. The minutes floor and the window scale to the gameweeks played (`min(60 x window, 45 x gameweeks played)`, so 90 minutes over 2 GWs rather than an unreachable 360 over 6); the configured bar binds from GW9, or GW11 for `--all`. JSON `metadata` carries `window_label`, `gameweeks_played` and `min_minutes`, and `metadata.warnings` an `early_season_minutes_floor` notice while the bar is scaled, plus `understat_team_unmatched` for any club Understat carried no players for. When nothing qualifies, `data.empty_reason` says whether the floor (`below_minutes_floor`) or the data (`no_minutes_played`) caused it | Yes | General | No | via-agent |
 | `price-changes` | Show price changes and transfer activity | No | General | No | via-agent |

{fplkit-2.7.0 → fplkit-2.7.1}/CHANGELOG.md

@@ -1,6 +1,29 @@
 # Changelog
 
 All notable changes to this project will be documented in this file.
+## [2.7.0] - 2026-09-08
+
+### Bug Fixes
+
+- never record rank movement out of a league's first gameweek (#325)
+- stop the gameweek review narrative inventing its own counts (#328)
+- keep the settled league position, not a mid-settlement one (#331)
+- keep players who have never appeared off the review's Blankers list (#333)
+- stop draft recaps reading an outbid manager as one who never tried (#334)
+- mark the reader's own row in the saved review's Nearby Rivals table (#335)
+- give managers level on points the same position in the review (#338)
+- record the waiver claims a draft manager lost in the league ledger (#339)
+- fine every manager who ties for last, not just one of them (#340)
+
+### Features
+
+- surface contested waiver claims in the draft recap (#341)
+
+### Other
+
+- No AFCON this season
+- add back mention of AFCON transfers
+
 ## [2.6.1] - 2026-09-07
 
 ### Bug Fixes

{fplkit-2.7.0 → fplkit-2.7.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: fplkit
-Version: 2.7.0
+Version: 2.7.1
 Summary: CLI tool for Fantasy Premier League analysis - classic and draft formats
 Project-URL: Homepage, https://github.com/rossgroomio/fpl-cli
 Project-URL: Repository, https://github.com/rossgroomio/fpl-cli

{fplkit-2.7.0 → fplkit-2.7.1}/docs/architecture.md

@@ -547,7 +547,7 @@ fpl_cli/
 │   ├── contract.py               # Runtime tripwires: CSV header checks + empty-output warnings for dataset drift
 │   ├── dataset_fetcher.py         # DatasetFetcher (disk cache with ETag/TTL for GitHub CSVs)
 │   ├── fpl.py                    # FPLClient (main API, caches bootstrap-static)
-│   ├── fpl_draft.py              # FPLDraftClient + match_draft_to_main() + the transaction `result` vocabulary (`is_accepted_transaction()` / `is_lost_claim()`, issue #329). The feed carries denied claims alongside accepted ones and the two denial codes differ: `di` is a claim a rival won -- a genuine attempt -- while `do` means the manager's own earlier accepted claim had already consumed the drop, a conditional-chain cascade that is never an attempt. Consumers filter through these two predicates rather than comparing `result` themselves, so a move ledger never counts a denied row and an activity question never misses one
+│   ├── fpl_draft.py              # FPLDraftClient + match_draft_to_main() + the transaction `result` vocabulary (`is_accepted_transaction()` / `is_denied_on_the_incoming_player()` / `resolve_lost_claims()`, issues #329, #342). The feed carries denied claims alongside accepted ones, and the two denial codes say which side of the claim was already gone rather than who took it: `di` is the incoming player, `do` the nominated drop. Neither is a defeat on its own -- the engine processes claims league-wide in `index` order, so a manager's own winning claim removes the incoming player exactly as a rival's does, and a manager who wins a player he also listed lower down gets a `di` for the player he just won. What a manager actually lost is therefore only answerable from his whole gameweek, which is `resolve_lost_claims()`: it drops a `di` only where a claim of that manager's had *already taken* the player -- ordering, not end-of-gameweek ownership, since free agency runs after the whole waiver batch and a pickup there cannot have caused an earlier denial -- and returns a player he claimed several times once, at the best priority he spent, the same two rules `contested_draft_claims` states. Consumers go through these rather than comparing `result` themselves, so a move ledger never counts a denied row, an activity question never misses one, and a race a manager won is never reported as one he lost
 │   ├── understat.py              # UnderstatClient + match_fpl_to_understat(), understat_club_rows() (the club gate the matcher and `fpl doctor --providers` share), understat_join_warnings(), understat_name_join_stats() (the name-level join rate, the signal a silently unmatched player had none of), decode_entities() (Understat escapes its payload for HTML, so it is decoded once at the fetch boundary), matches_in_season() (the season guard behind get_team())
 │   ├── historical_types.py       # Shared dataclasses (SeasonHistory — incl. the four optional per-90 DEF/GK rates only Core-Insights publishes, PlayerProfile, GwTrendProfile) + compute_trend/compute_acceleration/compute_reliability
 │   ├── vaastav.py                # VaastavClient (the two oldest seasons of the window via DatasetFetcher)
@@ -594,7 +594,7 @@ fpl_cli/
 │   └── types.py                  # TypedDicts: CaptainCandidate, WaiverTarget, EnrichedPlayer, etc.
 ├── prompts/
 │   ├── scout.py                  # ScoutAgent system/user prompts
-│   ├── review.py                 # Review research + synthesis prompts. Squad and transfer lines in the synthesis data block carry each player's full club name, and the hard constraints bind club affiliation and blanket scored/blanked claims to that supplied data — an LLM's own club knowledge goes stale every transfer window. The synthesis prompt also carries a `<next_gameweek>` block — every club's next fixture and each squad player's positional FDR, built by `_review_next_gameweek` / `_format_next_gameweek` — and the "Next Week" instruction switches on whether it is there: grounded advice when it is, fixture-independent observations pointing at `fpl gw-prep` when it is not, because a results-only review was issuing confident fixture-dependent calls with no fixture data behind them (#191), with `check_next_week_grounding` checking the answer back against that block -- a cited FDR figure the block never printed, or any fixture claim on a run that had no block -- so the grounding claim is not left resting on prompt prose alone, the way the research half's rules are backed by `validate_research_teams`. Also the synthesis half's post-generation guard (`check_synthesis_completeness`, `required_synthesis_sections`), which reads the required `## ` headings back off the prompt that was actually sent rather than restating them as a constant. The research half's counts are grounded the same way: `fixture_aggregates()` computes the fixture, goal, clean-sheet and goalless-draw totals once, `FixtureAggregates.summary_line()` pins them at the top of the GW Results block as the narrative's only permitted source, and `validate_research_counts` checks the narrative back against the same object — a count the prompt pins cannot drift from the count the check enforces. It rewrites a contradicting figure in place rather than scrubbing the sentence, and corrects one only when neither its sentence nor the one before it names anyone the count could belong to — a club, a nickname, a player, a pronoun standing in for one — because a round-wide total is exactly the sentence that names nobody. The guard errs towards leaving prose alone: a missed correction ships the model's own words, while a wrong one fabricates a claim in prose that was true. That blind spot is why the check was needed at all — the narrative that reported six clean sheets as four (#324) named no player, so all three name-based validators passed it
+│   ├── review.py                 # Review research + synthesis prompts. Squad and transfer lines in the synthesis data block carry each player's full club name, and the hard constraints bind club affiliation and blanket scored/blanked claims to that supplied data — an LLM's own club knowledge goes stale every transfer window. The synthesis prompt also carries a `<next_gameweek>` block — every club's next fixture and each squad player's positional FDR, built by `_review_next_gameweek` / `_format_next_gameweek` — and the "Next Week" instruction switches on whether it is there: grounded advice when it is, fixture-independent observations pointing at `fpl gw-prep` when it is not, because a results-only review was issuing confident fixture-dependent calls with no fixture data behind them (#191), with `check_next_week_grounding` checking the answer back against that block -- a cited FDR figure the block never printed, or any fixture claim on a run that had no block -- so the grounding claim is not left resting on prompt prose alone, the way the research half's rules are backed by `validate_research_teams`, which folds both the supplied name and the model's cell through `normalise_name` before the allowlist search so a reformat is not read as an invention, and leaves a `[table trimmed: N unlisted row(s) removed]` line under a table it did shorten — the strip notice otherwise reaching stderr and `--debug` only, both gone by the time the markdown is read (#343). Also the synthesis half's post-generation guard (`check_synthesis_completeness`, `required_synthesis_sections`), which reads the required `## ` headings back off the prompt that was actually sent rather than restating them as a constant. The research half's counts are grounded the same way: `fixture_aggregates()` computes the fixture, goal, clean-sheet and goalless-draw totals once, `FixtureAggregates.summary_line()` pins them at the top of the GW Results block as the narrative's only permitted source, and `validate_research_counts` checks the narrative back against the same object — a count the prompt pins cannot drift from the count the check enforces. It rewrites a contradicting figure in place rather than scrubbing the sentence, and corrects one only when neither its sentence nor the one before it names anyone the count could belong to — a club, a nickname, a player, a pronoun standing in for one — because a round-wide total is exactly the sentence that names nobody. The guard errs towards leaving prose alone: a missed correction ships the model's own words, while a wrong one fabricates a claim in prose that was true. That blind spot is why the check was needed at all — the narrative that reported six clean sheets as four (#324) named no player, so all three name-based validators passed it
 │   ├── returnees.py              # Return-intel search prompt for `fpl returnees --enrich` (one player per query, so a citation list belongs to a single player)
 │   └── league_recap.py           # League recap synthesis prompts, including the anchored League History section, its never-infer-history rule (emitted even when the pack is empty), and the season-phase framing instruction. The GW Standings section leads with an explicit "Previous gameweek's leader" fact (issue #189) so a "topped the table"/"fell from the top" claim is checkable against a stated name instead of inferred from the Prev column or the size of a fall, and the rules forbid merging two managers' separate League History entries into a shared record or "club". `collect_player_clubs()` regroups the club each squad/transfer row already resolved off its `team_id` by the name the prose uses, feeding both a `## Player Clubs` roster and the club printed inline on each captain group, so club claims bind to supplied data instead of recall; a name the data gives two clubs for is dropped rather than guessed at, since the prose can't tell the two players apart. Transfers get the same full-roster treatment as captains and chips (issue #71): `format_recap_transfers_context()` lists every manager who transferred with each move, the hit and the post-hit net, names who made none, and keeps a manager whose moves the collector could not capture among the movers with the moves marked unknown, so the rule pins transfer narration to that section rather than to the two award winners — the only transfer data the model used to see, which it read as the whole story. `format_recap_waivers_context()` is the draft half (issue #301): every waiver and free-agent move as it was made, never chain-contracted (that is the awards' display compression, not a record of activity), each tagged by kind through the shared `draft_transaction_kind_label()` / `draft_transaction_kind_counts()` in `_league_recap_types.py` so the roster and the waiver awards never describe one move in two vocabularies; the rule names that section as draft's source of truth and only falls back to "say nothing about moves" when neither roster is present. It states three groups rather than two (issue #329): movers, the managers who claimed a player and lost him to a rival, and the managers who did neither. A waiver is a competition, so an outbid manager ends the gameweek with no accepted move and used to be indistinguishable from one who submitted nothing -- the editorial read that absence as inactivity and assigned a motive for it, so the rule now forbids calling anyone in the outbid group idle. The section closes with the gameweek's contested players (issue #330) — one sentence per player more than one manager claimed, from `contested_draft_claims()` / `format_contested_claim()` in `_league_recap_types.py`, the same sentence the Most Contested award prints for a pile-up of `MOST_CONTESTED_MIN_CLAIMANTS` or more that a recapped manager won (a race nobody can be seen to have won is context, never the award), with a rule pinning who-wanted-whom to those lines and limiting what may be said of anyone's waiver order to the winner having stood higher in it. `format_recap_prior_seasons_context()` (issue #131) is the opener's one source of history: each classic manager's FPL-wide seasons before this one, folded once by `summarise_prior_seasons()` (`_league_recap_types.py`) so the saved report and the prompt read the same lines, with an explicit count, the no-record and unfetched managers named rather than omitted, and a rule pinning tenure to FPL-wide phrasing — entry and league IDs are reissued each season, so "Nth season in this league" is unknowable and the section says so
 ├── parsers/
@@ -608,7 +608,7 @@ fpl_cli/
     ├── gameweek.py                # is_opening_gameweek(gw) — shared GW1 check (transfers, waivers and league tables don't exist yet)
     ├── markdown.py                # HeadingMatcher, find_section, section_body, leaf_body, fence_flags — fence-aware markdown section location tolerant of LLM heading drift; shared by the gw-prep validator scripts and fpl_cli.prompts.review. Also unescape_specials/find_entities — repair and reporting for markdown that arrived HTML-escaped
     ├── teams.py                  # describe_team_set_mismatch — diff a per-team config against the live team list (promotion/relegation drift)
-    ├── text.py                   # strip_diacritics (name matching across sources)
+    ├── text.py                   # strip_diacritics (name matching across sources). normalise_name folds the rest of what a retyped name varies by — the apostrophe family onto U+0027, whitespace runs (NFKC, so non-breaking spaces too) and the space after an initial ("B. Fernandes" → "B.Fernandes") — on top of the diacritic strip and lowercasing. Apply it to both sides of a comparison. Shared by everywhere the review matches an LLM-written name against an API one: `validate_research_teams` / `ensure_top_performer_first` in prompts/review.py, and `_normalise_name` in cli/_review_summarisation.py, which layers its parenthetical and leading-initial strips on top for `--compare-recs`. Neither a `\b`-anchored regex nor an equality test survives any of these differences: they cost a valid row in the review's Disappointments table, and would read a captain that was in fact fielded as a recommendation ignored (#343). Also ordinal_suffix/ordinal_word
     └── time.py                   # format_deadline/format_kickoff/format_generated_at — UK local (Europe/London, auto GMT↔BST). Canonical formatter for every user-facing timestamp.
 
 platformdirs (user_config_dir / user_data_dir)  # macOS: ~/Library/Application Support/fpl-cli/
@@ -712,5 +712,5 @@ A settings block present but empty — every line under it commented out — par
 - **One allocation and one merge for the historical sources.** `historical_season_windows()` (`api/historical.py`) is the only place that decides which of the four seasons a profile spans come from Core-Insights (the newest two, all it publishes) and which from vaastav (the two before), and `make_historical_provider()` and `fpl doctor --providers` both read it. `merge_season_histories()` then keeps one row per `(element_code, season)` with Core-Insights outranking vaastav and announces any repeat, so provenance is a decision rather than two window expressions happening to be disjoint: before #101 a widened window would have doubled a season in every per-season mean and taken two of the reliability window's three slots without raising.
 - **Season data frozen in code is surfaced, not guarded.** Every other season-derived artefact rolls or invalidates itself — the historical window rolls at the July cutover, a stale `player_prior.yaml` or `returnee_snapshot.json` is discarded and rebuilt. The calibrated quality ceilings cannot: they are measurements of a completed season's player cohort, and only re-running `scripts/calibrate_quality_ceilings.py --write` against a newly completed season can replace them. So the generated block records `CALIBRATION_SEASON` beside the fingerprint and `fpl doctor` compares it against the newest completed season (#128). It reports, rather than fails, on purpose: anchors from last season are correct for the whole season being played, so the mid-season state is not a defect, and a rollover changes the truth of the block with no commit behind it — a CI guard would have nothing to fire on until someone touched the code, which is exactly the case it is not for.
 - **Who a player *was* is remembered; where he played is re-derived.** A replay resolves every pick against today's bootstrap, so a player transferred or renamed since lands on a past gameweek's row wearing his current club and current name (issue #169). `_carry_recorded_identity` answers that by keeping what the gameweek already recorded, which works only where something *was* recorded — and two cases have nothing: a first capture, and a coarse row being upgraded, since the coarse tier stores headline numbers and no squad at all. The second is the documented workflow, so a mid-season first run plus `--backfill-detail` writes today's clubs across a whole season (issue #177). `services/player_clubs.py` closes the club half from the gameweek itself instead of from a prior row: the live payload records which fixtures each player's club played, a fixture names its two clubs, and the intersection is where he was — settled outright by a double, narrowed to a pair by a single, and paid for with one `element-summary` request only where today's club is absent from that pair, which is proof he moved and the one case the pair cannot resolve. Because it is *derived* rather than remembered, it also supersedes a recorded club, where name and position are only ever carried: a row a first capture or a coarse upgrade wrote holds today's club as fact, so carrying it forward would preserve the mistake permanently — the same earliest-not-winner lesson as #169, applied to a value the gameweek can recompute. Which makes the *precision* of "derived" load-bearing in both directions. A derivation must supersede a record even when it agrees with today's club, or a player who left and came back keeps a stale row forever; and an assumption must never be called a derivation, or today's club overwrites a correctly recorded one — which is why the ambiguous single-fixture case answers nothing rather than answering "he has not moved". Name and position stay carry-forward-only because fixtures say nothing about them, and a blanking club has nothing to intersect; both fall back to the recorded value, then to today's. A lost waiver claim names two players the way a move does and a replay restamps both the same way, so it is carried by the same rule — read off the earliest line that recorded any claims rather than the earliest squad line, since a gameweek captured before schema version 6 holds its squad on a line that records nothing about them (issue #332).
-- **Absence from the accepted set is not inactivity.** The draft transaction feed carries every claim the league processed, and a claim a rival won is evidence the manager was active — but the ledger held completed moves alone, so a manager whose whole gameweek was one lost claim was written into the permanent record as having sat it out, and the recap named real people as idle on that basis (issues #329, #332). The row now carries `lost_claims` beside `transactions` rather than a result code inside it: nothing moved, so a lost claim has no points and no net, and folding it into a list every consumer reads as completed moves — the waiver streaks sum `net` over it, the identity carry pairs it slot for slot — would have made each of them learn to skip entries. Only the lost-to-a-rival denial is recorded; the feed's other denial means the manager's own earlier accepted claim had already used the drop, which is the cascade behind a success and never an attempt. The field is three-state on purpose: a list is what the feed held, `[]` included, and `None` says nothing was recorded — a classic row, an unknown row, or a row written before the field existed. That last state is what makes the backfill work without a migration: `coverage()` counts such rows on draft partitions, `_gaps` hands those gameweeks to the detailed tier behind `--backfill-detail`, the replay re-records them from the feed while it still serves the season, and because `[]` differs in content from `None` the superseding line lands once and the target converges. Presence is carried as well as identity: the feed is a log, so a finished gameweek's claims are all in it and a replay that finds fewer has lost some — a player it can no longer place, or a gameweek the feed has stopped serving — and `_carry_recorded_claims` keeps the longest recorded list rather than letting the remnant supersede it, while a longer replayed list still lands as the correction it is.
+- **Absence from the accepted set is not inactivity.** The draft transaction feed carries every claim the league processed, and a claim a rival won is evidence the manager was active — but the ledger held completed moves alone, so a manager whose whole gameweek was one lost claim was written into the permanent record as having sat it out, and the recap named real people as idle on that basis (issues #329, #332). The row now carries `lost_claims` beside `transactions` rather than a result code inside it: nothing moved, so a lost claim has no points and no net, and folding it into a list every consumer reads as completed moves — the waiver streaks sum `net` over it, the identity carry pairs it slot for slot — would have made each of them learn to skip entries. Only genuine defeats are recorded, which neither denial code identifies by itself: `do` is the cascade behind a success, and `di` covers one too, since the manager's own winning claim removes the incoming player just as a rival's does (issue #342). `resolve_lost_claims()` settles both from the manager's whole gameweek, on the order the league processed it rather than on who owned the player by the end — so a waiver lost to a rival who then dropped him, and signed in free agency afterwards, stays the defeat it was — and dedupes a target he offered against several drops down to the one player he wanted. The field is three-state on purpose: a list is what the feed held, `[]` included, and `None` says nothing was recorded — a classic row, an unknown row, or a row written before the field existed. That last state is what makes the backfill work without a migration: `coverage()` counts such rows on draft partitions, `_gaps` hands those gameweeks to the detailed tier behind `--backfill-detail`, the replay re-records them from the feed while it still serves the season, and because `[]` differs in content from `None` the superseding line lands once and the target converges. Presence is carried as well as identity: the feed is a log, so a finished gameweek's claims are all in it and a replay that finds fewer has lost some — a player it can no longer place, or a gameweek the feed has stopped serving — and `_carry_recorded_claims` keeps the longest recorded list rather than letting the remnant supersede it, while a longer replayed list still lands as the correction it is.
 - **A row that knows less never supersedes one that knows more.** The ledger is append-only and reads take the newest row per manager, so a capture that writes a null over a recorded value destroys it as surely as an edit would — and permanently. Draft is where that bites: it has no per-manager history endpoint and its standings always describe the current gameweek, so a *replayed* draft gameweek derives no league position and no cumulative total at all. Writing those rows out cost the ledger every position that gameweek held, which is the one input the streak and season-count projections have, and each replay left a full set of dead lines behind (issue #223). Three things stop it. `_carry_recorded_standings` fills a null from the *latest-captured* line that recorded the field — read off the whole file rather than off `resolved_gameweek`'s winner, and ordered by `captured_at` rather than by position in it, since `append_rows` skips on tier rank alone and so does not guarantee the two agree — the same read-past-the-winner move `_carry_recorded_identity` makes, and for the same reason: by the time anyone notices, the degraded row is the winner. What keeps a degraded row out is the value being non-null, not the line being earliest, and that holds whichever way the pass runs; direction only settles which recorded value wins when several disagree, and there the later one is right — a gameweek captured repeatedly while bonus and late results were still landing holds a stale position in its first capture and the settled one in its last (issue #320). Identity stays earliest-first, because a name and a position do not settle over a gameweek the way a table does. `_fill_draft_standings` reconstructs what the ledger can supply on its own, summing a cumulative total from earlier gameweeks and ranking from it (at the league's start gameweek the total *is* the gameweek score, so `gross_points` alone settles that table), and derives a whole table or none of it. Every manager needs a total, because ranking the subset that summed cleanly would renumber everyone below whoever was left out; and no row may already carry a position, because `_assign_cohort_ranks` fills only the nulls, so a cohort part-carried and part-re-derived is ranked against two tables at once and lands two managers on the same place with nobody on the next. Draft breaks a head-to-head tie on points-for, which a cumulative total cannot reproduce, so those two rankings disagree in the ordinary case rather than only on a tie — and a null, which every streak condition holds across, beats a wrong position recorded as fact. `_repair_recorded_standings` then sweeps already-damaged gameweeks, ascending, on every run: it re-fetches nothing, so it needs neither `--backfill-detail` nor a request, and it is the only path that heals a ledger damaged before this existed. Filling only nulls is what makes all three idempotent — a genuine correction still lands, and a replay that reproduces a gameweek exactly now writes no line at all.

{fplkit-2.7.0 → fplkit-2.7.1}/docs/command-reference.md

@@ -750,7 +750,7 @@ fpl review --dry-run              # Build prompts without calling LLMs
 
 **Classic:** team summary, player-by-player breakdown (captain doubled/tripled), transfer assessment, league standings with nearby rivals, best/worst performers.
 
-**League position:** your own position and the `Pos` column of Nearby Rivals are competition-ranked from the cumulative totals, the same numbering `fpl league-recap` writes to the ledger: managers level on points share a place and the next distinct total skips the places they consumed (1, 2, 2, 4). The standings API hands out strictly sequential ranks instead, splitting a tie on fewest transfers season-to-date — a figure no column here shows — so the same gameweek used to place the same tie differently depending on which report you read.
+**League position:** your own position and the `Pos` column of Nearby Rivals are competition-ranked from the cumulative totals, the same numbering `fpl league`'s table shows and `fpl league-recap` writes to the ledger: managers level on points share a place and the next distinct total skips the places they consumed (1, 2, 2, 4). The standings API hands out strictly sequential ranks instead, splitting a tie on fewest transfers season-to-date — a figure no column here shows — so the same gameweek used to place the same tie differently depending on which report you read.
 
 **Draft:** squad breakdown, transaction assessment, league standings, best/worst performers.
 
@@ -1043,9 +1043,12 @@ priority it was made at. They sit apart from `transactions`, which stays the lis
 that happened — nothing moved here, so there are no points on either side and no net —
 because a manager whose whole gameweek was one claim they lost has no completed move,
 and a ledger holding moves alone wrote them into the permanent record as having sat the
-week out. Only claims lost to a rival are recorded: a claim denied because the manager's
-own earlier accepted claim had already dropped the nominated player is the cascade
-behind a claim that succeeded, not an attempt, and never appears (see
+week out. Only claims a rival won are recorded, which the feed's denial codes do not
+identify on their own: a claim denied because the manager's own earlier accepted claim
+had already dropped the nominated player is the cascade behind a success, and so is a
+claim denied because he had just won the incoming player himself — both are read against
+his whole gameweek and neither appears. A player he claimed several times against
+different drops is one claim, at the best priority he spent on him (see
 [Conditional chains and outcomes](fpl-rules.md#waivers)). A replay that finds fewer
 claims than the gameweek recorded keeps the recorded list and says so
 (`league_history_claims_carried`): a claim whose player can no longer be placed is

{fplkit-2.7.0 → fplkit-2.7.1}/docs/fpl-rules.md

@@ -189,15 +189,21 @@ Processed **24 hours before the GW deadline**. After processing, **free agency**
 
 **Locked players** (unavailable for waivers): players added to the game within 24 hours of the waiver deadline, or players recently dropped from another squad. Locked players become available at the next waiver deadline.
 
-**Conditional chains and outcomes.** A manager submits several claims in their own priority order, and claims may share a drop, so only one of a group is ever expected to land. Each submitted claim ends in one of three states, and the last two are not the same thing:
+**Conditional chains and outcomes.** A manager submits several claims in their own priority order. Claims may share a drop, and may name one target against several drops, so only one of a group is ever expected to land. Claims are processed league-wide in a single order, and each ends in one of three states:
 
 | Outcome | Meaning |
 |---|---|
 | Accepted | The claim was processed; the incoming player joined the squad and the nominated player was dropped |
-| Lost to a rival | A manager with higher priority claimed the same player. A genuine attempt, and the manager ends with no move from it |
-| Drop already used | An earlier accepted claim by the same manager had already dropped the nominated player, so this one could not be processed. The cascade behind a claim that succeeded, not an attempt that failed - it cannot occur without that earlier accepted claim |
+| Incoming player gone | Someone had already taken him by the time this claim processed, so it could not be filled |
+| Drop already used | An earlier accepted claim by the same manager had already dropped the nominated player, so this one could not be processed. It cannot occur without that earlier accepted claim |
 
-Only accepted claims changed a squad, so only they belong in a record of moves. But a manager who submitted claims and lost them all was active, and reading their absence from the accepted set as inactivity misreports them.
+Neither denial says on its own whether the manager lost anything, because "someone" in the second row includes the manager himself. A manager who wins a player at one priority and listed him again lower down gets an "incoming player gone" for the player he just won — the same self-cascade the third row describes, arriving on the other side of the claim. Only a denial where a **different** manager took the player is a defeat.
+
+So a claim's outcome is only readable against the manager's whole gameweek, never from the claim alone. Two rules follow: a denial for a player one of the manager's own claims had **already taken** is his own cascade, not a loss; and a player he claimed several times and lost was wanted once, not once per drop he offered.
+
+The first rule turns on order, not on who ends the gameweek owning the player. Waivers process as one batch and free agency opens only afterwards, so a manager who loses a waiver to a rival, and signs the same player once that rival drops him, still lost the waiver.
+
+Only accepted claims changed a squad, so only they belong in a record of moves. But a manager who submitted claims and genuinely lost them all was active, and reading their absence from the accepted set as inactivity misreports them.
 
 ### Free Agents
 Unclaimed players can be picked up first-come, first-served in the **24-hour window before each GW deadline**. Free agent pickups don't affect waiver priority.

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '2.7.0'
-__version_tuple__ = version_tuple = (2, 7, 0)
+__version__ = version = '2.7.1'
+__version_tuple__ = version_tuple = (2, 7, 1)
 
 __commit_id__ = commit_id = None

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/api/fpl_draft.py

@@ -17,22 +17,28 @@ logger = logging.getLogger(__name__)
 BASE_URL = "https://draft.premierleague.com/api"
 
 # The Draft API's transaction `result` codes. Every row the league processed
-# carries one, and the two denial codes do not mean the same thing -- reading
-# either as "no move happened" is right, reading either as "no attempt was
-# made" is wrong for one of them and right for the other (issue #329).
+# carries one, and the two denial codes say which side of the claim was
+# already gone -- not who took it (issues #329, #342).
 #
 # `a`  -- the league processed the claim into a completed move.
-# `di` -- denied because a rival won the incoming player. A genuine
-#         competitive loss: the manager tried and was beaten to him.
-# `do` -- denied because the outgoing player had already been used as the
-#         drop in an earlier accepted claim by the same manager. Managers
-#         submit several claims sharing one drop slot expecting only one to
-#         land, so this is the cascade behind a claim that succeeded, not an
-#         attempt that failed. It cannot occur without that earlier accepted
-#         claim, so a `do` row never stands alone as a manager's only
-#         activity.
+# `di` -- denied on the *incoming* side: the player was gone when this claim
+#         processed. Usually a rival won him, which is a genuine competitive
+#         loss. But the engine processes claims globally in `index` order and
+#         a manager's own earlier accepted claim removes him exactly as a
+#         rival's does, so a manager who wins a player and also listed him
+#         lower down gets a `di` for the player he just won.
+# `do` -- denied on the *outgoing* side: the player nominated as the drop had
+#         already been used as the drop in an earlier accepted claim by the
+#         same manager. It cannot occur without that earlier accepted claim,
+#         so a `do` row never stands alone as a manager's only activity.
+#
+# Both denials therefore cover a self-cascade as well as a real defeat, which
+# is why the code alone cannot say whether a manager lost anything: managers
+# submit several claims sharing one drop slot, or naming one target against
+# several drops, expecting only one to land. `resolve_lost_claims()` answers
+# that from the manager's whole gameweek; a single row cannot.
 DRAFT_TXN_ACCEPTED = "a"
-DRAFT_TXN_LOST_TO_RIVAL = "di"
+DRAFT_TXN_DENIED_PLAYER_GONE = "di"
 DRAFT_TXN_DROP_ALREADY_USED = "do"
 
 
@@ -45,14 +51,89 @@ def is_accepted_transaction(txn: Mapping[str, Any]) -> bool:
     return txn.get("result") == DRAFT_TXN_ACCEPTED
 
 
-def is_lost_claim(txn: Mapping[str, Any]) -> bool:
-    """Whether this row is a claim the manager submitted and a rival won.
+def is_denied_on_the_incoming_player(txn: Mapping[str, Any]) -> bool:
+    """Whether this row was denied because the incoming player was gone.
 
     True for `di` alone. A `do` row is deliberately excluded: counting it as
     a failed attempt would misreport the manager whose *winning* claim caused
     it, which is the misattribution this classification exists to prevent.
+
+    Row-local, and so not the same question as "did this manager lose the
+    player" -- his own winning claim makes him gone too. Callers wanting that
+    want `resolve_lost_claims()`.
+    """
+    return txn.get("result") == DRAFT_TXN_DENIED_PLAYER_GONE
+
+
+def draft_claim_priority_rank(priority: int | None) -> tuple[int, int]:
+    """Sort key placing a numbered priority before none at all, 1 first."""
+    return (1, 0) if priority is None else (0, priority)
+
+
+def _processing_position(txn: Mapping[str, Any], arrival: int) -> tuple[int, int, int]:
+    """Where one row sits in the order the league processed the gameweek.
+
+    Waivers run first, as a single batch the engine works through in `index`
+    order; free agency opens once that batch is done and its rows carry no
+    index at all. `arrival` is the row's place in the feed, which orders the
+    rows an index cannot separate.
+    """
+    index = txn.get("index")
+    return (0, index, arrival) if isinstance(index, int) else (1, 0, arrival)
+
+
+def resolve_lost_claims(txns: Sequence[dict[str, Any]]) -> list[dict[str, Any]]:
+    """The claims one manager genuinely lost, from all their rows for one
+    gameweek -- the question no single row can answer (issue #342).
+
+    Two things a row-local read gets wrong, both consequences of managers
+    submitting conditional chains rather than independent claims:
+
+    - A `di` for a player this manager had *already taken* is his own cascade,
+      not a defeat. He listed the same target twice with different drops, one
+      landed, and every later claim for him was then denied on the incoming
+      side. Reporting it inverts the outcome for the manager who won the race.
+    - A player he claimed several times and lost was wanted once, so he is
+      returned once, at the best priority he spent on him. Otherwise one
+      target across three drops reads as three separate defeats.
+
+    "Already taken" is a question about order, not merely about owning him by
+    the end of the gameweek: only a claim that landed *before* the denial can
+    have caused it. Free agency opens after the whole waiver batch, so a
+    manager who loses a waiver to a rival and signs the same player as a free
+    agent once the rival drops him still lost that waiver, and the loss is
+    still recorded -- clearing it on the later pickup would erase a real
+    defeat and contradict the case `contested_draft_claims` documents.
+
+    Both rules are the ones that function already states and works to; this
+    brings the stored claims into line with them, so the two layers cannot
+    disagree about what a manager lost. Order follows the feed, by the row
+    kept for each player.
     """
-    return txn.get("result") == DRAFT_TXN_LOST_TO_RIVAL
+    # The earliest point at which a claim of this manager's took each player.
+    taken_at: dict[Any, tuple[int, int, int]] = {}
+    for arrival, txn in enumerate(txns):
+        if not is_accepted_transaction(txn):
+            continue
+        player = txn.get("element_in")
+        at = _processing_position(txn, arrival)
+        if player not in taken_at or at < taken_at[player]:
+            taken_at[player] = at
+
+    best: dict[Any, dict[str, Any]] = {}
+    for arrival, txn in enumerate(txns):
+        player = txn.get("element_in")
+        if player is None or not is_denied_on_the_incoming_player(txn):
+            continue
+        taken = taken_at.get(player)
+        if taken is not None and taken < _processing_position(txn, arrival):
+            continue
+        known = best.get(player)
+        if known is None or draft_claim_priority_rank(txn.get("priority")) < draft_claim_priority_rank(
+            known.get("priority"),
+        ):
+            best[player] = txn
+    return list(best.values())
 
 
 class FPLDraftClient:

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/_league_recap_data.py

@@ -2033,8 +2033,8 @@ async def collect_draft_recap_data(
     from fpl_cli.api.fpl_draft import (
         FPLDraftClient,
         is_accepted_transaction,
-        is_lost_claim,
         match_draft_to_main,
+        resolve_lost_claims,
     )
     from fpl_cli.models.player import POSITION_MAP
 
@@ -2073,15 +2073,22 @@ async def collect_draft_recap_data(
         # but who was active cannot -- a manager whose only claim a rival won
         # has no accepted row and used to be indistinguishable from one who
         # submitted nothing (issue #329). So both are kept, separately.
+        #
+        # Bucketed by manager *before* either question is asked: what a
+        # manager lost is only answerable from his whole gameweek, since a
+        # claim denied on a player he went on to win is his own cascade
+        # rather than a defeat (issue #342).
         txn_response = await draft_client.get_league_transactions(draft_league_id)
         all_txns: list[dict[str, Any]] = txn_response.get("transactions", [])
         gw_txns = [t for t in all_txns if t.get("event") == gw]
-        txns_by_entry = _bucket_draft_txns_by_league_entry(
-            [t for t in gw_txns if is_accepted_transaction(t)], league_entries,
-        )
-        lost_by_entry = _bucket_draft_txns_by_league_entry(
-            [t for t in gw_txns if is_lost_claim(t)], league_entries,
-        )
+        by_entry = _bucket_draft_txns_by_league_entry(gw_txns, league_entries)
+        txns_by_entry = {
+            le_id: [t for t in rows if is_accepted_transaction(t)]
+            for le_id, rows in by_entry.items()
+        }
+        lost_by_entry = {
+            le_id: resolve_lost_claims(rows) for le_id, rows in by_entry.items()
+        }
 
         # Fetch picks for each manager
         sem = asyncio.Semaphore(_PICKS_CONCURRENCY)

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/_league_recap_types.py

@@ -6,6 +6,7 @@ from collections.abc import Iterable, Sequence
 from dataclasses import dataclass
 from typing import NotRequired, TypedDict
 
+from fpl_cli.api.fpl_draft import draft_claim_priority_rank
 from fpl_cli.utils.text import ordinal_word
 
 
@@ -656,11 +657,6 @@ def _contested_player_key(
     return (move["player_in"], move["player_in_team"])
 
 
-def _priority_rank(priority: int | None) -> tuple[int, int]:
-    """Sort key placing a numbered priority before none at all, 1 first."""
-    return (1, 0) if priority is None else (0, priority)
-
-
 def _contest_winner(
     accepted: Sequence[tuple[int, str]], claimants: Iterable[RecapContestedClaimant],
 ) -> int | None:
@@ -688,22 +684,27 @@ def contested_draft_claims(
     contested first: by claimant count, then by how early the beaten
     managers ranked him (two first-choice claims outrank one), then by name.
 
-    Regrouped from the manager rows rather than fetched: a `di` row in the
-    feed means a rival won the player, so the gameweek's lost claims, bucketed
-    by player, are the races, and the accepted move that brought the same
-    player in names the winner (issue #330). Read off the raw move list, not
+    Regrouped from the manager rows rather than fetched: a stored lost claim
+    is one a rival won, so the gameweek's lost claims, bucketed by player, are
+    the races, and the accepted move that brought the same player in names the
+    winner (issue #330). Only the stored claims carry that meaning -- the
+    feed's `di` code says the incoming player was gone, which the manager's
+    own winning claim also causes; `resolve_lost_claims()` settles that
+    upstream (issue #342). Read off the raw move list, not
     the awards' chain-contracted one, so a manager who won a player and moved
     him on again the same gameweek still won him.
 
     A manager who lost several claims on one player -- a conditional chain
     offering different drops for him -- wanted him once, and is named once,
     at the highest priority they gave him. The winner is never also among
-    the beaten: once a manager's first claim for a player lands, any later
-    claim of theirs for him is denied on the incoming side (a `di`, since it
-    is the incoming player that is gone), and a manager who lost the waiver
-    and signed him as a free agent later the same gameweek carries both
-    rows too. Either way they wanted him once and got him, and a player
-    nobody else wanted is then no race at all. Empty for classic, whose rows
+    the beaten: a manager who lost the waiver and signed him as a free agent
+    later the same gameweek carries both rows. Either way they wanted him
+    once and got him, and a player nobody else wanted is then no race at all.
+
+    Both rules now hold of the stored claims before this runs, since
+    `resolve_lost_claims()` applies them at ingestion -- these are kept as
+    the guarantee this function owns, so a caller handing it claims from
+    anywhere still gets one row per manager per race. Empty for classic, whose rows
     carry no claims.
     """
     players: dict[_ContestedPlayerKey, RecapDraftLostClaim] = {}
@@ -719,7 +720,9 @@ def contested_draft_claims(
         for claim in m.get("lost_claims") or []:
             key = _contested_player_key(claim)
             known = best.get(key)
-            if known is None or _priority_rank(claim["priority"]) < _priority_rank(known["priority"]):
+            if known is None or draft_claim_priority_rank(claim["priority"]) < draft_claim_priority_rank(
+                known["priority"],
+            ):
                 best[key] = claim
         for key, claim in best.items():
             players.setdefault(key, claim)
@@ -733,7 +736,7 @@ def contested_draft_claims(
         winner = _contest_winner(accepted.get(key, []), wanted.values())
         beaten = sorted(
             (c for position, c in wanted.items() if position != winner),
-            key=lambda c: (_priority_rank(c["priority"]), c["manager_name"]),
+            key=lambda c: (draft_claim_priority_rank(c["priority"]), c["manager_name"]),
         )
         if not beaten:
             continue
@@ -752,7 +755,7 @@ def contested_draft_claims(
 
     contests.sort(key=lambda c: (
         -c["claimants"],
-        tuple(_priority_rank(loser["priority"]) for loser in c["losers"]),
+        tuple(draft_claim_priority_rank(loser["priority"]) for loser in c["losers"]),
         c["player"],
         c.get("player_code") or 0,
     ))

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/_review_classic.py

@@ -443,8 +443,13 @@ async def _review_classic_league(
         # here records, leaving the same gameweek placing the same tie two
         # different ways depending on whether you read the review or the
         # recap's ledger (#337, the defect #163 and #230 fixed elsewhere).
+        #
+        # An entry with no total is omitted rather than passed a placeholder,
+        # per the helper's contract -- a substituted 0 would tie it with a
+        # manager who really has scored 0.
         league_positions = derive_point_in_time_positions([
-            (e["entry"], e.get("total", 0)) for e in standings if e.get("entry") is not None
+            (e["entry"], e["total"]) for e in standings
+            if e.get("entry") is not None and e.get("total") is not None
         ])
         user_entry = next((e for e in standings if e.get("entry") == entry_id), None)
         if user_entry:

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/_review_draft.py

@@ -57,8 +57,8 @@ async def _review_draft(
     from fpl_cli.api.fpl_draft import (
         FPLDraftClient,
         is_accepted_transaction,
-        is_lost_claim,
         match_draft_to_main,
+        resolve_lost_claims,
     )
 
     draft_league_data = None
@@ -275,8 +275,10 @@ async def _review_draft(
                     # but a week whose only waiver activity was a claim the
                     # user lost is not a week they sat out, and reporting it
                     # as "no waivers this week" is the misattribution in
-                    # issue #329 pointed at the user's own review.
-                    lost_txns = [t for t in my_txns if is_lost_claim(t)]
+                    # issue #329 pointed at the user's own review. Resolved
+                    # against the reader's whole gameweek, so a claim denied
+                    # on a player he went on to win is not one he lost (#342).
+                    lost_txns = resolve_lost_claims(my_txns)
 
                     # Collapse same-GW churn using net squad delta (Counter diff).
                     # Pair residual adds and drops by (position, web_name) for like-for-like rows.

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/_review_summarisation.py

@@ -25,7 +25,7 @@ from fpl_cli.services.scoring import ATTACKING_POSITIONS
 from fpl_cli.services.team_ratings import api_difficulty_scale, fdr_columns_footer
 from fpl_cli.utils.gameweek import is_opening_gameweek
 from fpl_cli.utils.teams import describe_team_set_mismatch
-from fpl_cli.utils.text import strip_diacritics
+from fpl_cli.utils.text import normalise_name
 
 if TYPE_CHECKING:
     from fpl_cli.prompts.review import SynthesisCompleteness
@@ -1273,12 +1273,20 @@ async def _review_llm_summarise(
 
 
 def _normalise_name(name: str) -> str:
-    """Normalise a player name for fuzzy matching."""
-    import re
-    name = strip_diacritics(name).strip().lower()
+    """Normalise a player name for fuzzy matching.
+
+    One side of every comparison here is a name an LLM typed into the
+    recommendations markdown and the other is a `web_name` off the API, so the
+    fold has to survive the styling the writer applied on the way -- the
+    apostrophe family and whitespace runs included, via `normalise_name`. It
+    matters more here than in the table guard that shares it: a miss there
+    dropped a row, while a miss here reports a captain you *did* field as a
+    recommendation you ignored, and prices the difference against himself.
+    """
+    name = normalise_name(name)
     name = re.sub(r"\s*\(.*?\)\s*$", "", name)  # strip parentheticals
     name = re.sub(r"^[a-z]\.\s*", "", name)  # strip leading initials
-    return name
+    return name.strip()
 
 
 def _names_match(a: str, b: str) -> bool:

{fplkit-2.7.0 → fplkit-2.7.1}/fpl_cli/cli/league.py

@@ -13,6 +13,7 @@ from rich.table import Table
 
 from fpl_cli.cli._context import Format, console, error_console, fpl_config, get_format, get_settings
 from fpl_cli.cli._helpers import _entry_league_meta, _fetch_standings_with_costs
+from fpl_cli.cli._league_recap_data import derive_point_in_time_positions
 
 logger = logging.getLogger(__name__)
 
@@ -58,10 +59,31 @@ def league_command(ctx: click.Context) -> None:
                     league_name = standings_data.get("league", {}).get("name", "Classic League")
                     standings = standings_data.get("standings", {}).get("results", [])
 
+                    # Classic `rank` is strictly sequential, so it splits a
+                    # points tie on fewest transfers season-to-date -- a figure
+                    # no column here shows and the ledger does not record.
+                    # Position the table the way `fpl review` and the ledger
+                    # do, so the same tie isn't numbered two ways depending on
+                    # which command the reader runs (#344, the defect #337
+                    # fixed one surface along). An entry below this page can
+                    # share a place with the last one on it without changing
+                    # any number here: a shared place consumes the ones behind
+                    # it, never the ones above.
+                    #
+                    # An entry with no total is omitted rather than passed a
+                    # placeholder, per the helper's contract: a substituted 0
+                    # would tie it with a manager who really has scored 0, and
+                    # an explicit null would take the whole section down here
+                    # rather than at the row it belongs to.
+                    league_positions = derive_point_in_time_positions([
+                        (e["entry"], e["total"]) for e in standings
+                        if e.get("entry") is not None and e.get("total") is not None
+                    ])
+
                     # Find user's entry
                     user_entry = next((e for e in standings if e.get("entry") == entry_id), None)
                     if user_entry:
-                        user_rank = user_entry.get("rank", "?")
+                        user_rank = league_positions.get(entry_id, "?")
                         user_total = user_entry.get("total", 0)
                         user_gw_pts = user_entry.get("event_total", 0)
                         # `standings` is one 50-entry page; a league bigger than
@@ -87,7 +109,7 @@ def league_command(ctx: click.Context) -> None:
                     table.add_column("Total", justify="right")
 
                     for entry in standings:
-                        rank = str(entry.get("rank", "?"))
+                        rank = str(league_positions.get(entry.get("entry"), "?"))
                         name = entry.get("player_name", "Unknown")
                         gw_pts = entry.get("event_total", 0)
                         total = entry.get("total", 0)