Thalarch TypeScript

Discover the actual runtime, package manager, compiler, framework, module system, and quality tools. Do not assume Node, React, Next.js, npm, ESM, or strict TypeScript.

Preflight

Inspect:

• package.json scripts and engines;
• lockfile/package manager;
• tsconfig* and module resolution;
• framework/build tool versions;
• lint/format/type/test setup;
• browser vs server vs edge/runtime boundaries.

Use repository scripts instead of inventing equivalent commands.

Type discipline

• Preserve strictness already configured; do not weaken the compiler to make code pass.
• Prefer narrowing from unknown to spreading any across a boundary.
• Model discriminated unions for real variant states.
• Avoid type assertions that merely silence the compiler; prove the invariant or validate the boundary.
• Keep runtime validation separate from compile-time typing.
• Do not generate duplicate DTO/types when an existing schema/source of truth can produce or define them.

Async/runtime behavior

Review:

• promise ownership and missing awaits;
• cancellation/AbortSignal when the stack supports it;
• race conditions from stale async results;
• unhandled rejections;
• browser/server resource lifetime;
• event listener/subscription cleanup;
• concurrency fan-out and rate limits.

Do not introduce a new state-management or async library to solve a local problem without clear evidence it is required.

Frontend/framework overlay

When React/Vue/Svelte/Angular/another framework is present, follow its current project version and existing patterns.

For React-family code, verify hook lifecycles, effect dependencies, stale closures, state ownership, server/client boundaries, key stability, accessibility, and unnecessary rerenders. Do not add useMemo/useCallback everywhere as ritual optimization.

Combine visual work with thalarch-web-design, thalarch-browser-qa, and design review.

Backend/API overlay

For Node/server code, combine with thalarch-api, thalarch-security, and thalarch-data-sql when relevant. Validate input at external boundaries and preserve error/HTTP semantics.

Dependencies

Use the existing package manager and lockfile. Confirm package exports and version-specific APIs before importing them. Avoid installing a package for functionality already covered by the runtime/framework or a small local implementation.

Testing and verification

Use configured tools such as Vitest/Jest/Node test/Playwright/Cypress only when actually present. Typical proof layers are typecheck → focused test → lint → build → browser/runtime evidence as required by the acceptance contract.

A TypeScript compile does not prove browser interaction or server integration.