The demo folder holds four OpenAPI documents, a sample changelog and three
pages of prose in `docs/`. The source reads only `docs/` as ordinary pages;
the generated sections read the API files and changelog beside it. This keeps
the changelog from also appearing as an ordinary documentation page.

It is a second source beside the documentation, declared with
`slug: 'demo'`, which is what keeps the prose at the root while these pages sit
under `/demo`.

Naming a slug is what claims the segment. The automatic rule gives every source
one only when the list holds more than one **repository**, and both of these are
this checkout, so it never fires: without the slug this source would have wanted
the same prefix as the documentation, and the build would have said so.

## What the second source buys

The section row above is this area's own. An entry belongs to the source whose
prefix it lies under, so `Overview`, `Demo API` and `Demo Changelog` stand there while the
documentation keeps its six at the root — one `sections` list, drawn per area.

The navbar entry opens the area; the row moves around inside it. That is the
same relationship the row at the root has with the documentation, which is why
it needed no second mechanism.

## Where its declaration is

`www/app/app.config.ts`, in full, with a comment per key. What each key does is
in [Reference → API reference → Declaring the section](~/reference/openapi/section).
The `~/` prefix starts at the website root, so this link leaves `/demo`; a bare
`/reference/…` remains inside this source and renders as `/demo/reference/…`.