Xssmaze::Catalog

Endpoints the catalog publishes for tooling. Rendered in the page footer. /solutions/basic stands in for the per-category answer key (/solutions/ <category>); /solutions.json is the whole key keyed by maze name.

Path Item operations OpenAPI 3.0 actually defines. Anything outside this set — HTTP QUERY, for one — is not a valid Path Item field, so it goes into the x-additional-operations extension instead of quietly making the whole document invalid for every consumer.

Build every cached static asset in one shot. The key naming maps 1:1 to the route table in server.cr so adding a new catalog view is a matter of: add a builder above, add an Entry here, add a route in the server table.

Per-category rollup. Beyond the raw count, this breaks each category down by vulnerability class and reachability so a benchmark can pick its target set (and exclude controls) without walking every endpoint in /map/json.

Minimal OpenAPI 3.0 document so external tooling (Swagger UI, code generators, scanner runners) can ingest the catalog directly.

One cached Entry per solution category, keyed by category name. Built the same way as the flat catalog views so /solutions/<category> gets the same ETag / gzip / 304 treatment — it just needs a dynamic route to select the category rather than a fixed STATIC_ROUTES row.

The 404 body is the one page that varies per request (it echoes the missed path), so it is rendered rather than cached like the entries above. The path is escaped — this page is chrome, not a maze. It shares the index stylesheet instead of carrying its own, so the two pages can never drift apart.