# e2e_checks proposal — docker_tui # app_id: docker_tui # lang: go # stack: Bubble Tea (charmbracelet/bubbletea) + lipgloss + devfactory TUI framework # dir_path: apps/docker_tui # date: 2026-05-19 # issue: 0121a wave 2 # # Generado por fn-recopilador modo design-e2e. # NO copiar directamente al app.md — requiere revision humana (mismo flujo que proposals). # # --------------------------------------------------------------------------- # DIAGNOSTICO # --------------------------------------------------------------------------- # lang=go, framework=bubbletea, entry_point=main.go # Sin tests: no hay *_test.go en ningún paquete. # Sin --help ni --version: el binario es TUI pura, requiere TTY. # - timeout 2s ./docker-tui --help → exit 1 + "could not open a new TTY" # - Eso es el comportamiento esperado de CI: sin TTY el proceso sale con error. # CGO requerido: la dependencia devfactory (go.work local path # /home/lucas/.local_agentes/backend) declara go-duckdb v1.6.5 que usa CGO. # go vet pasa con CGO_ENABLED=1. Build sin CGO no es posible por la dep transitiva. # Docker CLI: toda la logica llama al binario `docker` via shell.RunWithTimeout. # No usa SDK de Docker ni abre /var/run/docker.sock directamente. # Al fallar la invocación (socket ausente, daemon parado) devuelve error que # la vista TUI muestra en pantalla — no hay panic ni exit(1). # operations.db presente: 4 migraciones aplicadas (001-004). Sin entidades ni # ejecuciones aun — la app es nueva (v0.1.0). Incluir ops_audit igualmente. # go.work: referencia path absoluto /home/lucas/.local_agentes/backend. # El build en CI necesita que ese path exista, o reemplazar con GOFLAGS/replace # en el Makefile. El check build puede fallar en CI remoto si el path no monta. # Se marca severity: warning para no bloquear gate mientras no hay CI remoto. # --------------------------------------------------------------------------- e2e_checks_suggested: - id: build # CGO_ENABLED=1 obligatorio — devfactory backend tiene go-duckdb (CGO). # go.work en la raiz del app resuelve el replace local automaticamente. # El binario resultante es ~42 MB con trimpath+ldflags. cmd: "cd apps/docker_tui && CGO_ENABLED=1 go build -trimpath -ldflags='-s -w' -o /tmp/docker_tui_e2e ." timeout_s: 120 severity: warning # warning porque el build depende de /home/lucas/.local_agentes/backend # (path absoluto en go.work). En CI remoto puede no existir; pendiente # resolver via GOFLAGS o módulo publicado en Gitea. - id: vet # go vet detecta errores estaticos sin necesitar TTY ni docker daemon. # Pasa con CGO_ENABLED=1 segun verificacion directa. cmd: "cd apps/docker_tui && CGO_ENABLED=1 go vet ./..." timeout_s: 60 - id: no_tty_exits_cleanly # TUI pura sin --help. En ausencia de TTY (CI headless), el binario debe # salir con exit != 0 y escribir un mensaje de error legible en stderr. # Verificamos que: # 1. Sale antes del timeout (no se queda colgado esperando input). # 2. El stderr contiene "TTY" (mensaje de error conocido del framework). # expect_exit: 1 porque tui.RunFullscreen devuelve error cuando no hay TTY. cmd: "timeout 5s /tmp/docker_tui_e2e 2>&1 || true" expect_stdout_contains: "TTY" expect_exit: 0 # expect_exit 0 porque usamos '|| true' para capturar stdout/stderr y # verificar el mensaje. La condicion real es stdout_contains "TTY". timeout_s: 10 - id: docker_cli_present # Verifica que el binario docker esta en PATH antes de intentar operaciones. # Sin docker instalado, todas las vistas muestran error — la TUI sigue # funcionando (no crashea), pero el check avisa al operador en CI. cmd: "docker --version" expect_stdout_contains: "Docker version" timeout_s: 5 - id: docker_socket_optional # Simula socket de Docker ausente. Verifica que el CLI reporta el error # correctamente y sale con codigo != 0 (comportamiento esperado). # Este check es diagnostic: confirma que cuando el daemon no esta disponible # el codigo de error es coherente. La TUI lo maneja gracefully (muestra # el error en la lista en lugar de crashear). cmd: "DOCKER_HOST=unix:///tmp/nonexistent_docker_e2e.sock docker ps 2>&1" expect_stdout_contains: "failed to connect" expect_exit: 0 # expect_exit 0 porque la shell captura el stderr via 2>&1 y el check # evalua stdout_contains. La condicion real es que docker reporta el error. severity: warning timeout_s: 5 - id: ops_audit # operations.db presente con 4 migraciones aplicadas. # Sin entidades aun (app nueva v0.1.0) — el audit valida que el schema # esta completo y no hay referencias rotas. ref: "fn-recopilador:apps/docker_tui" # --------------------------------------------------------------------------- # JUSTIFICACION # --------------------------------------------------------------------------- # | check | razon | # |------------------------|--------------------------------------------------| # | build | CGO requerido por devfactory/go-duckdb. Sin | # | | build verificado no hay binario que testear. | # | | severity:warning por dependencia path absoluto. | # | vet | Analisis estatico sin TTY ni daemon. Detecta | # | | bugs de tipos y contextos antes de runtime. | # | no_tty_exits_cleanly | CI es headless. Verificar que el binario sale | # | | con error legible (no se cuelga) es el unico | # | | gate posible para una TUI sin --self-test. | # | docker_cli_present | Toda la logica wrappea el CLI `docker`. Si no | # | | esta en PATH, las vistas muestran error pero | # | | la causa raiz debe detectarse en CI. | # | docker_socket_optional | Documenta el comportamiento cuando el daemon | # | | no esta. La TUI debe degradar gracefully, no | # | | crashear. severity:warning — ambiente dependiente.| # | ops_audit | operations.db existe, 4 migraciones aplicadas. | # | | Audita schema completo y coherencia de datos | # | | (aunque este vacio en v0.1.0). | # --------------------------------------------------------------------------- # # CHECKS OMITIDOS y razon: # - tests: no hay *_test.go. Proponer agregar tests unitarios para # views/docker.go (parseJSONLines, helpers) — candidato a issue futuro. # - smoke con health URL: TUI sin servidor HTTP. No aplica. # - --self-test flag: no implementado. Podria anadirse al main.go para # verificar build de modelos sin lanzar el loop de bubbletea. # - build_frontend: no hay frontend web. No aplica. # # NOTA CRITICA — go.work con path absoluto: # El replace en go.work apunta a /home/lucas/.local_agentes/backend. # Para que el check `build` funcione en cualquier maquina/CI, pendiente # publicar devfactory como modulo en Gitea o agregar GONOSUMCHECK + replace # via GOFLAGS. Hasta entonces build=warning, no critical.