Orientation

There is no diagram of this project, because the folder is the diagram.

The cascade, on disk

Import order is cascade order, and the numbered folders make that order visible on disk — read the tree top to bottom and you read the cascade in the sequence the browser applies it.

css/
│
├── profile/          01 · the package — assembles itself
│   ├── primitives/       colors · typography · spacing · borders · surfaces
│   ├── semantic/         colors · typography · spacing · borders · surfaces
│   ├── themes/           aero · luna · classic · dark · contrast · forced-colors
│   └── accessibility/    skip-link · sr-only
│
├── resets/           02 · normalised browser defaults
│                         modern-reset · forms
│
├── document/         03 · the presentation — spends the vocabulary
│   ├── tokens.css        the seam, where chrome and prose part company
│   ├── base.css
│   ├── blocks/           headings · code · table · lists · details · controls
│   ├── layout/           page · wrapper
│   └── utils/            flow · label · card
│
├── components/       04 · shared UI — built from the vocabulary
│                         the site's own: navigation · breadcrumbs ·
│                         page-navigation · footer
│                         Win32 chrome: window · menubar · toolbar ·
│                         tabs · listview · transport
│
└── vendors/          05 · third-party CSS — admitted as-is (reserved)

The directories

The tree divides once, and that cut matters most: profile/ is the package, everything after it merely spends that vocabulary.

The dependency arrow runs one way — consumers reach into the package, the package never reaches back. See Package vs presentation.

  • profile/ — the package. The shared vocabulary: primitives, roles, themes, the accessibility floor. The part that would ship if anything did, and the one directory everything else is written against.
  • resets/ — brackets the front: normalised browser defaults, borrowed and admitted like vendors — the floor the authored CSS sits on.
  • document/ — the presentation. One site's way of spending that vocabulary: base styles, blocks, layout, and the seam in tokens.css.
  • components/ — shared UI, built from the vocabulary. Two families: this site's own chrome, and the rest are Win32 chrome the site both documents and wears.
  • vendors/ — third-party CSS, admitted as-is. Last in the cascade by design: an enhancement nothing depends on, so it can never quietly become load-bearing.

A folder you can open

No build step rearranges any of this. What you read on disk is what the cascade does, in the order it does it — nothing is compiled away into output a tool emits and no one opens again.

The structure stays legible because it was kept legible: the numbered folders, the one-way dependency, the cut between package and consumer are there to be read, not only to run.

This makes the folder an artefact of the inquiry — not the residue an investigation leaves behind, but a thing made on purpose. The question was what a document wears when it wants to be an application, and the answer turns out to be a structure you can hold and walk through. The inquiry, in the end, is a folder — made to be opened.