Revision de Seguridad de Tipos

El Problema

TypeScript promete seguridad de tipos, pero los desarrolladores la socavan rutinariamente. Esparcir any silencia al compilador mientras oculta bugs reales. Verificaciones null faltantes crashean en runtime a pesar del modo estricto. Tipos union demasiado amplios fuerzan type assertions inseguros. El resultado: TypeScript que brinda una falsa sensacion de seguridad — los tipos compilan, pero el codigo sigue lanzando Cannot read property of undefined en produccion.

El Prompt

Revisa el siguiente codigo TypeScript por seguridad de tipos. Actua como un arquitecto TypeScript aplicando mejores practicas de modo estricto.

CONTEXTO: [ej. Frontend React, API Node.js, libreria compartida]
MODO ESTRICTO: [si/no — strict: true en tsconfig?]

CODIGO:
[pegar codigo TypeScript aqui]

Analiza en estas dimensiones de seguridad de tipos:

1. **Auditoria any / unknown**
   - Marcar cada `any` — es realmente inevitable o solo pereza?
   - Deberia reemplazarse con `unknown`, un tipo correcto o un generic?
   - Verificar any implicito por tipos de retorno o parametros faltantes

2. **Seguridad Null**
   - Se verifican valores opcionales antes de acceder (nullish coalescing, optional chaining)?
   - Se usa el operador non-null assertion (!)? Esta justificado?
   - Las firmas de funcion reflejan correctamente cuando null/undefined es posible?

3. **Correctitud de Generics**
   - Se usan generics donde los tipos se repiten con diferentes parametros?
   - Hay constraints genericos (`extends`) para prevenir mal uso?
   - Los generics estan sobre-ingeniados (3+ parametros para casos simples)?

4. **Type Narrowing**
   - Se usan discriminated unions en lugar de type assertions?
   - Los switch/if manejan exhaustivamente todos los miembros de la union?
   - Se usa `as`? Podria un type guard reemplazarlo?

5. **Diseno de Interfaces**
   - Las interfaces son esbeltas (sin propiedades opcionales que siempre estan presentes)?
   - Los tipos compartidos estan centralizados?
   - Los parametros de funcion usan el tipo mas estrecho posible?

6. **Alineacion Runtime-Compile**
   - Los tipos coinciden con las respuestas API reales (validado con zod/io-ts)?
   - Los limites de datos externos estan tipados y validados?

Para cada problema, proporciona:
- **Ubicacion**: Archivo y linea
- **Riesgo**: Que bug podria causar en runtime
- **Severidad**: Inseguro (crash) / Debil (seguridad reducida) / Estilo
- **Fix**: Codigo de reemplazo correctamente tipado

Ejemplo de Salida

## Revision de Seguridad de Tipos: 7 problemas encontrados

### Inseguro: Respuesta API No Validada
Ubicacion: src/api/users.ts:15
Codigo: `const data = await res.json() as User[]`
Riesgo: Si el shape de la API cambia, `as` oculta el mismatch.
Fix:
  import { z } from 'zod';
  const UserSchema = z.object({ id: z.number(), name: z.string() });
  const data = z.array(UserSchema).parse(await res.json());

### Debil: any Implicito en Event Handler
Ubicacion: src/components/Form.tsx:28
Fix: `const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => setState(e.target.value)`

Cuando Usar

Ejecutar al revisar PRs de TypeScript, al migrar desde JavaScript, o al auditar un codebase antes de activar modo estricto. Particularmente valioso para librerias compartidas y capas de limite de API.

Tips Pro

• Incluir tsconfig — las configuraciones de modo estricto cambian fundamentalmente lo que cuenta como problema.
• Enfocarse en limites — la seguridad de tipos importa mas en puntos de entrada: respuestas API, inputs de formulario, params de URL.
• Pedir plan de migracion — si hay muchos any, preguntar “Ordena por riesgo y dame un plan paso a paso.”