Decide launch approach for Golden Boot and Player Guide

[petternitter]

Summary

Review the current state of Golden Boot and Player Guide requirements, data dependencies and ownership, and recommend the most pragmatic delivery approach for World Cup 2026.

Why

Golden Boot and Player Guide are in scope for the tournament structure and navigation workstream, but the right implementation approach is still unclear. Before creating delivery tickets, we need to confirm whether these should remain interactive/one-off experiences, be built into platform components/templates, or be deferred beyond launch.

Scope

• Confirm the current understanding of the Golden Boot and Player Guide experiences we want to support for World Cup 2026
• Validate when the relevant data becomes available and whether it will be delivered in the expected format
• Identify any architectural or backend dependencies we need to support
• Clarify ownership and whether these are better delivered as interactives/one-offs or platform capabilities for this tournament
• Recommend the most pragmatic approach for launch, with reuse/configurability considered only where it does not meaningfully add scope or risk

Examples

• Recommend leaving one or both items as Visuals/interactives-led outputs for this tournament if that is the fastest sensible launch path
• Recommend light platform work only if it is clearly achievable and reduces future rework without increasing launch risk
• Document what would need to be true for a more reusable/configurable version later

Out of scope

• Building Golden Boot or Player Guide in this ticket
• Creating full editorial tooling or a generic reusable player/tournament data model
• Solving post-launch reusability in detail

Deliverable

• Recommendation for Golden Boot delivery approach
• Recommendation for Player Guide delivery approach
• Summary of data, architectural and ownership constraints
• Follow-on tasks for any agreed implementation or deferred work

Acceptance criteria

• Data availability/format questions have been reviewed
• Key dependencies and ownership questions are documented
• A recommended launch approach exists for Golden Boot
• A recommended launch approach exists for Player Guide
• Any follow-on work or decisions needed are clearly documented

[DanielCliftonGuardian]

1. Recommendation for Golden Boot delivery approach reusability

Approach: Build as a native DCR-hosted platform data page (Reusable).
Instead of treating this as a one-off interactive atom, we should build the Golden Boot natively at /football/world-cup-2026/golden-boot. This will mirror the architecture of our existing long-running data pages like (/football/tables, /football/fixtures, /football/results).

Why: MAPI already contains the foundational code and endpoints for this, so the data model is stable. Building it natively reduces future rework, fulfils the Sports desk's desire for reusable Golden Boot pages across other leagues (e.g., Premier League), and gives us a unified solution.

2. Recommendation for Player Guide delivery approach reusability

Approach: Retain as a Visuals/Interactives-led one-off output.
Why: The Golden Boot relies on structured, automated PA data, making platform integration straightforward. A Player Guide, however, is heavily editorialised and lacks a generic reusable data model. Attempting to build full editorial tooling and a generic player data model into the platform for this tournament adds significant scope and risk. Visuals should own this unless the display and approach is fundamentally altered.

3. Summary of Data, Architectural, and Ownership Constraints

   Core Golden Boot Data (Ownership: MAPI/PA): The data is already available and formatted correctly. We can consume the MAPI endpoint, which provides rank, name, goals, minutesPlayed, assists, and a games array for per-game breakdowns.

   Architecture: We can implement standard DCR patterns—new FE types, AJV JSON schemas for validation, and a main React page component.

   Player Photos (Ownership: Visuals / Cross-team dependency): Photos don't need to be in the initial server-side render page to prevent blocking. Visuals maintains a Google Sheet mapped to a JSON proxy. We could build a client-side Island component that fetches this proxy on mount, matching paName to the API's player.name, and hydrates the images dynamically or pull images from the grid.

4. Follow-on tasks / Next Steps

   DCR Golden Boot Page Implementation: Create the core FootballGoldenBootPage DCR components, parsers, and MAPI integration. Must support the three tournament "stages" (early: all players shown; mid: per-game dots for 3+ goals; late: 1-goal players collapsed).

   Photo Hydration Island: Create the follow-up ticket to build the Island component that fetches the visuals .

   Design & CP Sync: Finalise the exact presentation of the page with Design and coordinate with CP (who originally requested the reusable approach) to ensure the implementation works for both dotcom and apps.