Entity pages
A fixture, team, player or referee — the detail pages, the lookup lists in front of them, and why only the trailing id resolves.
(dashboard)/(entities)
Two shapes, and the difference matters.
Detail pages
/fixture/[fixtureSlug]/[fixtureId]
/team/[teamSlug]/[teamId]
/player/[playerSlug]/[playerId]
/referee/[refereeSlug]/[refereeId]The slug is decoration — only the trailing id resolves. A renamed team does not break an old link, and a wrong slug with a right id still lands on the right page. That is deliberate: the slug is there for readers and for search engines, not for routing.
Lookup pages
/fixtures, /teams, /players — the lists in front of the detail pages.
They exist because a detail page is useless if you cannot find the thing, and a
search box that returns nothing until you type is a dead end. /fixtures is the
one with something to show before you type — today's matches — so it renders
them.
Prerendering
src/lib/static-params.ts generates params for these routes from the sitemaps
the API already serves, capped at 250 paths each. It does not fail
the build when the API is unreachable, because docker build has no API on its
network.
They are not currently prerendered anyway — the (dashboard) layout reads a
cookie, so the whole segment renders per request. Data
has the details and what would switch it on.