[Toolchain][P2] TypeScript 5.8 → 6 → 7 reproduzierbar gegen WASD prüfen

[OuroborosCollective]

Ziel

TypeScript 7 nicht wegen Hersteller-Benchmarks direkt übernehmen, sondern die WASD-Toolchain reproduzierbar von 5.8 über TypeScript 6 zu TypeScript 7 prüfen. Der Compilerwechsel darf keine Änderung an ARE-Kausalität oder Runtime-Semantik erzwingen.

Auditbaseline

• aktueller beobachteter main: b60209d69240bdcf50dd50788c72ec2ec08a03d8
• Primärquelle: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/
• TypeScript 7.0 ist seit 8. Juli 2026 stabil verfügbar und nativ in Go implementiert.
• Microsoft beschreibt 7.0 als semantisch an TypeScript 6.0 ausgerichtet; TypeScript 7.0 besitzt noch keine neue programmatische API.
• Für Tools mit programmatic API empfiehlt Microsoft den parallelen Einsatz von TypeScript 6, u. a. über @typescript/typescript6.

Phase 0 — unveränderte WASD-Baseline

• Exakten Test-SHA, Lockfile, Node-/pnpm-Version und Runner-Hardware dokumentieren.
• Aktuelle 5.8-Builds, Typechecks, Guards, Unit-/Integrationstests unverändert ausführen.
• Diagnosen, Exitcodes, Artefakt-Hashes, Laufzeit und Peak-RSS erfassen.
• Bestehende rote Gates nicht als Compiler-Regression oder Erfolg umdeuten.

Phase A — TypeScript 6 als Semantikbrücke

• TS6 in isoliertem Workspace testen.
• Breaking-/Default-Änderungen vollständig klassifizieren.
• Root, Server, Shared/Core-Logic und alle realen Clients typechecken und bauen.
• Keine Scheinlösung über neue any, @ts-ignore, skipLibCheck oder ausgeschlossene Workspaces.
• Unterschiede in ESM-/Module-Resolution, Declaration-Emit und Sourcemaps erfassen.

Phase B — TypeScript 7

• TS7 isoliert gegen dieselbe freigegebene TS6-Baseline testen.
• typescript-eslint, Parser/Plugins, tsx, ts-node-dev, Vite, Vitest und Build-Skripte prüfen.
• Alle programmatic-API-Verbraucher inventarisieren; fehlende TS7-API nicht durch Fake-Adapter kaschieren.
• Generierte Artefakte und Modulauflösung vergleichen.

Benchmark

• Mindestens drei kalte und drei warme Läufe je Szenario.
• Root-Build, Server-Typecheck, Server-Build, Shared/Core-Logic und Client-Builds messen.
• Median, Streuung, CPU, RSS, Cache-Zustand, Revision und Kommandos dokumentieren.
• Microsofts Performancewerte nur als Herstellerreferenz, niemals als WASD-Evidence verwenden.

ARE-Invarianten

• 10-Hz-/100-ms-Tick unverändert.
• Kappa1000 unverändert.
• Event-Ordering und CanonicalIntent-Verträge unverändert.
• Replay-/State-/History-Hashes für identische autoritative Inputs unverändert oder vollständig erklärbar.
• Compiler-/Benchmark-Telemetrie bleibt Side-Channel.

Abschluss

BAUEN nur bei vollständiger Kompatibilität und lokal belegtem Nutzen. WEITER BELEGEN bei Tooling-/API-Lücken. VERWERFEN bei unzulässiger Semantik- oder Determinismus-Regression.

[linear]

AIM-94

[github-actions]

The issue outlines a cautious and methodical plan to evaluate and potentially migrate the WASD monorepo's TypeScript compiler from version 5.8 to the newly released TypeScript 7. The process emphasizes determinism, compatibility testing across build tools, dependency stability, and stringent validation gates to ensure a seamless transition. Migration will only proceed after verifying reproducible builds, robust type checking, and no regression in existing functionality, with safeguards in place for rollback and documentation of any encountered blockers.