Laden
Neuer Stand wird geladen
Page Of Truth
Referenz für aktive oder offene Turniere: minimale Endpunkte, watched-player-zentriert, sparse reconstruction für live-kritische Daten.
Diese Seite ist die lesbare Referenz dafür, wie dieser Turniertyp geladen, aus Cache/Storage wiederverwendet, aufbereitet und dargestellt werden soll.
Pflegbarer Status
Diese Auswahl lebt bewusst im Browser-Storage, damit die Seite als Arbeitsfläche für die echte Implementierung genutzt werden kann.
Diese Dateien im privaten Repo sind die primären Wartungsorte für diesen Turniertyp. Erkenntnisse sollen zuerst dort gepflegt und dann in der UI-Doku gespiegelt werden.
.opencode/skills/matchplay-tournament-type-live-open/SKILL.md.opencode/skills/matchplay-tournament-types-memory/SKILL.md.opencode/skills/matchplay-data-minimization/SKILL.md.opencode/skills/matchplay-tournament-type-bracket/SKILL.md.opencode/skills/matchplay-tournament-type-group-match-play/SKILL.md.opencode/skills/matchplay-tournament-type-matchplay/SKILL.md.opencode/skills/matchplay-tournament-type-knockout/SKILL.md.opencode/skills/matchplay-tournament-type-target-match-play/SKILL.md.opencode/skills/matchplay-tournament-type-pace-match-play/SKILL.md.opencode/skills/matchplay-tournament-type-max-match-play/SKILL.md.opencode/skills/matchplay-tournament-type-amazing-race/SKILL.md.opencode/skills/matchplay-tournament-type-frenzy/SKILL.md.opencode/skills/matchplay-tournament-type-golf/SKILL.md.opencode/agents/matchplay-tournament-types.md.opencode/agents/matchplay-tournament-type-maintainer.mdWas dieser Flow leisten soll, bevor wir daran weiter implementieren.
Diese Regeln sind der aktuell verbindliche Minimalpfad. Erst dokumentieren und verifizieren, bevor hiervon abgewichen wird.
Von Endpoint zu Endpoint, inklusive Datenentnahme und Aufbereitung.
Mit expliziter `selectedTournamentId` startet der Flow direkt bei `/tournaments/{tournamentId}`. Nur ohne Turnier-ID wird über `played tournaments` active oder latest-played bestimmt.
`load-strategy` entscheidet über rounds, standings, single-player-games und watched-player-games anhand von Status und Tournament Type.
Die relevanten Endpunkte werden parallel geladen, aber nur wenn der Typ sie wirklich benoetigt.
Multiplayer-Turniere nutzen primär genau einen `/games?tournaments={id}&player={playerId}`-Load statt globaler Spielmengen oder mehrfacher Games-Requests. Dieser Payload ist die aktuelle Minimalbasis für sofort renderbare Round/Game-Shells.
Derzeit deaktiviert, bis ein verifizierter Ersatzendpunkt existiert. Den funktionierenden Minimalpfad mit genau einem watched-player `/games` nicht brechen.
Für Group-Turniere wird die aktuelle Gruppe gebaut, damit Area und Opponents des aktiven Kontexts sichtbar bleiben.
Welcher Endpunkt liefert was und welche Felder wir daraus wirklich ziehen.
/tournaments?played={playerId}Nur für automatische Turnier-Auflösung ohne explizite `tournamentId` oder später für die lazy Tournament-Select-Liste.
tournamentIdnamestatusupdatedAt/tournaments/{tournamentId}?includePlayers=true&includeArenas=true&includeLocation=trueGrunddaten des Turniers laden und Typ bestimmen.
typestatusplayersarenaslocationupdatedAt/tournaments/{tournamentId}/roundsRunden/Holes/Brackets aufbauen, wenn das Format sie benoetigt.
roundIdnameindexstatusarenaId/tournaments/{tournamentId}/standingsPositionen, Punkte und Spielerbezug herstellen.
playerIdpositionpointsgamesPlayedentriesPlayed/games?tournaments={tournamentId}&player={tournamentPlayerId}Nur relevante Multiplayer-Games des betrachteten Players laden. Dieser Call soll pro Overview nur einmal passieren, ein sinnvolles purpose tragen und ist aktuell die verbindliche Minimalbasis für Round/Game-Shells.
gameIdroundIdarenaIdstatusstartedAtplayers/results/tournaments/{tournamentId}/single-player-gamesAmazing Race / Best Game / Pingolf Daten laden.
singlePlayerGameIdplayerIdarenaIdroundIdscorestatusWann Daten aus Storage kommen, was dort drinsteht und wie Wiederverwendung entschieden wird.
Beim Eingeben oder Wiederverwenden von Player IDs auf der Startseite.
player idplayer nameifpaIdclaimedBycountrycitystateZur Priorisierung haeufig geladener Spieler in der UI.
player idplayer nameloadCountlastLoadedAtServerseitiger Overview-Cache vor Netzwerkanfragen.
komplette LiveTournamentOverviewcachedAtexpiresAtFallback bei 429 oder wenn kein exakter Cache-Hit verfuegbar ist.
letzte erfolgreiche Overview je PlayercachedAtexpiresAtWiederverwendung einzelner Match Play Responses für Tournament-Details.
raw API responsecachedAtexpiresAtWelche Daten aus dem Rohmaterial extrahiert werden und wie daraus die sichtbare Darstellung entsteht.
Players und standings werden kombiniert, damit claimedBy / Match Play IDs sauber auf Tournament Player gemappt werden.
Arenas kommen primaer aus Tournament Detail; Round/Game-Shells und vorhandene Gegner-/Result-Daten kommen direkt aus watched-player-games. Weiteres per-game Detail bleibt deaktiviert, bis der Ersatzendpunkt verifiziert ist.
Wenn eine Optimierung active game oder active group unvollständig macht, ist sie für dieses Repository nicht akzeptabel.
Prioritaet: active game, danach explicit activeGameIds, danach offene Spiele.
Wenn der Typ eine Gruppe hat, wird `currentBracketGroup` gebaut und mit allen relevanten Matches angezeigt.
Started `group match play` und `group knockout` behalten zusätzlich die normale `MatchHistorySection`, damit die bestehende CSV-Hydration für bereits abgeschlossene Runden weiterläuft; nur echte Group-Bracket-Grid-Ansichten bleiben primär auf dem Gruppenpanel.
Wenn nur stale cache verfuegbar ist, wird `cacheState` in der UI sichtbar gemacht.
Live / Progress Direktlade-Test
Diese Eingabe öffnet den echten Live-/Started-Pfad mit denselben Query-Parametern wie die App. So lässt sich direkt prüfen, wie das Turnier minimal geladen, angereichert und mit allen live-kritischen Infos dargestellt wird.
Diese Reihenfolge bildet die echten `flowSteps` aus `live-tournament.ts` auf hoher Ebene ab.
query-paramsPlayer- und Turnierauswahl lesen.
conditional-resolverNur ohne explizite `tournamentId` wird über `played tournaments` aufgelöst; beim Direktload mit `playerId + tournamentId` fällt dieser Schritt initial weg.
matchplay:/tournaments/{tournamentId}/tournaments/{tournamentId}Basisdetail für Typentscheid laden.
tournament-type-switchBestimmen, ob rounds, standings, single-player-games oder watched-player-games benoetigt werden.
matchplay:multi-endpointFormatrelevante Datasets in minimaler Menge laden.
matchplay:/games?tournaments={id}&player={playerId}/gamesNur Spiele des betrachteten Players laden, statt das ganze Turnier breit zu fetchen. Dieser `/games`-Load soll pro Overview nur einmal passieren und ein sinnvolles purpose statt `unspecified` tragen.
disabled-until-verified-endpointKein per-game Nachladen, solange der Ersatzendpunkt nicht verifiziert ist. Der aktuelle Minimalpfad bleibt: genau ein watched-player `/games` und sofortiges Rendern der Round/Game-Shells.
active-flowAktuelles/nächstes Spiel und aktive Gruppe für UI aufbereiten.
Was an diesem Flow bewusst so ist und wo wir bei Änderungen aufpassen müssen.
Diese Formate teilen sich denselben dokumentierten Pfad oder dieselbe Referenzlogik. Die repo-lokalen Skills sind der erste Pflegeort, der Quellcode die technische Umsetzung.
src/lib/matchplay/live-tournament.tssrc/lib/matchplay/cache.ts