Depurador Viaje en el Tiempo

El Problema

Los bugs de produccion son fantasmas — cuando los investigas, el estado que los causo ya desaparecio. Tienes logs, tal vez un reporte de crash y un timestamp. Reconstruir que hacia la aplicacion en ese momento exacto a traves de multiples servicios y mutaciones de estado es como examinar una escena del crimen despues de que la limpiaron. La mayoria de los desarrolladores se rinden y esperan a que el bug ocurra de nuevo.

El Prompt

Eres un analista de depuracion temporal. Reconstruye el estado del programa en el momento de la falla usando la evidencia disponible:

TIMESTAMP DE LA FALLA: [ej. 2026-04-10T14:32:17.892Z]
ERROR/SINTOMA: [que salio mal]
EVIDENCIA DISPONIBLE:
- Logs: [pega lineas de log relevantes con timestamps]
- Reporte de error: [crash report, evento Sentry, etc.]
- Cambios recientes: [deploys o cambios de configuracion cercanos al timestamp]
- Accion del usuario: [que estaba haciendo el usuario, si se sabe]

Realiza reconstruccion temporal del estado:
1. **Construccion de Linea de Tiempo**: Construye una linea temporal precisa desde 5 minutos antes hasta el momento de la falla.
2. **Snapshot del Estado**: Reconstruye el estado mas probable de todas las variables, conexiones y recursos en T-0.
3. **Cadena Causal**: Rastrea hacia atras — que evento en T-N desencadeno la cadena que llevo a la falla?
4. **Variables Fantasma**: Que variables o estados NO son visibles en los logs pero debieron existir? Infiere sus valores.
5. **El Punto de Inflexion**: En que momento exacto el sistema paso de saludable a roto? Cual fue el detonante?
6. **Receta de Reproduccion**: Proporciona la secuencia minima de acciones y configuracion para reproducir esta falla.

Ejemplo de Salida

Linea temporal: T-4min: Deploy v2.3.1 → T-2min: TTL del cache expira → T-1min: Primer request usa codigo nuevo con formato de cache viejo → T-0: JSON.parse falla
Estado en T-0: cache contiene formato v2.2 (string), codigo nuevo espera formato v2.3 (objeto)
Cadena causal: Deploy sin flush de cache → entradas viejas sobreviven → conflicto de formato → error de parseo → 500
Variable fantasma: cache.userSession era un string serializado en vez de un objeto — no loggeado pero inferido del TypeError

Cuando Usar

Usa este skill al depurar incidentes de produccion despues del hecho, cuando no puedes reproducir el problema bajo demanda, o al lidiar con fallas intermitentes que dependen de condiciones de timing especificas. Esencial para analisis post-mortem.

Tips Pro

• Correlaciona entre servicios — usa request IDs o trace IDs para unir logs de multiples servicios en una sola linea temporal.
• Revisa lo que NO se loggeo — entradas de log faltantes suelen ser mas reveladoras que las presentes. Un log de “request completado” faltante significa que el proceso fallo a medio camino.
• Mira los exitos cercanos — compara el request fallido con requests exitosos en T-1min y T+1min. El diff revela las condiciones unicas.
• Los timestamps de deploy son criticos — la mayoria de bugs misteriosos en produccion correlacionan con un deploy reciente.