TypeScript Clean Standard

Each item has an identifier, the kind of package it applies to, and the evidence that proves it. The kinds are:

• All: every TypeScript package in the tree.
• Shared: a package the browser can reach without pulling in Node. That is @ores/wire-protocol through its /browser entry, whose root entry does carry the NATS client, and @ores/contracts, whose shipped source imports nothing from Node; its devDependencies do carry @types/node for the build, which is a different claim. Only the BFF imports @ores/contracts today, and closing that gap is one of the defects the architecture audit records.
• Browser: code the browser runs, in packages/web.
• Server: code Node runs, in packages/bff.
• Generated: a file ores.codegen writes into packages/wire-protocol/src/generated/.

An item that does not apply is recorded as "not applicable" with the reason, never skipped in silence. An item that cannot pass is recorded on the task with its reason and the date, and the package is not called clean.

There is no registry. The Component Clean Standard keeps one because thirty-five components each need a row, an accepted-exception list and a gate that reads them; four packages in one component do not. When a second TypeScript component appears, the registry becomes worth building and this paragraph is where it starts.

The items are ordered by how a reader should work, not by importance. Work in the order of the sections: an inventory before an edit, types before data, data before effects, and verification last, because verification is what proves the rest.

The compiler is the strongest gate this standard has, so the first items are the ones it already proves. The rest are the mistakes it does not catch, and each names the rule that does.

A boundary is where a value the compiler knows nothing about becomes one it does. The rule is parse, do not validate: the parse produces the typed value, and there is no second representation downstream.

Measured on 2026-09-27, before any of this was acted on. The compiler gate, the suite and the format figures come from ef8df25c61; the branch that adds this page adds two files to the component, so where a figure moves, the cell gives both. The numbers are the reason the standard says what it says.

Four things follow from that table.

The compiler gate is the one that works, and it earns its place: the strictness set already makes implicit any, an unchecked index, an undefined in an optional property and a fall-through switch into compile errors. It is also the only gate that is not optional, which is what makes the exclusion of the test files worth a separate item.

The format gate is named in package.json and has never run. There is no configuration at all, in the component or above it, so this is not a missing file that somebody deleted: the component has never been formatted by the tool it declares, and the style it does follow was never captured. Two decisions follow, and they are separate. The generated tree should be the generator's business, not the formatter's, because 303 of the 363 files are generated and hand-formatting them is undone by the next regeneration. The hand-written tree should be formatted once, against a configuration committed with it.

The lint gate does not exist, and most of the items above name a rule from it. This is the one gate the standard requires and the component does not have. It is also the gate that catches what the compiler cannot: the unsafe assertion, the non-null assertion, the floating promise, the unbound method, the non-exhaustive switch, and the missing import type that verbatimModuleSyntax only partly covers. Nothing enforces TS-T02, TS-T03, TS-T04, TS-T07, TS-T12, TS-T13, TS-T15, TS-E01 or TS-H02/H05/H06/H07 today, and a review is the only thing standing in for all of them.

The engine floor is a live defect rather than a convention. A contributor on the declared minimum installs a tool that refuses to run, and nothing in the repository says so.

One item is worth stating because it is easy to get wrong. erasableSyntaxOnly rejects an enum, a namespace and a class parameter property, and does not reject a declare enum. That was checked by compiling each form, which is why TS-T09 leans on both the flag and the rule.

Measured on 2026-09-27 at 0df6665001, the commit that lands the formatting. The tree is that commit's, so every figure below is a measurement rather than an intention.

Four items move, and one of them only in part.

• TS-R02 is met by the first branch it offered. The generator formats its own output, so no generated file is formatted by a tool other than the one that wrote it, and the templates never have to be prettier-shaped.
• TS-H01 is met. The configuration is committed, the tree passes, and the check runs on a pull request.
• TS-V04 is met with one exclusion, which is the "by decision" this item asks for rather than an accident: eighteen files of refdata's generated protocol tree are excluded, because the render disagrees with them about content, and formatting a file the drift sweep then finds changed fails that gate. The reason is written in .prettierignore beside the pattern, and the exclusion goes when refdata is regenerated.
• TS-V08 stays open, closer than it was. The workflow now names typecheck, format:check and test; build, lint, coverage and the live-fleet check are still missing.

One conclusion in the first audit needs correcting, because the words were read too narrowly. It said the generated tree "should be the generator's business, not the formatter's", which this work took to mean the generated tree stays unformatted. The two are different: the generator's business can include running the formatter, and now it does. The 306 generated files are prettier-shaped because the render makes them so, not because anyone formatted them by hand.