El Módulo 7 terminó con un diagnóstico incómodo: Nómada Tareas tiene seis capas, catorce módulos, dos fuentes de datos y un canal en tiempo real, y la única forma de saber si algo funciona es abrirlo y probarlo a mano. Esta lección ataca la primera mitad del problema —cuando ya sabes que algo falla, ¿cómo averiguas por qué?— y lo hace con un cambio de mentalidad: depurar no es adivinar, es un procedimiento. Vas a aprender el ciclo reproducir → aislar → formular hipótesis → comprobar → corregir → prevenir, la técnica de bisección que reduce a la mitad el terreno sospechoso en cada paso, la consola entera (que es mucho más que console.log), el depurador de las DevTools con sus seis clases de puntos de interrupción, la lectura de una pila de llamadas asíncrona, los source maps, y los paneles de red y almacenamiento. Y terminarás resolviendo tres fallos reales de Nómada Tareas paso a paso, con el método delante.

1. Por qué depurar por intuición no escala
2. El método: seis pasos
3. Bisección: partir el problema por la mitad
4. La consola más allá de console.log
5. El truco de las llaves: console.log({variable})
6. La sentencia debugger y el primer punto de interrupción
7. Los seis tipos de punto de interrupción
8. Ejecutar paso a paso: step over, into y out
9. Los paneles Scope, Watch y Call Stack
10. Leer un stack trace y «Pause on exceptions»
11. Depurar código asíncrono
12. Source maps: por qué producción es ilegible sin ellos
13. Depurar la red: el panel Network
14. Depurar el almacenamiento: el panel Application
15. Depurar en un móvil real
16. Caso 1: la tarea que no cambia de estado
17. Caso 2: el filtro que pierde tareas al recargar
18. Caso 3: el contador de horas descuadrado
19. El bug que no se reproduce
20. Errores Comunes y Consejos
21. Ejercicios
22. Conclusión

La forma en que casi todo el mundo empieza a depurar es esta: leer el código donde cree que está el fallo, ver algo raro, cambiarlo, recargar, mirar si sigue fallando. Repetir. A esto se le llama depuración por cambio aleatorio, y tiene tres problemas graves:

• No converge. Cada cambio modifica el sistema, así que el fallo puede desaparecer por una razón distinta de la que creías, y reaparecer una semana después.
• Introduce fallos nuevos. Un if añadido "por si acaso" que tapa el síntoma deja el sistema con dos problemas en lugar de uno.
• No enseña nada. Cuando el fallo se va, no sabes por qué se fue, y por tanto no puedes evitar el siguiente de la misma familia.

La alternativa es tratar el fallo como lo que es: una diferencia entre lo que el programa hace y lo que crees que hace. Depurar es localizar el punto exacto donde tu modelo mental y la realidad se separan. Y para eso existe un procedimiento.

Una idea que conviene interiorizar desde ya: el 90 % del tiempo de depuración se gasta en localizar el fallo, no en arreglarlo. La corrección suele ser una línea. Por eso todo el método está orientado a localizar rápido, no a escribir rápido.

Los seis pasos, con lo que significa cada uno en la práctica:

El paso 6 es el que casi todo el mundo se salta, y es el que convierte una tarde perdida en un activo permanente. Todavía no sabes escribir esas pruebas —eso llega en Pruebas Unitarias con Jest—, pero en esta lección ya vas a dejar escrita la comprobación que debería existir para cada fallo. Cuando llegues a 08-03 tendrás tres pruebas esperándote.

Una regla de oro del paso 3: una hipótesis que no se puede demostrar falsa no es una hipótesis. «Creo que hay algo raro en el filtro» no sirve. «Creo que estado.filtros.responsable vale 'Iván' cuando debería valer null» sí sirve, porque un solo vistazo la resuelve.

Cuando el fallo está en algún punto de un recorrido largo —el clic entra por controlador.js, pasa por tablero.js, vuelve por tablero-vista.js y termina en repositorio-local.js—, buscar leyendo es lento. La técnica correcta es la bisección: elegir un punto intermedio del recorrido, comprobar si allí los datos ya están mal, y descartar la mitad correspondiente.

Si el dato ya está mal en el punto medio (C), el fallo está entre A y C. Si está bien, está entre C y E. Cada comprobación divide el terreno entre dos. Con cuatro comprobaciones cubres un recorrido de dieciséis pasos.

La bisección se aplica a tres dimensiones distintas, y conviene conocer las tres:

• En el flujo de datos, como acabas de ver: comprobar en puntos intermedios del camino.
• En el tiempo, con git bisect: si la aplicación funcionaba hace treinta commits y ahora no, Git puede buscar en binario el commit culpable en cinco pasos.

• En el código, comentando la mitad: si desactivas conectarFormulario y el fallo desaparece, ya sabes de qué lado mirar. Es la versión más tosca, pero en una interfaz con muchos oyentes es sorprendentemente eficaz.

console.log es una herramienta legítima —quien diga que un profesional nunca la usa, miente—, pero el objeto console tiene una docena de métodos que resuelven mejor problemas concretos. Estos son los que se usan de verdad:

Cuatro de ellos merecen un ejemplo completo, porque cambian de verdad la forma de trabajar.

console.table es la diferencia entre entender un array de seis objetos de un vistazo y no entenderlo. Acepta un segundo argumento con las columnas que quieres:

Las columnas de la tabla de DevTools se ordenan al pulsar en la cabecera. Ordenar por estado y contar es más rápido que cualquier filter escrito a mano.

console.count responde a la pregunta más frecuente de una interfaz: ¿por qué esto se ejecuta tres veces?

Ese resultado ya es un diagnóstico: hay tres oyentes distintos reaccionando al mismo evento, o el evento burbujea y se maneja dos veces. Sin count, ese fallo se manifiesta solo como "va un poco lento".

console.assert es una afirmación que solo habla cuando se incumple. Es perfecta para vigilar invariantes conocidos, como los números canónicos del backlog:

console.group convierte un vertedero de líneas en un árbol plegable:

Con console.groupCollapsed() el grupo aparece ya plegado, que es lo que quieres cuando registras algo que ocurre muchas veces.

Este pequeño truco ahorra más tiempo del que parece. Compara:

Al envolver las variables en llaves usas la abreviatura de propiedades de ES6 (04-01): { responsable } es { responsable: responsable }. El resultado es un objeto donde cada valor viene etiquetado con el nombre de su variable, y además se muestra plegable e inspeccionable en la consola. Adóptalo como norma: no cuesta nada y elimina la clase entera de errores de "estoy leyendo el log de otra variable".

Dos complementos del mismo estilo:

copy() no es JavaScript estándar: es una de las funciones de utilidad de la consola de DevTools, junto con $0 (el último elemento seleccionado en el inspector), $_ (el último resultado) y $$('selector') (un querySelectorAll que devuelve array de verdad). Solo funcionan escritas a mano en la consola, nunca en tu código.

console.log te dice el valor de lo que se te ocurrió imprimir. El depurador te deja mirarlo todo, en el momento exacto, y además seguir avanzando. La diferencia de potencia es enorme.

La forma más rápida de entrar en el depurador es la palabra clave debugger:

Con las DevTools abiertas, la ejecución se congela en esa línea y puedes inspeccionar id, nuevo, this y todo lo demás. Con las DevTools cerradas, la sentencia no hace nada.

debugger tiene una ventaja (es una línea, funciona siempre, sobrevive a un cambio de fichero) y un peligro serio: si se cuela en producción, congela la aplicación a cualquiera que tenga las herramientas abiertas. En la lección siguiente configurarás una regla de ESLint (no-debugger) que impide exactamente eso.

Lo habitual, sin embargo, es no tocar el código: en el panel Sources (Chrome/Edge) o Depurador (Firefox), abres el fichero y pulsas en el número de línea. Aparece un marcador azul: ese es un punto de interrupción normal.

Aquí es donde el depurador deja de ser "un console.log más elegante" y se convierte en otra cosa. Estos son los seis tipos y cuándo usar cada uno:

El condicional es el que más tiempo ahorra en este proyecto. La función pintarTarjeta se ejecuta seis veces por render; parar en las seis es inútil. Con la condición tarea.id === 3 paras solo en la que te interesa:

La condición es una expresión JavaScript normal evaluada en el ámbito de esa línea. Truco poco conocido: si escribes console.count('paso') como condición, nunca para (porque devuelve undefined, que es falso) pero sí ejecuta el contador. Eso es exactamente lo que hace un logpoint, que es la versión oficial de la idea.

El logpoint merece un párrafo propio porque sustituye al 80 % de los console.log que la gente escribe:

Ventajas frente a escribir el console.log en el fichero: no modificas el código, no hay que recargar, no hay riesgo de olvidarlo en un commit, y funciona igual sobre código de terceros o minificado. Cuando termines, borras el punto y no queda rastro.

Los puntos por evento resuelven la pregunta "¿qué código se ejecuta cuando pulso este botón?" en una aplicación que no conoces. Activas Mouse → click, pulsas el botón, y el depurador te deja dentro del manejador, con la pila de llamadas completa. En Nómada Tareas eso te llevaría directamente al oyente delegado de js/vista/controlador.js, con evento.target ya disponible.

Los puntos por petición (XHR/fetch Breakpoints) paran justo antes de que salga una petición cuya URL contenga el texto que indiques —por ejemplo tareas—. Sirven para inspeccionar el body que estás a punto de enviar antes de que el servidor lo rechace, y para descubrir quién dispara una petición inesperada: la pila de llamadas te lo dice.

Los puntos por cambio del DOM son la solución al clásico "esta clase se quita sola". En el inspector, clic derecho sobre el nodo → Break on → attribute modifications, y el depurador para en la línea de JavaScript que modifica ese atributo. Hay tres variantes:

Una vez detenido, controlas la ejecución con cuatro botones. Entenderlos bien es lo que separa usar el depurador de sufrirlo:

La regla práctica es sencilla:

• Usa step over por defecto. Vas leyendo el flujo de la función actual sin perderte en las llamadas.
• Usa step into solo cuando sospeches de la función a la que estás llamando.
• Usa step out en cuanto te des cuenta de que has entrado donde no querías (típicamente, dentro de una función de librería).

Con reconciliar, pintarTarjeta y map por medio, es fácil acabar veinte fotogramas dentro de código ajeno. Para evitarlo existe Ignore List (antes blackboxing): marcas un fichero o un patrón como ignorado y el depurador nunca entra en él ni lo muestra en la pila. Marca ahí tus dependencias y la pila se vuelve legible al instante.

Cuando la ejecución está detenida, la mitad derecha del panel es donde ocurre la depuración de verdad.

Scope muestra las variables agrupadas por ámbito, y es la comprobación empírica de todo lo que estudiaste en 03-04 y 03-05:

Ese bloque Closure es literalmente el entorno capturado del que hablaba 03-04, listado con nombre y contenido. Si alguna vez dudaste de que los closures existen físicamente, aquí están.

Watch es una lista de expresiones que se reevalúan en cada paso. No estás limitado a variables: puedes vigilar cálculos completos.

Ver horasAbiertas cambiar de 45 a 39 en el paso exacto en que ocurre es una información imposible de obtener con logs sueltos.

Call Stack es la pila de llamadas: quién llamó a quién hasta llegar aquí. Se lee de arriba abajo, del más reciente al más antiguo:

Pulsando en cualquier fotograma te trasladas a él con su Scope correspondiente, sin perder la detención. Es la manera de responder "¿con qué argumentos me han llamado?" cuando el problema no está aquí sino en quien llamó.

Y una función poco conocida y muy útil: Restart frame. Clic derecho sobre un fotograma → Restart frame vuelve a ejecutar esa función desde el principio, con los mismos argumentos. Si has pasado de largo la línea interesante con un F10 de más, no hace falta recargar la página y repetir los diez clics que te trajeron hasta aquí: reinicias el fotograma y vuelves a pasar. (Con una advertencia: los efectos secundarios que ya ocurrieron —una petición enviada, un setItem hecho— no se deshacen.)

Un error sin capturar imprime algo así:

Se lee así:

• Primera línea: tipo de error y mensaje. Aquí ya sabes que es una regla R6 incumplida.
• Línea 1 de la pila: dónde se lanzó. tarea.js:71:13 = fichero, línea 71, columna 13.
• Líneas siguientes: la cadena de llamadas hacia atrás. La última suele ser el punto de entrada real.
• HTMLUListElement.<anonymous>: una función anónima adjunta como oyente a un <ul>. Es el oyente delegado de 06-04.

El error más común al leer una pila es fijarse solo en la primera línea. El lugar donde se lanza casi nunca es el lugar donde está el fallo. Aquí el error se lanza en Tarea, pero la causa está en controlador.js:38: alguien intentó reabrir una tarea ya terminada porque el botón no estaba desactivado. La primera línea dice qué pasó; las de abajo dicen por qué.

«Pause on exceptions» (el icono ⏸ con el rombo, en el panel Sources) hace que el depurador se detenga en el instante en que se lanza el error, con todo el contexto vivo. Tiene dos niveles:

La segunda es la joya escondida. Nómada Tareas captura errores en varios sitios (el try/catch del formulario, el catch del repositorio que descarta datos corruptos, el conReintentos). Si un fallo se está tragando en uno de esos catch, activar «pause on caught exceptions» te lleva directamente al throw original. Eso sí: actívala solo mientras investigas, porque también parará en errores capturados que son perfectamente normales.

Aquí es donde el depurador clásico solía rendirse. Cuando un setTimeout, una promesa o un await retoman la ejecución, la pila de llamadas original ya se ha vaciado —es exactamente el mecanismo del bucle de eventos que estudiaste en 05-07—. Sin ayuda, la pila mostraría solo esto:

Inútil: no dice quién pidió esa petición. Por eso los navegadores modernos mantienen pilas asíncronas, que cosen el fotograma actual con el que programó la tarea:

Ahora sí: la petición nació de un clic en el controlador. Cuatro consejos concretos para depurar asincronía en este proyecto:

• Pon el punto de interrupción después del await, no antes. Antes solo ves la promesa pendiente; después ves el valor resuelto.
• Usa un punto condicional en conReintentos con la condición intento > 1: paras solo cuando algo ya ha fallado una vez.
• En el panel Network activa la columna Initiator. Igual que la pila asíncrona, te dice qué línea disparó cada petición.
• Cuidado con las carreras que el propio depurador provoca. Al detener la ejecución cinco segundos, un timeout de 8 s puede vencer. Si sospechas de una condición de carrera, prefiere logpoints a detenciones.

Un patrón muy útil para asincronía es medir dónde se va el tiempo sin frenar nada:

El finally garantiza que el timeEnd se ejecute aunque la petición falle; si no, un error dejaría el temporizador abierto y el siguiente console.time avisaría de una etiqueta duplicada.

El código que se despliega no es el que escribes. Un empaquetador lo une, lo minifica y renombra las variables, así que un error en producción se ve así:

t, línea 1, columna 24817. Sin información adicional, esa pista no vale nada.

Un source map es un fichero (app.4f3a1b.js.map) que contiene el diccionario de traducción entre el código generado y el original: qué posición del fichero minificado corresponde a qué fichero, línea, columna y nombre de variable del código fuente. El navegador lo carga si encuentra el comentario final:

Y entonces el mismo error se muestra así:

Tres decisiones prácticas sobre source maps:

Ten presente que un source map reconstruye tu código fuente. Publicarlo equivale a publicar el código sin minificar. No es un fallo de seguridad por sí mismo —la seguridad nunca debe depender de ofuscación—, pero es una decisión consciente que hay que tomar.

En DevTools, si un source map no carga, la pestaña Sources muestra un aviso en la consola (DevTools failed to load source map). Las tres causas habituales: el .map no se desplegó, la ruta del comentario final es incorrecta, o el servidor lo devuelve con un 404 tras una configuración de caché agresiva.

El Módulo 7 llenó Nómada Tareas de peticiones. Cuando una falla, el panel Network responde en segundos lo que el código no puede contarte:

• Filtra por Fetch/XHR para ver solo tus peticiones, sin imágenes ni CSS.
• La columna Status distingue lo que fetch no distingue: un 200 con cuerpo vacío, un 404, un 500, o (failed) para un fallo de transporte.
• La pestaña Headers muestra lo que enviaste y lo que llegó, incluida la cabecera Content-Type que hace fallar el pedirJson cuando llega HTML.
• La pestaña Payload enseña el cuerpo del POST tal cual salió: aquí se descubren los undefined que JSON.stringify elimina en silencio.
• La pestaña Timing desglosa el tiempo: Stalled, Waiting (TTFB), Content Download. Si el TTFB es 4 s, no es culpa de tu JavaScript.

Tres funciones del panel que conviene conocer:

Copy as fetch. Clic derecho sobre una petición → Copy → Copy as fetch. Pega el resultado en la consola y reproduces la petición exacta, con sus cabeceras, tantas veces como quieras. Es la mejor forma de aislar si el problema está en el servidor o en tu código: si la petición copiada funciona en la consola y no en la aplicación, el fallo es tuyo.

Throttling. El selector de red (No throttling / Slow 4G / Offline) simula conexiones lentas. Es imprescindible para probar dos cosas que escribiste en el Módulo 7 y que en local nunca se ven: los estados de "cargando" de 07-03 y el funcionamiento sin conexión del service worker de 07-05. En una red local de 1 ms, el estado de carga aparece y desaparece antes de renderizarse.

Preserve log. Marca esta casilla si la petición que investigas provoca una navegación o una recarga; sin ella, el registro se borra y la petición culpable desaparece.

Para todo lo de 07-01 y 07-05, el panel Application es la ventana directa al estado persistido:

El valor de localStorage se puede editar en el sitio: haces doble clic en el valor, cambias el JSON y recargas. Es la forma más rápida de comprobar cómo reacciona tu código a datos corruptos, a un formato de versión antigua, o a un tablero vacío… sin escribir una línea. Y Clear site data te devuelve a un arranque limpio, que es el estado en el que debes reproducir cualquier fallo antes de darlo por bueno.

El emulador de dispositivo de las DevTools cambia el tamaño y simula el táctil, pero no es Safari en un iPhone ni Chrome en un Android de gama baja. Los fallos de verdad —un 100vh que se come la barra de direcciones, un evento táctil que no burbujea, una API que no existe en esa versión— solo se ven en el aparato.

La inspección remota conecta las DevTools de tu ordenador a la página que se ejecuta en el teléfono:

• Android + Chrome: activa las Opciones de desarrollador y la Depuración por USB en el teléfono, conéctalo por cable y abre chrome://inspect#devices en el ordenador. La pestaña del teléfono aparece en la lista; pulsas inspect y tienes las DevTools completas, incluidos el depurador y el panel Network.
• iOS + Safari: activa Ajustes → Safari → Avanzado → Inspector web en el iPhone y Safari → Ajustes → Avanzado → Mostrar menú Desarrollo en el Mac; el dispositivo aparece bajo el menú Desarrollo.

Y para probar Nómada Tareas en el móvil hace falta que el teléfono llegue a tu servidor de desarrollo. Dos vías:

La opción B importa por un detalle de 07-05: los service workers exigen HTTPS salvo en localhost. Y localhost en el móvil es el propio móvil, no tu portátil. Sin túnel HTTPS no podrás depurar la PWA en un dispositivo real.

Aplicamos el método completo a un fallo real.

El parte de incidencia. Marta escribe: «He creado la tarea Revisar extintores con el formulario y luego he pulsado Empezar y no hace nada. Las demás sí funcionan.»

Paso 1 · Reproducir. Primero, un arranque limpio (Clear site data). Después, la secuencia exacta:

1. Abrir la aplicación con el backlog canónico (6 tareas).
2. Pulsar Empezar en la tarea 2 → funciona.
3. Crear una tarea nueva con el formulario.
4. Pulsar Empezar en la tarea nueva → no pasa nada.

Reproducido, y con una pista de oro: falla solo en las tareas creadas durante la sesión. Las del backlog van bien.

Paso 2 · Aislar. ¿Es del formulario o de la creación? Probamos a crear una tarea desde la consola, sin tocar el formulario:

El formulario queda descartado: el problema está en las tareas que vienen de crearTarea, es decir, de la API.

Paso 3 · Hipótesis. El flujo del clic es: controlador lee li.dataset.id → llama a tablero.cambiarEstado(id, ...) → buscarPorId(id) compara con t.id === id. Y dataset siempre devuelve cadenas. Para las tareas del backlog, id es un número en el modelo; para las de la API… la hipótesis concreta es:

Tarea.desdeJSON está guardando id como cadena para las tareas que llegan del servidor, y buscarPorId usa ===, que no convierte tipos (01-07). Por eso buscarPorId('7') devuelve null y no encuentra la tarea.

Espera: si devolviera null, Tablero.cambiarEstado lanzaría ErrorDeValidacion. ¿Por qué no vemos nada? Porque el controlador captura ese error para mostrarlo, y el catch lo escribe en un contenedor que está oculto. Segunda parte de la hipótesis: el error se lanza y se traga.

Paso 4 · Comprobar. Dos comprobaciones, ninguna modifica el código:

• Activar Pause on caught exceptions, pulsar el botón. El depurador se detiene… en el throw de Tablero.cambiarEstado. Hipótesis B confirmada.
• Poner un logpoint en la línea de buscarPorId con {id, tipoId: typeof id, ids: this.tareas.map((t) => [t.id, typeof t.id])}:

Confirmadísimo. El id del modelo es una cadena '7', el dataset también devuelve cadena, pero el controlador hacía Number(li.dataset.id) antes de llamar, así que compara 7 === '7' → false.

Paso 5 · Corregir la causa. Tres arreglos posibles, y solo uno es el correcto:

Y de paso, el catch que se tragaba el error deja de ser silencioso: si el contenedor de errores está oculto, se muestra. Un error que nadie ve es un error que existe dos veces.

Paso 6 · Prevenir. La prueba que debería existir, y que escribirás en 08-03:

El parte. Iván: «He filtrado por mi nombre para ver mis tareas, he cerrado el portátil, y al volver solo quedaban tres tareas en todo el tablero. Las de Marta y Lucía han desaparecido.»

Paso 1 · Reproducir. Con el backlog canónico: filtrar por Iván (quedan 3 visibles), recargar (F5) → el tablero tiene 3 tareas y el resumen dice 25 h. Reproducible al 100 %. Y es un fallo de pérdida de datos, la peor categoría: prioridad máxima.

Paso 2 · Aislar. La pregunta clave: ¿se guardó mal, o se lee mal? El panel Application la responde sin tocar el código. Filtramos por Iván (sin recargar) y miramos Local Storage → nomada:tablero:v1:

Sólo tres tareas ya escritas. El fallo está en la escritura, no en la lectura. Acabamos de descartar la mitad del recorrido con un vistazo.

Paso 3 · Hipótesis. ¿Quién llama a guardar y con qué? Aquí la herramienta es console.trace() colocado como logpoint en RepositorioLocal.guardar, con la expresión:

La hipótesis se escribe sola:

app.js está guardando lo que la vista muestra en lugar del tablero completo. Al filtrar, la vista tiene 3 tareas y eso es lo que se persiste, machacando las otras 3.

Paso 4 · Comprobar. Abrimos app.js:78:

Alguien, al añadir el enrutador de 07-06, quiso "guardar el estado al filtrar" y construyó un tablero nuevo con las tareas visibles. Hipótesis confirmada con la línea delante.

Paso 5 · Corregir. La causa real es conceptual, y merece enunciarse: se ha persistido un valor derivado de la vista como si fuera estado del modelo. El filtro es presentación (06-06) y su sitio es la URL (07-06); el tablero es el modelo y su sitio es el almacén.

Paso 6 · Prevenir. Dos comprobaciones para 08-05, donde se prueban modelo y datos juntos:

El parte. Lucía: «El resumen dice 48 h abiertas nada más abrir. Deberían ser 45; la tarea del inventario está hecha desde hace una semana.»

Este caso es distinto de los anteriores: no hay que reproducir nada, falla siempre. Y hay algo mucho mejor que un parte de incidencia: hay un oráculo. El backlog canónico tiene números conocidos —48 h totales, 45 h abiertas, esfuerzo 124— y el programa contradice uno de ellos.

Paso 2 · Aislar. Un solo comando en la consola separa el modelo de la vista:

El modelo ya devuelve 48. La vista está inocente: solo pinta lo que le dan. Y hay un detalle revelador: abiertas: 5 es correcto (5 tareas abiertas de 6), pero horasAbiertas coincide exactamente con horasTotales. Eso no es un error de cálculo, es un error de selección: se están sumando las seis.

Paso 3 · Hipótesis.

horasAbiertas está reduciendo sobre todas las tareas en lugar de sobre las abiertas.

Paso 4 · Comprobar. Ponemos el punto de interrupción en el getter y usamos Watch con dos expresiones a la vez:

La expresión correcta da 45. Miramos el código:

Un copiar y pegar. El fallo clásico: dos líneas casi idénticas, una de ellas sin adaptar. Sospecha siempre de las líneas gemelas.

Comprobación adicional con git, para saber cuándo entró y descartar que hubiera más daños en el mismo cambio:

Paso 5 · Corregir.

Paso 6 · Prevenir. Este caso es el argumento perfecto para el módulo entero. Un fallo así:

• No lanza ningún error.
• No rompe ninguna pantalla.
• Es invisible salvo que alguien conozca el número correcto.
• Y sale de una capa —el modelo— que se puede comprobar sin navegador, sin DOM y sin red, con una función que recibe datos y devuelve datos.

Mientras tanto, una red de seguridad de treinta segundos que puedes dejar puesta ya, activada por una bandera:

Queda la categoría más difícil: «a veces, al salir del ascensor, se me duplican las tareas». No hay pasos, no hay pantalla, no hay pila. Cuatro herramientas, en orden de esfuerzo creciente:

1 · Registro estructurado. Sustituye los console.log sueltos por un registrador único que emita objetos con contexto. Los objetos se pueden filtrar, contar y enviar; el texto libre no.

El buffer circular es la clave: cuando el fallo raro por fin ocurre, tienes las 200 líneas anteriores, no solo el momento del desastre. Ese es exactamente el contexto que falta en los incidentes que no se reproducen.

2 · Banderas de diagnóstico. No puedes pedirle a Marta que abra las DevTools. Pero sí puedes darle un interruptor:

Y un botón «Copiar informe de diagnóstico» que ponga en el portapapeles el historial, el resumen del tablero, la versión de la aplicación y el navigator.userAgent. Un informe así convierte «a veces falla» en un caso reproducible.

3 · Reproducir las condiciones, no los pasos. Los fallos intermitentes casi siempre vienen de cuatro sitios: la red (usa Slow 4G y Offline), el tiempo (una tarea que vence hoy y no ayer), la concurrencia (dos pestañas abiertas con el evento storage de 07-01) y el estado previo (un localStorage de una versión antigua). Provoca esas condiciones deliberadamente y muchos "irreproducibles" se vuelven fiables.

4 · Monitorización de errores. Para lo que ocurre en el ordenador de otra persona, la solución de la industria es un servicio de monitorización (Sentry, Rollbar, Bugsnag y similares). El mecanismo esencial cabe en diez líneas, y entenderlo importa más que el proveedor concreto:

Lo que un servicio añade sobre esto: agrupa incidencias idénticas, aplica los source maps del apartado 12 para mostrar tu código original, guarda la traza de acciones previas del usuario, y avisa cuando aparece un fallo nuevo tras un despliegue. Dos advertencias imprescindibles: no envíes datos personales en el contexto (ni títulos de tarea, si pueden contener información sensible), y respeta la normativa de protección de datos aplicable.

• Cambiar el código antes de entender el fallo. Si no puedes explicar por qué falla, tu arreglo es una apuesta. Primero la hipótesis comprobada, después la edición.
• Depurar en un estado sucio. Un localStorage con datos de tres experimentos anteriores produce fallos fantasma. Reproduce siempre desde Clear site data, y en una ventana de incógnito si sospechas de una extensión.
• Confundir dónde se lanza el error con dónde está el fallo. Lee la pila entera, de abajo arriba. El culpable suele estar dos fotogramas más abajo que el throw.
• Olvidar que dataset devuelve cadenas. Es la fuente del caso 1 y de la mitad de los fallos de identidad en aplicaciones con DOM. Normaliza los tipos en la frontera, siempre.
• console.log de un objeto y creer que ves su valor de entonces. La consola muestra objetos en vivo: al desplegarlo puedes estar viendo su estado actual, no el del momento del log. Si necesitas la foto, registra structuredClone(obj) (04-08) o JSON.stringify(obj).
• Poner el punto de interrupción antes del await. Ponlo después: antes solo verás una promesa pendiente.
• Dejar debugger o logs de depuración en un commit. Se resuelve solo en la lección siguiente, con no-debugger y no-console en ESLint más un hook de Git.
• Tapar errores con try { … } catch {} vacío. Un catch vacío convierte un fallo ruidoso en uno silencioso, que es infinitamente peor. Si de verdad quieres ignorar algo, escribe por qué en un comentario.
• Consejo: escribe la hipótesis en una nota antes de comprobarla. Obliga a concretar y evita la deriva de ir mirando cosas al azar. Al terminar tendrás además el material del post mortem.
• Consejo: si llevas más de una hora sin avanzar, explícaselo a alguien. El rubber duck debugging funciona porque verbalizar obliga a hacer explícitas las suposiciones. La mitad de las veces la solución aparece a mitad de la explicación.
• Consejo: Ctrl/Cmd + P en el panel Sources abre cualquier fichero por nombre, y Ctrl/Cmd + Mayús + P es la paleta de comandos de las DevTools. Con esos dos atajos dejarás de buscar ficheros en el árbol.

Ejercicio 1 — Diagnóstico con el método. Un compañero reporta: «Al pulsar dos veces rápido sobre Empezar en la tarea 1, la tarjeta se queda en en-curso pero el resumen dice que hay 4 tareas abiertas en lugar de 5, y en la consola aparece un ErrorDeValidacion: Transición no permitida: "en-curso" → "en-curso"». Redacta el diagnóstico completo siguiendo los seis pasos: pasos de reproducción, caso mínimo aislado, hipótesis falsable, qué instrumento de DevTools usarías para comprobarla (indica el tipo exacto de punto de interrupción y su condición), en qué capa corregirías, y qué prueba escribirías para prevenirlo.

Ejercicio 2 — Un módulo de registro con niveles y buffer. Escribe js/util/registro.js completo con: cuatro niveles (debug, info, warn, error), un umbral configurable por bandera (?diag=1 en la URL, persistido en localStorage), un identificador de sesión estable durante toda la visita, un buffer circular de las últimas 200 líneas, y volcarInforme() que devuelva un objeto con el historial, el resumen del tablero, la versión de la aplicación y el userAgent, listo para copiar al portapapeles. Debe salir por console.debug/info/warn/error según el nivel para que el filtro de la consola funcione.

Ejercicio 3 — Instrumentar el flujo de un clic. Sin modificar el código de la aplicación, describe la configuración de DevTools que te permitiría seguir el recorrido completo de un clic en Empezar de la tarea 3 —desde el oyente delegado hasta la escritura en localStorage— registrando en cada punto los valores relevantes y sin detener nunca la ejecución. Indica el fichero, la línea aproximada y la expresión exacta de cada logpoint, y qué esperarías ver en la consola si todo funciona bien.

Solución 1

Solución 2

Solución 3

Has cambiado la forma de enfrentarte a un fallo. Ya no se trata de mirar el código hasta que algo parezca sospechoso, sino de recorrer seis pasos: reproducir de forma fiable, aislar hasta el caso mínimo, formular una hipótesis falsable, comprobarla con un instrumento, corregir la causa en la capa correcta y prevenir con una prueba. Y sabes que cuando el terreno es grande, la bisección —en el flujo de datos, en la historia con git bisect o en el propio código— convierte una búsqueda lineal en una logarítmica.

Conoces la consola entera y no solo console.log: table para ver seis tareas de un vistazo, count para descubrir los renders duplicados, assert para vigilar invariantes como las 45 h abiertas, group para no ahogarte en líneas, trace para saber quién llamó, y el truco de las llaves console.log({variable}) que etiqueta cada valor con su nombre. Y dominas el depurador de verdad: la sentencia debugger y sus riesgos, los seis tipos de punto de interrupción —normal, condicional, de registro, por evento, por petición y por cambio del DOM—, la navegación con step over, into y out, los paneles Scope (donde los closures de 03-04 son por fin visibles), Watch con expresiones calculadas y Call Stack con su Restart frame. Sabes leer un stack trace de abajo arriba, activar «Pause on caught exceptions» para cazar los fallos que se tragan los catch, seguir una pila asíncrona cosida a través de los await de 05-07, y por qué sin source maps un error de producción no dice nada. Y tienes el panel Network con su Copy as fetch y su throttling, el panel Application para el localStorage y el service worker del Módulo 7, y la inspección remota para el móvil de verdad.

Sobre todo, has resuelto tres fallos reales con el método delante: un id que llegaba como cadena desde la API y hacía fallar el === de 01-07 —corregido en la frontera de datos, no en el modelo ni en la vista—; un filtro que persistía las tareas visibles en lugar del tablero completo, confundiendo un valor derivado de la vista con el estado del modelo; y un horasAbiertas que sumaba sobre todas las tareas y devolvía 48 en lugar de 45, un fallo silencioso que ninguna pantalla delataba. Y has visto qué hacer cuando el fallo no se reproduce: registro estructurado con buffer circular, banderas de diagnóstico activables por URL, reproducción de condiciones en lugar de pasos, y una nota sobre los servicios de monitorización que aplican tus source maps a los errores de otras personas.

Los tres casos comparten un final incómodo: los tres se han cerrado con una prueba «pendiente de escribir». Y los tres, además, tenían una advertencia previa que nadie vio. El id mezclando tipos, el catch vacío que se tragaba el error, las dos líneas gemelas donde una no se adaptó: son exactamente el tipo de problema que una máquina puede señalar antes de ejecutar nada, leyendo el código. Antes de automatizar las comprobaciones de comportamiento conviene automatizar las de forma, porque son más baratas y atrapan una familia entera de fallos por sí solas. Eso es lo siguiente: Calidad de Código: ESLint, Prettier y Convenciones, donde configurarás un analizador estático sobre Nómada Tareas, arreglarás los avisos que aparezcan —incluido, con toda seguridad, algún debugger olvidado de esta lección— y pondrás un guardián en Git para que nada de esto vuelva a llegar al repositorio.