Hermes: creación de servidores, permisos y trabajo medido

La petición grabada solicita un LXC Debian 13 sin privilegios, Docker, SSH por clave, un registro DNS y una instantánea inicial. Pide cuatro núcleos, 8 GB de RAM, 2 GB de swap y 64 GB de almacenamiento. El resultado debe funcionar y quedar documentado para quien lo administre después.

Es una ejecución exitosa seleccionada tras diez intentos de práctica. No permite calcular la tasa de éxito al primer intento. La comprobación independiente del video aporta evidencia concreta: el propietario resuelve el nombre DNS, entra con su clave y ejecuta hello-world de Docker.

Petición en WhatsApp → perfil homelab → modelo y sesión
    → terminal Docker → CLI lab o SSH como root
    → contenedor Proxmox, Docker y DNS
    → inventario y registro → comprobación independiente

El entorno monta /lab con escritura y /secrets en modo de solo lectura. Una credencial de solo lectura todavía puede autorizar cambios en otro sistema. Los comandos se ejecutan en Docker, pero SSH como root en el nodo Proxmox les da autoridad sobre el hipervisor.

La CLI lab rechaza escrituras sin una explicación --confirmed y registra las llamadas confirmadas. El agente redacta esa explicación. SSH y las llamadas directas pueden evitar la CLI; además, el agente puede editar el registro. Estos controles permiten inspeccionar el trabajo, pero el cumplimiento de la aprobación y la integridad del historial dependen de las instrucciones.

Hermes consultó recursos, red de un contenedor de referencia, almacenamiento, plantillas, DNS, ARP y concesiones DHCP. Propuso los valores y esperó autorización. La comprobación de IP quedó inconclusa: no aparecer en ARP o DHCP no demuestra que la dirección esté reservada. Un sí permitió continuar sin resolver esa ambigüedad.

La creación usó pct por SSH como root porque keyctl requería privilegios que el token de API no tenía. La instalación se ejecutó con pct exec. El invitado recibió la clave del propietario, pero el agente conservó acceso por el hipervisor. Validó SSH con sshd -t, creó la instantánea, respaldó DNS y verificó el registro después de escribirlo.

Un patch al inventario falló porque no encontró el texto esperado. El agente lo corrigió unos trece segundos después. El video conserva ese error. No muestra un intento de acceso por contraseña rechazado: la evidencia de SSH corresponde a la configuración, su sintaxis y el acceso exitoso con la clave del propietario.

La petición llega al resumen en unos 6 minutos y 14 segundos. El registro completo suma 1,294,930 tokens y unos 279 segundos de latencia acumulada del modelo, incluidas las tres llamadas posteriores. Restar esa latencia al tiempo de creación no produce una medida válida del tiempo de herramientas. La exportación cuenta por separado 33 llamadas a herramientas.

Descargar consumo por llamada. Son conteos acumulados, no texto único, ahorro medido de caché ni una factura. Excluyen la práctica. La aprobación por comando estaba apagada.

Usa un contenedor desechable y una reserva explícita de IP. Conserva el plan aprobado, identificadores, tiempos y comandos de aceptación. Comprueba DNS y acceso al invitado fuera del resumen del agente. Si mides fiabilidad, conserva los intentos fallidos en el denominador.

Las siguientes mejoras deben verificar la aprobación fuera del texto que escribe el agente, limitar su autoridad sobre el hipervisor y enviar los eventos a un registro que no pueda reescribir. Las correcciones deben agregarse al historial. La ejecución incluye la corrección de un conteo de paquetes sin respaldo, un ejemplo concreto del problema de un registro editable.

El artículo técnico documenta la configuración y la ejecución. Este informe organiza esa evidencia para revisarla; no presenta una nueva prueba.