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