# Propuesta e2e_checks para apps/pipeline_launcher
# Generada por fn-recopilador en modo design-e2e (2026-05-19)
# app_id:  pipeline_launcher
# lang:    go
# stack:   TUI bubbletea + CGO + mattn/go-sqlite3
# issue:   0121a wave 2
#
# INSTRUCCIONES: copiar el bloque e2e_checks al frontmatter de
# apps/pipeline_launcher/app.md tras revision humana.
# NO modificar app.md automaticamente.
#
# Stack detectado:
#   lang=go, framework=bubbletea v0.25.0
#   CGO_ENABLED=1 (mattn/go-sqlite3 v1.14.37 en go.mod)
#   build tags: fts5 necesarios (importa fn-registry que usa fts5)
#   NO frontend/ (TUI pura, sin assets web)
#   NO tests/ ni *_test.go (check tests OMITIDO)
#   entry_point: main.go → binario: pipeline_launcher
#   config.Default() resuelve rutas via FN_REGISTRY_ROOT env var
#   Sin flags --headless, --list, --version ni --help propios en main.go
#     (la app es TUI pura; la unica salida "rapida" es abrir + cerrar con Ctrl+C)
#   operations.db presente: tablas init (sin logs — migracion 003 NO aplicada)
#     entities=0, relations=0, executions=0, assertions=0
#   registry.db: 30 pipelines con tag 'launcher' disponibles al momento de audit
#
# NOTAS IMPORTANTES:
#   - La app no expone ningun modo headless ni flag CLI propio. Para un check
#     "arranca bien y ve pipelines", la estrategia es: (a) go vet (compilacion
#     y lint sin ejecutar TUI) + (b) query directa a registry.db via sqlite3
#     para verificar que existen pipelines con tag launcher (lo que la TUI
#     mostraria). No se ejecuta el binario en modo TUI porque requiere TTY.
#   - El check ops_init aplica las migraciones faltantes (especialmente 003_logs)
#     sobre operations.db de e2e en /tmp, garantizando schema completo.
#   - ops_audit invoca fn-recopilador sobre la operations.db real para validar
#     integridad. Util como gate de regresion de schema/datos.
#   - No hay tag 'service' → no se necesita smoke/health check HTTP.
#   - Port e2e: N/A (no es service).

e2e_checks:
  # -----------------------------------------------------------------------
  # check: build
  # Por que: gate primario. Valida que el modulo Go compila con CGO+fts5.
  #          CGO es obligatorio por mattn/go-sqlite3. fts5 es necesario
  #          porque el modulo fn-registry (replace local) usa FTS5 en sus
  #          queries sobre registry.db. Sin este tag el build falla con
  #          "undefined: fts5".
  #          El binario se escribe en /tmp para no contaminar el worktree
  #          y hacer el check idempotente.
  # -----------------------------------------------------------------------
  - id: build
    cmd: "cd $HOME/fn_registry/apps/pipeline_launcher && CGO_ENABLED=1 go build -tags fts5 -o /tmp/pipeline_launcher_e2e_bin ."
    timeout_s: 120

  # -----------------------------------------------------------------------
  # check: vet
  # Por que: go vet con CGO+fts5 detecta errores semanticos que no bloquean
  #          la compilacion pero indican bugs (printf de tipo incorrecto,
  #          locks copiados, etc.). Complementa build — bajo coste, alta
  #          cobertura estatica.
  #          Se corre sobre el modulo completo (./...) para cubrir app/,
  #          config/ y views/ que el build check no ejercita separadamente.
  # -----------------------------------------------------------------------
  - id: vet
    cmd: "cd $HOME/fn_registry/apps/pipeline_launcher && CGO_ENABLED=1 go vet -tags fts5 ./..."
    timeout_s: 60

  # -----------------------------------------------------------------------
  # check: pipelines_list_loads
  # Por que: valida la query central de la TUI — que registry.db contiene
  #          >=1 pipeline con tag 'launcher'. Si este check falla, la pantalla
  #          principal de la app mostraria "No pipelines found" que es el caso
  #          de fallo silencioso mas dificil de detectar sin correr la TUI.
  #          Query: buscar en functions donde kind='pipeline' y tags incluye
  #          'launcher'. Equivalent a loadPipelines() en views/pipelines.go.
  #          No requiere el binario compilado — usa sqlite3 CLI directamente
  #          sobre registry.db (ya autorizado para queries en operations.db
  #          y uso diagnostico segun excepciones de registry_calls.md).
  # -----------------------------------------------------------------------
  - id: pipelines_list_loads
    cmd: >
      COUNT=$(sqlite3 $HOME/fn_registry/registry.db
      "SELECT COUNT(*) FROM functions WHERE kind='pipeline' AND tags LIKE '%launcher%';");
      [ "$COUNT" -ge 1 ] && echo "launcher_pipelines=$COUNT OK" || { echo "FAIL: no launcher pipelines found in registry.db"; exit 1; }
    timeout_s: 10
    expect_stdout_contains: "OK"

  # NOTA: el check `ops_schema_complete` se removio (issue 0126).
  # Razon: `fn_operations.Open` usa `ApplyVersionedMigrations` con tabla
  # `schema_migrations` — al abrir pipeline_launcher, 003_logs y migraciones
  # posteriores se aplican automaticamente sobre la BD existente. No hay
  # applier custom. Verificar via ops_audit (siguiente check) basta.

  # -----------------------------------------------------------------------
  # check: ops_audit
  # Por que: invoca fn-recopilador sobre la operations.db real para detectar
  #          referencias rotas, tablas faltantes o datos inconsistentes.
  #          Es el gate del bucle reactivo fase 3 — sin este check el agente
  #          no tiene visibilidad sobre regresiones de schema/datos entre
  #          versiones del app.
  # -----------------------------------------------------------------------
  - id: ops_audit
    ref: "fn-recopilador:apps/pipeline_launcher"