Laden
Neuer Stand wird geladen
Page Of Truth
Referenz für geplante Turniere: Metadata lesen, noch keine Live- oder Completed-Auswertung erzwingen.
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-planned/SKILL.md.opencode/skills/matchplay-tournament-types-memory/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.
`/tournaments?played={playerId}` liefert die Kandidatenliste. Daraus wird selected, active oder latest-played bestimmt.
playerId aus Queryoptionales selectedTournamentIdtournamentIdstatusname`loadTournamentDetail()` holt Players, Arenas und Location. Das reicht, um den Typ und den Grundstatus zu kennen.
tournamentIddetail.statusdetail.typeplayersarenaslocationWenn `detail.status === planned`, dann lädt `loadPlannedTournamentDetail()` dasselbe Turnier erneut mit den Zusatzfeldern für die Info-Darstellung.
tournamentIdstatus=plannedentryConfigurationrsvpConfigurationlinkedTournamentseventseriesbanks`getPlannedInfo(detail)` extrahiert genau die Felder, die später im UI lesbar dargestellt werden.
angereichertes detailstartsAtcreatedAtupdatedAteventNameseriesNameentryConfiguration[]rsvpConfiguration[]linkedTournaments[]Die UI bekommt Players, Arenas, Tournament-Optionen und `plannedInfo`, aber keine Completed-Auswertung.
detailplannedInfoLiveTournamentOverview für plannedWelcher 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}?includePlayers=true&includeArenas=true&includeBanks=true&includeLocation=true&includeEntryConfiguration=true&includeRsvpConfiguration=true&includeLinkedTournaments=true&includeEvent=true&includeSeries=trueKomplette geplante Metadaten für die Info-Darstellung laden.
startsAtcreatedAtupdatedAtevent.nameseries.nameentryConfigurationrsvpConfigurationlinkedTournamentsbanksWann 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.
Verwendet werden besonders `type`, `status`, `updatedAt`, `players`, `arenas`, `location`, `event`, `series`, `entryConfiguration`, `rsvpConfiguration`, `linkedTournaments`.
Kein Completed-Bundle und keine breite Match-Auswertung, solange das Turnier nur geplant ist.
Tournament detail und played tournaments werden wiederverwendet; geplante Turniere haben stabile TTLs und können sicher kurzzeitig gecacht werden.
Status und Typ kommen direkt aus `detail.status` und `detail.type`.
Startzeit, Event, Serie, Entry- und RSVP-Konfiguration werden aus `plannedInfo` angezeigt.
Linked tournaments kommen direkt aus `plannedInfo.linkedTournaments`.
Planned Direktlade-Test
Diese Eingabe öffnet den echten Planned-Pfad mit denselben Query-Parametern wie die App. So lässt sich direkt prüfen, wie Tournament Detail, Cache und Timestamp-basierte Wiederverwendung für dieses Turnier greifen.
Diese Reihenfolge bildet die echten `flowSteps` aus `live-tournament.ts` auf hoher Ebene ab.
query-paramsPlayer und optionales Tournament aus Query lesen.
matchplay:/tournaments?played={playerId}/tournamentsListe gespielter Turniere laden, um Zielturnier und Status zu bestimmen.
matchplay:/tournaments/{tournamentId}/tournaments/{tournamentId}Basisdetail mit Players, Arenas und Location laden.
matchplay:/tournaments/{tournamentId}/tournaments/{tournamentId}Planned-Turnier mit include*-Parametern für Metadata, RSVP und verlinkte Turniere nachladen.
tournament-type-switchTyp und Status entscheiden, ob weitere Datasets überhaupt nötig sind.
matchplay:multi-endpointFür planned meist nur leere oder minimale Zusatzdaten; kein Completed-Bundle.
latest-played-flowUI-Overview mit plannedInfo, Players, Arenas und Tournament-Optionen erzeugen.
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.tssrc/app/page.tsx