Standardize TypeScript tooling across evalops with google/gts + google/wireit

[haasonsaas]

Context

• gts (https://github.com/google/gts, 5.3k★) — zero-config TypeScript style guide + formatter + linter. Google's internal default.
• wireit (https://github.com/google/wireit, 6.4k★) — smarter npm/pnpm task runner with file-hash-based caching and cross-package DAG scheduling.

Why

Evalops has ~12 active TypeScript repos (console, admin, fabric, chat, hopper, explorer, maestro, maestro-internal, cadence, ensemble, conductor, lark, proto, mcp-openapi, shared-memory-mcp, deliberate-reasoning-engine, deep-code-reasoning-mcp, openclaw-safety-harness, diffscope-web-poc, cerebro-frontend). Each almost certainly has drifting ESLint/Prettier configs, divergent tsconfig.json defaults, and bespoke package.json scripts with no caching.

• gts unifies style + lint + format with one dependency. Opinionated, so arguments end.
• wireit caches script outputs by input hash; in a monorepo-adjacent setup (many repos sharing proto types) this saves minutes per CI run and per local npm run build.

Plan

• Pilot gts in one TS repo (suggest explorer — small, active, no heavy custom lint rules). Document the diff.
• If the pilot is net-positive, publish a shared @evalops/ts-config package that re-exports gts presets with evalops-specific overrides
• Separately: pilot wireit in a repo with slow builds (console or maestro). Measure cold vs. warm build times.
• Roll both into .github org templates so new TS repos inherit them

Out of scope

• Migrating to pnpm workspaces / Turborepo / Nx — that's a separate, larger conversation about whether the TS repos belong in a monorepo at all

Non-goals

• Forced migration. Repos that already have working lint/build stacks should migrate only when touched for other reasons.