TypeScript type coverage above 85%

High any density in core business logic means TypeScript's safety guarantees are opt-out rather than opt-in across the most critical code paths. ISO 25010:2011 §6.5.5 treats this as a reliability defect: when an API response shape changes, a database column is renamed, or a third-party SDK updates its return type, any-saturated code compiles without complaint and fails silently or noisily at runtime. A practical threshold is fewer than 15% of typed positions using any — above that, the type checker is too porous to catch refactoring regressions.

Replace any with unknown for values with genuinely unknown types, then narrow at the usage site. Work through the highest-traffic files first — src/lib/, src/services/, and API handlers typically have the most impact.

// Bad: loses all type information
function processResponse(data: any) {
  return data.result.items;
}

// Good: preserves type safety with runtime validation
function processResponse(data: unknown): Item[] {
  if (!isApiResponse(data)) throw new Error('Unexpected API response shape');
  return data.result.items;
}

To measure your starting point: npx type-coverage --detail reports the percentage of fully-typed nodes across the project.