tcm's AT Protocol flows against Bluesky's own software, locally and offline, before a release: dev-env's PDS (its OAuth server and consent pages) and PLC directory, with a stand-in for Jetstream and a relay fed by the PDS's own firehose (`tcmts.dev.devenv.run` says what it checks). `pnpm tcm run tcmts.dev.atprotoTrial [tcm.js] [dir]`: the tcm given (default the known-good one), in `dir` (default a directory in the system's temp, kept, so dev-env is installed there once; not as tcm's dependency). Needs Chrome.
The docs site's code browser (`code/`): tcm's own codebase, every definition a page, and an index of it and the examples, each of which tcm's server shows in a forge of its own (`code/<name>/`, its codebase as its setup script builds it: `tcm serve --forge`); and each example's files to download (`examples/<name>.tar.gz`, a directory of its name). One that's a static site is built into the site, from the codebase its setup script builds (kept in dist/examples by what its files hash to, so it's built again only when they change, and kept a day after it was last used, as verifies of other branches may have other files: each built one at a time). Returns what couldn't be built, and any link in it to a page that isn't there: named exactly, case and all (a filesystem that ignores case would find `Highlighter.html` for `highlighter.html`; the server's doesn't). `env` is given to the examples' setup and builds: a slot's (`withSlot`), when this runs in one, so they don't wait for another. `base` is the path the site is served under: an example that's a static site is built for its place in it.
Build the docs site into `out`: the site's pages (SOURCES: tcm's docs and the examples page, as the codebase has them), text-file-looking, ordered by the index's tables, numbered like sections of a text file, with a numbered menu down the side. They're the docs app (Docs) built as a static site (`tcm build --static`), every page rendered as it's built, so each is there before any code runs; then the code browser beside them. Every relative link and anchor must resolve, and every page be reached from the index: what isn't is a problem, so the docs can't quietly rot. `env` is given to the docs app's build and the examples': a slot's (`withSlot`), when this runs in one, so they don't wait for another. `base` is the path it's served under (tcm's server has it at `/docs`), for the docs app's own navigation and the examples that are static sites; its links are relative.
Where a verify of `branch` (main, without one) builds the tcm it checks: dist/candidates/<branch>, its own, as each worktree has its own files. (A name a directory can't have as it is, a session's `session/…`, is made one, with a hash of it to keep it the branch's alone.)
Check examples (all, or those named) as their files are now, in seconds rather than a fresh build: each has a codebase of its own kept for checking (`dist/examples/<name>-check`, made once by its setup script), and its files are saved into it in its setup's order, so what doesn't typecheck says so. `--tests` runs its tests too. A large one (Effect, minutes to import) is checked only when named. Run with `pnpm examples:check [name…] [--tests]`.
Each of tcm's libraries (`TCM_LIBRARIES`), added to a fresh codebase as another codebase would add it, by its namespace as the branch this runs on has it (released or not: a library's releases are made on `main` once it's landed): every definition it brings must be named there (nothing it uses arrives as an unnamed version). `pnpm verify` runs it; `pnpm tcm run tcmts.dev.checkLibraries` does too.
Take away what verifies built and left behind in `dist`: each branch's candidate (dist/candidates/<name>), unless a verify is building it now (its verify.lock held) or its branch is still one of `branches` and it was built in the last `maxAge` (a day: a failed one is kept a while, to run its tcm again); and dist/candidate, where every verify built before each had its own, unless a verify of that kind holds dist/verify.lock. Says what it took.
Hashes don't depend on the compiler (`pnpm compare-compilers`): every definition in tcm's codebase, rendered and hashed again with tsrs (TypeScript 7 in Rust, installed into a temporary directory), must be the hash TypeScript 7 gave it (`tcm verify`), and the golden hashes must pass with tsrs too.
Deploy tcm's library registry, `https://tcm.codes/registry`: `tcm registry` on Railway, its directory on the service's volume, behind tcm's server. What's uploaded is the registry's files (`tcmts.deploy.registry`) and the known-good tcm's package, to the `tcm-hub` service of the Railway project the repository is linked to (`railway link`): named from when the registry was called the hub, kept so its private address (`tcm-hub.railway.internal`) stays. `pnpm registry:deploy`.
Deploy tcm's server, tcm.codes: `tcm serve` of tcm's codebase, and its site, on Railway. What's uploaded is the server's files (`tcmts.deploy.server`, with the site's home page), the known-good tcm's package and the docs site built from the codebase, under `/docs`, to the `tcm-server` service of the Railway project the repository is linked to (`railway link`). `pnpm server:deploy`.
How long what the web UI's pages compute takes on a codebase (`tcm run tcmts.dev.forgeTimings <dir>`): the warm-up a server starts with, and the longest it holds up other work; each step the first time (cold), as the first requests after the head moves make it; then the history summaries of the latest `check` entries compared with `diffNamespaces` of their names read whole.
Wait for `lock` (a file holding the pid of the process that has it), take it, and give it back when this process exits, or sooner, when what it returns is called. One left by a process that's gone is taken over. `what` says, while waiting, what's being waited for.
The known-good tcm's package (the build the last passing `pnpm verify` tested), to deploy: its directory and the tarball in it, checked to be the install verify tested.
Publish the lexicons of tcm's records (`tcmts.records.lexicons`) as `com.atproto.lexicon.schema` records, for tcm's maintainers: `pnpm tcm run tcmts.dev.publishLexicons [-- --as <handle>] [--dry-run]`. Each document is checked against the Lexicon spec first; the account is the one `_lexicon.tcm.codes` names in DNS (signing in as anyone else is refused), with a loopback OAuth sign-in asking only to write lexicon schemas. Idempotent: a schema published as it is now isn't written again, a changed one is replaced, a new one is created. `--dry-run` says what it would do, without signing in.
The registry, locally, on the end-to-end tests' fake AT Protocol network, to look at while working on its pages: alice's geo released twice (a breaking change, two additions, one reaching the network, and a change with the same API), maya's review of it, and alice's Bluesky profile; the registry mirrors them, says its address, and runs until it's stopped. `pnpm tcm run tcmts.dev.registryTrial <tcm.js>`: a packed tcm's (`tcm pack tcm-ts`, installed), as the registry ships only in one.
tcm's repository: up from here, the directory with `scripts/codebase.sh` (what gets the codebase, and where it, its known-good tcm and its builds are kept).
`sh`, without waiting: run a program, resolving with whether it passed and what it printed, so several can run side by side. `onLine` hears each line as it's printed.
Where the libraries tcm ships are, for the examples' setups (`tcm lib add tcm react`) run with the tcm of its codebase, which has none beside it: as `tcm test` gives its suites (`TCM_SHIPPED_LIBRARIES`), packed once per release.
A verify's turns in `dist`: its own place to build in (`dir`, dist/candidates/<branch>: `candidateDir`), once no other verify of the same branch has it; and, main's alone, `promote`: making its tcm the known-good one, which every checkout runs, once no other verify is (dist/verify.lock), until what it returns is called. Verifies of different branches build side by side, and a branch's never waits for a promotion.
Write the files tcm's repository keeps (`pnpm repository`) as the codebase has them: what's in git is only how to get the codebase (its script, the agents' instructions, the README), and it's changed in the codebase like anything else. Says which changed; commit them by hand.
The examples, by name: what each shows, and its files as the codebase keeps them. One that's an app runs on tcm's server under /examples/<name>/ (`app`: the app, `tcm start` flags, and whether its data starts over every six hours), as the site's `examples/apps.txt` lists for the server's start script. One that's a static site (`site`: the app) is built into the docs site there instead (`tcm build --static`), and served as its files. Each one's codebase is shown in a forge of its own on tcm's server, under /docs/code/<name>/ (`tcm serve --forge`). One that's `large` (a library imported whole, minutes to build) is checked only when named (`pnpm examples:check effect --tests`), after changing what importing it exercises.
The tcm libraries tcm's codebase ships (packages with `npm: false`, which others `tcm lib add`): `pnpm verify` checks each holds everything it uses (`tcm release check`), as its releases must.
The order an example's setup script saves its files in, with the namespace a file kept as written goes into: `tcm add styles.css --into userinput.design` lines, then the files of its `for f in …; do` loop.