Pool and player data

The season data is maintained in Python source. There is no administrative UI or database editor for the roster, square ownership, or digit assignments.

Source of truth

File/value	Meaning
`app/pool.py`: `BOARD_PLAYER_NAMES`	Ownership of the 100 squares
`BOARD_SQUARES`	Derived row/column/player-ID records
`POOL_MAP`	Game date keys, NFL weeks, opponents, and digit lists
`BYE_WEEK`, `BYE_DATE_KEY`	The separate BYE entry
`app/players.py`: `PLAYERS`	Display names, optional selector labels, addresses, and notification flags
`2026 Ravens Pool 4.pdf`	Original 2026 roster and digit-assignment reference

The PDF and player contact records remain in the repository, not in the generated documentation output. Use display-only or synthetic examples in public guides.

Coordinates and last digits

flowchart LR
    Score[Period score: Ravens 23, opponent 17] --> Digits[Last digits: 3 and 7]
    Digits --> Lookup[Find indices in weekly digit lists]
    Lookup --> Stored[Stored Ravens row and opponent column]
    Stored --> Owner[Square owner]
    Stored --> Display[Browser transposes to printed-sheet orientation]

The printed pool sheet has Ravens columns and opponent rows. Ownership is transposed into the application’s Ravens-row/opponent-column model. The browser transposes the stored coordinates back for display. Change the mapping only with a test that verifies both score lookup and board orientation.

Duplicate owner names intentionally share a player ID, so a person may own multiple squares. Roster normalization removes parenthetical seller/group labels; the known spelling variation in the 2026 source is merged into the confirmed single player record. Preserve stable IDs when changing display names.

Notifications and public fields

A winner is eligible for an individual notification when their player record has both notify enabled and a nonempty email. A player winning both periods receives one combined winner message. Summaries use Azure’s summary settings, independently of individual player notification flags.

The snapshot includes only name and selector_name from each player record. Addresses and notify flags are not published. Turning a notification flag off does not remove that player’s squares or earned prizes from the public board.

Season update checklist

Confirm the new season’s square ownership and per-week digit assignments.
Update POOL_MAP and the BYE constants. Each team’s weekly digit list must represent the digits 0–9 without duplication.
Keep PLAYERS keys aligned with the IDs generated for square ownership.
Verify names, optional selector labels, and notification preferences privately.
Review the last configured game date, including TBD or moved kickoffs. ESPN matching uses NFL week, while configured dates also control the season window.
Review payout settings and summary personalization in Azure.
Run the full test suite, including board mapping and winnings tests.
Deploy the Function. During the active window, the next hourly invocation publishes changed public data; reload the website to see it.

Season state is stored by the year of the first configured game. A new state file can catch up completed games and send messages. Review that behavior before introducing historical season data. Do not delete existing state as a routine part of a roster edit.