60 min + 10 de entregable. En esta sesión circula el nodo viajero: 10 min por persona para identificar físicamente los buses vistos en simulación.

Paso 0 · Preparación (5 min)

Duplicar el proyecto saboteado. El proyecto escribe registros a SD y permite forzar un reset a media escritura.

Paso 1 · Caza de bugs (20 min)

Síntoma: al resetear a media corrida, el archivo aparece vacío o cortado mucho antes de donde debería — se pierden muchos más datos de los esperados.

Bug raíz (uno solo): la política de flush es cada 500 registros, que a la frecuencia de este log equivale a decenas de segundos de datos en RAM sin escribir.

Procedimiento:

1. Calcular primero, con lápiz: a la frecuencia del log, ¿cuántos segundos representan 500 registros? Ese número es la respuesta.
2. Forzar el reset y contar cuántos registros sobrevivieron. Comparar con el cálculo.
3. Hipótesis por escrito.
4. Cambiar a flush por tiempo. Barrer: 5 s, 1 s, 250 ms. Para cada valor, medir datos perdidos en el reset y el impacto en el jitter de la tarea de adquisición (la medición de la Sesión 4 se reutiliza aquí).
5. Elegir un valor y defenderlo con los dos números. No hay respuesta única correcta; hay respuestas justificadas.

Paso 2 · Prueba de recuperación (15 min)

1. Correr con el formato original y resetear a media escritura. Intentar leer el archivo. Documentar exactamente qué se ve.
2. Cambiar a registros de longitud fija con marcador de inicio y checksum.
3. Repetir el reset. Escribir el procedimiento de lectura tolerante: recorrer buscando marcadores, validar checksum, descartar el último registro incompleto, reportar cuántos se recuperaron.
4. Reportar: registros escritos / recuperados / perdidos, en ambos formatos.

Paso 3 · Especificación del formato de log (20 min)

Más: tamaño de registro, registros/segundo, MB por hora de carrera, convención de nombre de archivo, y el runbook de recuperación en pasos numerados — escrito para que alguien lo ejecute en pits con prisa.