Files
fn_registry/dev/proposals_e2e_checks_0121/docker_tui.yaml
T
egutierrez 1d3d2f43b3 feat(0121a): wave 2 e2e_checks proposals (8 apps) + README updated
8 fn-recopilador design-e2e paralelos:
- services_api      (Go service, schema custom operations.db)
- registry_mcp      (Go stdio MCP, JSON-RPC handshake test)
- sqlite_api        (Go service read-only HTTP, query_endpoint)
- registry_dashboard (C++ ImGui, NO Go+React como yo supuse)
- primitives_gallery (C++ build gate de toda API C++ del registry, 44 .cpp)
- pipeline_launcher (Go TUI bubbletea)
- docker_tui        (Go TUI + go-duckdb)
- fn_match          (subcmd ./fn, hook helper, fuzzy match)

13/26 apps cubiertas. README documenta:
- 6 bugs/drift descubiertos lateral (dag_engine x3, deploy_server,
  pipeline_launcher, docker_tui).
- 3 correcciones de mi prompt (yo asumi stacks incorrectos).
- Hallazgos arquitectonicos (primitives_gallery = build gate C++).

Pendiente wave 3 (13 apps) + 0121b + 0121c.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-19 00:43:09 +02:00

133 lines
7.2 KiB
YAML

# 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.