The code of this site is written by an AI — Claude, in Claude Code — from what I ask of it. I say what the site is and how it should be made; it writes the program, and the tests.
The picture is that program. Every ball is a file, every box a folder of the frame or a feature, and every arrow a box that needs another. It is read from the source by the TypeScript compiler, at every commit that changed it. Play it and watch it grow; tangle it to see the same files with nobody saying where anything goes, and untangle it again. Put the tests in, and every file with something in it to run that no test imports directly is drawn as a ring.
The picture can be looked through lenses. A ball can be as big as the files that need it — the hotspots, the files a change reaches first — or as the files it needs; as all the files a change to it could reach, near or far; as much as it stands between the others; as the commits that have changed it so far, which grows as the history plays and stops where a file settles; or as its lines. It can be coloured by how lately it changed, by how often files standing where it stands changed, or by how stable its box is, with the arrows that go against stability in red. Threads can be drawn between the files that changed together, dashed where no arrow joins them; tangled, they pull the files together too. Every file a commit changes rings as it comes.
Point at a file, and what it is asked to show comes out, said on the line over the picture so that no word covers an arrow: its own arrows, what it needs and what needs it, each in the colour the line keys it to, one arrow out or as far as they go — all a change to it could reach, and all whose change could reach it; the group the arrows gather it into; or the files that changed with it. Click a file or a box, and the panel by the picture tells of it at the commit shown: where a file stands in the network, what its history has been and what it changed with; a box's couplings, with the sum worked out. Every file and box it names leads to its own details, and a link leads to the code on GitHub as it stood then. With nothing chosen, the panel tells of the network as a whole.
079ed30 13 October 2026 — A module of the LCARS display is moved by hand, the last of what David said it lacked: carried up or down its column onto another row, where what stood there changes places with it, the rest making room as it goes and a mark showing where it would land. Its column it keeps, since that says what comes before what, and the flow says it. Moving one module among others that stood where the layout wished would move nothing — each stands level with what feeds it, so they would all follow — so from the first move every module stays where it stood, and the display only finds a place for what is new, around them; Tidy hands the layout back. A move is a step Undo takes back, though the blueprint is the same before and after: where modules were put is kept beside each state of it while the page is open, and not with the reader's version nor in a link, since the text of a blueprint says nothing of it. Alt and an arrow move the module chosen; a finger on a module still moves the page. The schematic says of itself where its rows are and which each module stands on, so a hand on it is read against what is drawn. And what the display asks when a conduit could be run more ways than one is worded in a function of its own, tested without a page 781 files in 52 boxes, 428 tests · 654 arrows between boxes, 853 of all 2234 onto a type · a test reaches 567 of the 710 files with something to test · no boxes in a circle
How often each file changes, how far a change travels, and which files change together with no arrow between them is the other half of this picture: how this site changes.
What the tangle shows
Tangled, with no boxes, the files arrange themselves by the arrows alone, and structures appear: knots of files that need one another, and files that everything seems to pass through. Both can be counted, and the figures here follow the picture's history as it plays.
The network. Read as network science reads any network, the source is files joined by arrows, and the first questions are the ones asked of every other: how the links are spread among the files, and how far apart the files are.
needed by so many or moreneeding so many or more
Of the 781 files that ship, 74% are needed by two others or fewer, and NodeKind.ts is needed by 86, the most; Workbench.ts needs 36, the most. The network is 41 times as clustered as a random network of as many files and links, and the ways between its files are 1.1 times as long: a small-world-ness of 36.7.
When this was written, on 29 September 2026, most files were needed by one or two others and a few by very many, the tail that the log scales keep in sight. And the files were far more clustered than in a random network of as many files and links, where two files joined to a third are seldom joined to each other, while the ways between them were nearly as short. Watts and Strogatz called a network like that a small world (1998): clustered like a lattice, near like a random network. Humphries and Gurney made the two one number, small-world-ness (2008): the clustering over a random network's, over the length of the ways over a random network's, a small world above one. Until then it had grown with the source, which says less than it seems: a random network's clustering falls as it grows with as many links a file, and this one's had hardly fallen. Christopher Myers found the graphs of what works with what inside several open-source programs to be small worlds too, and scale-free, a few of their parts linked to very many (2003); no such fit is made here.
With nothing chosen, the panel by the picture tells more of the network at the commit shown: whether files with many links join files with few, as Newman found technological networks mostly do (2002); how deep its knot is, its deepest core, what is left when every file with fewer links than some number is taken away, again and again (Seidman, 1983); and how tall its stack of what needs what. Choose a file, and it tells the file's own: its place by PageRank (Brin and Page, 1998), which is to be needed by files that are themselves needed; how near it is to the rest, and how much it stands between them (Freeman, 1978).
The groups the arrows make. The Louvain method (Blondel and others, 2008) finds the groups a graph makes without being told any. How much a grouping keeps its arrows inside its groups, beyond what arrows drawn at random would, is its modularity (Newman and Girvan, 2004); the method moves each file into the neighbouring group that raises it most, then treats each group as one file and starts again, until nothing moves. The modularity of the boxes can be worked out the same way.
a box of the framea featurethe top of the source
The arrows alone, with no box said, gather the 781 files that ship into 27 groups, 8 groups of fewer than 3 files among them, not drawn. 5 of the 33 features are a group to themselves: all of their files, and nothing else. Drawn as the boxes say, the source has a modularity of 0.62; drawn as the arrows would, 0.73.
Some features make a group of their own, whole: islands, as the rules want. Where the arrows gather several boxes into one group, their files are more tied to one another than to the rest — often a feature and the part of the frame it leans on most, sometimes features that lean on the same things. Set pointing to show its group, and the picture draws any file's.
The bridges. Some files stand between the others: most of the shortest ways from one file to another pass through them, the arrows read either way. Set the size to bridges, and the picture shows how much each does.
platform/plugin/Feature.ts stands on 35% of the shortest ways between two other files that ship, the arrows read either way; where several ways are as short, each counts for its share.
When this was written, on 28 September 2026, the first three were the contract every feature fulfils, the one way to make an element on the page, and the one way to make text safe to print: files where much of the source meets. Read either way, the arrows say where the parts of the source meet, not which way a change would go; a file that needs nothing carries no change through it.
How far a change could reach. Every arrow is a road a change could take back to what needs it. The share of the source a change to one file could reach, on average, following them all the way, is a design's propagation cost (MacCormack, Rusnak and Baldwin, 2006); set the size to reach, and the picture shows each file's.
In theory a change to one file could reach 1.6% of the source, on average; at the first commit, 17%. The farthest reaching: platform/blueprint/NodeKind.ts, whose change could reach 187 files; platform/markdown/escapeHtml.ts, whose change could reach 182 files; and platform/content/Page.ts, whose change could reach 114 files.
A source that grows by features, which little else needs, sees it fall: a change inside a new feature can reach little beyond it. How far changes did go, rather than could, is on how this site changes.
The arrows point one way
A rule written in a document is a rule that can be missed, by a person or by an AI. So the rules of this code are not in a document: they are tests it has to pass. architecture.test.ts reads the same graph this picture draws, and fails when
a file outside a folder named browser/ touches the page,
the frame imports a feature,
a feature imports another: where two go together, it is the composition that says so, as it hands the stars whatever world turns,
two boxes, or two files, need each other round in a circle,
a file exports more than one value,
a feature is missing from the diagrams in ARCHITECTURE.md.
Some of what the pages here measure can only be held, not forbidden. A ratchet turns one way. A file in the source, architecture.ratchet.json, keeps where four measures of the source stand, and a test fails if any of them gets worse. When one gets better, the test fails too, until the new value is written into the file, in the same commit, so that the gain cannot be lost again. A limit drawn by taste would either fail on the first day or be too loose to catch anything; a ratchet starts where the source is, and only lets it go forward. It asks nobody, person or AI, to remember anything: whatever makes the shape worse is told so, by name.
For each measure, the figure sets what the ratchet holds beside what the source measures. What it holds is read from the file at every commit since it came in, a band that steps wherever the file was changed. What the source measures is taken at every commit of the history, as the ratchet takes it now, the commits before it began as well, a line inside the band. Under them, how the ratchet went: when it began, what it held, and every time it was tightened since, or loosened.
what the ratchet holds
over the history
held
measured
arrows against stability box arrows from a box to one less stable than itself, by Robert C. Martin's measure; the composition's aside, which has to point at every feature
1
1
deepest core how deep the knot of files goes: what is left when every file with fewer links than that is taken away, again and again
5
5
tallest stack the longest chain of what needs what, in arrows
12
12
untested files files that ship with something in them to run that no test imports
143
143
measured at every commitheld by the ratchet
How the ratchet went
29 September 2026: began, holding 8 box arrows against stability, a core 5 deep, a stack 12 arrows tall and 156 files with something to run that no test imports
29 September 2026: tightened, the arrows against stability from 8 to 5
29 September 2026: tightened, the untested files from 156 to 155
29 September 2026: tightened, the untested files from 155 to 147
1 October 2026: tightened, the arrows against stability from 5 to 4 and the untested files from 147 to 146
2 October 2026: tightened, the arrows against stability from 4 to 3
2 October 2026: tightened, the arrows against stability from 3 to 2
5 October 2026: tightened, the arrows against stability from 2 to 1 and the untested files from 146 to 144
8 October 2026: tightened, the untested files from 144 to 143
At this commit, the ratchet holds 1 box arrow against stability, a core 5 deep, a stack 12 arrows tall and 143 files with something to run that no test imports, and the source measures the same. At no commit since it began has the source measured more than the ratchet held.
And what how this site changes finds, files that keep changing together with no arrow between them, is held too: two files of different boxes that changed together twice with nothing joining them need a test that imports both, so that what they agree on, which no import states, is written down where breaking it fails. Two files of one box changing together is what makes the box one, and the files that put the features together change with everything they put together: both are left out. So the page the build writes and the scripts that take it over agree in a test; so do the theme the head paints before anything shows and the one the theme's script settles, and the list at the end of a directory's page and what ls prints there.
Two more things watch the AI as it works, and they are in the repository too. After every edit to a file of the source, it is told what the history knows of that file: how often it has changed, what it changes with, and whether a test holds what they agree on — the panel beside the picture, said at the moment it matters. It cannot commit, nor end its turn, while the type check or the tests are red, and the checks that read the history read it as the deploy will write it, with what is being committed in it. Then, after every push, the deploy breaks the lines that push changed on purpose, one small change at a time, === into !==, && into ||, and lists the ones no test noticed. Code coverage says a line was run; this says whether running it was checked, which is the difference a program that tests nothing makes plain. And it lists what no test runs, not as a number to raise but as a question each file asks. If nothing in the site uses it, it has no purpose, and goes. If only a browser runs it, it is hard to test where it is, and what it decides can move out of the browser. And if the site uses it and no test runs it, it has a behaviour no test states yet, and the test is what is missing: the first such test said, of every page, that every figure it names stands in its HTML, which the build had never been made to prove.
The dashed arrows need only a type: a box that depends on an interface, not on what implements it. That is dependency inversion, and it is what lets a feature be removed by removing its folder.
8 September 2026
On its first day the source was sorted by kind of file: a core and a ui. On the second it was sorted by what the site is — a frame, and the features standing in it — in one commit: The folders say what the site is, not what kind of file each one holds. Drag the slider back to it and watch the files cross.