Extraction produces a markdown tree. It does not produce a place to read it.
ae-xtr solves the drift problem: it reads the @ae::dx comments out of the source and writes the documentation as a markdown tree that mirrors the code. The output is accurate, but it is raw files in folders, shaped like a source repository. Nobody browses a folder of markdown, and nobody hands one to a reader.
The studio ships a family of these tools: ae-dx, ae-os, ae-sys, ae-xtr, symbol. The obvious route, a static site per tool, duplicates the styling and the routing and walls each project's docs off from the rest. ae-dx is the studio's own answer: one SvelteKit application that renders the whole family's extracted markdown into a single themed, browsable, searchable website. The documentation stops being a folder of files and becomes the stack's reference.
One application, three surfaces over the extracted tree.
The reader meets three surfaces: a homepage that introduces the family, a per-project tree rendered under a clean URL, and a global search overlay that jumps to any heading in any project. Underneath, every surface reads the same markdown, the projection ae-xtr writes, compiled once at build time.
One extracted tree becomes two things: a page a reader can open, and one search across the whole family.
Two things happen to the extracted markdown. Each file is compiled into a page in the site's own layout, with its code recoloured onto the site's palette so a code block reads as part of the page rather than a pasted-in theme. Separately, before the site is bundled, every project is indexed into a single static file the browser searches in place, so a query crosses the whole family with no external service and no round trip.
One front-end, every project under one roof.
What the reader gets: a single home for the whole family, a tree per project under a clean URL, search that crosses every project in place, and code that reads as part of the page.
A folder of files, or a place to read them.