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.jsonscripts 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
unknownto spreadinganyacross 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/
AbortSignalwhen 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.