Table of Contents

Anatomy by Source Directory

The rest of Anatomy is keyed on the shipped surface — a route, a Control-Tree branch, a reusable control. This layer is keyed on the source tree instead, and it is the entry point for the reader who knows which directory a change landed in but not which screen it shows up on.

Ordered the way a request travels: the front end first, then the process that serves it.

Directories

  • Web Service SPA Source Tree — the Quasar front end under wwwroot-src/src: how components/ is grouped two ways at once, what the Control-Tree registry actually is, and why half the route table is redirects
  • Web Service Backend Source Tree — the ASP.NET Core half: how to read a filename, why folder nesting does not predict a route, and which declared hub is never mapped

What This Layer Is For

A page in the rest of Anatomy answers what is this thing on my screen made of. Both of these answer the inverse: this directory changed — what does it show up as, and which page is now wrong. That makes them the first stop after a refactor, and the reason each directory entry names the pages that document it.

They are directory indexes, not file listings. A file worth naming is named on the page that documents the surface it implements; what lives here is the shape of the tree, the conventions that hold across it, and the traps that survive a careful reading of any single file.

What Is Not Indexed Here

The HiAPI engine repositories are not given a directory document. Anatomy cites engine source where a shipped surface depends on it, but the engine's own structure is covered by the generated API Reference, which stays correct in a way a hand-written index could not.

See Also