chore: auto-commit (8 archivos)
- .claude/rules/registry_calls.md - apps/dag_engine/README.md - apps/dag_engine/app.md - docs/capabilities/INDEX.md - docs/capabilities/systemd.md - docs/execution_standard.md - dev/proposals_e2e_checks_0121/ - docs/capabilities/backends.md Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,133 @@
|
||||
# Propuesta e2e_checks para apps/auto_metabase
|
||||
#
|
||||
# Generado por fn-recopilador en modo design-e2e
|
||||
# App: auto_metabase (lang: py, framework: httpx, entry_point: main.py)
|
||||
# Detectado:
|
||||
# - CLI con argparse, subcomandos (projects, login, pull, push, validate, ...)
|
||||
# - NO service (no tag 'service', no puerto propio)
|
||||
# - Deps: yaml, httpx en python/.venv (registry venv compartido)
|
||||
# - Test: dashboard_split_test.py — pytest puro, imports relativos a apps/auto_metabase/
|
||||
# - NO operations.db propia (no bucle reactivo propio)
|
||||
# - Toca Metabase REAL en todos los comandos de red (login, pull, push, ...)
|
||||
# -> todos los checks e2e deben ser OFF-LINE: import, CLI help, tests puros
|
||||
#
|
||||
# Justificacion por check:
|
||||
#
|
||||
# | check | razon |
|
||||
# |--------------------|---------------------------------------------------------------------------|
|
||||
# | import | Valida que el entry point y sus modulos cargan sin errores de import, |
|
||||
# | | que sys.path al registry de funciones esta bien y que yaml/httpx estan |
|
||||
# | | disponibles en el venv compartido. |
|
||||
# | cli_help | Valida que argparse esta correctamente configurado y que el CLI no |
|
||||
# | | crashea en el arranque (antes de que necesite project o red). Confirma |
|
||||
# | | que todos los submodulos (sync_push, sync_pull, payload, ...) se cargan. |
|
||||
# | mbql_validate_pure | Valida la funcion PURA metabase_mbql_validate del registry sin tocar |
|
||||
# | | red. Es la unica funcion del modulo que puede correr offline sin |
|
||||
# | | credenciales. Detecta regresiones en el validador MBQL local. |
|
||||
# | tests_dashboard_split | Corre dashboard_split_test.py — tests puros del helper de split/merge |
|
||||
# | | de dashboards por tab. No requieren red ni credenciales. |
|
||||
# Los checks que SI requieren red (login, pull, push, validate --check-sql)
|
||||
# no se incluyen porque tocan Metabase real o credenciales. Se dejan para
|
||||
# un entorno de smoke con Metabase en Docker (ver nota abajo).
|
||||
#
|
||||
# NOTA — smoke con Docker (severity: warning, no incluido por default):
|
||||
# Si se quiere gate de smoke real, levantar Metabase en Docker local y usar:
|
||||
# docker run -d -p 3100:3000 --name mb_e2e metabase/metabase
|
||||
# python/.venv/bin/python3 apps/auto_metabase/main.py init-project e2e_test --base-url http://localhost:3100 \
|
||||
# --email test@test.com --password Test1234!
|
||||
# python/.venv/bin/python3 apps/auto_metabase/main.py -p e2e_test login
|
||||
# python/.venv/bin/python3 apps/auto_metabase/main.py -p e2e_test status
|
||||
# Ese bloque queda fuera de e2e_checks hasta tener un entorno Docker reproducible.
|
||||
|
||||
app_id: auto_metabase
|
||||
dir_path: apps/auto_metabase
|
||||
lang: py
|
||||
generated_by: fn-recopilador
|
||||
generated_at: "2026-05-19"
|
||||
|
||||
e2e_checks:
|
||||
- id: import
|
||||
# Carga completa del entry point: sys.path al registry, yaml, httpx,
|
||||
# metabase.client, payload, sync_pull, sync_push, etc.
|
||||
# Si cualquier modulo tiene un import roto, falla aqui.
|
||||
cmd: >-
|
||||
python/.venv/bin/python3 -c
|
||||
'import sys; sys.path.insert(0, "apps/auto_metabase");
|
||||
import importlib.util, pathlib;
|
||||
spec = importlib.util.spec_from_file_location("main", "apps/auto_metabase/main.py");
|
||||
m = importlib.util.module_from_spec(spec);
|
||||
spec.loader.exec_module(m);
|
||||
print("import OK")'
|
||||
expect_stdout_contains: "import OK"
|
||||
timeout_s: 30
|
||||
severity: critical
|
||||
# por que: valida que el entry point carga sin ImportError (yaml, httpx,
|
||||
# metabase.client, payload, sync_push, ...) usando el venv del registro.
|
||||
|
||||
- id: cli_help
|
||||
# Valida que argparse esta bien formado y todos los submodulos cargan.
|
||||
# 'projects --help' dispara solo el parser, no requiere red ni proyecto.
|
||||
cmd: "python/.venv/bin/python3 apps/auto_metabase/main.py --help"
|
||||
expect_stdout_contains: "usage:"
|
||||
timeout_s: 15
|
||||
severity: critical
|
||||
# por que: el CLI tiene ~30 subcomandos; si cualquier modulo falla al
|
||||
# importarse (payload.py, sync_push.py, etc.) esto lo captura.
|
||||
|
||||
- id: mbql_validate_pure
|
||||
# Corre la funcion PURA metabase_mbql_validate del registry de forma offline.
|
||||
# Prueba un dataset_query MBQL minimo valido (debe devolver lista vacia de errores)
|
||||
# y uno con UUID duplicado (debe detectar el error).
|
||||
cmd: >-
|
||||
python/.venv/bin/python3 - <<'PYEOF'
|
||||
import sys
|
||||
sys.path.insert(0, "python/functions")
|
||||
from metabase import metabase_mbql_validate
|
||||
import uuid
|
||||
|
||||
# Caso valido: query nativo minimo sin errores
|
||||
u1, u2 = str(uuid.uuid4()), str(uuid.uuid4())
|
||||
valid_q = {
|
||||
"lib/type": "mbql/query",
|
||||
"database": 1,
|
||||
"stages": [{"lib/type": "mbql.stage/native",
|
||||
"native": "SELECT 1",
|
||||
"lib/uuid": u1}],
|
||||
"lib/uuid": u2,
|
||||
}
|
||||
errs = metabase_mbql_validate(valid_q)
|
||||
assert errs == [], f"Esperaba 0 errores, got: {errs}"
|
||||
|
||||
# Caso invalido: UUID duplicado
|
||||
dup = str(uuid.uuid4())
|
||||
bad_q = {
|
||||
"lib/type": "mbql/query",
|
||||
"database": 1,
|
||||
"stages": [{"lib/type": "mbql.stage/native",
|
||||
"native": "SELECT 1",
|
||||
"lib/uuid": dup}],
|
||||
"lib/uuid": dup,
|
||||
}
|
||||
errs2 = metabase_mbql_validate(bad_q)
|
||||
assert len(errs2) > 0, "Esperaba error de UUID duplicado"
|
||||
|
||||
print("mbql_validate_pure OK")
|
||||
PYEOF
|
||||
expect_stdout_contains: "mbql_validate_pure OK"
|
||||
timeout_s: 30
|
||||
severity: critical
|
||||
# por que: metabase_mbql_validate es la unica funcion del modulo metabase
|
||||
# ejecutable offline. Detecta regresiones en el validador MBQL puro.
|
||||
|
||||
- id: tests_dashboard_split
|
||||
# Corre el unico test file puro de la app: dashboard_split_test.py.
|
||||
# No requiere red, no toca Metabase. Pytest con confdir en la app dir.
|
||||
cmd: >-
|
||||
python/.venv/bin/python3 -m pytest -x -q
|
||||
--rootdir=apps/auto_metabase
|
||||
apps/auto_metabase/dashboard_split_test.py
|
||||
timeout_s: 60
|
||||
severity: critical
|
||||
# por que: dashboard_split.py tiene logica de split/merge de dashboards
|
||||
# multi-tab y el test file tiene casos exhaustivos. Es el unico gate
|
||||
# automatico de esa logica que no requiere Metabase.
|
||||
@@ -0,0 +1,43 @@
|
||||
# app_id: deploy_server
|
||||
# lang: go (CGO, sin fts5)
|
||||
# stack: net/http + go-sqlite3 (CGO) + multi-strategy deployer (systemd/systemd-remote/docker-compose)
|
||||
# deteccion automatica fn-recopilador 2026-05-19, issue 0121a
|
||||
#
|
||||
# Notas de deteccion:
|
||||
# - go.mod usa github.com/mattn/go-sqlite3 (CGO=1) pero NO usa fts5 tags
|
||||
# - sin *_test.go en el directorio -> check tests OMITIDO
|
||||
# - server.go confirma: --port flag con default 9090, GET /api/health handler
|
||||
# - puerto e2e: 9190 (+100 sobre puerto productivo 9090)
|
||||
# - operations.db presente con tablas propias (deploy_targets, deploy_logs) -> ops_audit incluido
|
||||
# - BD e2e en /tmp/ para idempotencia; binario en /tmp/ para no contaminar el directorio de la app
|
||||
|
||||
e2e_checks:
|
||||
# build: compila el binario con CGO habilitado. Sin -tags fts5 (no lo usa el modulo).
|
||||
# Valida que el modulo go-sqlite3 linkea correctamente en el entorno local.
|
||||
- id: build
|
||||
cmd: "cd /home/lucas/fn_registry/apps/deploy_server && CGO_ENABLED=1 go build -o /tmp/deploy_server_e2e_bin ."
|
||||
timeout_s: 180
|
||||
|
||||
# cli_help: verifica que el binario arranca y responde sin crashear ni pedir args obligatorios.
|
||||
# Captura el caso de init() con side effects o missing assets.
|
||||
- id: cli_help
|
||||
cmd: "/tmp/deploy_server_e2e_bin help"
|
||||
expect_exit: 0
|
||||
expect_stdout_contains: "deploy_server"
|
||||
timeout_s: 10
|
||||
|
||||
# migrations: arranca el servidor con la BD de prueba y lo cierra inmediatamente.
|
||||
# El servidor abre la BD al arrancar y aplica migraciones automaticamente (sqlite_apply_migrations).
|
||||
# Usamos --port 0 no esta soportado (flag es int sin port-0), asi que usamos puerto alto efimero.
|
||||
# Tras el health check, el proceso se mata automaticamente por fn-analizador.
|
||||
- id: smoke
|
||||
cmd: "/tmp/deploy_server_e2e_bin serve --port 9190 --db /tmp/deploy_server_e2e.db &"
|
||||
health: "http://127.0.0.1:9190/api/health"
|
||||
timeout_s: 15
|
||||
|
||||
# ops_audit: fn-recopilador audita operations.db de la app.
|
||||
# Verifica integridad referencial, schema completo, ausencia de datos corruptos.
|
||||
# La BD tiene tablas propias (deploy_targets, deploy_logs) + tablas del ciclo reactivo.
|
||||
- id: ops_audit
|
||||
ref: "fn-recopilador:apps/deploy_server"
|
||||
severity: warning
|
||||
@@ -0,0 +1,116 @@
|
||||
# e2e_checks proposal — registry_api
|
||||
#
|
||||
# app_id: registry_api
|
||||
# lang: go
|
||||
# stack: net/http, CGO+FTS5, SQLite (mattn/go-sqlite3), replace fn-registry => ../../
|
||||
# date: 2026-05-19
|
||||
# issue: 0121 (design-e2e fn-recopilador)
|
||||
#
|
||||
# Diagnostico del stack:
|
||||
# - entry_point: main.go (acepta --port N y --db PATH)
|
||||
# - health endpoint: GET /api/status (sin auth, siempre 200 + JSON {"status":"ok",...})
|
||||
# - auth layer: checkToken() en handleSync solamente; Traefik basicAuth en prod (no
|
||||
# aplica en e2e local). /api/status, /api/search, /api/locations NO tienen auth.
|
||||
# - no hay *_test.go => check "tests" omitido
|
||||
# - operations.db no declarada para esta app => ops_audit omitido
|
||||
# - puerto prod 8420 => e2e usa 8521 para no colisionar
|
||||
#
|
||||
# Instrucciones de adopcion:
|
||||
# 1. Copiar el bloque "e2e_checks:" al frontmatter de apps/registry_api/app.md
|
||||
# (justo antes del primer "##" de la seccion de prosa).
|
||||
# 2. Revisar que el binario compilado quede en apps/registry_api/registry_api
|
||||
# (el build check lo deja ahi por convencian).
|
||||
# 3. El check auth_check requiere que REGISTRY_API_TOKEN este seteada en el
|
||||
# entorno de test; si no lo esta, /api/sync devuelve 200 (token desactivado).
|
||||
# Ajustar severity a "warning" si el CI no tiene la variable disponible.
|
||||
#
|
||||
# NOTA: NO escribir directo al app.md — propuesta para revision humana.
|
||||
|
||||
e2e_checks:
|
||||
# --- build ---
|
||||
# Compila el binario localmente con CGO+FTS5. El replace directive en go.mod
|
||||
# apunta a ../../ (raiz del registry), por lo que el build debe lanzarse
|
||||
# desde dentro del directorio de la app.
|
||||
- id: build
|
||||
cmd: "cd /home/lucas/fn_registry/apps/registry_api && CGO_ENABLED=1 go build -tags fts5 -o registry_api ."
|
||||
timeout_s: 120
|
||||
severity: critical
|
||||
# por que: sin binario el resto de checks no tiene sentido; fallo de build
|
||||
# indica cambio de API en fn-registry (replace) o dep rota.
|
||||
|
||||
# --- smoke ---
|
||||
# Arranca el servidor con una BD efimera en /tmp y espera que responda en
|
||||
# /api/status. Puerto 8521 (!=8420 prod, !=8420 dev) para no colisionar.
|
||||
# El proceso en background se mata al terminar la suite por fn-analizador.
|
||||
- id: smoke
|
||||
cmd: "/home/lucas/fn_registry/apps/registry_api/registry_api -port 8521 -db /tmp/registry_api_e2e.db &"
|
||||
health: "http://127.0.0.1:8521/api/status"
|
||||
timeout_s: 10
|
||||
severity: critical
|
||||
# por que: tag 'service' => gate minimo es que el binario arranca y sirve
|
||||
# el health endpoint. Sin esto no tiene sentido probar endpoints de negocio.
|
||||
|
||||
# --- status_json ---
|
||||
# Verifica que /api/status devuelve JSON con campo "status":"ok".
|
||||
# Distingue un servidor arrancado de uno en modo degradado.
|
||||
- id: status_json
|
||||
cmd: "curl -sf http://127.0.0.1:8521/api/status"
|
||||
expect_stdout_contains: '"status":"ok"'
|
||||
timeout_s: 5
|
||||
severity: critical
|
||||
# por que: el health check del smoke solo valida HTTP 200; este check
|
||||
# valida ademas el contrato de respuesta JSON.
|
||||
|
||||
# --- search_open ---
|
||||
# Verifica que /api/search acepta GET sin auth y devuelve JSON valido.
|
||||
# Usa q=test para tener un resultado predecible (siempre devuelve arrays).
|
||||
- id: search_open
|
||||
cmd: "curl -sf 'http://127.0.0.1:8521/api/search?q=test'"
|
||||
expect_stdout_contains: '"functions"'
|
||||
timeout_s: 5
|
||||
severity: critical
|
||||
# por que: /api/search es el endpoint mas usado por fn sync y el MCP.
|
||||
# Fallo aqui indica problema de FTS5 o schema de registry.db.
|
||||
|
||||
# --- search_missing_q ---
|
||||
# Verifica que /api/search sin q= devuelve 400 (validacion de entrada).
|
||||
- id: search_missing_q
|
||||
cmd: "curl -s -o /dev/null -w '%{http_code}' 'http://127.0.0.1:8521/api/search'"
|
||||
expect_stdout_contains: "400"
|
||||
timeout_s: 5
|
||||
severity: warning
|
||||
# por que: regression guard para la validacion de parametros obligatorios.
|
||||
|
||||
# --- auth_check ---
|
||||
# Verifica que POST /api/sync rechaza requests con token incorrecto cuando
|
||||
# REGISTRY_API_TOKEN esta seteada. Usa credencial falsa conocida.
|
||||
# IMPORTANTE: si REGISTRY_API_TOKEN no esta en el entorno de e2e, el servidor
|
||||
# responde 200 (token desactivado por diseno). En ese caso este check pasa
|
||||
# igualmente (exit 0 de curl) pero no valida auth real — ajustar a warning
|
||||
# o setear la variable antes de correr la suite.
|
||||
- id: auth_check
|
||||
cmd: >
|
||||
REGISTRY_API_TOKEN=real-secret
|
||||
/home/lucas/fn_registry/apps/registry_api/registry_api -port 8522 -db /tmp/registry_api_e2e_auth.db &
|
||||
sleep 1 &&
|
||||
STATUS=$(curl -s -o /dev/null -w '%{http_code}'
|
||||
-X POST http://127.0.0.1:8522/api/sync
|
||||
-H 'Content-Type: application/json'
|
||||
-H 'X-Registry-Token: wrong-token'
|
||||
-d '{"pc_id":"e2e"}') &&
|
||||
kill %1 2>/dev/null; [ "$STATUS" = "401" ]
|
||||
timeout_s: 15
|
||||
severity: warning
|
||||
# por que: /api/sync es el unico endpoint protegido por token de aplicacion.
|
||||
# Fallo indica regresion en checkToken(). Severity warning porque en CI sin
|
||||
# REGISTRY_API_TOKEN el comportamiento es abierto por diseno.
|
||||
|
||||
# --- locations_open ---
|
||||
# Verifica que /api/locations devuelve JSON sin requerir auth.
|
||||
- id: locations_open
|
||||
cmd: "curl -sf http://127.0.0.1:8521/api/locations"
|
||||
expect_stdout_contains: "["
|
||||
timeout_s: 5
|
||||
severity: warning
|
||||
# por que: /api/locations es consumido por fn sync locations; fallo indica
|
||||
# problema en db.ListAllPcLocations() o schema de pc_locations.
|
||||
@@ -0,0 +1,47 @@
|
||||
# Propuesta e2e_checks para apps/shaders_lab
|
||||
# Generado por fn-recopilador modo design-e2e
|
||||
# Fecha: 2026-05-19
|
||||
#
|
||||
# Diagnostico:
|
||||
# lang=cpp, framework=imgui (fn::run_app), domain=gfx
|
||||
# toolchain: mingw-w64 (cross-compile Windows desde WSL)
|
||||
# modulos: main.cpp + compiler.cpp + 19 .cpp del registry (gfx + core)
|
||||
# deps externas: imgui_node_editor, SQLite::SQLite3
|
||||
# persistencia propia: shaders_lab.db (junto al .exe, via shaderlab_db)
|
||||
# sin tests/ ni tests_*.py detectados
|
||||
# sin primitives_gallery integration (golden_image: OMITIDO)
|
||||
# sin --self-test: fn::run_app no parsea argv (confirmado piloto 0120)
|
||||
# sin tag 'service': no expone HTTP (smoke con health: OMITIDO)
|
||||
# operations.db: NO usa (ops_audit: OMITIDO)
|
||||
#
|
||||
# Patron: C++ ImGui — checks estructurales sin lanzar GUI ni GPU
|
||||
|
||||
app_id: shaders_lab
|
||||
|
||||
e2e_checks:
|
||||
# Build: compila el target completo para Windows via mingw-w64.
|
||||
# Valida que todos los .cpp del registry enlazados (19 archivos gfx+core)
|
||||
# compilan sin errores y el linkado con imgui_node_editor + SQLite tiene exito.
|
||||
# Es el check mas valioso: detecta regresiones de API en cualquiera de las
|
||||
# 19 funciones del registry que usa la app.
|
||||
- id: build
|
||||
cmd: "cmake --build /home/lucas/fn_registry/cpp/build/windows --target shaders_lab -j"
|
||||
timeout_s: 300
|
||||
severity: critical
|
||||
|
||||
# Verifica que el artefacto .exe existe tras el build.
|
||||
# Detecta casos donde cmake reporta exit 0 pero el linker no produjo binario
|
||||
# (muy raro con mingw-w64 pero ha ocurrido en builds parciales con -j).
|
||||
- id: binary_exists
|
||||
cmd: "test -f /home/lucas/fn_registry/cpp/build/windows/apps/shaders_lab/shaders_lab.exe"
|
||||
timeout_s: 5
|
||||
severity: critical
|
||||
|
||||
# Verifica que el .ico esta presente junto al .exe.
|
||||
# add_imgui_app genera shaders_lab_appicon.rc que windres incluye como recurso;
|
||||
# si el .ico falta el build pasa pero el .exe queda sin icono embebido
|
||||
# (visible al deploy a /mnt/c/.../Desktop/apps/).
|
||||
- id: icon_exists
|
||||
cmd: "test -f /home/lucas/fn_registry/apps/shaders_lab/appicon.ico"
|
||||
timeout_s: 5
|
||||
severity: warning
|
||||
Reference in New Issue
Block a user