Framework Multi-Agente para Desarrollo de Software Autónomo en Bare Metal
Arquitectura KISS para SDLC Enterprise con Agentes de IA Especializados

Índice

1. Introducción

1.1. El Problema con las Herramientas Actuales

Las herramientas comerciales de desarrollo asistido por IA (Claude Code, OpenCode, Kilo Code, etc.) ofrecen capacidades "multi-agente" en su marketing, pero en la práctica presentan limitaciones fundamentales:

  • Agentes monolíticos: Un solo agente con acceso a todas las herramientas y permisos
  • Sin aislamiento real: Todos los "sub-agentes" comparten el mismo sistema de archivos
  • Comunicación síncrona: No hay bus de mensajes ni eventos asíncronos
  • Sin roles estrictos: Las restricciones son solo sugerencias en el prompt, no restricciones del sistema
  • Sin iteración autónoma: El humano debe detectar errores y pedir correcciones manualmente

1.2. Nuestra Solución

Construimos un Framework Multi-Agente Real que implementa un Ciclo de Vida de Desarrollo de Software (SDLC) completo, autónomo y profesional, utilizando únicamente herramientas nativas de Linux y filosofía Unix/KISS.

2. Arquitectura del Sistema

2.1. Principios Fundamentales

  1. Especialización: Cada agente tiene un rol único y definido
  2. Aislamiento: Los permisos se aplican a nivel de sistema operativo
  3. Comunicación Asíncrona: Bus de mensajes nativo de Linux (/var/spool/mail)
  4. Filosofía KISS: Sin Docker para la IA, sin MCPs, sin sobreingeniería
  5. Trazabilidad Completa: Cada acción genera un registro formal

2.2. Agentes y Roles

Agente Rol Dominio Exclusivo Permisos
pm agent Project Manager / Orquestador Todo (solo lectura) read, bash
dev frontend Desarrollador Frontend /client read, write (solo /client)
dev backend Desarrollador Backend /server read, write (solo /server)
qa agent Quality Assurance / Auditor Todo (solo lectura) read, bash
ci cd CI/CD / DevOps Infraestructura Docker read, write, bash
doc agent Documentación y Calidad /docs read, write (solo /docs)
security agent Seguridad y Cumplimiento Auditoría (solo lectura) read, bash

2.3. Flujo de Comunicación

FLUJO DE COMUNICACIÓN MULTI-AGENTE Ciclo de Vida de Desarrollo de Software (SDLC) Autónomo 👤 Founder correo inicial (requerimiento) PM PM Agent delega vía correo FE Dev Frontend [código en /client] BE Dev Backend [código en /server] ambos terminan QA QA Agent [valida y aprueba/rechaza] si hay bugs CICLO DE ITERACIÓN Devs corrigen → QA re-valida si aprueba CI/CD CI/CD Agent [genera Dockerfiles, compose] cuando todo está listo DOC Doc Agent [genera documentación] SEC Security Agent [audita seguridad] reportes finales PM PM Agent reporta al Founder LEYENDA DE AGENTES Founder (Humano) PM Agent (Orquestador) Dev Frontend Dev Backend QA Agent (Auditor) CI/CD Agent (DevOps) Doc Agent (Documentación) Security Agent (Seguridad) Línea punteada = Ciclo de iteración Flujo de comunicación asíncrona vía correo local | Ciclo de vida completo con iteración autónoma de corrección de bugs

3. Infraestructura de Colaboración: Gitea como Sistema de Control de Versión

3.1. ¿Por qué Git como Columna Vertebral?

Git no es solo una herramienta de versionado en este framework; es el sistema nervioso central que permite la colaboración entre agentes. Sin Git, los agentes estarían trabajando en silos aislados, sin forma de:

  • Versionar el código: Cada cambio queda registrado con autor, timestamp y mensaje descriptivo
  • Trabajar en paralelo: Múltiples agentes pueden trabajar en ramas independientes sin pisarse
  • Revisar el trabajo: Los Pull Requests permiten la revisión formal antes de la integración
  • Trazabilidad completa: Cada commit está vinculado a un Issue, a un agente y a un propósito
  • Rollback seguro: Si algo falla, se puede revertir a un estado anterior conocido

En un entorno multi-agente, Git proporciona las garantías que normalmente da un equipo humano: quién hizo qué, cuándo, por qué y con qué autorización.

3.2. ¿Por qué Gitea?

Gitea es una implementación ligera de Git escrita en Go, diseñada para ser auto-hospedada. Lo elegimos sobre alternativas como GitHub, GitLab o Gogs por razones específicas:

3.2.1. Ventajas sobre Soluciones Comerciales (GitHub/GitLab)

Característica GitHub/GitLab Gitea
Dependencia de internet ❌ Requiere conexión ✅ 100% local
Costo ❌ Suscripciones ✅ Gratuito y open source
Privacidad ❌ Código en la nube ✅ Datos 100% en tu servidor
Latencia ❌ Depende de red ✅ Localhost (< 1ms)
Control ❌ Sujeto a ToS ✅ Control total
Consumo de recursos N/A ✅ ~100MB RAM
API REST ✅ Compleja ✅ Simple y documentada

3.2.2. Ventajas sobre Gogs

  • Mantenimiento activo: Gitea tiene una comunidad más grande y releases frecuentes
  • Mejor API REST: Más completa y mejor documentada para automatización
  • Interfaz más pulida: Mejor UX para revisión manual de PRs
  • Soporte para Actions: Permite CI/CD nativo si se desea en el futuro

3.3. ¿Por qué Gitea como Contenedor Docker?

Esta decisión sigue el mismo principio KISS que aplicamos al resto del sistema, pero con una excepción deliberada:

3.3.1. La Excepción al Principio "No Docker para la IA"

Mientras que los agentes de IA corren nativamente en Bare Metal (para evitar la sobrecarga de múltiples contenedores de LLM), Gitea sí corre en Docker. ¿Por qué esta asimetría es correcta?

  1. Aislamiento del servicio: Gitea es un servicio de infraestructura, no un agente de IA. No consume tokens de API ni tiene "pensamiento" que proteger.
  2. Facilidad de despliegue: Un solo comando = Gitea funcionando con base de datos incluida
  3. Portabilidad: Si mañana migras el servidor, mueves el contenedor y listo
  4. Actualizaciones seguras: Cambiar de versión es tan fácil como cambiar la etiqueta de la imagen
  5. Recursos predecibles: Gitea consume ~100MB RAM constante, sin picos

3.3.2. Lo que NO hacemos con Docker

  • ❌ No corremos los agentes de IA en contenedores (sería lento y complejo)
  • ❌ No usamos Docker Compose para orquestar los agentes
  • ❌ No usamos volúmenes Docker para el spool de correo (usamos /var/spool/mail nativo)

3.3.3. Lo que SÍ hacemos con Docker

  • ✅ Corremos Gitea como servicio de infraestructura
  • ✅ El agente CI/CD genera imágenes Docker para la aplicación final
  • ✅ El agente CI/CD usa docker-compose para desplegar la app

Esta es la aplicación correcta del principio KISS: Docker donde aporta valor (servicios), Bare Metal donde aporta valor (agentes de IA).

3.4. Configuración de Gitea en el Sistema

3.4.1. Despliegue del Contenedor

# Crear directorio persistente para Gitea
mkdir -p /opt/gitea/data /opt/gitea/config

# Ejecutar Gitea
docker run -d \
  --name gitea \
  --restart always \
  -p 3000:3000 \
  -p 222:22 \
  -v /opt/gitea/data:/data \
  -v /opt/gitea/config:/data/gitea/conf \
  -e USER_UID=1000 \
  -e USER_GID=1000 \
  gitea/gitea:latest

3.4.2. Acceso e Inicialización

3.5. El Rol de Gitea en el Flujo Multi-Agente

Gitea cumple tres funciones críticas en la arquitectura:

3.5.1. 1. Fuente de Verdad del Código

Todos los agentes clonan desde Gitea y hacen push a Gitea. Esto garantiza:

  • Un solo lugar donde vive el código
  • Historial completo de cambios
  • Resolución automática de conflictos mediante merge

3.5.2. 2. Mecanismo de Revisión (Pull Requests)

Los Pull Requests son el equivalente digital de la "revisión de código" en un equipo humano:

Flujo típico:
1. Dev Frontend crea rama feature/todo-list-frontend
2. Hace push de sus cambios
3. Crea PR #3 apuntando a main
4. QA Agent revisa el PR (código + tests)
5. Si hay bugs → QA rechaza con comentarios
6. Dev corrige y actualiza el PR
7. QA aprueba → PM fusiona a main

3.5.3. 3. API REST para Automatización

Los agentes interactúan con Gitea programáticamente mediante su API REST:

# Crear un Issue (PM Agent)
curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/issues" \
  -H "Authorization: token $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Implementar Todo-List", "body": "..."}'

# Crear un Pull Request (Dev Agent)
curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/pulls" \
  -H "Authorization: token $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title": "Frontend implementation", "head": "feature/frontend", "base": "main"}'

# Fusionar un PR (PM Agent)
curl -X POST "http://localhost:3000/api/v1/repos/pm_agent/test/pulls/3/merge" \
  -H "Authorization: token $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"merge_commit_id": "auto"}'

# Cerrar un Issue (PM Agent)
curl -X PATCH "http://localhost:3000/api/v1/repos/pm_agent/test/issues/2" \
  -H "Authorization: token $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"state": "closed"}'

3.6. Gestión de Tokens por Agente

Cada agente tiene su propio token de API en Gitea, con permisos específicos según su rol:

Agente Permisos en Gitea Propósito
pm agent Lectura y Escritura (Issues, PRs, Repos) Crear Issues, fusionar PRs, cerrar
dev frontend Lectura y Escritura (Repos) Clonar, crear ramas, push, crear PRs
dev backend Lectura y Escritura (Repos) Clonar, crear ramas, push, crear PRs
qa agent Solo Lectura (Repos) Clonar para auditar, no modificar
ci cd Lectura y Escritura (Repos) Clonar, push de infraestructura
doc agent Lectura y Escritura (Repos) Clonar, push de documentación
security agent Solo Lectura (Repos) Clonar para auditar, no modificar

3.6.1. Principio de Mínimo Privilegio

Cada token solo tiene los permisos estrictamente necesarios:

  • Los agentes que no modifican código (QA, Security) tienen solo lectura
  • Los agentes que escriben código (Devs, CI/CD, Docs) tienen lectura y escritura
  • Solo el PM puede fusionar PRs y cerrar Issues

Esto previene que un agente mal comportado o con alucinaciones pueda dañar el repositorio más allá de su dominio.

3.7. El Flujo Completo con Gitea

FLUJO DE TRABAJO CON GITEA 1. PM Agent Crea Issue #2 en Gitea vía API REST PM 2. Dev Frontend Clona repo → rama feature/frontend → PR #3 FE 3. Dev Backend Clona repo → rama feature/backend → PR #4 BE 4. QA Agent Clona repo → Revisa PRs #3 y #4 Bugs → Rechaza | OK → Aprueba QA RECHAZO APROBADO 5. PM Agent Fusiona PRs a main vía API → Cierra Issue #2 PM 6. CI/CD Agent Genera Dockerfiles → rama infra/issue-2 → PR #5 CI 7. PM Agent Fusiona PR #5 (infra) a main PM 8. Usuario Final git clone → docker-compose up -d 👤 LEYENDA PM Agent Dev Frontend Dev Backend QA Agent CI/CD Agent Rechazo QA ☕ Gitea localhost:3000

3.8. Ventajas de esta Arquitectura con Gitea

  1. Trazabilidad completa: Cada Issue, PR y commit está registrado con autor y timestamp
  2. Revisión formal: Los Pull Requests obligan a una revisión antes de la integración
  3. Paralelismo seguro: Múltiples agentes trabajan en ramas independientes
  4. Rollback garantizado: Si algo falla, se puede revertir cualquier cambio
  5. Auditoría automática: El historial de Git documenta todo el proceso
  6. Independencia total: No dependes de servicios externos ni de internet
  7. Escalabilidad: Puedes agregar más agentes sin cambiar la infraestructura base

3.9. Comparación con Alternativas

3.9.1. ¿Por qué no GitHub/GitLab?

  • Dependencia externa: Si GitHub cae, todo tu SDLC se detiene
  • Costo recurrente: Suscripciones mensuales por equipo privado
  • Privacidad: Tu código vive en servidores de terceros
  • Latencia: Cada operación de API depende de tu conexión a internet
  • ToS restrictivo: GitHub puede suspender tu cuenta por cualquier motivo

3.9.2. ¿Por qué no Git puro sin interfaz?

  • Sin Pull Requests: No hay mecanismo formal de revisión
  • Sin Issues: No hay sistema de tickets integrado
  • Sin API REST: Los agentes tendrían que manipular archivos .git directamente (frágil)
  • Sin interfaz web: No puedes revisar el código manualmente cuando quieras
  • Sin webhooks: No puedes automatizar acciones basadas en eventos

Gitea nos da todo esto en un paquete ligero, auto-hospedado y gratuito.

4. Integración con el Resto del Sistema

4.1. Gitea + Correo Local = Orquestación Completa

La combinación de Gitea (para el código) y el spool de correo local (para la comunicación) crea un sistema de orquestación completo:

DOS CAPAS DE COMUNICACIÓN CAPA 1: GIT (Gitea) 🔀 Qué se está construyendo • Código fuente versionado Versionado y trazabilidad • Historial completo de cambios Mecanismo de revisión • Pull Requests formales Fuente de verdad • Artefacto final en rama main CAPA 2: CORREO LOCAL 📧 Qué se está coordinando • Tareas y delegaciones Comunicación asíncrona • Entre agentes especializados Notificaciones de eventos • [COMPLETADO], [RECHAZADO], etc. Bus de mensajes • /var/spool/mail (event-driven) código tareas RESULTADO: SISTEMA INTEGRADO ✨ Los agentes saben QUÉ hacer (vía correo local) Los agentes saben DÓNDE está el código (vía Gitea) Los agentes saben CÓMO revisarlo (vía Pull Requests) Arquitectura Multi-Agente KISS | Git + Correo Local = Orquestación Autónoma

4.2. Flujo de Datos Completo

FLUJO DE DATOS COMPLETO Comunicación entre Founder, Agentes y Gitea 👤 Founder (Humano) PM PM Agent Orquestador correo ☕ GITEA localhost:3000 (Contenedor Docker) API REST DEV Dev Frontend/ Backend correo git push QA QA Agent Auditor correo (PR creado) revisa PR en Gitea CI/CD CI/CD Agent correo (aprobación) push infra a Gitea LEYENDA Founder (Humano) PM Agent Dev Frontend/Backend QA Agent CI/CD Agent Gitea (Infraestructura) Líneas punteadas = lectura Flujo de datos: Correo Local (coordinación) + Gitea API (código) = Sistema Multi-Agente Autónomo

5. Conclusión sobre Gitea

Gitea no es un componente opcional en esta arquitectura; es la columna vertebral que hace posible la colaboración multi-agente. Sin él, los agentes estarían trabajando en aislamiento, sin forma de integrar su trabajo de manera segura y trazable.

La decisión de correr Gitea como contenedor Docker (mientras los agentes corren nativamente) es una aplicación pragmática del principio KISS: usar la herramienta correcta para cada trabajo. Docker aporta valor para servicios de infraestructura; Bare Metal aporta valor para agentes de IA.

Esta combinación de Gitea + Correo Local + Agentes Especializados crea un sistema que es:

  • Autónomo: Los agentes se coordinan sin intervención humana constante
  • Seguro: Los permisos están restringidos a nivel de sistema operativo y de API
  • Trazable: Todo queda registrado en Git y en el spool de correo
  • Profesional: Sigue los mismos patrones que usaría un equipo humano de ingeniería
  • Ligero: Consume mínimos recursos, sin dependencias externas

6. Implementación Técnica

6.1. Configuración del Sistema Operativo

6.1.1. Creación de Usuarios y Grupos

# Crear grupo compartido para herramientas
groupadd tools

# Crear usuarios para cada agente
for agent in pm_agent dev_frontend dev_backend qa_agent ci_cd doc_agent security_agent; do
  useradd -m -s /bin/bash $agent
  passwd $agent
  usermod -aG tools $agent
done

# Agregar ci_cd al grupo docker para construir contenedores
usermod -aG docker ci_cd

6.1.2. Instalación de Herramientas Globales

# Instalar Node.js, npm, OpenCode en /opt/tools
mkdir -p /opt/tools
cd /opt/tools

# Descargar e instalar Node.js
curl -fsSL https://nodejs.org/dist/v22.0.0/node-v22.0.0-linux-x64.tar.xz | tar -xJ
ln -s node-v22.0.0-linux-x64 node
ln -s node/bin/node /usr/local/bin/node
ln -s node/bin/npm /usr/local/bin/npm
ln -s node/bin/npx /usr/local/bin/npx

# Instalar OpenCode
npm install -g opencode

# Configurar permisos
chown -R root:tools /opt/tools
chmod -R 775 /opt/tools

6.1.3. Configuración del Servidor de Correo Local

# Instalar Postfix (o usar el MTA nativo de Slackware)
# Configurar para entrega local únicamente
postconf -e "inet_interfaces = loopback-only"
postconf -e "mydestination = localhost, mtk.org"
systemctl restart postfix

6.2. Configuración de Cada Agente

6.2.1. Estructura de Archivos

/home/{agente}/
├── .opencode/
│   ├── opencode.json          # Configuración de permisos
│   └── system-prompt.md       # Instrucciones especializadas
└── .bashrc                    # Configuración del shell

6.2.2. Ejemplo: opencode.json para devfrontend

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "default": {
      "prompt": "{file:/home/dev_frontend/.opencode/system-prompt.md}",
      "permission": {
        "write": "allow",
        "edit": "deny",
        "read": "allow",
        "bash": "allow"
      }
    }
  }
}

6.2.3. Ejemplo: system-prompt.md para dev frontend (fragmento)

# DIRECTRICES OPERATIVAS: AGENTE DESARROLLADOR FRONTEND (NIVEL SENIOR)

## 1. MISIÓN Y ALCANCE
Usted actúa como Desarrollador Frontend Senior. Su responsabilidad es implementar
la interfaz de usuario según los requisitos del Product Manager.

DOMINIO EXCLUSIVO:
- Trabajar EXCLUSIVAMENTE en la carpeta /client
- Implementar componentes React, estilos CSS, y lógica de UI

PROHIBICIONES ABSOLUTAS:
- NO tocar archivos en /server
- NO escribir lógica de base de datos
- NO instalar dependencias globales

## 2. REGLA DE ORO DE AISLAMIENTO DE ROL
- Su único trabajo es el frontend
- Si necesita algo del backend, solicítelo por correo al PM

## 3. PROTOCOLO DE HERRAMIENTAS (POLÍTICA KISS)
Queda estrictamente prohibido el uso de MCPs. Toda interacción se ejecuta
exclusivamente vía bash usando utilidades POSIX.

REGLA DE ESCAPADO SEGURO:
- Para correos: Use heredocs con comillas simples (cat << 'EOF' | mail ...)

## 4. REGLA DE ENTORNO PRECONFIGURADO (CRÍTICO)
El sistema ya tiene Node.js, npm, npx y OpenCode instalados globalmente en /opt/tools.
- NUNCA intente instalar Node.js, npm o NVM
- NUNCA use apt install
- Ejecute npm install dentro del directorio del proyecto

6.3. Flujo de Trabajo Estándar (SOP)

6.3.1. Fase 1: Ingesta de Correo

# Comando obligatorio para leer el último correo
formail -s cat < /var/spool/mail/{agente}

6.3.2. Fase 2: Análisis del Contexto

  • Extraer número de Issue
  • Identificar tarea específica
  • Verificar permisos y alcance

6.3.3. Fase 3: Ejecución de la Tarea

  • Clonar repositorio si es necesario
  • Implementar la funcionalidad
  • Hacer commit y push a rama feature/

6.3.4. Fase 4: Notificación

# Enviar reporte al PM
cat << 'EOF' | mail -s "[COMPLETADO] Issue #X: Descripción" pm_agent@mtk.org
Estimado PM,

Se ha completado la implementación.

DETALLES TÉCNICOS:
- Issue: #X
- Rama: feature/descripcion
- Commit: hash
- PR: http://localhost:3000/pm_agent/test/pulls/Y

Atentamente,
{Agente}
EOF

7. Caso de Uso: Aplicación Todo-List Full-Stack

7.1. Requerimiento Inicial

De: Founder
Para: pm_agent
Asunto: [REQUERIMIENTO] Crear aplicación Todo-List Full-Stack

Necesito una aplicación de lista de tareas con:
- Frontend en React
- Backend REST con SQLite
- Capacidad de agregar, completar y eliminar tareas
- Despliegue con Docker

7.2. Ejecución del Flujo

  1. PM Agent: Crea Issue #2, delega a Frontend y Backend
  2. Dev Frontend: Implementa UI en /client (PR #3)
  3. Dev Backend: Implementa API en /server (PR #4)
  4. QA Agent: Detecta 2 bugs:
    • Falta endpoint PUT tasks:id
    • Proxy mismatch en package.json
  5. Devs: Corrigieron bugs
  6. QA Agent: Aprueba PRs
  7. CI/CD Agent: Genera Dockerfiles y docker-compose.yml
  8. Bug de Integración: Frontend no conecta con backend en Docker
  9. CI/CD Agent: Implementa Nginx Reverse Proxy
  10. Doc Agent: Genera documentación técnica
  11. Security Agent: Audita seguridad

7.3. Resultado Final

Repositorio: http://localhost:3000/pm_agent/test
Rama main: Código fusionado y funcional
Artefacto: docker-compose.yml listo para producción

Para desplegar:
  git clone http://localhost:3000/pm_agent/test.git
  cd test
  docker-compose up -d

Acceder a: http://localhost:3002

8. Ventajas Comparativas

8.1. vs. Herramientas Comerciales (Claude Code, OpenCode, etc.)

Característica Herramientas Comerciales Nuestro Framework
Aislamiento de permisos ❌ Solo sugerencias ✅ Restricciones reales
Comunicación asíncrona ❌ Síncrona ✅ Bus de mensajes
Roles estrictos ❌ Configuración ✅ Sistema operativo
Iteración autónoma ❌ Manual ✅ Automática
Trazabilidad ❌ Un solo hilo ✅ Correos formales
Filosofía ❌ Productos comerciales ✅ Unix/KISS
Replicabilidad ❌ Dependencias externas ✅ 100% Bare Metal

8.2. Casos de Uso Recomendados

8.2.1. Usar Herramientas Comerciales si:

  • Proyecto personal pequeño
  • Prototipado rápido
  • No se requiere trazabilidad
  • Proyecto efímero

8.2.2. Usar Nuestro Framework si:

  • Software profesional con calidad empresarial
  • Separación de responsabilidades requerida
  • Trazabilidad y auditoría necesarias
  • Sistema debe autocorregirse
  • Filosofía Unix y control total

9. Automatización (Futura Mejora)

9.1. Script de Cron para Despertar Agentes

#!/bin/bash
# /usr/local/bin/check-and-run-agent.sh

USER="qa_agent"
MAILBOX="/var/spool/mail/$USER"

# Verificar si el archivo de correo fue modificado en los últimos 10 minutos
if find "$MAILBOX" -mmin -10 2>/dev/null | grep -q .; then
    echo "[$(date)] Nuevo correo detectado para $USER" >> /var/log/agent-trigger.log

    # Ejecutar OpenCode en modo headless
    su - "$USER" -c 'opencode run "Ejecuta tu flujo operativo estricto con el último correo. Finaliza tu turno."' >> /var/log/agent-trigger.log 2>&1
else
    exit 0
fi

9.1.1. Configuración de Cron

# Ejecutar cada 5 minutos
*/5 * * * * /usr/local/bin/check-and-run-agent.sh

10. Conclusión

Este framework demuestra que es posible construir un Sistema Multi-Agente de Desarrollo de Software completamente autónomo, profesional y robusto, utilizando únicamente herramientas nativas de Linux y aplicando principios de ingeniería de software clásicos.

La clave no está en la complejidad tecnológica, sino en la arquitectura: agentes especializados, aislamiento de permisos, comunicación asíncrona y orquestación event-driven.

Este enfoque no solo es viable, sino que es superior a las soluciones comerciales en términos de seguridad, calidad, trazabilidad y mantenibilidad.

11. Apéndices

11.1. A. Comandos Útiles

# Ver correos de un agente
formail -s cat < /var/spool/mail/{agente}

# Limpiar buzón de un agente
> /var/spool/mail/{agente}

# Ver grupos de un usuario
groups {usuario}

# Cambiar a un agente
su - {agente}

# Ejecutar OpenCode
opencode

11.2. B. Estructura del Repositorio Final

test/
├── client/
│   ├── src/
│   ├── public/
│   ├── package.json
│   └── Dockerfile
├── server/
│   ├── routes/
│   ├── database/
│   ├── index.js
│   ├── package.json
│   └── Dockerfile
├── docs/
│   ├── README.md
│   ├── API_SPEC.md
│   ├── ADR_001.md
│   └── ISO_25010_CHECKLIST.md
├── docker-compose.yml
├── nginx.conf
└── .dockerignore

11.3. C. Referencias

Fecha: 2026-07-31

Autor: Gaston Pepe

Created: 2026-07-31 Fri 10:19

Validate