--- name: typescript-coding-engine description: > Plugin-first TypeScript doctrine and runtime engine for strictness posture, type diagnosis, advanced typing, runtime validation, architecture decisions, testing/toolchain governance, and Rust↔TypeScript/Tauri/WASM interop. 适用于 TypeScript 类型系统、运行时验证、架构决策、测试治理与跨语言互操作场景。 metadata: model: opus version: "0.3.0" --- # TypeScript Coding Engine > Type safety is architecture, not decoration. > 类型安全不是装饰，而是架构本身。 ## Purpose This is the canonical runtime shell and doctrine control center for `typescript-coding-engine`. It is not just a first-wave shell description anymore. It now serves as the main control surface for routing TypeScript-heavy work into a stronger doctrine backbone. Use this engine when the task is primarily about: - strictness posture and compiler-guided design - type error diagnosis and recovery - advanced typing, inference, narrowing, and branding - runtime validation and trust boundaries - toolchain, quality gates, testing, and migration discipline - Rust↔TypeScript, Tauri, or WASM boundary design --- ## Root Navigation ### Root doctrine entrypoints - `references/INDEX.md` - `references/source-reservoir-map.md` ### Category doctrine lanes - `references/foundations/INDEX.md` - `references/advanced/INDEX.md` - `references/clean-code/INDEX.md` - `references/architecture/INDEX.md` - `references/interop/INDEX.md` ### Bridge skills - `skills/core-types/SKILL.md` - `skills/generics-and-inference/SKILL.md` - `skills/type-level-programming/SKILL.md` - `skills/runtime-validation/SKILL.md` - `skills/tooling-and-quality/SKILL.md` - `skills/testing/SKILL.md` - `skills/architecture/SKILL.md` - `skills/interop/SKILL.md` ### Runtime surfaces - `commands/prime/ts-foundations.md` - `commands/prime/ts-tooling.md` - `commands/check/types.md` - `commands/check/toolchain.md` - `commands/route/choose-runtime-validation.md` - `commands/route/choose-state-pattern.md` ### Bounded specialist agents - `agents/type-diagnostician.md` - `agents/ts-architecture-reviewer.md` - `agents/ts-tooling-auditor.md` - `agents/interop-reviewer.md` --- ## Doctrine Spine ### Foundations lane - `references/foundations/strict-type-system-posture.md` - `references/foundations/typescript-type-error-diagnosis-and-recovery.md` ### Advanced lane - `references/advanced/type-level-programming-patterns.md` - `references/advanced/typescript-narrowing-branding-and-inference-cookbook.md` ### Clean-code lane - `references/clean-code/quality-gates-governance.md` - `references/clean-code/typescript-runtime-validation-decision-matrix.md` - `references/clean-code/toolchain-posture.md` - `references/clean-code/typescript-testing-strategy-and-type-boundaries.md` - `references/clean-code/typescript-anti-patterns-and-migration-ladders.md` - `references/clean-code/runtime-boundaries.md` ### Architecture lane - `references/architecture/typescript-architecture-decision-trees.md` ### Interop lane - `references/interop/rust-typescript-contract-boundaries.md` - `references/interop/tauri-frontend-rust-bridge.md` - `references/interop/boundary-activation-model.md` --- ## Operating Rule When the task is TypeScript-heavy: 1. start at `references/INDEX.md` 2. classify the dominant pressure before proposing fixes 3. use the smallest relevant doctrine lane first 4. load bridge skills only to shorten routing or focused knowledge loading 5. invoke commands or agents only when explicit runtime leverage is needed 6. open donor reservoirs only after canonical doctrine is insufficient 7. keep TypeScript distinct from generic JavaScript runtime advice The engine exists to make TypeScript reasoning active, structured, and hard to ignore. --- ## Pressure Router Use this fast mapping when deciding where to go next: | Pressure | First Owner | | ---------------------------------------------------------------- | ---------------------------------- | | Baseline strictness, type errors, inference basics | `references/foundations/INDEX.md` | | Narrowing, branding, advanced generics, type-level transforms | `references/advanced/INDEX.md` | | Runtime validation, toolchain, testing, migration, quality gates | `references/clean-code/INDEX.md` | | System shape, module boundaries, state blast radius | `references/architecture/INDEX.md` | | Rust/Tauri/WASM/generated-contract boundaries | `references/interop/INDEX.md` | If two lanes seem relevant, choose the one that owns the earliest or most expensive boundary mistake. --- ## Boundary | Layer | Owner | Role | | ------------------ | -------------------------------------------- | ---------------------------------------------------- | | Canonical doctrine | this engine's references tree | stable TypeScript knowledge center | | Runtime shell | this plugin shell | activation, routing, diagnostics, lifecycle surfaces | | Donor reservoirs | preserved donor families and source archives | upstream pattern supply, not direct runtime UX | The shell must point to doctrine. It must not become a donor mirror or a second doctrine tree. --- ## Current State The TypeScript engine is now in canonical deep fusion. That means: - root references navigation is established - source-governance is established - foundations, advanced, clean-code, architecture, and interop lanes are active - multiple requirement-grade notes have already been upgraded into replacement-grade doctrine roots and support texts It is still not a finished universe. But it is now a real engine, not a placeholder shell. --- ## Conservative Posture This engine still keeps a conservative operational posture: - no destructive automation - no broad type-blocking hooks - no donor repo mirroring - no mandatory MCP dependency - no runtime behavior that replaces compiler, CI, or doctrine judgment The shell should stay clear, bounded, and doctrine-first while deep fusion continues.