Backend
Cloudflare Worker · TypeScript- lines
- 64.9% 1202/1853
- branches
- 65% 640/984
- functions
- 62.6% 261/417
Routes are excluded from the report: they are covered end to end by the integration tier, which drives them through real HTTP.
FantasyWiki documentation
A fantasy league played over Wikipedia pageviews. These pages are how it is built: the rules the game runs on, the seams the code is cut along, the decisions that got it here, and what the test suites reach.
Start hereExam reportRead it →The Docs Atlas
Every document, and every link between them, drawn from the markdown itself.
- A dot is a document: coloured by its section, sized by how many links touch it, so the hubs are visibly the hubs.
- A solid line is a curated edge, taken from a document's closing
## Relatedlist. A dashed one is a reference made in passing, mid-sentence. Both count; they do not mean the same thing. - A dot with no lines is a finding: a rule that was written down and then orphaned, which is the failure a folder of markdown cannot show you.
Coverage
Three packages, three test runners, three report formats, read from the reports the runs on master actually wrote, not from a badge, and not from a number typed into a page.
Across every measured package
4,043 of 5,545 executable lines are exercised by the test suites. Codecov gates the project at 70% overall and does not gate the changed lines of a pull request on their own.
64.9%
Frontend
Vue 3 + Ionic · TypeScript- lines
- 76.2% 2644/3469
- branches
- 67.4% 1253/1858
- functions
- 67.7% 981/1448
The lowest of the three, and expected to be. Frontend specs are regression smoke around stores, services and views; the game rules they would otherwise re-assert are tested where they live, in the backend. Mocks, the bootstrap and the specs themselves are excluded.
Scoring Collector
JVM · Kotlin- lines
- 88.3% 197/223
- branches
- 56.7% 110/194
- functions
- 90.2% 55/61
The nightly batch. Kover counts the whole module, including the Wikimedia dump parsing that carries most of its risk.
These are line coverage, and the three figures are not comparable with one another. The backend excludes the route modules the integration tier already drives end to end; the frontend's specs are deliberately regression smoke, with the game rules asserted where they are implemented rather than a second time in the browser; the Kotlin collector counts everything it has, including the Wikimedia response parsing that carries most of its risk.
What each suite is for, and which layer it may name →
The API
Every endpoint the Worker serves, counted out of the specification that describes it, not from a list anybody maintains.
40endpoints
OpenAPI 3.1.0 · v1.0.0
Across 34 paths and 37 schemas, grouped into 12 areas of the game. Which authentication applies is decided by the path prefix, not by the endpoint.
/api/*33The frontend, as a signed-in player./internal/*2The scoring engine, which is not a person./auth/*5Where a session is minted, and the deployment probe.- GET 23
- POST 13
- PUT 1
- PATCH 1
- DELETE 2
Nothing can be missing from this. The backend suite compares the spec with the Worker's own mounted route table in both directions, so an endpoint that exists and is not described fails the build, and so does one described and no longer served.
Every endpoint, with the status it answers and why →
If none of the vocabulary on this page means anything yet, start from what FantasyWiki is; if you are here to change something, start from the architecture overview; and if you already know what you are looking for, the documentation index is the shelf it is on.
Where these pages come from, and how the Atlas and the board are derived: About this site.
The FantasyWiki application, measured against WCAG 2.2 AA on 2026-08-30, axe-core across twelve screens, in both themes, with no violations. How it was tested →