TypeScript is deeply in-distribution (among the most common languages on GitHub), so ordinary typed application code and standard generic APIs are safe to be strict in.

But TypeScript has, arguably, the most powerful *and most tractable* tooling of any mainstream language (its only rival for analyzability is C++ via the clang/LLVM backend), and that cuts three ways for the Discipline — two advantages and one hazard that has no Rust analogue.

**Advantage 1 — generation-time type-constrained decoding EXISTS for TypeScript.** The one result behind much of this work — type-constrained decoding cutting compile errors ~74.8% — was measured *on TypeScript* (Mündler et al., PLDI'25; the only language with a real implementation, R2C-005 / DR1-014). *One of those two evidence ids does not resolve: `R2C-005` is authored (`##FINDING-R2C-005` in the core ATLAS), `DR1-014` is not — the roster runs `DR1-013`, then `DR1-015`, and no document in the tree defines a `DR1-014`. The claim itself stands on the cited paper and on R2C-005; the second id is a dead reference.*

For Rust, that oracle is a multi-year future bet (`vibe-tcg` Stage 3).

For TypeScript it is available *today*: the compiler-as-oracle can run **during** generation, not only after.

This flips the tooling story in TypeScript's favor (see §14).

**Advantage 2 — the most mature codemod/AST ecosystem of any language.** `ts-morph`, the TypeScript Compiler API, `jscodeshift`, and typed ESLint autofix make Classes A (generators), F (structured diagnostics), and especially I (codemods) far more achievable than in Rust — where Class I is [E-hyp] partly *because* the tooling is immature.

In TypeScript, scaffolded edit operations are a near-term reality, not a research gamble.

**The hazard with no Rust analogue — types are erased and can be lied to.** Rust's types are load-bearing at runtime; TypeScript's are **erased**.

The compiler believes a `value as Foo` assertion with no runtime check behind it.

This means TypeScript's type system — unlike Rust's borrow checker — is a verifier you can *defeat by writing the right two words* (`as`, `any`, `!`, `@ts-ignore`).

For an AI reader this is dangerous precisely because those words are statistically common in training data.

The Discipline's central TypeScript-specific job is therefore to **forbid the moves that defeat the type system** (§8) and to **regenerate trust at runtime boundaries** (§2).

**The law, projected.** TypeScript source under this discipline reads as *ordinary idiomatic TypeScript*.

No invented syntax — that would incur the out-of-distribution penalty (EsoLang-Bench: 0–11% on unfamiliar surface; in-context learning cannot teach it).

But TypeScript has a second OOD edge Rust lacks: its *type-level metaprogramming* (deep conditional types, recursive template-literal types, HKT emulation) is a sparse long tail that models handle far worse.

So the law has a TypeScript-specific clause: **use the type system's expressiveness up to the point where the types stay idiomatic, and not one step beyond.**

Type-level wizardry is OOD and is treated like `unsafe` — isolated, justified, deviation-marked (§8).

The strictness we add lives in the *compiler configuration, the runtime boundary, the metadata, and the verification loop* — not in clever types.

Unlike Rust, where the borrow/type checker's strictness is fixed and free, in TypeScript that strictness is **configurable**, so the first move of the discipline is to turn it all on (§1).

Rust's strictness is fixed; you get the borrow checker whether you ask or not.

TypeScript's strictness is **configurable** — a non-strict config gives "the syntax of static typing with almost none of the safety."

AI-Native TypeScript therefore **mandates the strictest practical configuration**, because every flag turned on is intent moved from prose into the compiler (A3).

The compiler is a free hallucination detector; we give it the maximum to check.

This is the TypeScript analogue of the Rust guide's "the compiler is a free hallucination detector" (Rust §0) — except here we must *opt in* to it, flag by flag.

Mandatory `tsconfig` floor:

The `tsconfig` is a **versioned artifact of the discipline** (a card-checked file), not a per-developer preference.

Loosening any mandatory flag requires `deviates` + reason.

*Rule:* the strict floor is set by config and maxed out; "we use strict TypeScript" while disabling individual flags or bypassing them with `@ts-ignore` is a discipline violation.

Because types vanish at runtime, the boundary between the typed interior and the untyped exterior (network, JSON, `process.env`, user input, third-party `any`) is where the type system's guarantees end and a model's false confidence begins.

At that boundary the Discipline requires **runtime validation from a single source that is simultaneously the static type and the runtime checker** — a schema library (Zod, Valibot, ArkType, TypeBox).

One declaration yields both `type User = z.infer<typeof UserSchema>` and `UserSchema.parse(input)`.

This fuses three scaffolds (A generator + B typed surface + C runnable contract) into one TypeScript-shaped artifact — the densest single move in the projection.

*Rule:* untyped external data enters as `unknown` (never `any`) and is narrowed only through a runtime validator or an assertion function (§5, §8); a bare `as` on external data is forbidden (§8).

The schema is the boundary's contract; inside the boundary the compiler is trusted, outside it is not.

This is the TypeScript form of "the compiler is a verifier we maximize" — we re-establish the verifier's guarantee at exactly the points where erasure would otherwise silently void it.

The **cell** is the unit of modification, closed under paging (R3-001): it declares its full semantic dependency set so a pager can assemble sufficient context mechanically.

Each is a card in this package's `cards/` (the TypeScript projection of the language-neutral scaffold catalog `02-EXECUTABLE-SCAFFOLDS.xml`); here is the TypeScript shape and the rule.

`throw` in TypeScript is **untyped** — you can throw anything, and the type system is blind to it.

So a thrown error is invisible to a reader and to the compiler.

The Discipline therefore makes failure a **value**, not a throw, on the contract surface: a discriminated union `Result<T, E> = { ok: true; value: T } | { ok: false; error: E }` (or `neverthrow`/`Effect`), with `E` a discriminated union of named error variants carrying `spec://` REQ references.

Exhaustiveness over `E` is enforced by a `satisfies never` / `assertNever` check in the default branch.

*Rule:* failure on a seam is a typed value with REQ-citing variants; the exhaustive `switch` over the error union is checked at compile time (R-010, projected).

*The gate now checks this* — the `ts-seam-error-cites-req` rule flags a discriminated-union error type alias `E` whose variants carry no `spec://` REQ. Honest limits, recorded (never a silent claim): it detects **Form-1** only — a `type` alias whose RHS is a union of object-literal members, each carrying a discriminant property from the closed set `{ kind, tag, _tag }`; the error position is taken from the alias **name** (`*Error` / `E`), NOT from the second argument of `Result<T, E>` (the single-file extractor does not resolve references); and the discriminant set is closed to `{ kind, tag, _tag }`, so a union discriminated any other way is not matched — what the heuristic cannot see is recorded here, not claimed. The parity behind it — no projection enforces the discipline more weakly than another without a recorded reason — is a discipline law in the manifesto (`spec://org.vibevm.ai-native/core-ai-native/00-MANIFESTO#PARITY-ACROSS-PROJECTIONS`).

The Rust guide forbids `if flag` in domain logic; the same rule holds in TypeScript, and the erasure boundary (§2) sharpens it.

Flags and external configuration are read **once, at the composition root** (the app/entry cell), narrowed there through a schema (so `process.env` — pure untyped exterior — is validated and typed exactly once), and a **registry** (a typed `as const` map, or a discriminated-union selector) chooses the cell/strategy.

**No `if (flag)` scattered through domain cells** (R-001).

An explicit `switch` over a discriminated config union at the composition root, exhaustiveness-checked, beats string-keyed dynamic lookup and module-load side effects — "one switch is the system's table of contents."

Two tiers, mirroring Rust's cargo-features-vs-runtime-flags split:

The flag/registry is **typed data with provenance, birth, and sunset** — a branded or `as const` table, not stringly-typed ambient lookup, and never a module-level mutable singleton (which would breach §3 closure). *Built (B-039), TS-shaped: the demo registry is `research/ts-demo/src/main.ts` (a typed `as const` dispatch table — the provenance the line normatively asks for), and the `ts-flag-sites` rule in the conform engine polices WHERE the exterior is read — `process.env` / `import.meta.env` reads are legal only in the file named by `[typescript] composition_root`, and any read in a scanned file outside it is a finding. Honest limit: the rule catches the mechanical half (config/env reads outside the root) but NOT the `if (flag)` half — detecting a conditional on a flag needs flag identity, and no flag table flows through the facts yet, so a bare `if (someValue)` in a domain cell is undetected. The Rust-shaped `FlagSites` (R-001, keyed on construction sites) remains Rust-only; this is its TS-native twin keyed on the read sites the `ts-tsc` frontend can actually see.*

*Rule:* flags are read at the composition root and dispatched through a typed registry; `if (flag)` in a domain cell, or reading config outside the root, requires `deviates` + reason.

These are the moves that *defeat the erased type system* — the TypeScript analogue of Rust's `unwrap`/inline-asm/`unsafe` ban set.

Forbidden by default in domain code; legal only with the escape hatch shown and a recorded reason (`deviates`):

A ban with no escape hatch is a discipline bug; a deviation with no reason is a code bug.

`spec://` URIs carried by JSDoc tags (`/** @implements spec://... */`), TC39 decorators (stage-3 ES decorators) on classes/methods, or a sidecar mapping; `.d.ts` files as a natural meta/shape layer.

The edge kinds mirror PROP-014 (`implements | verifies | documents | deviates | informs`, ≤3 edges per item, the specmark budget); two-tier revisions (author-asserted semantic revision + content hash) with **asymmetric invalidation** (spec bump → edges suspect; code change → edges stay valid); a derived deterministic committed index; an orphan ratchet; `deviates` requires a reason.

The metadata is the authored retrieval index (R3-012): stable anchors + a uniform one-line what/why per exported symbol, in a fixed grammar the pager consumes.

(Decorators have runtime cost and partial erasure — prefer JSDoc tags for inert metadata to stay erasure-clean under §1.)

Wrong prose is worse than no prose (R2C-004, H4): a model conditions on in-repo text with high trust, so a lying comment is adversarial input, and the harm exceeds that of absence.

TypeScript-specific sharp edge: a JSDoc `@param`/`@returns` that has drifted from the signature is a lie the model trusts *over* the (correct) types.

*Rule:* behavioral claims near code are **machine-checked** — backed by Twoslash/`@example` (type-checked) or `expectTypeOf` (type-level checked) — or **explicitly trust-labeled** (verified / unverified / aspirational); JSDoc that merely restates the types is duplication (a defect) — let the types speak.

Misleading `console.log`/error strings count too (the harm is the false claim, not the syntax).

TSDoc remains the human detail layer; duplication with the spec is a spec defect.

Replacing a cell ships a **differential oracle** (Class D, §5) against the old cell — `fast-check` feeding identical generated inputs to `old` and `new` and asserting equal outputs — plus the `@verifies spec://…` edge (§9).

Characterization goldens (`vitest` snapshots) pin opaque legacy behavior; goldens must fail loudly when stale (run under `--ci`; never `--update` silently auto-rewriting).

The characterization variant enshrines current behavior including its bugs — pair it with a spec edge marking which behaviors are intentional vs incidental.

This is byte-for-byte the Rust replacement protocol (R-040) with TypeScript tools; it is the one place the modification-time safety net is mandatory rather than advisory.

**Test matrices.** Declared test matrices, never an implicit `2^n`.

`vitest`/`jest` `test.each` / `it.each` over a **named, bounded case table** (`as const` so the table is typed and exhaustiveness is visible); `fast-check` for behavioral surfaces; the differential oracle (§11) covers replacement; per-cell `vitest` runs in the fast loop (§5).

The matrix is authored data, not a combinatorial explosion the reader must hold in their head (R-060, projected).

**Type-level testing (a TypeScript-unique scaffold).** TypeScript can assert **type relationships at compile time** — a class of runnable contract no mainstream language has so readily, and a place where TypeScript's expressiveness pays the discipline back instead of costing it.

`expectTypeOf<X>().toEqualTypeOf<Y>()` (vitest), `tsd`'s `expectType`, and `@ts-expect-error` as a negative assertion let you test that a generic, a branded type (§4), or a discriminated union (§6) behaves as intended *before any code runs*.

*Rule:* public generic/branded/union surfaces carry type-level tests asserting their key relationships; these run in the Class E loop (a type-level test that regresses fails `tsc`).

This is Class C/D applied to the types themselves — Rust has no comparable readily-available form, so it is additive over the Rust projection, not a mirror.

The weak swarm does **not** read this guide.

It receives, per edit, the Band-3 ops extract of whichever cards' triggers fire — a small, activation-matched set (lazy-push, R3-014; minimal sufficiency, AGENTbench).

This guide and the cards are the authoring/review artifact for the strong author and the human; the runtime surface for the weak reader is "the right TypeScript card's routine + checker, when its trigger fires" — and for `.ts` edits that is a card from *this package's* `cards/`, never the Rust core's.

Cross-cutting concerns the per-edit loop cannot hold are swept by raids (`03-RAID-PLAYBOOK.xml`).

The tcg line has TWO briefs, split by where the intervention happens:

**The TypeScript tooling asymmetry, stated honestly.** The PLDI'25 result proves type-constrained decoding works for TypeScript (75.3% (synthesis) / 70.2% (translation) compile-error reduction; ~94% of TS compile errors are type-level) — but its repository is inspiration-only under the clean-room rule (never a code source; the algorithm would be reimplemented from the paper in structurally different code).

What makes TypeScript first anyway is the compiler itself: unlike Rust at decode time, TypeScript exposes its checker programmatically (Compiler API / language service), so our oracle stands on the REAL checker rather than a rebuilt subset.

Combined with the mature codemod ecosystem (Class I), that makes TypeScript the strongest near-term pilot for the swarm story, second only to where the algorithmic core lives (Rust/vibevm).

**The honest counterweight.** TypeScript's erasure and structural typing mean its *default* safety is *lower* than Rust's — more must be done manually (branding, runtime validation, banning `as`/`any`) to reach the same floor.

TypeScript gives more tooling leverage and more expressiveness, but it also gives more rope.

The Discipline's TypeScript projection is heavier on *bans and boundary validation* (§2, §8) than the Rust projection precisely for this reason — and that asymmetry, not a failure of mirroring, is the genuine T2 content.

**The standing open question (shared with Rust).** The 74.8% / type-constrained-decoding result is a *generation*-time result; the Discipline's central unproven bet is whether scaffolds help *comprehension and modification* of in-distribution code, not just generation.

A type oracle makes a weak agent *write* well-typed TypeScript (by construction at token level; by cheap consultation agentically); whether it then *modifies* existing TypeScript safely is still the pilot's job — and erasure means well-typed code can still lie at runtime if an `as` slipped through, which is why the §8 ban on `as` matters even with the type oracle on.

The agentic battery (two arms, weak model, mechanical verification — see the sibling brief's «Staged ambition», `vibe-agentic-tcg-ts.xml` §4) is the first standing measurement of exactly this question.

The stack ships the toolchain as runnable code (PROP-024); a consumer wires it in five moves:

Gotchas the fresh walks caught:

The recurring posture is the shipped Sweep Playbook driven by `/typescript-ai-native-sweep`; the TypeScript-specific idioms: