Problema observado

Usuarios con la aplicación instalada no podían recuperar o seleccionar proyectos de AXET. El síntoma visible era un selector vacío o un fallo de la consola auxiliar.

La integración tenía una complejidad especial: AXET no exponía una API estable para esta operación. La aplicación dependía de un helper que interactuaba con una consola de Windows y con un catálogo remoto cuyo tiempo de carga no era inmediato.

Hipótesis iniciales

Se consideraron varias causas:

  • Ejecutable AXET ausente.
  • Ejecutable no firmado o no autorizado.
  • Agente o bridge todavía sin iniciar.
  • Consola Windows inaccesible para el helper.
  • Catálogo realmente vacío.
  • Catálogo remoto cargando más despacio que el timeout de la aplicación.
  • Diferencias entre ejecutar el helper directamente y lanzarlo por la ruta real de PowerShell.
La investigación evitó tratar todos esos casos como “no hay proyectos”. Esa diferenciación era necesaria para que el mensaje al usuario y las acciones de recuperación fueran correctos.

Reproducción real

Se ejecutó el helper contra AXET 1.1.0. En la máquina de desarrollo recuperó 41 proyectos. Esto demostró que:

  • AXET sí tenía proyectos disponibles.
  • El protocolo de extracción seguía siendo funcional.
  • El selector podía necesitar más tiempo antes de mostrar el primer elemento.
Se observó que la implementación anterior interpretaba como vacío un selector que llevaba aproximadamente 1,8 segundos sin contenido. La conclusión fue que existía una condición de carrera entre el arranque del agente, la apertura del selector y la carga del catálogo remoto.

Decisión: convertir un timeout rígido en estados explícitos

En lugar de aumentar indiscriminadamente todos los tiempos, se definieron ventanas distintas para cada fase:

  • Hasta 45 segundos para que apareciera el primer proyecto.
  • Hasta 180 segundos para el arranque del agente.
  • Hasta 240 segundos de polling desde la aplicación web.
También se separaron los errores:
  • Catálogo realmente vacío.
  • Selector todavía no preparado.
  • Consola Windows no disponible.
  • Agente AXET no iniciado o no autorizado.
La distinción permite mostrar mensajes accionables y facilita el soporte posterior.

Decisión de experiencia de usuario: AXET no debe bloquear la web

La integración era importante, pero no debía impedir utilizar el resto de la aplicación. Se añadió una opción Configurar más tarde.

El aplazamiento se guardó en sessionStorage. Esta elección tenía dos ventajas:

  • No alteraba permanentemente la selección del usuario.
  • El asistente podía reaparecer en una sesión futura sin dejar el sistema en un estado difícil de recuperar.
La operación quedó reintentable. El fallo de una dependencia local pasó de ser un bloqueo global a ser una degradación controlada.

Importancia de probar la ruta real

La ejecución directa del auxiliar compilado podía fallar con un error equivalente a “no se pudo adjuntar la consola”. Sin embargo, la ruta real de producción lo lanzaba oculto desde PowerShell y, mediante esa ruta, recuperaba los 41 proyectos.

La decisión fue validar el componente como realmente lo invocaba la aplicación. Probar únicamente el ejecutable aislado habría producido un falso diagnóstico.

Construcción y validación de la release

Se actualizaron:

  • Script Python de interacción con la consola.
  • Script PowerShell de arranque del agente.
  • Backend de la aplicación web.
  • JavaScript y HTML del frontend.
  • Pruebas, documentación y metadatos de release.
La corrección se publicó en la versión 2.23.20. Se recompilaron el helper y el instalador, y se ejecutaron 256 pruebas dentro de la imagen web.

Segunda parte: diseño de un Companion sin privilegios de administrador

Una aplicación web no puede ejecutar directamente axet-code.exe. Era necesario un puente local, pero los portátiles corporativos imponían límites fuertes:

  • Sin permisos de administrador.
  • Sin servicios de Windows.
  • Sin tareas programadas.
  • Sin Docker ni WSL.
  • Sin cambios globales de registro.
  • Sin instalar certificados en el almacén de máquina.
  • Sin saltarse políticas mediante ExecutionPolicy Bypass.
La propuesta fue un Companion ejecutado como usuario y limitado a operaciones AXET previamente definidas.
text
Aplicación web central
        |
        | HTTPS / WebSocket saliente
        v
Companion en perfil de usuario
        |
        | comandos permitidos
        v
AXET ya instalado y autorizado

El estado se alojaría únicamente en %LOCALAPPDATA% o %APPDATA%. El canal sería saliente para reducir la necesidad de abrir puertos entrantes o modificar el equipo.

Conflicto arquitectónico: VPN full-tunnel frente a AXET

Se identificó que una VPN de túnel completo podía alterar las rutas necesarias para AXET. Sin aislamiento de red privilegiado, ejecutar simultáneamente ambos flujos en el portátil podía no ser viable.

Se evaluaron tres alternativas:

Worker Windows centralizado

Un servidor autorizado ejecutaría AXET y recibiría operaciones de usuarios. Simplificaría los portátiles, pero requeriría seguridad multiusuario, trazabilidad y capacidad operativa central.

Fases secuenciales

La aplicación alternaría entre una fase VPN y una fase AXET. Reduciría infraestructura, pero introduciría cambios de contexto y mayor tiempo de operación.

VPN central aislada por usuario

La VPN se movería a infraestructura central con sesiones separadas. Sería una solución más limpia para el cliente, pero dependía de la política corporativa y de requisitos de identidad y aislamiento.

No se eligió definitivamente una opción porque faltaba una decisión de seguridad y red. Documentar esta dependencia fue mejor que fingir que una solución técnicamente posible estaba autorizada.

Resultado real

  • Corrección del descubrimiento de proyectos: validada y publicada.
  • Recuperación de 41 proyectos: comprobada en la ruta real del helper.
  • Suite de 256 pruebas: superada.
  • Confirmación en el portátil originalmente afectado: pendiente.
  • Arquitectura Companion sin administrador: diseñada, pero condicionada a políticas corporativas.