tcm studio (`tcm studio` runs it, on this machine only): a codebase to work in from the browser. Its overview (what got worse and why, what's running, agents, scratch files, what needs fixing), its code as the forge shows it, each definition with how it runs, scratch files to edit in the browser and update the codebase with, what tcm runs on it (`tcm ps`'s, with jobs and the machine's slots), its traces, and its history, branches and releases. Every page renders on the server from the codebase (`TCM_SHARE_CODEBASE`, or this app's own, under `tcm dev`). `tcm dev tcmts.studio.App` serves tcm's own codebase while you work on it.
A scratch file checked: what's wrong with it, or, if nothing is, what updating the codebase with it would do to each definition it holds (as `tcm check` says it: new, an update, identical to what's there...).
A completion in a scratch file: what it writes, its kind (as the editor's icons have them), what it is, how it ranks, and, for a name from the codebase the file doesn't import yet, the change to its imports that brings it in.
What's wrong with a scratch file, as tcm checks it: where (its line and column, from 1), and what, from TypeScript, tcm or oxlint; and what would fix it, when that's known (a name the codebase has, imported).
A watch's value in a scratch file read as a notebook: the line its statement ends on, and what it came to (or what it threw), a React element rendered too (`html`); kept from before (`cached`); or, not run, what it reaches outside that waits for asking (`waits`). A test the file holds has its outcome here too (`test`), on its first line.
What an app the studio started (Start, as `tcm dev`) has said: its output's last 400 lines, as they come (made again every two seconds while it's shown), and whether it's running still, to open or stop.
AppPage({ name }: { name: string; }) => Promise<Element>
An app (`name`, what `tcm dev` is pointed at), and what it's made of (`appParts`): its code in the browser, the server functions the browser calls, the tables they reach, its recurring jobs and its tests; whether it's running (where, for how long, its output), to open, stop or start. Made again every few seconds while it's shown.
The app's data (its typed tables, as `tcm data` lists them): each table the codebase declares or has rows in, with its columns, how many rows, how many are stored as an older row type, when one was last written, and the definition declaring it (a test's tables, once they have rows).
HowItRuns({ name }: { name: string; hash: string; }) => Element | null
How a definition ran on this machine in the last day, from its traces (as `tcm traces <name>` says it): what runs worse than its version before, and the change that did it; each version side by side, with its calls and the history entry that made it; where its calls came from in the browser, as pages waited for it; and its slowest traces. Nothing, if nothing's recorded for it.
The app's background jobs (as `tcm jobs` lists them): how many are queued, running, done, failed and cancelled, each state a filter (`status`); the newest 200, each with its function, its attempts, when it runs or ran, and its error; one (`job`) in full: its arguments, its error, its trace, with Retry or Cancel. Beside them, the app's recurring jobs (`every()`), each with how often and its last run. Made again every few seconds while it's shown.
The codebase's libraries (other codebases' code, mounted read-only), as `tcm lib` lists them: each with what it is, who announced it, where it's fetched from, what it reaches outside itself and what uses it, and what its author and the people the codebase trusts say of it (a yank, an advisory, a review); on hover, Upgrade and Remove. Add a library, or find one on the registry (`q`, as `tcm lib search`), each found with its Add.
What needs fixing on the branch, as `tcm todo` says, each with what fixes it: a merge waiting apart (what it left, as merged, and Drop the merge); conflicted names, each definition with its side (Edit merges them into a file, Keep ours, theirs or one by hash settles it); definitions that stopped typechecking, with why (Edit writes each against what replaced what it used); and code using a version nothing names. On a branch only read, nothing to press.
The studio's first page: what needs you, and what's going on. What runs worse than its version before (and the change that did it); what tcm runs on the codebase (apps, servers) and agents' sessions; the scratch files holding work; beside them the last day's calls and errors, what needs fixing, and the latest history.
A package at one range (`range`, else the newest the codebase runs): what it is, its README, its API (each export by name, its kind and doc, its signature folded under it), and what in the codebase uses it; beside them its version, license, homepage and types, and Upgrade (within its ranges, as `tcm upgrade`).
What tcm runs on the codebase, whoever started it (the studio, a terminal, an editor, an agent): each `tcm dev`, `start`, `serve` and `studio`, with where it listens, its branch and how long it's run, to open or stop, and the codebase's apps that aren't running, to start (`tcm dev`); each agent's session and the background jobs it's running (the machine's slots have a page of their own). Made again every few seconds while it's shown.
Every package the codebase has, each a link to its own page (`releaseHref`): its latest release and when, and whether a release waits (something under its namespace changed since its latest), not worked out further here (its page says what version, and why); those waiting first, then those up to date, then those never released, the codebase's own first among its kind. `q` narrows them to names and descriptions with it.
A scratch file, to edit (`ScratchEditor`; `show`, a definition it holds, in view as it opens): read only while the browser reads another branch, since what it saves goes to the codebase's own.
SinceRelease({ namespace, since, version }: { namespace: string; since: string; version: string; }) => Element …
What changed under `namespace` since the history entry `since` (a package's last release), as the history has it: each entry that edited, added, removed or renamed something there, newest first (of the latest 400), each a link to its page with what it changed there; and how many definitions that is in all. Why a release waits, its API the same or not.
The machine's slots, which every tcm on it shares (`withSlot`): what one holds keeps about a core busy (a suite, test definitions, checking, an app build). Each slot and what holds it; the runs holding them, each with what it is, whose codebase (this one, or another) and branch, its process, how many slots and since when; the line waiting for one, in turn; how many were held and waited for over the last half hour, as the studio saw them; and why there are as many as there are (the machine's cores and memory, or `TCM_SLOTS`). Made again every few seconds while shown.
The codebase's branches, and what to do with them: its own first (New branch makes one from it), then the others, then agents' sessions (those older than a day folded away), each with when it last changed, how many names differ from the codebase's own, a contribution proposing it, and, on hover, Merge (Land it, onto main), Work on it and Delete. A merge the studio started shows what it says as it runs (made again every two seconds while it does).
StudioCodePage({ name }: { name: string; }) => Promise<Element>
A definition's or namespace's page, as the forge shows it, in the studio: a definition's with how it runs.
Every studio page's frame, and the forge's pages' in the studio: the project and the branch it shows, the finder, and the tabs as a column on the left: the overview, the code, the scratch files, what needs fixing (counted), the tests, the libraries and the packages; what's running, how it runs and its data; history, branches and releases. Reading another branch, a notice says so, with what to do with it (merge it, work on it). Without the token (the link `tcm studio` prints signs the browser in), it's the sign-in page instead.
A package's own releases page (`pkg`; the index, `ReleasesIndexPage`, leads to it): its next release as things stand, first (the version it calls for and why, the bump, each semver finding behind it with what it means for code using the package, what it can't be released for yet, the summary drafted for it, and how to release it), then the releases made, newest first, each with its notes folded under it; beside them, the package: its namespace, exports, commands and the changelog. A tab for each package, saying how many findings wait in its next release.
A table's rows: newest first (or sorted by a column: `sort`, `desc`), searched (`q`, anywhere in a row), filtered (`where`: fields equal to values, as `find` has them), 50 at a time (`page`), each cell shown as its type reads (dates as when, numbers aligned, nothing as nothing, objects in one short line), its columns saying their types and which are unique or indexed. A row asked for (`row`; "new", a new one) is above them to edit, as JSON, saved as the table's own writes are; the rows as they're shown download as JSON or CSV. Rows stored as an older row type say so, with a button migrating them.
The codebase's tests: each test definition, by namespace, with its last outcome as kept (passes, fails, or not run as it is now), failures first with what they said; a run of them (Run all, a namespace's, one's), as `tcm test` runs it, its output as it comes (made again every second and a half while it runs). `q` narrows them to names with it.
One row of the traces page as a page of its own: a definition's spans of a kind (each version of it alike), or a page's, a view's or a statement's, `since` long ago (1h, 24h, 7d). Its calls, errors, p50 and p95; what runs worse than its version before and the change that did it; each version side by side; where its calls came from in the browser; its slowest and latest traces, each a link to its waterfall.
One trace (an id, or its start), as `tcm traces --trace` shows it, drawn as a waterfall on one clock: each span by where it ran (the browser, the server, the database) under the one it's inside, its definition linked to its page, the definition that made a call from the browser, an error under the span that threw it, and the jobs it enqueued.
What the app did on this machine (`tcm dev` and `tcm start` record it), or `from` production (its server's traces, fetched: `fetchProduction`, set up here, `ProductionForm`), as `tcm traces` says it: what runs worse than its version before and the change that did it, then what it spent its time on by definition as named now (`show` "errors": the errors instead, grouped by the definition that threw them), `since` long ago (1h, 24h, 7d).
Add a library, as `tcm lib add <source> [what] [--as <name>]` does: a release its author announced (`@alice.dev/geo`), or what a remote, URL, directory or `tcm` holds (`what`: `<package>[@<version>]` or a namespace's hash), fetched with what it uses and mounted read-only. What it said.
Announce release `version` of `name` on the AT Protocol, as `tcm release <name>@<version> --announce` does (it's run: signed in in the browser the first time, which opens there, or kept from before), as `as` (a handle; else the account used last) and fetched from `source` (else what's kept, or origin): what it said.
What an app is made of, as `tcm build` plans it (and the editor's Apps view shows it): its code that runs in the browser, the server functions the browser calls, the tables that server code reaches (each with its rows here), and, in its namespace, its recurring jobs and its tests; what's wrong with its plan, if anything is.
The codebase, for what the studio does with its branches (make, switch to, merge, delete one): only the studio's maintainer does, whichever branch this browser reads (it's the one they act on).
What upgrading the library `library` (its mount, or its name) would do, as `tcm lib upgrade --check` says it: to its package's newest release (an announced one's, the highest its author announced), what changed in its API.
Completions at `offset` in a scratch file (`text` being what it holds; `trigger`, the character typed that asked, a "." say): TypeScript's, from its language service, and after them the codebase's names the word begins (where a name, not a member, goes), each with the import it needs. From where the word they complete starts.
Where the name at `offset` in a scratch file is defined: a name from the codebase, its page; one the file declares, where (an offset); one from elsewhere (a package, the standard library), nowhere here.
Write the definition `name` into a scratch file to edit, as `tcm edit <name>` does: code into `scratch.ts` (or `scratch.tsx` for JSX), beside what it holds already; a file kept as written into one of its own, named as it is (or, being edited there already, that one); a conflicted name, its definitions merged, into a file named after it. While a merge waits apart, as merged (`tcm edit` writes it). The file's name.
The codebase, for changing it from the studio: only the studio's maintainer does, and only on the codebase's own branch (another branch, as the branch menu reads it, is only read).
What `expr` comes to, in a scratch file (`text` being what it holds): run as a statement of it would be, once, its value (a React element rendered too) and what it wrote out; what's wrong with it, if it doesn't check (it sees the file's top-level names, not what's local to a definition).
A table's rows as the page shows them (`q` searched, `where` filtered, `sort` ordered; up to 10,000), as a file to download: JSON (each row its id and value, as `toJson` writes it) or CSV (a column a field, as its cells read).
Make the expression at `from`..`to` in a scratch file (`text` being what it holds) a definition of its own, named `name`, above the one it's in: what it uses that's local to that one (parameters, variables) becoming its parameters (typed as they are there), the expression giving way to a use of it (awaited, if it awaits). What the file holds then, and where the new definition's name is.
Fetch production's traces (`GET /__tcm/traces.sqlite` on its server, with its traces token) into the studio's copy, which its traces pages read: what came, or why nothing did.
How many things need fixing on the branch `cb` reads, for the studio's tabs: conflicts and what stopped typechecking (while a merge waits apart, as `fixesOf` last said, or at least the merge).
What needs fixing on the branch `cb` reads, as `tcm todo` lists it: conflicts, what stopped typechecking, code using versions nothing names. With a merge waiting apart on the studio's own branch, as merged (`tcm todo --json` says it, kept while the merge stays as it is); a branch only read is as it is.
A scratch file's code (`text`) formatted as tcm formats what it saves (oxfmt, as the language server formats a file as it's saved); as it was, if it doesn't parse or isn't code.
What a scratch file has at `offset` to say on hovering it (`text` being what it holds): a name from the codebase, its names, hash, signature and doc, as its page has them (and its name, to pull it into the file); a definition the file declares, its type and what updating would do to it; a local of one, whose it is and where; anything else, its type, as TypeScript has it. Where that is in the file (offsets), and it as HTML.
A file kept as written, being edited at `abs` (holding `text`) to go back to `name`, checked: what updating would do, it being new there, an update, or as it is.
The name the scratch file at `abs` goes back to, if it's a file kept as written being edited: a Markdown file's first line (`<!-- tcm: path a.b -->`), or what the studio kept when it wrote it (`keptInto`).
Where the studio keeps, for the files kept as written it wrote into scratch files to edit (Edit on their page), the name each goes back to (a Markdown file's first line says so too): `.tcm/studio/kept.json`, by the file's path.
The libraries the branch `cb` holds, as `tcm lib` lists them: what each is, who announced it, where it's fetched from, what it reaches, what uses it, and what its author and the people the codebase trusts say of it.
Every test definition the codebase names (as `tcm test` finds them: named test…, or under `tests`), each with its last outcome as kept (by hash, as `tcm test` keeps it: a pass, a failure, or none, not run as it is now); a suite's test (`suite`: one running a package's command, as its manifest declares) has its passing run, for its code as it is, if one's kept.
Release `name` at the version its changes call for, as `tcm release <name>` does (it's run, in the codebase's directory: its notes from the draft if there is one, a mirror's record of it, all as the command makes them). Only for the studio's maintainer, and only on main, the codebase's own branch: releases are main's. Says what the command said, or why it refused.
Bring a table's rows stored as an older row type up to its current one, as `tcm data migrate <table>` does (it's run, so the table's `migrate` does it): what it said.
A scratch file's watch (the statement beginning on `line`, `text` being what the file holds) that comes to a React element, built to run in the browser: its module and what it uses, bundled with the React DOM its React goes with (one script, React DOM's `createRoot` rendering it), for a notebook to run in a frame of its own; kept by the statement's hash (`previewBuilds`), so it's built again only when what it runs changes. Code that only runs on the server fails there, saying why.
Where the studio keeps production's address and traces token (`.tcm/studio/production.json`, only its user reads it), and when its traces were last fetched.
Pull definitions (`names`) into the scratch file `file` (`text` being what it holds), as `tcm edit <names> --file` does: each written with what the file holds kept (a definition saved as it is there stays, written again with them), one the file has already left as it is; JSX into a .ts file makes it a .tsx one (`file`, its name now). What the file holds then, and what was done.
Read `branch` in this browser's studio, from its next page on (none, or the codebase's own: back to it). Only the studio's maintainer; a branch that isn't there is refused.
Where the name at `offset` in a scratch file is used (`text` being what it holds): its lines here, and, for a name the codebase has, what in the codebase uses it (the named definitions that refer to it).
Delete the branch `name`, as `tcm branch <name> --delete` does: not main, the studio's own, nor a session an agent is working on; the history it made stays. What it said.
Remove the name `name`, as `tcm rm` does (it's run, on the branch the studio serves): with `force`, even though named definitions use it (they keep working: they use it by hash). What it said.
Rename (or move) the definition or namespace `from` to `to`, as `tcm mv` does (it's run, on the branch the studio serves): no code changes, and what uses it follows, by hash. What it said.
renameInScratch(file: string, text: string, offset: number, to: string) => Promise<{ changes: { from: number; to: …
Rename the name at `offset` in a scratch file to `to` (`text` being what it holds): the changes to the file, and what was done in the codebase. A name the codebase has is renamed there too, as `tcm mv` does (its hash stays, so what uses it follows; `to` a leaf keeps its namespace, a dotted name moves it), and the file's import follows it; anything else is renamed in the file alone.
Settle the conflicted name `name` by keeping one of its definitions, as `tcm resolve` does: `ours` or `theirs` (the sides of the merge that made it), or a definition's hash. What uses the others is re-derived against it. What it said.
Run a scratch file's watches (its top-level statements: what each comes to), as `tcm check` does, for a notebook (`text` being what it holds; nothing, while it has problems). Values are kept by hash, as a test's results are; one whose code reaches outside (the clock, the network, files...) runs only when `all` asks, every time, and otherwise says what it waits on. Its tests' outcomes too: those kept (a pass is kept by hash), and, when `all` asks, each run.
Run tcm (this process's, as its command line runs it) with `args` in the codebase's directory `root`, as you would: without the studio's own variables, or the codebase's or branch's, unless `branch` keeps the branch tcm dev serves (`TCM_BRANCH`). What it said, colours taken out, and its exit code.
Run one test a scratch file holds (`path`, `text` being what the file holds), as `tcm test` runs it, again: its outcome, as the notebook shows it under the test.
Save row `id` of `table` (a new row, if there's no id) as `json` says: read by the table's row type (ISO strings where it has dates, and the like), checked against it as the app's own writes are, refused if it would share a unique field with another row. The row's id.
Keep `text` as the scratch file `file` (when it's changed), and check it, in this process, as the language server does as you type: TypeScript's problems and tcm's, each where it is (a name the codebase has, with the import that fixes it), oxlint's as warnings, and, if there are none, what updating the codebase with it would do. A file kept as written (Markdown, say) isn't code: only what updating would do.
The app's recurring jobs (`every()`, in its code): each by name, how often (its spec, as written), when the queue first saw it, and its last run. `found`: the recurring jobs, found before (the codebase being as it was then).
The scratch files there are, newest first: each `.ts` or `.tsx` file in `scratchDir`, and the files kept as written being edited there (`keptFile`); when each last changed.
The scratch file named `file` (only a name, of one in `scratchDir`: a `.ts` or `.tsx` file, or a file kept as written being edited, as `keptFile` says), as a path.
Keep production's address (`url`, the server `tcm start` runs the app on) and traces token (its `TCM_TRACES_TOKEN`), for the studio's traces to read; its traces fetched before go.
The call `offset` is in the arguments of, in a scratch file (`text` being what it holds): what's called, as its type reads (each signature, if there are several), where in that each parameter is (offsets in `label`), and which argument `offset` is at. Nothing, outside a call's arguments.
Start app `name` as `tcm dev <name>` does (it's run, on a free port, on the branch the studio serves), its output kept in `.tcm/studio/logs/<name>.log`; it runs on after the studio (Stop, or `tcm ps`, ends it). Where it's listening, once it is (it says so in `.tcm/run`), or that it's still starting.
Merge the branch `theirs` into the studio's own, as `tcm merge` does (on main, that lands it: main merged into it first, there, then its tests), run on, what it says kept as it comes (`mergeRuns`). `squash`: what came in as one entry (as sessions land); `message`: what the entry is for. One at a time. The run's id.
Run tests as `tcm test <names>` does (all of them, without names; the tests under a namespace, or one): it's run, on the branch the studio serves, what it says kept as it comes (`testRuns`). One at a time. The run's id.
Stop one of the tcms running on the studio's codebase (`tcm dev`, `start`, `serve`: one its records name, by its process), as Ctrl-C would. Only for the studio's maintainer; never the studio itself, or a process the records don't name.
The codebase the page being made reads: the one served, on its own branch, or, if the browser reads another branch (`BRANCH_COOKIE`) that's still there, the same codebase opened apart reading that one (`--branch`: nothing changes it), kept for the pages after.
Set up the forge's pages to show in the studio's frame (its column of tabs), a definition's with how it runs below its code and what to do with it (Edit, for code and files kept as written that are text; Rename and Delete; on the codebase's own branch, as another is only read), each reading the branch the browser reads (`studioCodebase`); and the machine's slots watched from then on (`slotSamples`): what every studio page does first.
Work on the branch `name`: the codebase's own moves to it, as `tcm switch` does (and this browser reads it, as its own). Not under `tcm dev`, which serves a session's branch (`TCM_BRANCH`): that stays on its own.
The environment a tcm the studio runs gets: its own, as you would run tcm, without the studio's variables (the codebase it serves, its sign-in, stopping with it) or the `NODE_ENV=production` `tcm start` gave it (`tcm dev` would bundle React's production build, without the development JSX its code is compiled to).
Update the codebase with the scratch file `file` (holding `text`), as `tcm update <file> --clear` does (a file kept as written, `--into` where it goes, unless it's Markdown, whose first line says): it's run, on the branch the studio serves, so what it does, refuses, and says is the command's, and the file goes once what it held is saved. What it said, and the history entry it made.
Upgrade the library `library`, as `tcm lib upgrade` does: one update, what changed in its API first, then the code using it follows (what doesn't typecheck goes to Needs fixing). What it said.
Move package `name` to the newest versions in the ranges the codebase runs it at, as `tcm upgrade <name>` does (it's run: no hash changes, everything using it is checked again, and if anything breaks the lock goes back): what it said.
Keep `summary` as what package `name`'s next release (`version`, as things stand) is about: its draft (`release-<name>.md`, as `tcm release --draft` writes it, its changes below the marker made again when it's released), which releasing takes its words from. An empty summary takes the draft away. Only for the studio's maintainer, on the codebase's own branch (not one only read here).
Browser
AbortMergeButton({ theirs, into }: { theirs: string; into: string; }) => Element
Drop the merge waiting apart (`tcm merge --abort`), asking first: what settled it so far goes with it.
Narrow a table's rows to those whose field equals a value (as `find` has it): asked which field and what value, it goes to the page so filtered (`href` the page as it is, its query kept).
Add a library (`tcm lib add`): where it comes from (a release its author announced, `@alice.dev/geo`; a remote, a `tcm serve` URL, another codebase's directory, or `tcm` for tcm's own), and, from a remote, URL or directory, which package (or namespace hash); what to call it, if not its package's name. Given `source` and `what` (a registry's find), it's one button.
AnnounceButton({ name, version }: { name: string; version: string; }) => Element
Announce a release (`announceRelease`): asked as whom (a handle, or the account used last) and where it's fetched from (or what's kept); signing in, the first time, opens in the browser.
What to do with another branch: merge it into the studio's own (`tcm merge`; on main, that lands it, with its tests run first), as one entry if asked, with what it's for; work on it (`tcm switch`, where the studio can); delete it (`tcm branch --delete`), asking first, unless it's to `keep` (main, a session an agent is working on).
BranchLink({ branch }: { branch: string; }) => Element
A branch's name as a link: it reads that branch in this browser, and shows its history.
The branch the studio shows, as a menu in its header: the codebase's own first, then the other branches, then agents' sessions (those an agent is working on now marked, and those changed in the last day; the rest under Older), each with when it last changed. Choosing one reads it in this browser from then on (`readBranch`), its code, history and traces; nothing changes it.
What settles a conflicted name: Edit, its definitions merged into a file (conflict markers where they overlap), or keep one: ours or theirs, where a merge made it, or each by its hash (`tcm resolve`).
What a definition's page does with it in the studio: Edit it (in a scratch file), Rename it (or move it: a name of another namespace), as `tcm mv`, or Delete its name, as `tcm rm`, asking first and saying what uses it (which keeps working, by hash). `usedBy`: the named definitions that use it; `editable`: whether it's code or text to edit.
EditButton({ name }: { name: string; }) => Element
Edit a definition from its page: it's written into a scratch file (`editDefinition`, as `tcm edit`), which opens.
What to do with a library: Upgrade, which first says what upgrading would change (`tcm lib upgrade --check`), then does it; Remove, asking first, with what uses it (which would then use code nothing names).
Live({ every }: { every?: number | undefined; }) => Element
Makes the page again every `every` milliseconds while it's shown (not in a tab in the background): for pages of what's running, which change without the codebase changing.
MigrateButton({ table }: { table: string; }) => Element
Migrate a table's older rows (`migrateTable`, as `tcm data migrate`), then show it again.
Make a branch from the studio's own (`tcm branch`), and work on it (`tcm switch`) where the studio can: not under `tcm dev`, which serves its session's branch, where it's read instead.
NewScratchButton({ small }: { small?: boolean | undefined; }) => Element
Start a scratch file (`newScratch`), and open it.
ProductionForm({ url: was }: { url: string; }) => Element
Set production up for the studio's traces: the server's address and its traces token (`setProduction`), its traces fetched at once (`fetchProduction`).
Find a definition in the codebase by name (`findDefinitions`: its letters in order) and pull it into the scratch file (`onPick`, its name).
ReleaseButton({ name, version }: { name: string; version: string; }) => Element
Release a package from the studio (`makeRelease`), asking first, since a release names a point of history for good; then the page shows it among the releases made, and a toast says so (or why not).
A row of a table, to edit: a form, a field each (text, a number, a checkbox, a date and time, one of its values, or JSON for what's nested), or the whole row as JSON (dates as ISO strings, maps as [key, value] pairs, sets as arrays). Saved (Save, or ⌘S) as the table's own writes are, checked against its row type (`saveRow`), the reason shown under it if it doesn't fit; or deleted, asking first (`removeRow`). A new row (`id` empty) starts from what its type needs. An optional field left empty is left out; a field that may be null, null. `back` is the page without the row.
A scratch file to edit in the browser, as a notebook: its code, in an editor coloured as the forge colours code, kept and checked as you type (`saveScratch`, after a pause, or at once with ⌘S), its problems marked where they are and listed below it; with none, what updating the codebase would do to each definition it holds, and what each of its statements comes to, under it (`runScratch`: a React element rendered; one reaching outside, the clock say, when ⌘↩ or Run asks). Code has hovers (`hoverInScratch`) with what's to do with a name: Go to it (`definitionInScratch`; ⌘-click too), its References (`referencesInScratch`: here, and what in the codebase uses it) and Rename it (`renameInScratch`: a codebase name in the codebase too, as `tcm mv`); and completions with the codebase's names and their imports (`completeInScratch`). A file kept as written (Markdown, JSON, CSS) is edited as what it is. Update codebase saves it (`updateScratch`, as `tcm update`) and shows the history entry that made; Discard throws it away.
What a release is about, in its notes: as it'll read (`html`, made on the server), or nothing, with a button that opens it to write (Add notes, Edit notes); written, it's saved (Save, or ⌘↩) to the package's draft (`writeReleaseSummary`), which releasing takes it from.
UpgradeButton({ name }: { name: string; }) => Element
Upgrade a package within its ranges (`upgradePackage`, as `tcm upgrade`), then show it again.
The studio's own styles, beside the forge's (`SHARE_STYLE`, whose colours, boxes, rows, badges and place bars it uses): the logo, a column of tabs on the left of every page (a row of them on a phone), the forge's pages laid out in the column beside it, a trace as a waterfall, and a scratch file's editor (CodeMirror, in the forge's colours).
The scratch file `abs` analyzed as it holds `text` (in this process, as the language server analyzes it), or as it was last if nothing's changed since: the text, or the codebase.
The change to a scratch file's imports (`text` being what it holds) that brings in `leaf` from `module`: added to the import there is from it (`import type` for a type), or a line of its own after the imports at the top (and the namespace pragma). Nothing, if it's imported already.
What needs fixing on a branch with a merge waiting apart, by the branch and the merge as it is (its setting): only a command works it out as merged, so `tcm todo --json` does, once for each.
The name at `offset` in a scratch file, as references and renaming see it: the identifier, its symbol here, where the file uses it (offsets, its own declaration or import included), and, for a name the codebase has (one it imports, or a definition the file holds that's saved), that name and its hash.
Notebook elements built to run in the browser (`previewInScratch`), by the statement's hash (which covers all it runs) and the React DOM it's built with: the newest 40.
Each scratch file's last analysis, as the studio's editor last asked about it (the text, and the codebase as it was): checking it, hovers, completions and going to a definition ask the same one while it stands.
Where the codebase's scratch files are: beside it, or in its session's directory when it's served for a session (`tcm dev` with `TCM_BRANCH`), as the command line has them.
The machine's slots as the studio has seen them while it ran: a sample every five seconds (`watchSlots`), the last half hour's, oldest first: how many there were, how many were held (by codebase), and how many slots work in line waited for.