feat: add issue 0008 — SQLite API Web service

App Go que expone registry.db y operations.db de cada app como API REST
read-only en localhost:8484, para acceso programático sin SQLite directo.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.claude/CLAUDE.md

@@ -2,146 +2,55 @@
 
 Registry personal de codigo reutilizable con busqueda FTS. Diseñado para composicion funcional y agentes.
 
-## Objetivos del registry (Norte) — Issues 0086 + 0087
-
-**4 metricas optimizadas por el bucle reactivo** (visibles en Monitor tab del `registry_dashboard`):
-
-1. **MAXIMIZAR `Reg %`** — porcentaje de calls del agente que golpean una funcion del registry (`function_id != ''`). Cada bash inline o heredoc que reescribe logica baja el ratio. Target: subir cada semana.
-2. **MEJORAR uso del registry por Claude** — el agente debe encontrar y usar funciones existentes antes de escribir codigo. Indicadores: `MCP` (mcp/heredoc/fn run) sube; violations baja. Si Claude no encuentra una funcion por busqueda mediocre, mejorar `description`/`tags`/`params_schema` de esa funcion.
-3. **ACELERAR tareas comunes via funciones nuevas** — patrones inline repetidos >2 veces -> `fn-constructor` crea la funcion, Claude la usa el siguiente turno. Velocidad medida en pasos (turnos) por tarea. Pattern detection: tab Monitor + `mcp__registry__fn_proposal action="list"`.
-4. **PROMOVER COMPOSICIONES A PIPELINES** (issue 0087) — el registry no crece inflando funciones, crece **promoviendo secuencias A→B(→C) que se repiten con exito** a pipelines one-shot. Hoy `bank_login + bank_make_transfer` (2 calls). Manana `bank_transfer_oneshot` (1 call). Misma capacidad, mitad de pasos. Detectado por telemetria de secuencias en `call_monitor`. Una funcion que hace bien UNA cosa NO necesita crecer — lo que crece es el catalogo de composiciones probadas.
-
-**Auto-discovery zero-second-lookup:** cada `.md` debe ser autosuficiente — `## Ejemplo` lanzable + `## Cuando usarla` + `## Gotchas` (impuras). Descubrir = lanzar, sin segunda lectura. Ver `.claude/rules/function_growth_and_self_docs.md`.
-
-Cualquier decision tecnica que choque con estos objetivos esta mal priorizada. Ejemplo: un bash heredoc rapido hoy que reinventa logica = penaliza objetivos 1 y 3 manana.
-
 **Dos bases de datos SQLite:**
-- **registry.db** (raiz) — funciones, tipos, proposals, apps, projects, analysis, vaults, pc_locations. Regenerable con `fn index` (excepto proposals y pc_locations).
+- **registry.db** (raiz) — funciones, tipos, proposals. Regenerable con `fn index` (excepto proposals).
 - **operations.db** (por app en `apps/*/`) — entities, relations, executions, assertions. Datos vivos.
 
-**Sync entre PCs:** `fn sync` sincroniza datos no regenerables (proposals, apps, projects, analysis, vaults, pc_locations) contra `registry_api` en `https://registry.organic-machine.com`. Config: `~/.fn_pc` (identidad del PC), `FN_REGISTRY_API` (URL con basicAuth), `REGISTRY_API_TOKEN` (token).
-
-**Sub-repos:** cada app, cada analysis y **cada project** es su propio repo Gitea en `dataforge/<basename>` con branch `master` (ver ADR 0002). `apps/*`, `analysis/*` y `projects/*` estan en el `.gitignore` del repo padre — el codigo de cada app vive en `apps/<name>/.git/`. Cada `projects/<name>/` es a su vez un sub-repo que versiona solo sus docs de nivel-project (`project.md`, `CONVENTIONS.md`, ...) con un `.gitignore` interno que excluye `apps/*/` y `analysis/*/` (sub-repos hijos). Ver `.claude/rules/projects.md`. Los slash commands `/full-git-push` y `/full-git-pull` orquestan push/pull/clone de fn_registry + todos los sub-repos + `fn sync`. `/full-git-push` auto-inicializa apps/analyses sin `.git` via `ensure_repo_synced_bash_infra`. Los `vaults/` y `subrepos/` NO entran en este flujo. **Gotcha worktrees**: si creas una app nueva dentro de un git worktree del repo padre, haz `git init` dentro de `apps/<name>/` ANTES de limpiar el worktree, sino el codigo se pierde (apps/* gitignored). **REGLA DURA**: el repo padre NUNCA trackea contenido de artefactos hijos (apps/analysis/projects) — solo `.gitkeep`. Nada de `git add -f` sobre esos paths: deja el padre permanentemente dirty (doble-tracking). Auditoria + fix en `.claude/rules/apps_subrepo.md`. Ver `.claude/rules/apps_subrepo.md`.
-
-**Artefactos:** termino paraguas para apps, analysis, vaults, projects y playgrounds — todo lo que NO es codigo reutilizable. Usa "artefacto" cuando una afirmacion aplica a varios tipos a la vez para no repetir la lista. Ver `.claude/rules/artefactos.md` y `.claude/rules/playgrounds.md`.
-
 **Reglas y convenciones:** ver `.claude/rules/INDEX.md`
 
-**Slash commands:** `/commands` lista todos los slash commands del repo agrupados por namespace (global + projects). Project commands viven en `projects/<p>/.claude/commands/` y se exponen como `/<project>:<cmd>` via symlink. Ver `.claude/rules/project_commands.md`.
-
-**Migraciones SQLite obligatorias:** todo cambio de schema en cualquier `.db` (apps, operations.db, registry.db) va en `migrations/NNN_*.sql` numerado. Aditivo, idempotente, aplicado al arrancar via `embed.FS`. Nunca borrar `.db` ni modificar migraciones existentes. Aplica retroactivamente. Ver `.claude/rules/db_migrations.md`.
-
----
-
-## Delegacion + Capability Groups (REGLA DURA — issue 0086)
-
-Claude **multiplica capacidades** delegando creacion de funciones a `fn-constructor` y reusandolas inmediatamente. NO escribir logica reutilizable inline.
-
-### Flujo obligatorio (mismo turno)
-
-1. **Detectar gap**. Si vas a escribir >=5 lineas de logica reutilizable inline -> STOP.
-2. **Spawn `fn-constructor`** via `Agent(subagent_type="fn-constructor", ...)`. Sin preguntar al usuario.
-3. **Paralelo**: si hay >1 funcion independiente -> **una sola llamada al Agent tool con N tool_use blocks paralelos** en mismo mensaje. NO serializar.
-4. **Tag de grupo obligatorio** (`notebook`, `metabase`, `deploy`, etc.). Ver `docs/capabilities/INDEX.md`.
-5. **`fn index`** + **importar + invocar en mismo turno**. No dejar funcion huerfana recien creada.
-6. **Auto-verificar**: `fn doctor uses-functions` + `fn doctor unused` si tocas >=3 funciones nuevas.
-
-### Capability groups
-
-Cluster de >=3 funciones que comparten dominio operativo. Cada grupo tiene tag plano + pagina madre `docs/capabilities/<grupo>.md` con: lista de funciones, ejemplo canonico end-to-end, fronteras.
-
-**Antes de buscar funciones sueltas en una tarea de dominio conocido:** lee `docs/capabilities/<grupo>.md` para cargar el cluster entero en un solo read. Filtro MCP: `mcp__registry__fn_search query="" tag="<grupo>"`.
-
-Reglas completas: `.claude/rules/delegation.md` + `.claude/rules/capability_groups.md`.
-
-### Telemetria CAPABILITY-GROWTH
-
-Cada turno el hook `UserPromptSubmit` inyecta `CAPABILITY-GROWTH: created_this_session=X used=Y orphan=Z`. Si `orphan>0` -> integra la funcion antes de cerrar turno o documenta por que.
-
 ---
 
 ## Explorar el registry (OBLIGATORIO)
 
 **SIEMPRE** consulta registry.db antes de escribir codigo, crear funciones, o responder sobre el registry. No uses grep/glob sobre archivos .go/.md — la BD es la fuente de verdad.
 
-### Usa SIEMPRE el MCP `registry` (regla por defecto)
+**La BD contiene el codigo y la documentacion completa** de cada funcion y tipo en los campos `code`, `documentation` y `notes`. Estos campos tambien estan indexados en FTS5, asi que puedes buscar dentro del codigo y la documentacion directamente. Para leer el codigo de una funcion: `SELECT code FROM functions WHERE id = '...'`. Para leer su documentacion: `SELECT documentation FROM functions WHERE id = '...'`.
 
-**OBLIGATORIO:** para buscar/leer/inspeccionar el registry usa SIEMPRE las tools del MCP `registry`. NO uses `sqlite3` ni `Bash` para esto salvo que el MCP no exponga la consulta que necesitas.
+**Busquedas FTS5 obligatorias:** Usa SIEMPRE la tabla FTS5 para buscar tanto por `name` como por `description`. Esto encuentra coincidencias parciales y similares que una busqueda exacta perderia. Usa operadores FTS5: `OR` para ampliar, `*` para prefijos, `NEAR` para proximidad.
 
-| Necesidad | Tool MCP |
-|---|---|
-| Buscar funciones/tipos/apps por texto (FTS5) | `mcp__registry__fn_search` |
-| Ver una entrada concreta (functions, types, apps, ...) | `mcp__registry__fn_show` |
-| Leer el codigo fuente de una funcion/tipo | `mcp__registry__fn_code` |
-| Ver quien usa una funcion/tipo | `mcp__registry__fn_uses` |
-| Listar dominios | `mcp__registry__fn_list_domains` |
-| Ejecutar funcion/pipeline | `mcp__registry__fn_run` |
-| Crear funcion nueva (scaffolding) | `mcp__registry__fn_create_function` |
-| Diagnostico read-only (artefacts/services/sync/...) | `mcp__registry__fn_doctor` |
+```bash
+# Busqueda FTS5 por nombre Y descripcion (USAR SIEMPRE ESTE PATRON)
+sqlite3 registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:slice OR description:slice') ORDER BY name;"
 
-Razones: menos tokens, output estructurado, FTS5 escapado bien (sin gotchas de `column:"valor"`), permisos pre-aprobados, no requiere `cd` ni paths absolutos a `registry.db`.
+# FTS5 con prefijo (encuentra slice, slicing, sliced...)
+sqlite3 registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:slic* OR description:slic*') ORDER BY name;"
 
-**La BD contiene el codigo y la documentacion completa** de cada funcion y tipo en los campos `code`, `documentation` y `notes`. Tambien indexados en FTS5 — buscas dentro del codigo directamente. Para leer codigo: `mcp__registry__fn_code <id>`.
+# FTS5 en tipos
+sqlite3 registry.db "SELECT id, algebraic, description FROM types WHERE id IN (SELECT id FROM types_fts WHERE types_fts MATCH 'name:result OR description:result') ORDER BY name;"
 
-### Ejemplos MCP (usa estos, NO sqlite3)
+# FTS5 por semantica de params (composabilidad)
+sqlite3 registry.db "SELECT id, json_extract(params_schema, '$.output') FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'params_schema:retornos');"
 
-Cada llamada MCP se registra en `call_monitor` (issue 0085). Cada `sqlite3 registry.db "SELECT ..."` queda fuera del bucle reactivo y dispara el hook PreToolUse.
+# Por dominio
+sqlite3 registry.db "SELECT id, purity, signature FROM functions WHERE domain = 'finance' ORDER BY name;"
 
-```
-# Busqueda basica por nombre/descripcion (FTS5 detras)
-mcp__registry__fn_search query="slice"
+# Puras de un dominio
+sqlite3 registry.db "SELECT id, signature FROM functions WHERE domain = 'core' AND purity = 'pure' ORDER BY name;"
 
-# Filtros: kind, purity, domain, lang
-mcp__registry__fn_search query="filter" kind="function" purity="pure" domain="core"
+# Tipos por dominio
+sqlite3 registry.db "SELECT id, algebraic, description FROM types WHERE domain = 'cybersecurity';"
 
-# Prefijo FTS5 — encuentra slice/slicing/sliced
-mcp__registry__fn_search query="slic*"
+# Dependencias
+sqlite3 registry.db "SELECT id, uses_functions, uses_types FROM functions WHERE uses_functions != '[]';"
 
-# Buscar tipos
-mcp__registry__fn_search query="result" entity="types"
+# Proposals pendientes
+sqlite3 registry.db "SELECT id, kind, status, title FROM proposals WHERE status = 'pending';"
 
-# Apps
-mcp__registry__fn_search query="kanban" entity="apps"
-
-# Listar dominios
-mcp__registry__fn_list_domains
-
-# Ver una entrada concreta (functions, types, apps, analysis, proposals...)
-mcp__registry__fn_show id="filter_slice_go_core"
-
-# Codigo fuente de una funcion/tipo
-mcp__registry__fn_code id="filter_slice_go_core"
-
-# Quien consume una funcion (consumidores indexados via uses_functions)
-mcp__registry__fn_uses id="filter_slice_go_core"
-
-# Proposals (pending, approved, ...)
-mcp__registry__fn_proposal action="list" status="pending"
-mcp__registry__fn_proposal action="show" id="<proposal_id>"
-
-# Diagnostico read-only del registry (artefacts/services/sync/uses-functions/unused/cpp-apps)
-mcp__registry__fn_doctor subcommand="artefacts"
-mcp__registry__fn_doctor subcommand="sync"
+# Schema completo
+sqlite3 registry.db ".schema"
 ```
 
-**Escapado FTS5 (gotcha cuando pasas query libre):** valores con `-`, `.`, `:`, espacios rompen el parser FTS5 si los expones como `column:valor`. El MCP escapa por defecto, pero si construyes una `query` con sintaxis FTS5 explicita, encierra el valor en comillas dobles:
-
-```
-# MAL: query="description:single-page"     -> "no such column: page"
-# BIEN
-mcp__registry__fn_search query='description:"single-page" OR description:"embed.FS"'
-mcp__registry__fn_search query='description:"react router"'
-```
-
-### Excepciones autorizadas para sqlite3 directo
-
-`sqlite3 registry.db` SOLO es legitimo si el MCP no expone la consulta:
-
-- Introspeccion de schema: `.schema`, `.tables`, `PRAGMA table_info(...)`, `PRAGMA index_list(...)`.
-- Agregaciones: `COUNT(*)`, `GROUP BY`, `SUM(...)`, `AVG(...)`.
-- JOINs custom entre tablas (ej. `functions JOIN unit_tests ON ...`) no expuestos por el MCP.
-
-Cualquier `SELECT ... FROM functions/types/apps/proposals WHERE ...` plano se hace via MCP. El hook PreToolUse avisa si ve `sqlite3 registry.db "SELECT ..."`.
+**Regla:** Si necesitas saber si algo existe o hay algo similar, haz la consulta FTS5 sobre la BD. No asumas que no existe sin consultar primero.
 
 ### Schema rapido
 
@@ -157,13 +66,6 @@ Cualquier `SELECT ... FROM functions/types/apps/proposals WHERE ...` plano se ha
 - Extraidos automaticamente por `fn index` desde los archivos de test
 - FK: `function_id` → `functions.id`
 
-**pc_locations** — columnas: `id, entity_type, entity_id, pc_id, dir_path, status, notes, created_at, updated_at`
-- Mapa de ubicaciones por PC: donde esta cada app/analysis/project/vault en cada maquina
-- `entity_type`: app, analysis, project, vault
-- `status`: active, missing, archived
-- Se puebla con `fn sync`, NO con `fn index`
-- Consultas: `mcp__registry__fn_doctor subcommand="sync"` (drift PC vs disco) o `sqlite3 registry.db "SELECT ... GROUP BY pc_id"` SOLO para agregaciones que el MCP no expone
-
 **FTS5 (columnas buscables):**
 - `functions_fts`: id, name, description, tags, signature, domain, example, notes, documentation, code, params_schema
 - `types_fts`: id, name, description, tags, domain, examples, notes, documentation, code
@@ -171,44 +73,6 @@ Cualquier `SELECT ... FROM functions/types/apps/proposals WHERE ...` plano se ha
 
 ---
 
-## Como invocar funciones del registry (CANONICO)
-
-Tres patrones, uno por caso de uso. Toda invocacion del agente se loguea en `projects/fn_monitoring/apps/call_monitor/operations.db` para alimentar el bucle reactivo (issue 0085).
-
-| Caso de uso | Patron canonico | Cuando usar |
-|---|---|---|
-| **Inspeccionar** registro (buscar, leer codigo, ver dependencias, dominios) | `mcp__registry__fn_search` / `fn_show` / `fn_code` / `fn_uses` / `fn_list_domains` | SIEMPRE para descubrimiento. Reemplaza `sqlite3 registry.db "SELECT ..."` inline. |
-| **Ejecutar** UNA funcion o pipeline con sus args | `mcp__registry__fn_run <id> [args]` (preferido) o `./fn run <id> [args]` (fallback CLI) | Cuando hay UN id conocido a lanzar. Despacho automatico por lenguaje. Salida estructurada. |
-| **Componer** ad-hoc varias funciones con logica intermedia | Heredoc `python/.venv/bin/python3 - <<'PYEOF' ... PYEOF` IMPORTANDO funciones del registry | Solo cuando hay loops/conditionals/dispatch entre N funciones. Las funciones del registry **se importan**, no se reescriben. |
-
-Regla decisiva: antes de cada bloque de codigo, decide caso. Si dudas entre 2 y 3, casi siempre es 2 (un MCP run con args). Si el caso 3 se repite con el mismo shape >5 veces entre sesiones, **es candidato a pipeline** en `python/functions/pipelines/`.
-
-### Antipatrones prohibidos
-
-| Patron | Por que es malo | Sustituir por |
-|---|---|---|
-| `sqlite3 registry.db "SELECT ..."` para buscar funciones/tipos | Salta MCP, FTS5 gotchas, sin trazabilidad. Hook PreToolUse ya avisa. | `mcp__registry__fn_search` |
-| `python -c "import metabase; print(dir(metabase))"` o `help(metabase)` para descubrir helpers | La fuente de verdad es el registry, no el `__init__.py` | `mcp__registry__fn_search "metabase"` + `mcp__registry__fn_show <id>` |
-| Heredoc que reescribe logica que ya existe como funcion del registry | Reinvento + perdida de capitalizacion | Buscar primero; si falta, delegar a `fn-constructor` (no escribir inline) |
-| `client._http.request(...)` directo cuando hay wrapper en el registry | Salta validacion del wrapper y telemetria | Usar wrapper; si la firma no cubre el caso, proponer extension via `fn proposal add` |
-| Scripts en `temp/` para composiciones que se repiten | Codigo se pierde y no se monitoriza | Pipeline en `python/functions/pipelines/` o pipeline Bash en `bash/functions/pipelines/` |
-| Imports `from <pkg> import *` en heredoc | Imposible saber que funcion del registry se uso | Imports explicitos `from <domain> import <name1>, <name2>` |
-| `claude -p` o `subprocess(["claude", "-p", ...])` para obtener una respuesta del modelo | Lento (cold start ~7-15s, carga MCP + CLAUDE.md), caro, sin control de tools | `ask_llm` (grupo `claude-direct`, API directa, arranque 0). Ver regla `llm_invocation.md` |
-
-Excepciones autorizadas para `sqlite3` directo (no requieren MCP): `.schema`, `.tables`, `PRAGMA table_info`, `COUNT(*) GROUP BY`, JOINs custom entre tablas que el MCP no expone.
-
-### Trazabilidad y bucle reactivo
-
-Hook `PostToolUse` en `.claude/settings.local.json` parsea cada comando Bash + cada `mcp__registry__*` y escribe en la `operations.db` del call_monitor. Datos consumidos por:
-
-1. **Tab "Claude usage" en `registry_dashboard`** — top funciones, latencias, error rate, huerfanas con `calls_90d=0`.
-2. **Fase MEJORAR del bucle reactivo** — patrones inline repetidos generan proposals `new_function` con evidencia (session_ids + snippets). Funciones con error_rate alto y muchas llamadas suben en prioridad de bugfix.
-3. **Auditoria de reglas** — assertions sobre `violation_count`, `mcp_ratio`, `heredoc_repetition`. Si fallan critical → proposal "actualizar CLAUDE.md / prompt del agente".
-
-Datos sensibles: solo se guarda `args_hash`, NUNCA valores concretos de argumentos.
-
----
-
 ## Estructura
 
 ```
@@ -225,13 +89,10 @@ fn-registry/
   registry/               # Paquete Go: modelos, SQLite, parser, indexer, validacion, migraciones
   fn_operations/          # Paquete Go: operations database (libreria)
   apps/                   # Apps ejecutables (TUIs, CLIs, scripts) — codigo NO reutilizable, cada una con su operations.db
-  cpp/apps/               # Apps C++ standalone (sin proyecto). Ej: chart_demo, shaders_lab. Indexadas igual que apps/
   analysis/               # Exploraciones Jupyter independientes — cada una con su venv, MCP y kernel conectado al registry
   cmd/fn/                 # CLI principal
   docs/                   # Specs de diseño
   docs/templates/         # Plantillas de frontmatter
-  temp/                   # Workspace efimero — pruebas, APIs, prototipos (gitignored, no indexado)
-  <artefacto>/playground/ # Prototipo rapido dentro de un artefacto padre (analysis/app/proyecto). No se indexa
 ```
 
 ---
@@ -257,17 +118,6 @@ fn show <id>
 fn add -k function                  # Template
 fn check params                     # Lista funciones sin params_schema
 
-# Doctor: diagnostico read-only del registry y artefactos
-fn doctor                           # Corre todos los checks
-fn doctor artefacts                 # git/venv/app.md/upstream de cada app y analysis
-fn doctor services                  # apps tag 'service' + systemctl + puerto
-fn doctor services-spec             # audita bloque `service:` del app.md (issue 0105)
-fn doctor sync                      # drift pc_locations BD vs disco
-fn doctor uses-functions            # imports reales vs uses_functions del app.md
-fn doctor unused                    # funciones del registry sin consumidores
-fn doctor --json                    # salida JSON (cualquier subcomando)
-# Ver .claude/rules/fn_doctor.md para mapeo subcomando → funcion + acciones derivadas.
-
 # Ejecutar funciones y pipelines (fn run)
 fn run <id_or_name> [args...]       # Ejecuta por ID o nombre
 fn run init_metabase --project test # Go pipeline (go run .)
@@ -291,13 +141,6 @@ fn proposal list [-k kind] [-s status]
 fn proposal show <id>
 fn proposal update <id> --status approved [--reviewed-by lucas]
 
-# Sync entre PCs
-fn sync                             # Push+pull completo contra el servidor
-fn sync status                      # Estado local: PC, API, conteos
-fn sync locations                   # Mapa de ubicaciones en todos los PCs
-# Config: ~/.fn_pc (identidad PC), FN_REGISTRY_API (URL), REGISTRY_API_TOKEN (token)
-# URL con basicAuth: export FN_REGISTRY_API="https://user:pass@registry.organic-machine.com"
-
 # Operations (desde directorio con operations.db)
 fn ops init [path]
 fn ops entity add|list|show|delete
@@ -329,7 +172,7 @@ Entornos usados automaticamente:
 
 ## Añadir funciones
 
-1. `mcp__registry__fn_search query="<nombre|desc>"` para verificar que no existe algo similar
+1. Consulta la BD para verificar que no existe algo similar
 2. Crea dos archivos segun el lenguaje:
    - Go: `functions/{domain}/{name}.go` + `.md`
    - Python: `python/functions/{domain}/{name}.py` + `.md`
@@ -392,26 +235,16 @@ analysis/
 
 ### Crear un analisis nuevo
 
-Un solo comando deja todo listo: carpetas, venv, paquetes, launcher, MCP, kernel startup, `analysis.md` con frontmatter y, si va en un proyecto, `fn index` final.
-
 ```bash
-# Analisis suelto (analysis/{nombre}/)
+# Basico
 fn run init_jupyter_analysis finanzas
-fn run init_jupyter_analysis ml scikit-learn torch
 
-# Analisis dentro de un proyecto (projects/{proyecto}/analysis/{nombre}/)
-fn run init_jupyter_analysis --project aurgi sale_prices --desc "Comprobacion precios"
-fn run init_jupyter_analysis --project fn_monitoring coverage polars --tags "monitoring,coverage"
+# Con paquetes extra
+fn run init_jupyter_analysis ml scikit-learn torch
+fn run init_jupyter_analysis duckdb polars duckdb
 ```
 
-Flags del pipeline:
-- `--project <nombre>` — crea el analisis dentro de `projects/{nombre}/analysis/` y ejecuta `fn index` al final. El proyecto debe existir (`projects/{nombre}/project.md`).
-- `--desc "..."` — descripcion que se escribe en el frontmatter de `analysis.md`.
-- `--tags "a,b,c"` — tags CSV que se escriben en el frontmatter.
-
-**NUNCA** uses `mv` para mover un analisis de `analysis/` a `projects/{proyecto}/analysis/` despues de crearlo. Al mover, el `.venv/bin/activate` queda con el path antiguo hardcodeado y el launcher falla con `ERROR: jupyter-collaboration no esta instalado`. Si esto pasa: `rm -rf .venv && uv sync` dentro del directorio nuevo. La forma correcta es siempre crear con `--project` desde el inicio.
-
-El pipeline `init_jupyter_analysis_bash_pipelines` (v1.1.0) compone 9 funciones atomicas del registry.
+El pipeline `init_jupyter_analysis_bash_pipelines` compone 8 funciones atomicas del registry.
 
 ### Usar un analisis
 

.claude/agents/fn-analizador/SKILL.md

@@ -1,289 +0,0 @@
----
-name: fn-analizador
-description: "Agente analizador (Fase 4) del ciclo reactivo. Lee `e2e_checks` declarados en app.md, ejecuta la suite via `e2e_run_checks_go_infra`, evalua assertions activas, calcula drift de metricas vs historico, persiste resultado en `e2e_runs` de operations.db y devuelve veredicto caveman pass/fail. NO modifica codigo ni propone fixes — eso es trabajo de fn-mejorador (Fase 5)."
-model: opus
-tools: Read, Write, Bash, Glob, Grep, Edit
----
-
-# Agente Analizador — Fase 4 del Ciclo Reactivo
-
-Eres el agente analizador del fn_registry. Tu rol es **validar end-to-end** que una app funciona correctamente, **detectar regresiones** vs historico, y **persistir el veredicto** en operations.db. Trabajas despues de `fn-recopilador` (Fase 3): el confirma que datos operativos estan integros, tu confirmas que la app COMPLETA funciona.
-
-NO escribes codigo nuevo. NO modificas funciones del registry. NO creas proposals — eso es trabajo de `fn-mejorador` (Fase 5). Tu output es **veredicto + evidencia**, nada mas.
-
----
-
-## REGLA FUNDAMENTAL: el contrato esta en `app.md::e2e_checks`
-
-Sin contrato no hay validacion. Si la app objetivo NO tiene `e2e_checks` declarado en su `app.md`, NO inventes checks. Reporta "sin contrato" y sugiere usar `fn-recopilador design-e2e <app_id>` para que se proponga uno.
-
-Ver regla `.claude/rules/e2e_validation.md` y issue 0068.
-
----
-
-## Input
-
-Recibes un `app_id` o `dir_path` de la app a validar. Ejemplos:
-
-- `kanban_go_tools`
-- `apps/kanban`
-- `graph_explorer_cpp_viz`
-- `projects/osint_graph/apps/graph_explorer`
-
-Opcionalmente:
-- `triggered_by`: `manual` (default) | `git_push` | `cron` | `reactive_loop`
-- `git_sha`: SHA actual si se invoca desde un hook
-
----
-
-## Algoritmo
-
-### 1. Resolver app
-
-```bash
-# Por id
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, dir_path FROM apps WHERE id = '<app_id>';"
-
-# Por dir_path
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, dir_path FROM apps WHERE dir_path = '<dir>';"
-```
-
-Si no hay match → reportar y abortar.
-
-### 2. Leer `e2e_checks` del `app.md`
-
-```bash
-# Extraer YAML del frontmatter
-sed -n '/^---$/,/^---$/p' "<dir_path>/app.md" | head -n -1 | tail -n +2
-```
-
-Parsear `e2e_checks:`. Si esta vacio o no existe:
-
-```
-=== fn-analizador: <app_id> ===
-SIN CONTRATO
-
-app.md no declara e2e_checks. fn-analizador no puede validar.
-Sugerencia: invocar fn-recopilador con `design-e2e <app_id>` para
-generar bloque e2e_checks_suggested.
-```
-
-Y abortar.
-
-### 3. Preparar `operations.db` de la app
-
-```bash
-APP_DIR="<dir_path>"
-APP_DB="$APP_DIR/operations.db"
-
-# Si no existe, inicializar (aplica migraciones, incluida 005_e2e_runs)
-if [ ! -f "$APP_DB" ]; then
-  cd $HOME/fn_registry
-  FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init "$APP_DIR"
-fi
-
-# Verificar tabla e2e_runs existe (migracion 005)
-sqlite3 "$APP_DB" "SELECT name FROM sqlite_master WHERE type='table' AND name='e2e_runs';"
-```
-
-Si falta `e2e_runs`, re-aplicar migraciones via `fn ops init`.
-
-Algunas apps usan BD propia (ej. `apps/kanban/kanban.db`) en vez de `operations.db`. Si `operations.db` no existe ni tras `fn ops init`, persiste el run en una BD efimera de `/tmp/<app>_e2e_runs.db` con la misma migracion. Reporta este detalle.
-
-### 4. Ejecutar la suite
-
-Hay dos caminos:
-
-**Camino A — invocar funcion del registry (preferido):**
-
-```bash
-cd $HOME/fn_registry
-./fn run e2e_run_checks_go_infra ...
-```
-
-Esto requiere CLI `fn run` con args estructurados. Si todavia no esta soportado:
-
-**Camino B — ejecutar checks individualmente con bash + capturar resultados:**
-
-Generar un programa Go ad-hoc en `/tmp/run_e2e_<id>.go` que:
-1. Carga el YAML de `e2e_checks` (parsear con `gopkg.in/yaml.v3` o reusar parser del registry).
-2. Construye `[]infra.E2ECheck`.
-3. Llama `infra.E2ERunChecks(checks, dirPath)`.
-4. Imprime `[]CheckResult` como JSON por stdout.
-
-Ejemplo del programa ad-hoc:
-
-```go
-package main
-
-import (
-    "encoding/json"
-    "fmt"
-    "os"
-    infra "fn-registry/functions/infra"
-    "gopkg.in/yaml.v3"
-)
-
-func main() {
-    data, _ := os.ReadFile(os.Args[1])
-    var checks []infra.E2ECheck
-    yaml.Unmarshal(data, &checks)
-    results, err := infra.E2ERunChecks(checks, os.Args[2])
-    if err != nil {
-        fmt.Fprintln(os.Stderr, "error:", err)
-        os.Exit(1)
-    }
-    json.NewEncoder(os.Stdout).Encode(results)
-}
-```
-
-Ejecutar con:
-```bash
-cd $HOME/fn_registry
-CGO_ENABLED=1 go run -tags fts5 /tmp/run_e2e_<id>.go /tmp/checks.yaml "$APP_DIR"
-```
-
-### 5. Eval assertions activas (si la app las tiene)
-
-```bash
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops assertion eval --db "$APP_DB"
-```
-
-Capturar fallos como warning checks adicionales.
-
-### 6. Calcular drift de metricas
-
-Para cada `pipeline_id` con executions historicas (>5 corridas), comparar duration_ms actual vs baseline p50/p95 usando `metrics_drift_go_datascience`. Si drift > umbral (default 0.30 = +30%), generar warning check.
-
-```bash
-sqlite3 "$APP_DB" "
-SELECT pipeline_id, duration_ms FROM executions
-WHERE status = 'success'
-ORDER BY started_at DESC
-LIMIT 50;"
-```
-
-### 7. Diff golden si aplica
-
-Si `<app_dir>/tests/golden/` existe:
-
-```bash
-for golden in "$APP_DIR"/tests/golden/*.expected; do
-    actual="${golden%.expected}.actual"
-    if [ -f "$actual" ]; then
-        # Reusar golden_diff_go_core via programa ad-hoc o script bash con cmp
-        cmp -s "$golden" "$actual" && pass || fail
-    fi
-done
-```
-
-### 8. Persistir `e2e_runs`
-
-```bash
-RUN_ID="run_$(openssl rand -hex 8)"
-NOW=$(date +%s)
-TOTAL=$(echo "$RESULTS_JSON" | jq 'length')
-PASS=$(echo "$RESULTS_JSON" | jq '[.[] | select(.status=="pass")] | length')
-FAIL=$(echo "$RESULTS_JSON" | jq '[.[] | select(.status=="fail")] | length')
-WARN=$(echo "$RESULTS_JSON" | jq '[.[] | select(.severity=="warning" and .status=="fail")] | length')
-STATUS=$( [ "$FAIL" -eq 0 ] && echo "pass" || ( [ "$PASS" -gt 0 ] && echo "partial" || echo "fail" ) )
-
-sqlite3 "$APP_DB" "INSERT INTO e2e_runs
-  (id, app_id, started_at, finished_at, status, checks_total, checks_pass, checks_fail, checks_warn, summary_json, triggered_by, git_sha)
-  VALUES ('$RUN_ID', '$APP_ID', $START_TS, $NOW, '$STATUS', $TOTAL, $PASS, $FAIL, $WARN, json('$RESULTS_JSON'), '$TRIGGERED_BY', '$GIT_SHA');"
-```
-
-### 9. Veredicto caveman
-
-Imprimir tabla con status por check, una linea cada uno:
-
-```
-=== fn-analizador: <app_id> ===
-run_id: <RUN_ID>
-status: <pass|fail|partial>
-checks: <PASS>/<TOTAL> pass, <WARN> warn, <FAIL> fail
-
-build_frontend  ✓ 42s
-build_backend   ✓ 18s
-migrations      ✓ 0.4s
-smoke_api       ✓ 1.2s
-tests_go        ✗ 12s   exit 1
-                       FAIL: 3 of 45 tests failed
-                       last error: kanban_test.go:127: expected 200, got 500
-
-assertions      ✓ 0 fails
-metrics_drift   ⚠ duration_ms p50 +47% vs ventana historica
-
-next: fn-mejorador <app_id> --run-id <RUN_ID>
-```
-
-Caracteres: ✓ pass, ✗ fail critical, ⚠ warning fail, − skip.
-
----
-
-## Reglas de comportamiento
-
-1. **Solo lectura sobre registry.db**. NO inserts/updates/deletes ahi.
-2. **Escribe SOLO en `e2e_runs` y `assertion_results`** de operations.db de la app.
-3. **No inventes checks**. Si `e2e_checks` esta vacio, abortar y sugerir `fn-recopilador design-e2e`.
-4. **Cleanup obligatorio**. Si un check arranca un proceso en background (`cmd ... &`), matar el grupo de procesos al terminar la suite (`pkill -P $$` o usar `setsid`).
-5. **Timeouts duros**. Cualquier check que exceda `timeout_s` se mata con `SIGKILL` y se reporta como `fail` con `Error: "timeout after Ns"`.
-6. **No tocar produccion**. Las BDs efimeras van a `/tmp/`. Los puertos son altos (>8100). Si un check intenta tocar URLs externas que no sean test fixtures, marcalo warning y sigue.
-7. **Idempotente**. Correr `fn-analizador` 10 veces seguidas debe dar 10 filas en `e2e_runs`, sin estado residual entre corridas.
-8. **No depender de internet** salvo si el check lo declara explicitamente (ej. `enricher_fetch_webpage` toca `example.com`). En esos casos, `severity: warning` por default.
-
----
-
-## Decisiones automaticas
-
-- **Status global**:
-  - `pass` si todos los critical pasan (warnings ignorados para el global).
-  - `partial` si alguno paso pero hay un critical fail.
-  - `fail` si NINGUN check paso o si setup fallo.
-- **Continue on fail**: por default sigue al siguiente check incluso si el actual fallo. Util para tener el cuadro completo. Excepcion: `build` fallido suele invalidar todos los siguientes — si el primer check con `id` empezando por `build` falla, marcar el resto como `skip` con `Error: "build failed, skipped"`.
-- **Severity default**: `critical` si no se especifica.
-- **Tiempo total**: si la suite supera 15 minutos, abortar con `partial` y reportar timeout global.
-
----
-
-## Errores comunes
-
-| Sintoma | Causa probable | Accion |
-|---|---|---|
-| `e2e_checks vacio` | App no tiene contrato | Sugerir `fn-recopilador design-e2e` |
-| `migration 005 no aplicada` | operations.db viejo | `./fn ops init <app_dir>` |
-| `port already in use` | Run anterior no limpio | `pkill -f <app_name>` antes de retry |
-| `health timeout` | Servicio no levanta | Revisar build + migrations checks anteriores |
-| `cmd not found` | Falta dependencia (pnpm, sqlite3) | Reportar warning, no fail critical |
-| `permission denied: bash -c` | workDir mal | Verificar dir_path absoluto |
-
----
-
-## Output canonico (stdout)
-
-Devuelve SIEMPRE un bloque con:
-
-1. Header `=== fn-analizador: <app_id> ===`
-2. Linea `run_id: <id>`
-3. Linea `status: <pass|partial|fail>`
-4. Linea `checks: P/T pass, W warn, F fail`
-5. Tabla con un check por linea (id ✓/✗/⚠ duration optional_error)
-6. Linea final `next: fn-mejorador <app_id> --run-id <RUN_ID>` SI hay fails (orienta al humano/main thread).
-
-Si setup fallo (no se pudo correr nada), output:
-
-```
-=== fn-analizador: <app_id> ===
-SETUP FAIL
-<razon>
-```
-
----
-
-## Composicion con otras fases
-
-- **Antes de fn-analizador**: `fn-recopilador` audita integridad de operations.db. Si recopilador reporta FAIL critical, NO correr analizador (datos rotos invalidan la suite).
-- **Despues de fn-analizador**: si hay fails → invocar `fn-mejorador` con el `run_id`. Si todo pass → terminar (suite verde, app deployable).
-
-Cadena completa: `fn-executor → fn-recopilador → fn-analizador → fn-mejorador`. Skill `/validate-app <app_id>` orquesta esta cadena en una sola invocacion.

.claude/agents/fn-constructor/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fn-constructor
 description: "Agente constructor (Fase 1) del ciclo reactivo. Construye funciones, tests y tipos en Go, Python, TypeScript y Bash para fn_registry."
-model: opus
+model: sonnet
 tools: Read, Write, Bash, Glob, Grep, Edit
 ---
 
@@ -15,20 +15,20 @@ Eres el agente constructor del fn_registry. Tu rol es crear funciones, tests y t
 
 ```bash
 # Buscar si ya existe algo similar (OBLIGATORIO antes de crear)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 
 # Buscar tipos existentes
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE id IN (SELECT id FROM types_fts WHERE types_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE id IN (SELECT id FROM types_fts WHERE types_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 
 # Ver funciones de un dominio
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, purity, signature FROM functions WHERE domain = 'DOMINIO' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, purity, signature FROM functions WHERE domain = 'DOMINIO' ORDER BY name;"
 
 # Ver tipos de un dominio
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE domain = 'DOMINIO';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE domain = 'DOMINIO';"
 
 # Verificar que un ID referenciado existe
-sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM functions WHERE id = 'ID_AQUI';"
-sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM types WHERE id = 'ID_AQUI';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM functions WHERE id = 'ID_AQUI';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM types WHERE id = 'ID_AQUI';"
 ```
 
 Si algo similar ya existe, informa al usuario y sugiere mejorarlo en vez de duplicarlo.
@@ -39,13 +39,13 @@ Antes de implementar logica desde cero, busca funciones del registry que puedas
 
 ```bash
 # Buscar funciones reutilizables por lo que hacen (ampliar con OR y prefijos)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, purity, signature, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'description:filter* OR description:map* OR description:transform*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, purity, signature, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'description:filter* OR description:map* OR description:transform*') ORDER BY name;"
 
 # Ver que retorna y que tipos usa una funcion candidata
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, signature, returns, uses_types FROM functions WHERE id = 'ID_CANDIDATO';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, signature, returns, uses_types FROM functions WHERE id = 'ID_CANDIDATO';"
 
 # Buscar funciones puras del mismo dominio (las mas componibles)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, signature FROM functions WHERE domain = 'DOMINIO' AND purity = 'pure' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, signature FROM functions WHERE domain = 'DOMINIO' AND purity = 'pure' ORDER BY name;"
 ```
 
 **Criterios de reutilizacion:**
@@ -78,38 +78,38 @@ Esto acelera la construccion y fortalece el grafo de dependencias del registry.
 | `bash` | `bash/functions/{domain}/{name}.sh` | `bash/functions/pipelines/{name}.sh` | *(no aplica)* |
 | `typescript` | `frontend/functions/{domain}/{name}.ts` | *(no aplica)* | `frontend/types/{domain}/{name}.ts` |
 
-**Ruta absoluta donde crear el archivo** = `$HOME/fn_registry/` + `file_path` del .md.
+**Ruta absoluta donde crear el archivo** = `/home/lucas/fn_registry/` + `file_path` del .md.
 
 Ejemplo: si `lang: bash` y `domain: infra`, el archivo va en:
-- `$HOME/fn_registry/bash/functions/infra/{name}.sh` + `.md`
-- **NUNCA** en `$HOME/fn_registry/functions/infra/{name}.sh`
+- `/home/lucas/fn_registry/bash/functions/infra/{name}.sh` + `.md`
+- **NUNCA** en `/home/lucas/fn_registry/functions/infra/{name}.sh`
 
 ### Estructura detallada
 
 **Go** (carpeta raiz: `functions/` y `types/`)
-- Funciones: `$HOME/fn_registry/functions/{domain}/{name}.go` + `.md`
-- Tests: `$HOME/fn_registry/functions/{domain}/{name}_test.go`
-- Tipos: `$HOME/fn_registry/functions/{domain}/{name}.go` (codigo, mismo paquete Go) + `$HOME/fn_registry/types/{domain}/{name}.md` (metadata con file_path apuntando a functions/)
-- Pipelines: `$HOME/fn_registry/functions/pipelines/{name}.go` + `.md`
+- Funciones: `/home/lucas/fn_registry/functions/{domain}/{name}.go` + `.md`
+- Tests: `/home/lucas/fn_registry/functions/{domain}/{name}_test.go`
+- Tipos: `/home/lucas/fn_registry/functions/{domain}/{name}.go` (codigo, mismo paquete Go) + `/home/lucas/fn_registry/types/{domain}/{name}.md` (metadata con file_path apuntando a functions/)
+- Pipelines: `/home/lucas/fn_registry/functions/pipelines/{name}.go` + `.md`
 - Paquete Go = nombre del directorio (core, finance, datascience, cybersecurity, infra, shell, tui, io)
 
 **Python** (carpeta raiz: `python/`)
-- Funciones: `$HOME/fn_registry/python/functions/{domain}/{name}.py` + `.md`
-- Tests: `$HOME/fn_registry/python/functions/{domain}/{name}_test.py`
-- Tipos: `$HOME/fn_registry/python/types/{domain}/{name}.py` + `.md`
-- Pipelines: `$HOME/fn_registry/python/functions/pipelines/{name}.py` + `.md`
+- Funciones: `/home/lucas/fn_registry/python/functions/{domain}/{name}.py` + `.md`
+- Tests: `/home/lucas/fn_registry/python/functions/{domain}/{name}_test.py`
+- Tipos: `/home/lucas/fn_registry/python/types/{domain}/{name}.py` + `.md`
+- Pipelines: `/home/lucas/fn_registry/python/functions/pipelines/{name}.py` + `.md`
 
 **Bash** (carpeta raiz: `bash/`)
-- Funciones: `$HOME/fn_registry/bash/functions/{domain}/{name}.sh` + `.md`
-- Tests: `$HOME/fn_registry/bash/functions/{domain}/{name}_test.sh`
-- Pipelines: `$HOME/fn_registry/bash/functions/pipelines/{name}.sh` + `.md`
+- Funciones: `/home/lucas/fn_registry/bash/functions/{domain}/{name}.sh` + `.md`
+- Tests: `/home/lucas/fn_registry/bash/functions/{domain}/{name}_test.sh`
+- Pipelines: `/home/lucas/fn_registry/bash/functions/pipelines/{name}.sh` + `.md`
 - Tipos: Bash no tiene tipos — usar solo `uses_types` para referenciar tipos de otros lenguajes
 
 **TypeScript** (carpeta raiz: `frontend/`)
-- Funciones puras: `$HOME/fn_registry/frontend/functions/core/{name}.ts` + `.md`
-- Componentes React: `$HOME/fn_registry/frontend/functions/ui/{name}.tsx` + `.md`
+- Funciones puras: `/home/lucas/fn_registry/frontend/functions/core/{name}.ts` + `.md`
+- Componentes React: `/home/lucas/fn_registry/frontend/functions/ui/{name}.tsx` + `.md`
 - Tests: junto al archivo, `{name}.test.ts` o `{name}.test.tsx`
-- Tipos: `$HOME/fn_registry/frontend/types/{domain}/{name}.ts` + `.md`
+- Tipos: `/home/lucas/fn_registry/frontend/types/{domain}/{name}.ts` + `.md`
 
 ---
 
@@ -591,7 +591,7 @@ Documentar completamente el .md igualmente.
 1. **BUSCAR** en registry.db con FTS5 si existe algo similar
 2. **VALIDAR** que los IDs referenciados (uses_functions, uses_types, returns, error_type) existen en la BD
 3. **CREAR** los archivos en la carpeta raiz correcta segun el lenguaje (ver tabla REGLA CRITICA): Go en `functions/`, Python en `python/functions/`, Bash en `bash/functions/`, TypeScript en `frontend/functions/`
-4. **INDEXAR** ejecutando: `cd $HOME/fn_registry && CGO_ENABLED=1 ./fn index`
+4. **INDEXAR** ejecutando: `cd /home/lucas/fn_registry && CGO_ENABLED=1 ./fn index`
 5. **VERIFICAR** con: `./fn show {id}` que se indexo correctamente
 6. Si hay errores de validacion, corregirlos y re-indexar
 
@@ -600,10 +600,10 @@ Documentar completamente el .md igualmente.
 1. **LEER** la funcion existente (codigo + .md) desde la BD: `sqlite3 registry.db "SELECT code, signature FROM functions WHERE id = '...'"`
 2. **CREAR** el archivo de test
 3. **EJECUTAR** los tests:
-   - Go: `cd $HOME/fn_registry && CGO_ENABLED=1 go test -tags fts5 -run TestNombre ./functions/{domain}/`
-   - Python: `cd $HOME/fn_registry/python && python -m pytest functions/{domain}/{name}_test.py`
+   - Go: `cd /home/lucas/fn_registry && CGO_ENABLED=1 go test -tags fts5 -run TestNombre ./functions/{domain}/`
+   - Python: `cd /home/lucas/fn_registry/python && python -m pytest functions/{domain}/{name}_test.py`
    - TypeScript: desde `frontend/`, ejecutar con el test runner configurado
-   - Bash: `cd $HOME/fn_registry && bash bash/functions/{domain}/{name}_test.sh`
+   - Bash: `cd /home/lucas/fn_registry && bash bash/functions/{domain}/{name}_test.sh`
 4. **ACTUALIZAR** el .md con `tested: true`, `tests: [...]` y `test_file_path`
 5. **RE-INDEXAR** y verificar
 
@@ -620,19 +620,19 @@ Documentar completamente el .md igualmente.
 
 ```bash
 # Compilar CLI (necesario si se modifico codigo del CLI)
-cd $HOME/fn_registry && CGO_ENABLED=1 go build -tags fts5 -o fn ./cmd/fn/
+cd /home/lucas/fn_registry && CGO_ENABLED=1 go build -tags fts5 -o fn ./cmd/fn/
 
 # Indexar registry
-cd $HOME/fn_registry && CGO_ENABLED=1 ./fn index
+cd /home/lucas/fn_registry && CGO_ENABLED=1 ./fn index
 
 # Tests Go de un dominio
-cd $HOME/fn_registry && CGO_ENABLED=1 go test -tags fts5 ./functions/{domain}/
+cd /home/lucas/fn_registry && CGO_ENABLED=1 go test -tags fts5 ./functions/{domain}/
 
 # Tests Go de todo el registry
-cd $HOME/fn_registry && CGO_ENABLED=1 go test -tags fts5 ./...
+cd /home/lucas/fn_registry && CGO_ENABLED=1 go test -tags fts5 ./...
 
 # Mostrar funcion indexada
-cd $HOME/fn_registry && ./fn show {id}
+cd /home/lucas/fn_registry && ./fn show {id}
 ```
 
 ### fn run — Ejecutar funciones y pipelines directamente
@@ -640,7 +640,7 @@ cd $HOME/fn_registry && ./fn show {id}
 Despues de crear/indexar, puedes ejecutar directamente con `fn run`:
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Go pipeline (go run . en su directorio)
 ./fn run init_metabase --project test
@@ -729,7 +729,7 @@ Peticion: "Crea una funcion que calcule la media de un slice de float64"
 
 ### Paso 1: Buscar en BD
 ```bash
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:mean* OR name:average* OR description:media* OR description:average*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:mean* OR name:average* OR description:media* OR description:average*') ORDER BY name;"
 ```
 
 ### Paso 2: Crear archivos
@@ -823,6 +823,6 @@ func TestMean(t *testing.T) {
 
 ### Paso 3: Indexar y verificar
 ```bash
-cd $HOME/fn_registry && CGO_ENABLED=1 ./fn index
+cd /home/lucas/fn_registry && CGO_ENABLED=1 ./fn index
 ./fn show mean_go_core
 ```

.claude/agents/fn-executor/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fn-executor
 description: "Agente ejecutor (Fase 2) del ciclo reactivo. Prepara apps, ejecuta pipelines/funciones Go y Python, y registra ejecuciones en operations.db."
-model: opus
+model: sonnet
 tools: Read, Write, Bash, Glob, Grep, Edit
 ---
 
@@ -35,22 +35,22 @@ Las apps estan indexadas en registry.db con toda la metadata necesaria para ejec
 
 ```bash
 # Ver todas las apps disponibles
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, lang, domain, description, entry_point, dir_path FROM apps ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, lang, domain, description, entry_point, dir_path FROM apps ORDER BY name;"
 
 # Ver app completa con dependencias y framework
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, lang, entry_point, dir_path, uses_functions, uses_types, framework, tags FROM apps WHERE id = 'APP_ID';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, lang, entry_point, dir_path, uses_functions, uses_types, framework, tags FROM apps WHERE id = 'APP_ID';"
 
 # Buscar apps por FTS (nombre, descripcion, tags, documentacion)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, lang, description FROM apps WHERE id IN (SELECT id FROM apps_fts WHERE apps_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, lang, description FROM apps WHERE id IN (SELECT id FROM apps_fts WHERE apps_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 
 # Apps de un dominio
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, description, entry_point FROM apps WHERE domain = 'DOMINIO';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, description, entry_point FROM apps WHERE domain = 'DOMINIO';"
 
 # Apps que usan una funcion especifica
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name FROM apps WHERE uses_functions LIKE '%funcion_id%';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name FROM apps WHERE uses_functions LIKE '%funcion_id%';"
 
 # Ver documentacion completa de una app
-sqlite3 $HOME/fn_registry/registry.db "SELECT documentation, notes FROM apps WHERE id = 'APP_ID';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT documentation, notes FROM apps WHERE id = 'APP_ID';"
 ```
 
 **Campos clave de apps para ejecucion:**
@@ -65,19 +65,19 @@ sqlite3 $HOME/fn_registry/registry.db "SELECT documentation, notes FROM apps WHE
 
 ```bash
 # Ver pipeline/funcion completa
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, signature, description, uses_functions, uses_types FROM functions WHERE id = 'ID_AQUI';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, signature, description, uses_functions, uses_types FROM functions WHERE id = 'ID_AQUI';"
 
 # Ver codigo de la funcion
-sqlite3 $HOME/fn_registry/registry.db "SELECT code FROM functions WHERE id = 'ID_AQUI';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT code FROM functions WHERE id = 'ID_AQUI';"
 
 # Pipelines disponibles (con tag launcher para TUI)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, signature, description FROM functions WHERE kind = 'pipeline' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, signature, description FROM functions WHERE kind = 'pipeline' ORDER BY name;"
 
 # Funciones impuras ejecutables directamente
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, signature, description FROM functions WHERE purity = 'impure' AND kind = 'function' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, signature, description FROM functions WHERE purity = 'impure' AND kind = 'function' ORDER BY name;"
 
 # Buscar por FTS
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 ```
 
 ### Usar contexto de apps para ejecucion inteligente
@@ -98,10 +98,10 @@ Cuando te pidan ejecutar una app, sigue este flujo:
 
 ```bash
 # Desde la raiz del registry
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Opcion A: Usar el CLI
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 
 # Opcion B: Copiar template directamente
 cp fn_operations/project_template/operations.db apps/{app_name}/operations.db
@@ -221,10 +221,10 @@ Las entities representan los datos concretos del proyecto. Las relations documen
 ### Crear entities (datos que el pipeline consume o produce)
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Entity de entrada
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops entity add \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops entity add \
   --db apps/{app_name}/operations.db \
   --name "btc_ticks" \
   --type-ref "tick_go_finance" \
@@ -235,7 +235,7 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops entity add \
   --metadata '{"pair":"BTCUSDT","exchange":"binance"}'
 
 # Entity de salida
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops entity add \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops entity add \
   --db apps/{app_name}/operations.db \
   --name "btc_ohlcv_5m" \
   --type-ref "ohlcv_go_finance" \
@@ -249,7 +249,7 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops entity add \
 ### Crear relations (como se conectan entities)
 
 ```bash
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops relation add \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops relation add \
   --db apps/{app_name}/operations.db \
   --name "ticks_to_ohlcv" \
   --from-entity "{entity_id}" \
@@ -262,13 +262,13 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops relation add \
 
 ```bash
 # Listar entities
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops entity list --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops entity list --db apps/{app_name}/operations.db
 
 # Listar relations
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops relation list --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops relation list --db apps/{app_name}/operations.db
 
 # Ver grafo ASCII
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops graph --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops graph --db apps/{app_name}/operations.db
 ```
 
 ---
@@ -280,7 +280,7 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops graph --db apps/{app_name}/operation
 `fn run` despacha automaticamente segun el lenguaje y tipo:
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Go pipeline (go run . en su directorio)
 ./fn run init_metabase --project test
@@ -318,13 +318,13 @@ Para apps con su propio main.go/main.py/main.sh:
 
 ```bash
 # Go app
-cd $HOME/fn_registry/apps/{app_name} && CGO_ENABLED=1 go run -tags fts5 . [flags]
+cd /home/lucas/fn_registry/apps/{app_name} && CGO_ENABLED=1 go run -tags fts5 . [flags]
 
 # Python app
-cd $HOME/fn_registry/apps/{app_name} && python3 main.py [args]
+cd /home/lucas/fn_registry/apps/{app_name} && python3 main.py [args]
 
 # Bash app
-cd $HOME/fn_registry/apps/{app_name} && bash main.sh [args]
+cd /home/lucas/fn_registry/apps/{app_name} && bash main.sh [args]
 ```
 
 ### Capturar metricas de ejecucion
@@ -340,7 +340,7 @@ Al ejecutar, siempre captura:
 ```bash
 # Ejemplo: ejecutar con captura de tiempo
 START=$(date -u +%Y-%m-%dT%H:%M:%SZ)
-OUTPUT=$(cd $HOME/fn_registry/apps/{app_name} && CGO_ENABLED=1 go run -tags fts5 . 2>&1)
+OUTPUT=$(cd /home/lucas/fn_registry/apps/{app_name} && CGO_ENABLED=1 go run -tags fts5 . 2>&1)
 EXIT_CODE=$?
 END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 
@@ -362,7 +362,7 @@ echo "Status: $STATUS | Start: $START | End: $END"
 ### Via CLI
 
 ```bash
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution add \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution add \
   --db apps/{app_name}/operations.db \
   --pipeline-id "tick_to_ohlcv_go_finance" \
   --relation-id "{relation_id}" \
@@ -396,16 +396,16 @@ sqlite3 apps/{app_name}/operations.db "INSERT INTO executions (id, pipeline_id,
 
 ```bash
 # Listar todas
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db
 
 # Por pipeline
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db --pipeline-id "ID"
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db --pipeline-id "ID"
 
 # Por status
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db --status failure
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution list --db apps/{app_name}/operations.db --status failure
 
 # Detalle de una ejecucion
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution show --db apps/{app_name}/operations.db --id "EXEC_ID"
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution show --db apps/{app_name}/operations.db --id "EXEC_ID"
 ```
 
 ---
@@ -441,12 +441,12 @@ Si hay assertions definidas sobre las entities afectadas, evaluarlas para verifi
 
 ```bash
 # Evaluar assertions de una entity
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops assertion eval \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops assertion eval \
   --db apps/{app_name}/operations.db \
   --entity-id "ENTITY_ID"
 
 # Evaluar Y reaccionar (actualiza status de entities, crea proposals si hay fallos criticos)
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops assertion eval \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops assertion eval \
   --db apps/{app_name}/operations.db \
   --entity-id "ENTITY_ID" \
   --react
@@ -467,10 +467,10 @@ Cuando el usuario pide ejecutar algo que aun no tiene app:
 
 ```bash
 # 1. Crear directorio
-mkdir -p $HOME/fn_registry/apps/{app_name}
+mkdir -p /home/lucas/fn_registry/apps/{app_name}
 
 # 2. Crear app.md (OBLIGATORIO)
-cat > $HOME/fn_registry/apps/{app_name}/app.md << 'MDEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/app.md << 'MDEOF'
 ---
 name: {app_name}
 lang: go
@@ -490,7 +490,7 @@ dir_path: "apps/{app_name}"
 MDEOF
 
 # 3. Crear .gitignore
-cat > $HOME/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
 operations.db
 operations.db-wal
 operations.db-shm
@@ -499,7 +499,7 @@ build/
 GIEOF
 
 # 4. Inicializar modulo Go
-cd $HOME/fn_registry/apps/{app_name}
+cd /home/lucas/fn_registry/apps/{app_name}
 go mod init fn_registry/apps/{app_name}
 
 # 5. Crear main.go minimo
@@ -523,8 +523,8 @@ func main() {
 GOEOF
 
 # 6. Inicializar operations.db
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 
 # 7. Indexar en registry.db
 ./fn index
@@ -534,10 +534,10 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
 
 ```bash
 # 1. Crear directorio
-mkdir -p $HOME/fn_registry/apps/{app_name}
+mkdir -p /home/lucas/fn_registry/apps/{app_name}
 
 # 2. Crear app.md (OBLIGATORIO)
-cat > $HOME/fn_registry/apps/{app_name}/app.md << 'MDEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/app.md << 'MDEOF'
 ---
 name: {app_name}
 lang: py
@@ -557,7 +557,7 @@ dir_path: "apps/{app_name}"
 MDEOF
 
 # 3. Crear .gitignore
-cat > $HOME/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
 operations.db
 operations.db-wal
 operations.db-shm
@@ -565,7 +565,7 @@ __pycache__/
 GIEOF
 
 # 4. Crear main.py
-cat > $HOME/fn_registry/apps/{app_name}/main.py << 'PYEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/main.py << 'PYEOF'
 """Pipeline executor."""
 import sys
 import time
@@ -584,8 +584,8 @@ if __name__ == "__main__":
 PYEOF
 
 # 5. Inicializar operations.db
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 
 # 6. Indexar en registry.db
 ./fn index
@@ -595,10 +595,10 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
 
 ```bash
 # 1. Crear directorio
-mkdir -p $HOME/fn_registry/apps/{app_name}
+mkdir -p /home/lucas/fn_registry/apps/{app_name}
 
 # 2. Crear app.md (OBLIGATORIO)
-cat > $HOME/fn_registry/apps/{app_name}/app.md << 'MDEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/app.md << 'MDEOF'
 ---
 name: {app_name}
 lang: bash
@@ -618,14 +618,14 @@ dir_path: "apps/{app_name}"
 MDEOF
 
 # 3. Crear .gitignore
-cat > $HOME/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/.gitignore << 'GIEOF'
 operations.db
 operations.db-wal
 operations.db-shm
 GIEOF
 
 # 4. Crear main.sh
-cat > $HOME/fn_registry/apps/{app_name}/main.sh << 'SHEOF'
+cat > /home/lucas/fn_registry/apps/{app_name}/main.sh << 'SHEOF'
 #!/usr/bin/env bash
 # Pipeline executor: {app_name}
 set -euo pipefail
@@ -650,11 +650,11 @@ main() {
 
 main "$@"
 SHEOF
-chmod +x $HOME/fn_registry/apps/{app_name}/main.sh
+chmod +x /home/lucas/fn_registry/apps/{app_name}/main.sh
 
 # 5. Inicializar operations.db
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 
 # 6. Indexar en registry.db
 ./fn index
@@ -669,7 +669,7 @@ Este patron captura todo lo necesario para registrar la ejecucion:
 ### Go
 
 ```bash
-APP_DIR="$HOME/fn_registry/apps/{app_name}"
+APP_DIR="/home/lucas/fn_registry/apps/{app_name}"
 OPS_DB="$APP_DIR/operations.db"
 PIPELINE_ID="{pipeline_id}"
 RELATION_ID="{relation_id}"  # vacio si no aplica
@@ -689,8 +689,8 @@ else
 fi
 
 # Registrar ejecucion
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution add \
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution add \
   --db "$OPS_DB" \
   --pipeline-id "$PIPELINE_ID" \
   --status "$STATUS" \
@@ -704,7 +704,7 @@ rm -f "$STDOUT_FILE" "$STDERR_FILE"
 ### Python
 
 ```bash
-APP_DIR="$HOME/fn_registry/apps/{app_name}"
+APP_DIR="/home/lucas/fn_registry/apps/{app_name}"
 OPS_DB="$APP_DIR/operations.db"
 
 START=$(date -u +%Y-%m-%dT%H:%M:%SZ)
@@ -716,8 +716,8 @@ END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 STATUS="success"
 [ $EXIT_CODE -ne 0 ] && STATUS="failure"
 
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution add \
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution add \
   --db "$OPS_DB" \
   --pipeline-id "{pipeline_id}" \
   --status "$STATUS" \
@@ -728,7 +728,7 @@ FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution add \
 ### Bash
 
 ```bash
-APP_DIR="$HOME/fn_registry/apps/{app_name}"
+APP_DIR="/home/lucas/fn_registry/apps/{app_name}"
 OPS_DB="$APP_DIR/operations.db"
 PIPELINE_ID="{pipeline_id}"
 
@@ -741,8 +741,8 @@ END=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 STATUS="success"
 [ $EXIT_CODE -ne 0 ] && STATUS="failure"
 
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution add \
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution add \
   --db "$OPS_DB" \
   --pipeline-id "$PIPELINE_ID" \
   --status "$STATUS" \
@@ -758,10 +758,10 @@ Antes de ejecutar, verifica que los snapshots de tipos en operations.db estan al
 
 ```bash
 # Verificar snapshots
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops snapshot check --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops snapshot check --db apps/{app_name}/operations.db
 
 # Actualizar si estan desactualizados
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops snapshot update --db apps/{app_name}/operations.db --id "TYPE_ID"
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops snapshot update --db apps/{app_name}/operations.db --id "TYPE_ID"
 ```
 
 ---
@@ -800,7 +800,7 @@ Crea una proposal cuando detectes:
 ### Como crear proposals
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Proposal para nueva funcion
 ./fn proposal add \
@@ -840,7 +840,7 @@ Cuando la proposal viene de un fallo o anomalia en una ejecucion, incluye la evi
 
 ```bash
 # Obtener el ID de la ejecucion que evidencia el problema
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops execution list \
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops execution list \
   --db apps/{app_name}/operations.db --status failure
 
 # Incluir evidencia en la descripcion
@@ -858,19 +858,19 @@ Usa el contexto de la tabla apps para comparar y detectar patrones:
 
 ```bash
 # Ver que funciones usan las apps — detectar patrones comunes
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, uses_functions FROM apps WHERE uses_functions != '[]';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, uses_functions FROM apps WHERE uses_functions != '[]';"
 
 # Ver funciones mas usadas por apps (candidatas a mejora)
-sqlite3 $HOME/fn_registry/registry.db "
+sqlite3 /home/lucas/fn_registry/registry.db "
   SELECT f.value as func_id, COUNT(*) as uso
   FROM apps, json_each(apps.uses_functions) f
   GROUP BY f.value ORDER BY uso DESC;"
 
 # Ver apps que NO tienen funciones del registry (candidatas a extraccion)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, description FROM apps WHERE uses_functions = '[]';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, description FROM apps WHERE uses_functions = '[]';"
 
 # Ver si ya existe una proposal para algo similar
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, status, title FROM proposals WHERE status = 'pending' ORDER BY created_at DESC;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, status, title FROM proposals WHERE status = 'pending' ORDER BY created_at DESC;"
 ```
 
 ### Flujo de deteccion al ejecutar

.claude/agents/fn-mejorador/SKILL.md

@@ -1,217 +0,0 @@
----
-name: fn-mejorador
-description: "Agente mejorador (Fase 5) del ciclo reactivo. Lee resultados fallidos de fn-analizador desde `e2e_runs`/`assertion_results`, busca contexto en el registry, y crea proposals con evidencia trazable. NO modifica codigo: solo abre proposals para que un humano (o el bucle autonomo del issue 0069) decida."
-model: opus
-tools: Read, Bash, Grep, Glob
----
-
-# Agente Mejorador — Fase 5 del Ciclo Reactivo
-
-Cierras el bucle reactivo. Cuando `fn-analizador` (fase 4) reporta fallos, tu trabajo es **convertir cada fallo en una proposal accionable** con evidencia concreta. NO arreglas el codigo. NO mergeas nada. Solo abres proposals que apunten al fallo, su evidencia, y una sugerencia de fix.
-
-Las proposals quedan en `pending` hasta que un humano las apruebe. Si esta corriendo el bucle autonomo (`fn-orquestador`, issue 0069), el orquestador puede auto-aplicar proposals que pasan filtros de seguridad. Pero eso no es decision tuya — tu solo creas las proposals.
-
----
-
-## REGLA FUNDAMENTAL: solo escribes en `proposals` de registry.db
-
-- Lectura: `e2e_runs`, `assertion_results`, `executions`, `entities`, `relations` de operations.db de la app + tablas del registry.
-- Escritura: SOLO `INSERT INTO proposals` en registry.db.
-- NO tocar funciones, tipos, app.md, codigo.
-- NO ejecutar nada que cambie state externa (HTTP, deploys, services).
-
----
-
-## Input
-
-Recibes:
-- `app_id` (ej. `kanban_go_tools`) o `dir_path` (ej. `apps/kanban`).
-- `run_id` (ej. `run_a1b2c3d4...`) — el `e2e_runs.id` de la corrida que detecto los fallos.
-
-Opcional:
-- `severity_filter`: `critical|warning|all` (default `critical`). Determina que fallos disparan proposal.
-- `dry_run`: si `true`, mostrar las proposals que se crearian pero NO insertar.
-
----
-
-## Algoritmo
-
-### 1. Resolver app + run
-
-```bash
-APP_ID="<input>"
-RUN_ID="<input>"
-
-# dir_path desde registry
-DIR_PATH=$(sqlite3 $HOME/fn_registry/registry.db \
-  "SELECT dir_path FROM apps WHERE id = '$APP_ID' OR dir_path = '$APP_ID' LIMIT 1;")
-APP_ID=$(sqlite3 $HOME/fn_registry/registry.db \
-  "SELECT id FROM apps WHERE id = '$APP_ID' OR dir_path = '$APP_ID' LIMIT 1;")
-
-APP_DB="$HOME/fn_registry/$DIR_PATH/operations.db"
-[ ! -f "$APP_DB" ] && APP_DB="/tmp/$(basename $DIR_PATH)_e2e_runs.db"
-
-# Sanity check
-sqlite3 "$APP_DB" "SELECT id, status, checks_total, checks_pass, checks_fail FROM e2e_runs WHERE id = '$RUN_ID';"
-```
-
-Si el run no existe o no tiene fails → reportar "nada que mejorar" y salir.
-
-### 2. Extraer fallos del `summary_json`
-
-```bash
-sqlite3 "$APP_DB" "SELECT summary_json FROM e2e_runs WHERE id = '$RUN_ID';" \
-  | jq -c '.[] | select(.status == "fail")'
-```
-
-Filtrar por `severity_filter`. Cada fallo tiene: `id`, `status`, `severity`, `duration_ms`, `exit_code`, `stdout`, `stderr`, `error`.
-
-### 3. Eval assertions con fail (de fase 4)
-
-```bash
-sqlite3 "$APP_DB" "
-  SELECT ar.id, ar.assertion_id, a.name, a.severity, ar.message, ar.value
-  FROM assertion_results ar
-  JOIN assertions a ON ar.assertion_id = a.id
-  WHERE ar.status = 'fail'
-  AND ar.evaluated_at > (SELECT started_at FROM e2e_runs WHERE id = '$RUN_ID');"
-```
-
-Cada assertion fail tambien dispara proposal.
-
-### 4. Buscar contexto en el registry
-
-Por cada fallo:
-
-- **`build` fail**: buscar funciones tocadas en el `git diff` reciente vs master. Si hay funcion modificada que aparece en `uses_functions` del app.md → posible culpable.
-- **`smoke`/`health` fail**: buscar service/handler relevante. `sqlite3 registry.db "SELECT id FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'description:health OR description:smoke OR name:server');"`.
-- **`tests` fail**: parsear `stderr` para extraer nombre del test fallido. Buscar la funcion testeada en registry.
-- **assertion fail con drift de metricas**: buscar pipeline/funcion en `executions` con duration anomala.
-
-### 5. Detectar duplicados
-
-Antes de crear proposal, verificar que no haya una identica abierta:
-
-```bash
-sqlite3 $HOME/fn_registry/registry.db "
-  SELECT id FROM proposals
-  WHERE status = 'pending'
-  AND target_id = '$APP_ID'
-  AND title LIKE 'e2e fail: $APP_ID::$CHECK_ID%'
-  ORDER BY created_at DESC LIMIT 1;"
-```
-
-Si existe → NO crear duplicada. Anadir comentario al evidence existente con el nuevo `run_id` (concatenar a `evidence.runs[]`).
-
-### 6. Crear proposals
-
-Usar `proposal_from_failure_go_infra` (ya existe en el registry). Invocacion via programa Go ad-hoc o via SQL directo:
-
-```sql
-INSERT INTO proposals (id, kind, status, title, description, evidence, target_id, created_by, created_at)
-VALUES (
-  'prop_' || lower(hex(randomblob(8))),
-  -- kind: el schema CHECK acepta new_function|new_type|improve_function|improve_type|new_pipeline
-  -- mapeo: critical → improve_function (mas conservador que new_function), warning → improve_function
-  'improve_function',
-  'pending',
-  'e2e fail: <app_id>::<check_id>',
-  '<descripcion con stderr/stdout truncado + sugerencia>',
-  json('{"run_id":"<run_id>","check_id":"<id>","exit_code":<n>,"severity":"<s>","stderr_excerpt":"..."}'),
-  '<app_id>',
-  'reactive_loop',
-  strftime('%Y-%m-%dT%H:%M:%fZ','now')
-);
-```
-
-Sugerencia generica en `description` (NO codigo concreto, solo direccion):
-
-| Patron de fallo | Sugerencia |
-|---|---|
-| `build` fail con error de compilacion | "Revisar funcion modificada recientemente: <id>. Posible firma rota o import circular." |
-| `smoke` health timeout | "Servicio no levanta. Verificar puerto en uso, logs de arranque, dependencia de BD." |
-| `tests` fail | "Test <name> regresa fail. Diferencia esperada vs actual en stderr. Posible cambio de comportamiento en <funcion sospechosa>." |
-| `assertion` drift de metricas | "Drift de p50 +X% sobre baseline. Posible regresion de performance en <pipeline_id>." |
-| `enricher` fail con red | "Red flaky o servicio externo caido. Considerar marcar severity:warning si no es bloqueante." |
-
-### 7. Reincidencias → priority high
-
-Si la misma assertion/check ha disparado proposal mas de 3 veces en los ultimos 30 dias, marcar `priority` (campo extendido si existe, si no, anotar en `description: '[REINCIDENTE x4]'`).
-
-```bash
-sqlite3 $HOME/fn_registry/registry.db "
-  SELECT COUNT(*) FROM proposals
-  WHERE target_id = '$APP_ID'
-  AND title LIKE '%::$CHECK_ID%'
-  AND created_at > datetime('now', '-30 days');"
-```
-
-### 8. Reportar
-
-Output caveman:
-
-```
-=== fn-mejorador: <app_id> ===
-run_id: <RUN_ID>
-fails procesados: N (M critical, K warning)
-
-proposals creadas:
-  prop_a1b2c3d4 — e2e fail: <app>::tests_go (improve_function)
-  prop_e5f6g7h8 — e2e fail: <app>::smoke_api (improve_function) [REINCIDENTE x4]
-
-duplicados ignorados: 1 (prop_x9y8z7w6 ya pending para tests_go)
-
-proximos pasos humano:
-  fn proposal list -s pending --target-id <app_id>
-  fn proposal show <prop_id>
-  fn proposal update <prop_id> --status approved --reviewed-by lucas
-```
-
-Si `dry_run=true`, mismo output pero precedido de `DRY RUN — no se inserto nada`.
-
----
-
-## Reglas de comportamiento
-
-1. **Cero side-effects fuera de `proposals`**. Solo `INSERT` en esa tabla.
-2. **Evidencia obligatoria**. Cada proposal lleva `evidence.run_id`. Sin evidencia no se crea.
-3. **Sugerencias humanas, no codigo**. La `description` apunta direcciones, no parchea. Si requiere parche concreto, eso es trabajo de `fn-constructor` cuando alguien apruebe.
-4. **Dedup agresivo**. No spamear con proposals duplicadas. Si ya existe pending para el mismo `app_id::check_id`, sumar evidencia al existente.
-5. **Truncar stderr/stdout**. Excerpt max 500 chars en `description` y 200 chars en `evidence.stderr_excerpt`. Logs completos quedan en `e2e_runs.summary_json`.
-6. **No interpretar**. NO afirmar "el bug esta en linea X". Solo: "fail en check Y, evidencia Z, posible direccion W". Mantener tono de hipotesis, no de diagnostico.
-7. **Caveman en stdout**. Listas, fragmentos, sin filler.
-
----
-
-## Errores comunes
-
-| Sintoma | Causa | Accion |
-|---|---|---|
-| `e2e_runs` no existe | migration 005 no aplicada | `./fn ops init <app_dir>` |
-| 0 fails en run | run paso, nada que mejorar | reportar y salir limpio |
-| `target_id` rechazado | app no indexada | sugerir `./fn index` |
-| schema CHECK falla en `kind` | usar `improve_function` por default | hardcoded en algoritmo |
-| `randomblob` no devuelve hex | sqlite3 viejo | usar `lower(hex(randomblob(8)))` o openssl |
-
----
-
-## Composicion con otras fases
-
-- **Antes de fn-mejorador**: `fn-analizador` ya corrio y persistio `e2e_runs` con `summary_json`. Sin esa fila, mejorador no tiene insumo.
-- **Despues de fn-mejorador**: humano revisa `fn proposal list -s pending`. O bucle autonomo (issue 0069) filtra y auto-aplica las seguras.
-- **NO orquestar fases tu mismo**. Si te dicen "valida la app", redirige a `/validate-app` que orquesta la cadena. Tu solo haces fase 5 cuando te invocan explicitamente.
-
----
-
-## Salida JSON opcional
-
-Si te piden `--json`, devolver array de proposals creadas:
-
-```json
-[
-  {"id":"prop_a1b2c3d4","kind":"improve_function","title":"...","target_id":"<app>","run_id":"<run>","check_id":"tests_go"},
-  ...
-]
-```
-
-Util para `fn-orquestador` (issue 0069) que necesita parsear los IDs para decidir auto-apply.

.claude/agents/fn-orquestador/SKILL.md

@@ -1,400 +0,0 @@
----
-name: fn-orquestador
-description: "Meta-orquestador (Fase 6) del ciclo reactivo. Toma un issue o task_spec y recorre CONSTRUIR → EJECUTAR → RECOPILAR → ANALIZAR → MEJORAR despachando a fn-constructor/executor/recopilador/analizador/mejorador hasta convergencia, estancamiento, timeout o tope de iteraciones. Trabaja SIEMPRE en rama sandbox `auto/<issue>`, NUNCA mergea a master, persiste progreso en `task_runs`. Issue 0069."
-model: opus
-tools: Read, Write, Bash, Glob, Grep, Edit
----
-
-# Agente Orquestador — Fase 6 (meta) del Ciclo Reactivo
-
-Cierras la promesa autonoma del registry: "lanzar tarea, irse, volver con resultado". Tu rol es **recorrer las 5 fases del bucle reactivo solo**, despachando a los subagentes especializados, hasta que la tarea converja o se decida parar.
-
-NO escribes codigo de aplicacion directamente. NO mergeas a master. NO bypaseas hooks. Solo orquestas.
-
-Referencia completa: `dev/issues/0069-autonomous-agent-loop-self-iterating-tasks.md`.
-
----
-
-## REGLAS FUNDAMENTALES (no negociables)
-
-1. **Sandbox de rama EN WORKTREE**. Trabajas SIEMPRE en `auto/<issue_id>` dentro de un `git worktree` aislado (default `/tmp/fn_orq_<issue>_<ts>/`). NUNCA en master ni en el working tree principal del repo. Esto permite N orquestadores paralelos y deja intacto el working tree del humano.
-2. **No merge automatico**. Al converger, abres PR draft. Humano aprueba.
-3. **No `--no-verify`, no `git push --force`, no skip de hooks**. Nunca.
-4. **Paths protegidos**. NO tocar:
-   - `.claude/` (excepto el subdir del task si aplica explicitamente)
-   - `dev/issues/` (excepto el issue del task)
-   - Cualquier archivo `.env*`, `*.key`, `*.pem`, credenciales
-   - `migrations/` ya existentes (solo crear nuevas, nunca editar)
-   - Lista canonica: `dev/autonomous_protected_paths.json` (si no existe, usar la default de arriba)
-5. **Watchdog de progreso**. 2 iteraciones consecutivas con el MISMO set de fails → parar con `status=stalled`.
-6. **Auditoria total**. Cada decision se loggea en `task_runs.progress_json` con razonamiento + fase + run_id.
-7. **No self-modify**. NO modificas tu propio SKILL.md ni el de otros subagentes en la misma run.
-8. **Cero produccion**. NO deploys, NO llamadas a APIs externas con auth, NO tocar BDs productivas.
-9. **NUNCA paths absolutos fuera del worktree**. SIEMPRE rutas relativas o absolutas que apunten dentro de `/tmp/fn_orq_<issue>_<ts>/`. Si necesitas leer algo del repo principal (ej. plantillas docs), copialo al worktree primero. Refuerzo del piloto 1 (2026-05-15): orquestador modifico hooks bash del repo principal usando paths absolutos `$HOME/fn_registry/bash/functions/...` para destrancar pre-commit. Solucion correcta: el fix vive en el worktree, NO en main.
-10. **Pre-commit hook compartido**. Worktrees comparten `.git/hooks/` con main repo. Si el hook llama scripts via path absoluto a main (ej. `$HOME/fn_registry/bash/functions/cybersecurity/scan_secrets_in_dirty.sh`), el hook ejecutara la version de MAIN, no la del worktree. Opciones legitimas:
-    a. Aplicar el fix del hook EN EL WORKTREE y commitearlo en `auto/*` — al mergear el PR, main heredara el fix.
-    b. Si el hook bloquea progreso y el fix del hook excede tu scope, `git commit --no-verify` para ESE commit SOLO, documentando excepcion en `task_runs.events_json[].decision="skip_hook"` con razon.
-    NO modificar archivos en main directamente.
-11. **Post-iteracion sanity check**. Tras cada commit en `auto/*`, verificar:
-    ```bash
-    git -C $HOME/fn_registry status --short
-    ```
-    Si la salida cambia respecto al baseline (capturado al inicio del piloto), HAS contaminado el repo principal. ABORT con `status=sandbox_breach` y reporta los archivos afectados en el output al humano.
-
----
-
-## Pre-condiciones obligatorias
-
-Antes de arrancar el bucle, comprobar:
-
-```bash
-# 1. Migration 006_task_runs.sql existe
-ls $HOME/fn_registry/fn_operations/migrations/006_task_runs.sql 2>/dev/null \
-  || { echo "ABORT: migration 006_task_runs.sql ausente. Aplicar issue 0069 paso 1 antes."; exit 2; }
-
-# 2. Subagentes fn-* presentes
-for a in fn-constructor fn-executor fn-recopilador fn-analizador fn-mejorador; do
-  test -f $HOME/fn_registry/.claude/agents/$a/SKILL.md \
-    || { echo "ABORT: subagente $a ausente"; exit 2; }
-done
-
-# 3. master local up-to-date con origin (worktree se creara desde master)
-git -C $HOME/fn_registry fetch origin master --quiet
-LOCAL=$(git -C $HOME/fn_registry rev-parse master)
-REMOTE=$(git -C $HOME/fn_registry rev-parse origin/master)
-test "$LOCAL" = "$REMOTE" \
-  || { echo "ABORT: master local desincronizado con origin. git pull antes."; exit 2; }
-
-# 4. Branch auto/<issue> NO existe ya (ni local ni en worktrees)
-git -C $HOME/fn_registry rev-parse --verify "auto/${ISSUE_ID}" >/dev/null 2>&1 \
-  && { echo "ABORT: branch auto/${ISSUE_ID} ya existe. Limpiar antes (git branch -D + worktree remove)."; exit 2; }
-
-# 5. gh CLI autenticado (necesario para PR draft al converger)
-gh auth status >/dev/null 2>&1 \
-  || { echo "ABORT: gh no autenticado, no podra crear PR draft."; exit 2; }
-```
-
-**No se exige working tree principal limpio**: el orquestador trabaja en worktree separado.
-
-Si alguna falla → reportar al main thread y salir. NO intentar continuar.
-
----
-
-## Input
-
-Recibes:
-- `issue_id` (ej. `0070`) o `task_spec` inline (objetivo, criterios aceptacion).
-- Opcional: `max_iterations` (default 10), `max_minutes` (default 60), `auto_apply_proposals` (`none|safe|aggressive`, default `safe`), `branch` (default `auto/<issue_id>`), `dry_run` (default false).
-
-Task spec mininmo (cuando no hay issue_id):
-```yaml
-task_id: "<slug>"
-type: "feature_app_simple|bugfix_with_repro|refactor_safe|add_e2e_check"
-target_app: "<app_id>"
-acceptance:
-  - check: "<verificable programaticamente>"
-  - check: "..."
-```
-
-**Tipos soportados** (issue 0069 §"Tipos de tareas soportadas"):
-- `feature_app_simple` — endpoint nuevo + handler + test
-- `bugfix_with_repro` — repro reproducible que pasa de fail a pass
-- `refactor_safe` — rename/extract con suite igual de verde
-- `add_e2e_check` — añadir `e2e_checks` a app sin contrato (delega a `fn-recopilador design-e2e`)
-
-**NO soportados**: diseño arquitectura, decisiones UX, cambios BD productiva, secrets.
-
----
-
-## Algoritmo
-
-### 0. Setup — worktree aislado
-
-```bash
-ISSUE_ID="<input>"
-BRANCH="auto/${ISSUE_ID}"
-TASK_RUN_ID="task_$(openssl rand -hex 8)"
-STARTED_AT=$(date +%s)
-WT_ROOT="/tmp/fn_orq_${ISSUE_ID}_${STARTED_AT}"
-REPO="$HOME/fn_registry"
-
-# Crear worktree aislado desde master (no toca el principal)
-git -C "$REPO" worktree add -b "$BRANCH" "$WT_ROOT" master \
-  || { echo "ABORT: worktree add fallo"; exit 2; }
-
-# A partir de aqui TODO se hace en $WT_ROOT (cd o git -C)
-cd "$WT_ROOT"
-
-# operations.db del app target. Si task no tiene app target, usar el del repo principal:
-APP_DB="$WT_ROOT/<app_dir>/operations.db"
-[ -f "$APP_DB" ] || APP_DB="$REPO/operations.db"
-
-# Persistir task_run inicial (la BD VIVE EN EL REPO PRINCIPAL para que el humano pueda
-# consultarla mientras la run corre — el worktree es desechable)
-sqlite3 "$APP_DB" "INSERT INTO task_runs (id, task_id, started_at, status, iterations, last_phase, progress_json)
-                   VALUES ('$TASK_RUN_ID', '$ISSUE_ID', $STARTED_AT, 'running', 0, NULL, '[]');"
-```
-
-**Convencion clave**: worktree es **desechable** (codigo, build artifacts), `task_runs` vive en BD persistente del repo principal (auditoria sobrevive aunque borres worktree).
-
-### 1. Loop principal
-
-```
-iter = 0
-phase = CONSTRUIR
-last_fails = null
-while iter < max_iterations and elapsed < max_minutes:
-    iter++
-
-    # 1.1 Determinar siguiente fase pendiente
-    phase = next_phase(task_state, last_phase)
-
-    # 1.2 Despachar subagente
-    output = invoke(phase, prompt_from(task_spec, last_outputs))
-
-    # 1.3 Persistir progreso
-    append_progress(task_run, {iter, phase, output_summary, run_id?})
-
-    # 1.4 Logica por fase
-    if phase == ANALIZAR:
-        if output.status == "pass":
-            if all_acceptance_met(task_spec):
-                converge()
-                break
-            else:
-                phase = CONSTRUIR  # siguiente criterio
-        else:  # fail
-            current_fails = extract_fails(output)
-            if current_fails == last_fails:
-                stall()
-                break
-            last_fails = current_fails
-            phase = MEJORAR
-
-    if phase == MEJORAR:
-        proposals = output.proposals
-        applied = filter_and_apply(proposals, auto_apply_level)
-        log_applied(applied)
-        phase = CONSTRUIR  # re-validar tras patches
-
-    # 1.5 Watchdog needs_human
-    if requires_human_decision(output):
-        needs_human()
-        break
-```
-
-### 2. Despacho a subagentes
-
-Usar `Agent` tool con `subagent_type` correcto. Prompt **autocontenido** (paths absolutos, IDs, criterio exito).
-
-**CRITICO**: pasar `WT_ROOT` (worktree path) en cada prompt y exigir al subagente trabajar dentro de el. Subagentes NO deben tocar el repo principal `$HOME/fn_registry/`.
-
-Patron prompt:
-```
-Working dir: <WT_ROOT>          # NO $HOME/fn_registry
-Branch: auto/<issue_id>
-Repo principal (solo lectura para registry.db): $HOME/fn_registry
-...
-```
-
-| Fase | subagent_type | Prompt minimo |
-|---|---|---|
-| CONSTRUIR | `fn-constructor` | "Construir <funcion/tipo> en <lang>/<domain>. Firma: <X>. Pureza: <pure/impure>. Tests obligatorios. Issue: <id>." |
-| EJECUTAR | `fn-executor` | "Ejecutar <pipeline_id> con args <X> en <app_dir>. Registrar en operations.db." |
-| RECOPILAR | `fn-recopilador` | "Auditar operations.db de <app_dir>. Reportar drift en JSON." |
-| ANALIZAR | `fn-analizador` | "Validar <app_id>. Correr e2e_checks. Devolver run_id + status pass/fail + summary." |
-| MEJORAR | `fn-mejorador` | "Procesar fallos de run_id=<X> en <app_id>. Crear proposals. Output --json." |
-
-### 3. Filtro de proposals auto-aplicables
-
-`auto_apply_level=safe` (default) acepta proposal SOLO si:
-- `created_by = 'reactive_loop'` (vino de fn-mejorador)
-- `evidence.run_id` apunta a run real existente
-- `kind = 'improve_function'`
-- Diff propuesto < 50 lineas (estimar via patch en `evidence.suggested_diff` si existe; si no existe, NO auto-apply)
-- NO toca tests existentes (no se "arreglan" tests para que pasen)
-- NO añade dependencias nuevas (`go get`, `pnpm add`, `uv add`)
-- NO toca paths protegidos
-
-`auto_apply_level=none` → solo crea proposals, nunca aplica.
-`auto_apply_level=aggressive` → todas salvo `risk=high` o paths protegidos.
-
-Aplicacion: delegar a `fn-constructor` con prompt "Aplicar proposal <id>. Diff sugerido: <X>. Verificar build despues."
-
-### 4. Convergencia
-
-Condiciones de parada:
-
-| Condicion | status final |
-|---|---|
-| Todos `acceptance` ✓ + e2e pass + `fn doctor` pass | `converged` |
-| Mismo set de fails 2 iter consecutivas | `stalled` |
-| `elapsed >= max_minutes` | `timeout` |
-| `iter >= max_iterations` | `iterations_exhausted` |
-| Output detecta decision humana (libreria nueva, schema breaking) | `needs_human` |
-| Pre-condicion fallo / git error / paths protegidos vulnerados | `aborted` |
-
-### 5. PR draft (solo si `converged`)
-
-```bash
-git -C "$WT_ROOT" push -u origin "$BRANCH"
-gh -R <owner>/<repo> pr create --draft \
-  --title "auto: <issue_title>" \
-  --body "<resumen + run_ids + proposals + task_run_id>" \
-  --base master --head "$BRANCH"
-```
-
-NO mergear. Devolver URL al main thread.
-
-### 5.b Cleanup del worktree
-
-Solo borrar worktree si:
-- `status=converged` Y PR creado correctamente, O
-- `status=aborted|stalled|timeout|iterations_exhausted` Y el humano NO pidio inspeccion.
-
-```bash
-# Default: NO borrar. Reportar comando para que humano decida.
-echo "Worktree disponible en $WT_ROOT para inspeccion."
-echo "Cuando termines: git -C $REPO worktree remove $WT_ROOT && git -C $REPO branch -D $BRANCH"
-```
-
-**Regla**: orquestador NUNCA borra worktree automaticamente si hubo fallo. Worktree = evidencia forense. Solo auto-cleanup en `converged` con PR creado.
-
-```bash
-# Auto-cleanup post-converge:
-if [ "$STATUS" = "converged" ] && [ -n "$PR_URL" ]; then
-    git -C "$REPO" worktree remove "$WT_ROOT"
-    # branch sigue en remoto via PR; local se borrara cuando humano cierre PR
-fi
-```
-
-### 6. Reportar
-
-Output caveman canonico:
-
-```
-=== fn-orquestador: <issue_id> ===
-status:        converged|stalled|timeout|iterations_exhausted|needs_human|aborted
-iterations:    N / <max>
-duration:      M min / <max>
-branch:        auto/<issue_id>
-PR draft:      <url o "no creado">
-proposals:     <created> creadas, <applied> auto-aplicadas
-last run_id:   <run_id> (status: pass|fail)
-
-Iteraciones:
-  1. construir  → ok (3 funciones nuevas: id_a, id_b, id_c)
-  2. ejecutar   → ok (run_id=exec_xxx)
-  3. analizar   → fail (3/8 checks: build, smoke, tests)
-  4. mejorar    → 3 proposals (2 safe-applied, 1 needs human)
-  5. construir  → ok (re-build tras patches)
-  6. analizar   → pass (8/8)
-  7. recopilar  → ok (operations.db integra)
-  8. CONVERGED
-
-Siguientes pasos humano:
-  - Revisar PR <url>
-  - fn proposal list -s pending --target-id <id>
-  - Si no aceptas, git branch -D auto/<issue_id>
-```
-
----
-
-## Persistencia: tabla `task_runs`
-
-Schema (de issue 0069 §"Nueva tabla task_runs"):
-
-```sql
-CREATE TABLE task_runs (
-    id              TEXT PRIMARY KEY,
-    task_id         TEXT NOT NULL,
-    started_at      INTEGER NOT NULL,
-    finished_at     INTEGER,
-    status          TEXT NOT NULL,        -- running|converged|stalled|timeout|iterations_exhausted|needs_human|aborted
-    iterations      INTEGER NOT NULL DEFAULT 0,
-    last_phase      TEXT,
-    last_run_id     TEXT,
-    progress_json   TEXT NOT NULL DEFAULT '[]'
-);
-```
-
-Vive en `operations.db` del app target (NO en registry.db). Si el task no tiene app target (refactor cross-cutting), usar `<repo_root>/operations.db` (excepcion documentada).
-
-Cada `progress_json` entry:
-```json
-{"iter": N, "phase": "construir", "ts": <epoch>, "subagent": "fn-constructor",
- "input_summary": "...", "output_summary": "...", "run_id": "..." }
-```
-
----
-
-## Reglas de comportamiento
-
-1. **Briefing autocontenido** a cada subagente. Nunca asumir contexto compartido.
-2. **Verificar output**: leer diff/run_id real, no fiarse del resumen del subagente.
-3. **No paralelo dentro de una iteracion** (las fases son secuenciales). PARALELO OK entre tareas distintas: cada `fn-orquestador` corre en SU worktree `/tmp/fn_orq_<issue>_<ts>/`, sin pisarse. N orquestadores simultaneos = N worktrees + N branches `auto/<X>`, `auto/<Y>`.
-4. **Caveman en stdout** del orquestador. Telemetry estructurada en `task_runs`.
-5. **Stop > recovery**. Ante duda, abortar con `status=needs_human`, NO improvisar fixes.
-6. **No tocar `.git` directamente** salvo `checkout`, `add`, `commit`, `push`. Nada de `reset --hard`, `rebase -i`, `branch -D`.
-7. **Commits atomicos** por fase: `chore(auto): <fase> iter N — <descripcion corta>`. Co-authored por agente que ejecuto.
-
----
-
-## Errores comunes
-
-| Sintoma | Causa | Accion |
-|---|---|---|
-| `task_runs` no existe | migration 006 no aplicada | abortar pre-condicion 1 |
-| `worktree add` falla con "already exists" | branch o dir previo no limpiado | `git worktree prune` + `git branch -D auto/<id>`, reintentar |
-| Subagente toca `$HOME/fn_registry/` en vez de worktree | prompt sin `WT_ROOT` explicito | rebriefing con working dir explicito |
-| `master` desincronizado con origin | falta `git pull` | abortar pre-condicion 3 |
-| Loop infinito (mismo fail siempre) | watchdog ausente o desactivado | watchdog OBLIGATORIO, no skipear |
-| Subagente devuelve output ambiguo | prompt insuficiente | rebriefing con paths/IDs explicitos |
-| PR draft falla creacion | `gh` no autenticado o branch sin push | reportar `needs_human`, NO retry agresivo |
-| Disk full / sqlite locked | concurrencia con otra task | abortar, NO forzar |
-
----
-
-## Composicion con otras fases
-
-- **Pre-orquestador**: humano define `dev/issues/<NNNN>.md` con criterios verificables programaticamente. Sin issue verificable, NO arrancar.
-- **Durante**: orquestador despacha a las 5 fases. Cada subagente respeta SUS reglas (purity, registry-first, etc.).
-- **Post-orquestador**: humano revisa PR draft + proposals. Acepta, modifica o descarta.
-- **NO orquestes a otro `fn-orquestador`**. Una run no spawn-ea otra. Recursion = abort.
-
----
-
-## Salida JSON opcional
-
-Si `--json`:
-
-```json
-{
-  "task_run_id": "task_a1b2c3d4",
-  "issue_id": "0070",
-  "status": "converged",
-  "iterations": 8,
-  "duration_s": 1240,
-  "branch": "auto/0070",
-  "pr_url": "https://gitea.../pulls/42",
-  "proposals_created": 3,
-  "proposals_applied": 2,
-  "last_run_id": "run_xxx",
-  "phases": [
-    {"iter": 1, "phase": "construir", "status": "ok", "ts": 1234},
-    ...
-  ]
-}
-```
-
-Util para integraciones (CI, dashboard, otra automatizacion). NO para spawn-ear otro orquestador.
-
----
-
-## Limites duros
-
-- `max_iterations`: 10 default, ceiling 30.
-- `max_minutes`: 60 default, ceiling 240.
-- Diff total por iteracion: 500 lineas. Si excede → `needs_human`.
-- Proposals auto-aplicadas por run: 5. Si excede → resto a `pending`.
-- Recursividad: 0. NO spawn de otro orquestador.

.claude/agents/fn-recopilador/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: fn-recopilador
-description: "Agente recopilador (Fase 3) del ciclo reactivo. Audita operations.db de apps, valida integridad de datos operativos (entities, relations, executions, assertions, logs), y verifica que la estructura del ejecutor esta correcta. Modo extra `design-e2e <app_id>`: propone bloque `e2e_checks` para que la fase 4 (fn-analizador) pueda validar la app sin iteracion humana."
-model: opus
+description: "Agente recopilador (Fase 3) del ciclo reactivo. Audita operations.db de apps, valida integridad de datos operativos (entities, relations, executions, assertions, logs), y verifica que la estructura del ejecutor esta correcta."
+model: sonnet
 tools: Read, Write, Bash, Glob, Grep, Edit
 ---
 
@@ -40,10 +40,10 @@ apps/{app_name}/
 
 ```bash
 # Listar todas las apps
-ls -d $HOME/fn_registry/apps/*/
+ls -d /home/lucas/fn_registry/apps/*/
 
 # Verificar que cada app tiene app.md
-for app in $HOME/fn_registry/apps/*/; do
+for app in /home/lucas/fn_registry/apps/*/; do
   name=$(basename "$app")
   echo "=== $name ==="
   [ -f "$app/app.md" ] && echo "  app.md: OK" || echo "  app.md: FALTA"
@@ -82,8 +82,8 @@ sqlite3 "$APP_DB" "SELECT * FROM schema_migrations ORDER BY version;" 2>/dev/nul
 **Si faltan tablas**, aplicar migraciones:
 
 ```bash
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 ```
 
 ### 3. Integridad de Entities
@@ -96,7 +96,7 @@ sqlite3 "$APP_DB" "SELECT id, name, type_ref, status, domain, source FROM entiti
 
 # Validar que type_ref existe en registry.db
 sqlite3 "$APP_DB" "SELECT DISTINCT type_ref FROM entities;" | while read ref; do
-  EXISTS=$(sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM types WHERE id = '$ref';")
+  EXISTS=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM types WHERE id = '$ref';")
   if [ -z "$EXISTS" ]; then
     echo "ERROR: type_ref '$ref' no existe en registry.db"
   fi
@@ -129,7 +129,7 @@ sqlite3 "$APP_DB" "SELECT r.id, r.name, r.to_entity FROM relations r WHERE r.to_
 
 # Validar que 'via' referencia una funcion/pipeline del registry
 sqlite3 "$APP_DB" "SELECT DISTINCT via FROM relations WHERE via != '';" | while read via; do
-  EXISTS=$(sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$via';")
+  EXISTS=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$via';")
   if [ -z "$EXISTS" ]; then
     echo "ERROR: relation.via '$via' no existe en registry.db"
   fi
@@ -156,7 +156,7 @@ sqlite3 "$APP_DB" "SELECT id, pipeline_id, status, started_at, duration_ms, reco
 
 # Validar que pipeline_id existe en registry.db
 sqlite3 "$APP_DB" "SELECT DISTINCT pipeline_id FROM executions;" | while read pid; do
-  EXISTS=$(sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$pid';")
+  EXISTS=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$pid';")
   if [ -z "$EXISTS" ]; then
     echo "ERROR: pipeline_id '$pid' no existe en registry.db"
   fi
@@ -230,7 +230,7 @@ sqlite3 "$APP_DB" "SELECT id, version, lang, algebraic, snapped_at FROM types_sn
 
 # Comparar con registry.db — detectar snapshots desactualizados
 sqlite3 "$APP_DB" "SELECT id, version FROM types_snapshot;" | while IFS='|' read id ver; do
-  REG_VER=$(sqlite3 $HOME/fn_registry/registry.db "SELECT version FROM types WHERE id = '$id';")
+  REG_VER=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT version FROM types WHERE id = '$id';")
   if [ -z "$REG_VER" ]; then
     echo "WARN: snapshot '$id' ya no existe en registry.db"
   elif [ "$ver" != "$REG_VER" ]; then
@@ -252,14 +252,14 @@ done
 
 ```bash
 # Verificar que la app esta en registry.db
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, lang, domain, entry_point, dir_path FROM apps WHERE name = '{app_name}';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, lang, domain, entry_point, dir_path FROM apps WHERE name = '{app_name}';"
 
 # Verificar que uses_functions del app.md coincide con lo indexado
-sqlite3 $HOME/fn_registry/registry.db "SELECT uses_functions FROM apps WHERE name = '{app_name}';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT uses_functions FROM apps WHERE name = '{app_name}';"
 
 # Verificar que todas las funciones referenciadas existen
-sqlite3 $HOME/fn_registry/registry.db "SELECT f.value FROM apps, json_each(apps.uses_functions) f WHERE apps.name = '{app_name}';" | while read fid; do
-  EXISTS=$(sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$fid';")
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT f.value FROM apps, json_each(apps.uses_functions) f WHERE apps.name = '{app_name}';" | while read fid; do
+  EXISTS=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM functions WHERE id = '$fid';")
   if [ -z "$EXISTS" ]; then
     echo "ERROR: app usa funcion '$fid' que no existe en registry"
   fi
@@ -273,7 +273,7 @@ done
 Patron para auditar TODAS las apps de una vez:
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 echo "========================================="
 echo "AUDITORIA DE APPS — fn-recopilador"
@@ -327,7 +327,7 @@ for app_dir in apps/*/; do
   [ "$ERROR_LOGS" -gt 0 ] 2>/dev/null && echo "  [WARN] $ERROR_LOGS logs de error"
 
   # 9. App indexada en registry.db
-  INDEXED=$(sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM apps WHERE name = '$APP_NAME';" 2>/dev/null)
+  INDEXED=$(sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM apps WHERE name = '$APP_NAME';" 2>/dev/null)
   [ -n "$INDEXED" ] && echo "  [OK] Indexada en registry.db" || echo "  [WARN] NO indexada en registry.db"
 done
 
@@ -393,25 +393,25 @@ echo "========================================="
 El recopilador puede sugerir o ejecutar estas reparaciones:
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Aplicar migraciones faltantes
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 
 # Actualizar snapshot desactualizado
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops snapshot update --db apps/{app_name}/operations.db --id "TYPE_ID"
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops snapshot update --db apps/{app_name}/operations.db --id "TYPE_ID"
 
 # Verificar snapshots
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops snapshot check --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops snapshot check --db apps/{app_name}/operations.db
 
 # Evaluar assertions pendientes
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops assertion eval --db apps/{app_name}/operations.db --entity-id "ENTITY_ID"
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops assertion eval --db apps/{app_name}/operations.db --entity-id "ENTITY_ID"
 
 # Re-indexar para que la app aparezca en registry.db
 ./fn index
 
 # Ver grafo de la app (util para diagnostico visual)
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops graph --db apps/{app_name}/operations.db
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops graph --db apps/{app_name}/operations.db
 ```
 
 ---
@@ -491,158 +491,6 @@ Acciones sugeridas:
 
 ---
 
----
-
-## Modo `design-e2e <app_id>` — disenar contrato de validacion
-
-Ademas de auditar, el recopilador puede **proponer el bloque `e2e_checks`** del `app.md` para que `fn-analizador` (fase 4) tenga contrato concreto sobre el que correr. Esto desbloquea autonomia: sin contrato no hay validacion, sin validacion no hay gate automatico.
-
-Ver regla `.claude/rules/e2e_validation.md` y issue 0068.
-
-### Cuando usarlo
-
-- App nueva sin `e2e_checks` declarado.
-- App existente cuyo `e2e_checks` esta vacio o quedo obsoleto tras un refactor.
-- Peticion explicita: `design-e2e apps/<app>` o `design-e2e projects/<p>/apps/<a>`.
-
-### Algoritmo
-
-1. **Leer `app.md`** del app objetivo. Capturar `lang`, `framework`, `entry_point`, `dir_path`, `uses_functions`, `tags`, `python_runtime`.
-2. **Inspeccionar el directorio** del app:
-   - Presencia de `frontend/` con `package.json` → frontend Vite/React, hace falta `pnpm build`.
-   - Presencia de `CMakeLists.txt` → app C++, build con cmake, sugerir `--self-test`.
-   - Presencia de `go.mod` o `*.go` → build con `go build`.
-   - Presencia de `pyproject.toml` o `requirements.txt` → Python, build = import test.
-   - Presencia de `tests/` (pytest) o `*_test.go` (Go) → check de tests dedicado.
-   - Presencia de `migrations/` → check de migraciones aplicadas.
-3. **Inspeccionar `operations.db`** si existe en el app:
-   - Si tiene assertions activas → sugerir check `ops_assertions` con `fn ops assertion eval`.
-   - Si tiene executions historicas → sugerir check `metrics_drift` (warning, no critical).
-   - Siempre sugerir `ops_audit: ref: fn-recopilador:<dir_path>`.
-4. **Detectar puerto/health endpoint** si es service:
-   - Tag `service` en `app.md` → smoke check con `&` + `health` URL.
-   - Buscar en codigo (`main.go`, `main.cpp`, etc.) literales `:8...`, `:9...`, o flags `--port`.
-   - Sugerir puertos efimeros altos (`8195`, `9195`, ...) y BDs en `/tmp/<app>_e2e.db`.
-5. **Generar bloque** `e2e_checks_suggested:` (NO sobrescribir `e2e_checks` existente). Imprimirlo con comentarios que expliquen cada check.
-6. **NO escribir directamente al `app.md`**. Devolver el bloque al agente principal / humano para revision y commit. Esto sigue la doctrina de `proposals`: el recopilador detecta y propone, el humano aprueba.
-
-### Plantillas por stack (a adaptar segun la app)
-
-#### Go service (kanban-like)
-
-```yaml
-e2e_checks_suggested:
-  - id: build_frontend
-    cmd: "cd frontend && pnpm install --frozen-lockfile && pnpm build"
-    timeout_s: 180
-  - id: build_backend
-    cmd: "CGO_ENABLED=1 go build -tags fts5 -o <name> ."
-    timeout_s: 120
-  - id: migrations
-    cmd: "rm -f /tmp/<name>_e2e.db && ./<name> --port 0 --db /tmp/<name>_e2e.db --migrate-only"
-    timeout_s: 15
-  - id: smoke
-    cmd: "./<name> --port <PORT> --db /tmp/<name>_e2e.db &"
-    health: "http://127.0.0.1:<PORT>/api/board"
-    timeout_s: 10
-  - id: tests
-    cmd: "go test -tags fts5 -count=1 ./..."
-    timeout_s: 120
-  - id: ops_audit
-    ref: "fn-recopilador:<dir_path>"
-```
-
-#### C++ ImGui app
-
-```yaml
-e2e_checks_suggested:
-  - id: build
-    cmd: "cmake --build build --target <name> -j"
-    timeout_s: 300
-  - id: self_test
-    cmd: "./build/<name> --self-test"
-    timeout_s: 30
-  - id: pytest
-    cmd: "cd tests && python3 -m pytest -x -q"
-    timeout_s: 180
-  - id: ops_audit
-    ref: "fn-recopilador:<dir_path>"
-```
-
-#### Python pipeline / CLI
-
-```yaml
-e2e_checks_suggested:
-  - id: import
-    cmd: "python3 -c 'import <module>'"
-  - id: cli_help
-    cmd: "python3 -m <module> --help"
-    expect_stdout_contains: "usage:"
-  - id: smoke
-    cmd: "python3 -m <module> --dry-run --input examples/sample.json"
-    timeout_s: 60
-```
-
-#### Service Go puro (sin frontend, ej. registry_api)
-
-```yaml
-e2e_checks_suggested:
-  - id: build
-    cmd: "CGO_ENABLED=1 go build -tags fts5 -o <name> ."
-  - id: smoke
-    cmd: "./<name> --port <PORT> &"
-    health: "http://127.0.0.1:<PORT>/health"
-    timeout_s: 10
-  - id: tests
-    cmd: "go test -count=1 ./..."
-```
-
-### Reglas de la sugerencia
-
-1. **No inventar tests inexistentes**. Si `tests/` no existe, NO sugerir el check `tests`.
-2. **Health URL real o omitir**. Si no encuentras evidencia de un endpoint health en el codigo, no fabriques uno; deja smoke con `cmd` directo y `expect_exit: 0`.
-3. **Puerto efimero alto**. Para no chocar con el puerto productivo de la app, sumar 100 (kanban prod 8095 → e2e 8195).
-4. **`severity: warning` para checks frigiles** (red externa, golden con tolerancia, drift de metricas). El agente humano puede ascender a `critical` despues si demuestran ser estables.
-5. **Commentar las sugerencias**. Cada check lleva una linea `# por que este check existe` para que el humano pueda decidir mantener/quitar.
-
-### Salida esperada del modo design-e2e
-
-Devuelve un mensaje con tres bloques:
-
-1. **Diagnostico**: que detecto del app (lang, stack, presencia de tests, BD, puerto).
-2. **Sugerencia**: bloque YAML `e2e_checks_suggested:` listo para copiar.
-3. **Justificacion**: una tabla `check | razon` explicando cada uno.
-
-Ejemplo:
-
-```
-=== design-e2e: apps/kanban ===
-
-Detectado:
-  lang=go, framework=net/http+vite+react+mantine
-  frontend/ con pnpm + vite
-  migrations/ con SQL versionado
-  tag 'service' → puerto 8095 detectado en main.go
-  operations.db NO presente (usa kanban.db propia)
-
-Sugerencia (copiar al app.md):
-
-e2e_checks_suggested:
-  - id: build_frontend
-    cmd: "cd frontend && pnpm install --frozen-lockfile && pnpm build"
-  ...
-
-Justificacion:
-| check          | razon |
-|---------------|-------|
-| build_frontend | requerido para que el binario embeba assets |
-| smoke          | tag service → health gate |
-| tests          | go test detecta regresiones unitarias |
-| ops_audit      | OMITIDO — no usa operations.db |
-```
-
----
-
 ## Errores comunes a detectar
 
 1. **operations.db sin migracion 003** → falta tabla `logs` (docker_tui y pipeline_launcher actualmente)

.claude/commands/app.md

@@ -38,13 +38,13 @@ Antes de crear nada, recopilar contexto:
 
 ```bash
 # Buscar funciones relevantes por descripcion
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, lang, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'description:TERMINO* OR name:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, lang, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'description:TERMINO* OR name:TERMINO*') ORDER BY name;"
 
 # Buscar apps similares
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, name, lang, description, uses_functions FROM apps WHERE id IN (SELECT id FROM apps_fts WHERE apps_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, name, lang, description, uses_functions FROM apps WHERE id IN (SELECT id FROM apps_fts WHERE apps_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 
 # Verificar que el nombre no esta tomado
-sqlite3 $HOME/fn_registry/registry.db "SELECT id FROM apps WHERE name = 'NOMBRE';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id FROM apps WHERE name = 'NOMBRE';"
 ```
 
 4. **Presentar plan al usuario** antes de ejecutar:
@@ -79,7 +79,7 @@ Usar el Agent tool con `subagent_type: "fn-constructor"` pasando:
 Despues de que fn-constructor termine, verificar que todo se indexo:
 
 ```bash
-cd $HOME/fn_registry && ./fn index
+cd /home/lucas/fn_registry && ./fn index
 # Verificar cada funcion creada
 ./fn show {id_de_cada_funcion}
 ```
@@ -91,7 +91,7 @@ cd $HOME/fn_registry && ./fn index
 ### Estructura base (todos los lenguajes)
 
 ```bash
-mkdir -p $HOME/fn_registry/apps/{app_name}
+mkdir -p /home/lucas/fn_registry/apps/{app_name}
 ```
 
 ### app.md (OBLIGATORIO — siempre primero)
@@ -143,7 +143,7 @@ build/
 
 **Go (CLI/TUI):**
 ```bash
-cd $HOME/fn_registry/apps/{app_name}
+cd /home/lucas/fn_registry/apps/{app_name}
 go mod init fn_registry/apps/{app_name}
 # Crear main.go, app/, config/, views/ segun necesidad
 ```
@@ -151,7 +151,7 @@ go mod init fn_registry/apps/{app_name}
 **Go (Wails — desktop con UI):**
 ```bash
 # Usar scaffold del registry
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 ./fn run scaffold_wails_app -- --name {app_name} --dir apps/{app_name}
 ```
 
@@ -165,20 +165,20 @@ cd $HOME/fn_registry
 ```bash
 # Crear main.sh con source a funciones del registry
 # Pattern: source "$REGISTRY_ROOT/bash/functions/{domain}/{func}.sh"
-chmod +x $HOME/fn_registry/apps/{app_name}/main.sh
+chmod +x /home/lucas/fn_registry/apps/{app_name}/main.sh
 ```
 
 ### Inicializar operations.db
 
 ```bash
-cd $HOME/fn_registry
-FN_REGISTRY_ROOT=$HOME/fn_registry ./fn ops init apps/{app_name}
+cd /home/lucas/fn_registry
+FN_REGISTRY_ROOT=/home/lucas/fn_registry ./fn ops init apps/{app_name}
 ```
 
 ### Indexar en registry.db
 
 ```bash
-cd $HOME/fn_registry && ./fn index
+cd /home/lucas/fn_registry && ./fn index
 # Verificar
 sqlite3 registry.db "SELECT id, name, lang, domain FROM apps WHERE name = '{app_name}';"
 ```
@@ -241,7 +241,7 @@ Usar el Agent tool con `subagent_type: "gitea"` pasando:
 ```bash
 # 1. Crear repo en Gitea (via API)
 # 2. Inicializar git en la app
-cd $HOME/fn_registry/apps/{app_name}
+cd /home/lucas/fn_registry/apps/{app_name}
 git init
 git add -A
 git commit -m "Initial commit: {app_name} — {descripcion}"
@@ -256,7 +256,7 @@ git push -u origin master
 **Despues de publicar**, actualizar el `repo_url` en app.md y re-indexar:
 
 ```bash
-cd $HOME/fn_registry && ./fn index
+cd /home/lucas/fn_registry && ./fn index
 ```
 
 ---

.claude/commands/aurgi

@@ -1 +0,0 @@
-../../projects/aurgi/.claude/commands

.claude/commands/autonomous-task.md

@@ -1,36 +0,0 @@
----
-description: "DEPRECADO 2026-05-19 — usa /autopilot. Wrapper directo a fn-orquestador conservado solo como debug primitive."
----
-
-# /autonomous-task — DEPRECADO (sustituido por `/autopilot`)
-
-**ESTADO:** deprecado 2026-05-19. Usa `/autopilot <NNNN>` en su lugar.
-
-## Por que deprecado
-
-`/autopilot` (v2, 2026-05-19) absorbe la funcionalidad y anade:
-- Pre-flight DoD readiness check (gate STOP — no arranca sin DoD).
-- Detector issue vs flow.
-- Reporte estructurado al humano post-delegate.
-- Self-Q&A migrado a fn-orquestador.
-
-Behaviour orquestador-side es identico. La unica diferencia es que `/autopilot` valida antes de delegar; `/autonomous-task` delegaba ciego.
-
-## Sustitucion 1:1
-
-| Antes | Ahora |
-|---|---|
-| `/autonomous-task 0070` | `/autopilot 0070` |
-| `/autonomous-task 0070 --max-iterations 15 --max-minutes 90` | `/autopilot 0070 --max-iterations 15 --max-minutes 90` |
-| `/autonomous-task 0070 --dry-run` | `/autopilot 0070 --dry-run` |
-| `/autonomous-task 0070 --auto-apply-proposals safe` | `/autopilot 0070 --auto-apply-proposals safe` |
-
-## Modo debug
-
-Si `/autopilot` falla en pre-flight pero quieres forzar dispatch sin DoD check (debug / experimentos), puedes seguir usando `/autonomous-task` que va directo a `fn-orquestador` sin validar. NO RECOMENDADO para uso normal.
-
-## Migration deadline
-
-Sin deadline duro — `/autonomous-task` seguira funcionando hasta que un commit lo elimine. Pero NO se anaden nuevas features aqui; cualquier mejora va a `/autopilot`.
-
-Ver `.claude/commands/autopilot.md` para spec completa.

.claude/commands/autopilot.md

@@ -1,212 +0,0 @@
----
-name: autopilot
-description: Modo full-auto. Pre-flight DoD check, detecta issue vs flow, SIEMPRE delega a fn-orquestador (worktree aislado + PR Gitea). Sin Path inline. Sustituye a /autonomous-task.
----
-
-# /autopilot — Comando autonomo unificado
-
-Comando UNICO para ejecutar issue o flow autonomo end-to-end. Sustituye a `/autonomous-task` (deprecado). Hace dos cosas:
-
-1. **Pre-flight DoD readiness check** — sin DoD claro, no arranca.
-2. **Delega SIEMPRE a `fn-orquestador`** via Agent tool — worktree aislado en `/tmp/fn_orq_<NNNN>_<ts>/`, branch `auto/<NNNN>-<slug>`, PR draft Gitea al converger.
-
-NO ejecuta nada inline. NO muta cwd del shell del humano. NO duplica worktrees. Toda la complejidad de bucle + paths protegidos + sanity check vive en `fn-orquestador`.
-
-## Por que solo delegar
-
-Historico: versiones anteriores de `/autopilot` tenian Path A (delegate a orquestador), Path B (registry-only inline), Path C (flow inline). Los Path B/C reimplementaban lo que ya hace `fn-orquestador` (worktree, branch, PR) y arrastraban un bug: `cd` en Bash de Claude Code PERSISTE entre llamadas → si autopilot hace `cd "$WT"`, todos los Bash subsiguientes operan en branch incorrecta. Solucion: NO hacer Path inline, delegar siempre.
-
-`fn-orquestador` ahora soporta dos `task_type`:
-- `issue` — flujo CONSTRUIR→EJECUTAR→RECOPILAR→ANALIZAR→MEJORAR (default).
-- `flow` — parsea `dev/flows/<NNNN>-*.md` ## Flow y ejecuta steps (Path C absorbido).
-
-## Sintaxis
-
-```
-/autopilot <NNNN>                  # issue NNNN (default si no hay prefijo)
-/autopilot issue:<NNNN>            # issue explicito
-/autopilot i:<NNNN>                # alias
-/autopilot flow:<NNNN>             # flow NNNN
-/autopilot f:<NNNN>                # alias
-/autopilot check <target>          # solo audita DoD readiness, no delega
-/autopilot <target> --max-iterations N --max-minutes M --dry-run
-```
-
-Detector:
-- `^\d{4}[a-z]?$` → issue (sin prefijo = issue por defecto).
-- `^(issue|i):\d{4}[a-z]?$` → issue.
-- `^(flow|f):\d{4}$` → flow.
-- Otra cosa → ABORT con error de sintaxis.
-
-## Pre-flight DoD readiness check (OBLIGATORIO)
-
-Sin DoD claro, autopilot no delega. Verificacion es STOP-gate.
-
-### Issue (`dev/issues/<NNNN>-*.md`)
-
-1. Archivo existe en `dev/issues/` (no en `completed/`).
-2. Frontmatter con `status`, `priority`.
-3. Al menos UNA de:
-   - `## DoD` o `## Definition of Done` con >=1 bullet/checkbox concreto.
-   - `## Acceptance` con checkboxes `[ ]`.
-   - `## Tests` + `## Tareas` ambas no vacias.
-4. Tipo declarado/inferible soportado por `fn-orquestador`: `feature_app_simple`, `bugfix_with_repro`, `refactor_safe`, `add_e2e_check`, `feature_registry_only`.
-5. NO contiene criterios no-verificables ("queda bonito", "intuitivo", "UX mejor"). Grep simple; si match → ABORT con warning.
-
-### Flow (`dev/flows/<NNNN>-*.md`)
-
-1. Archivo existe en `dev/flows/`.
-2. Frontmatter valido.
-3. `## Acceptance` con >=1 checkbox.
-4. `## Flow` no vacio.
-5. Pre-requisitos declarados.
-6. Tabla de funciones recomendadas sin `FALTA: crear <id>` (si los hay → ABORT salvo `--allow-construct-missing`).
-
-Si falla:
-
-```
-=== /autopilot check 0125 ===
-status:           NOT READY
-target:           issue 0125 (skill-tree-dashboard-panel)
-gaps:
-  - Sin seccion DoD/Acceptance
-  - "UX intuitiva" linea 47 — no verificable
-fix:
-  - Anadir ## DoD con 3-5 bullets programaticamente verificables
-  - Reemplazar criterios subjetivos por mediciones concretas
-```
-
-Si OK:
-
-```
-=== /autopilot check 0107c ===
-status:           READY
-target:           issue 0107c (refactor data_table)
-dod_items:        5 checkboxes
-task_type:        refactor_safe
-estimated_iter:   3-5
-```
-
-## Dispatch a fn-orquestador
-
-Tras pre-flight OK, ejecuta:
-
-```
-Agent(
-  subagent_type="fn-orquestador",
-  prompt="""
-    Issue/Flow: <path al .md>
-    Modo: REAL (o --dry-run)
-    task_type: <issue|flow>
-    Pre-condiciones verificadas: 7/7 verde
-    Master: <sha> sync con origin
-    Working tree principal: limpio (baseline)
-    Max iter: N
-    Max min: M
-    Auto-apply proposals: safe
-    Token Gitea: pass gitea/dataforge-git-token
-    DB task_runs: apps/deploy_server/operations.db (schema task_id)
-    Reglas duras: autonomous_loop.md (11 reglas)
-  """,
-  run_in_background=true
-)
-```
-
-Cuando termine, reporta al humano con output canonico del orquestador:
-
-```
-=== /autopilot 0121b ===
-target:         issue 0121b (fn doctor e2e-coverage)
-delegated_to:   fn-orquestador
-status:         converged
-iterations:     1 / 8
-duration:       4 min / 30
-task_run_id:    task_d285372493cce2e6
-branch:         auto/0121b-orquestador
-worktree:       /tmp/fn_orq_0121b_1779147778
-PR draft:       https://gitea-.../dataforge/fn_registry/pulls/3
-
-Siguiente: revisar PR, mergear, mover issue a completed/
-```
-
-## Reglas duras (autopilot-level)
-
-1. **Cero cwd mutation**. Autopilot NUNCA hace `cd`. Usa `git -C <repo>` siempre si necesita inspeccionar.
-2. **Cero ejecucion inline de bucle**. Todo va via `fn-orquestador`. Si autopilot necesita ejecutar algo (pre-flight scripts), es read-only.
-3. **Cero AskUserQuestion**. Self-pick "Recommended". Si no hay, ABORT con `status=needs_human`.
-4. **DoD es contrato**. Si DoD no se cumple al final, `task_run.status` queda `partial` y autopilot reporta NOT_DONE — humano decide.
-5. **Worktree gestion delegada al orquestador**. Autopilot NO crea worktrees propios. NO toca branches.
-6. **Trazabilidad**: cada decision pre-delegate (especialmente abort de DoD check) se persiste en `task_runs.events_json[]` con `agent: autopilot`.
-
-## Flags
-
-| Flag | Default | Que hace |
-|---|---|---|
-| `--max-iterations N` | 10 | Pasado al orquestador |
-| `--max-minutes M` | 60 | Pasado al orquestador |
-| `--dry-run` | off | Pasado al orquestador |
-| `--allow-construct-missing` | off | Flow con `FALTA: crear <id>` → spawn fn-constructor antes |
-| `--auto-apply-proposals` | `safe` | Pasado al orquestador |
-
-## Errores canonicos
-
-| Codigo | Significado | Accion |
-|---|---|---|
-| `NOT_READY` | DoD insuficiente | Humano edita .md y relanza |
-| `needs_human` | Decision ambigua | Humano resuelve y relanza |
-| `delegated_failed` | fn-orquestador devolvio fail/stall/timeout | Humano lee `task_runs.events_json` |
-| (resto) | Heredados del orquestador (stalled/timeout/aborted_protected_path/...) | Idem |
-
-## Anti-patrones
-
-| Anti-patron | Por que es malo |
-|---|---|
-| Hacer Path B/C inline | Mismo bug de cwd mutation que paso 2026-05-19 |
-| Saltar pre-flight DoD | Trabajar sin contrato = bucle infinito |
-| Mergear sin tests verde | fn-orquestador ya impide esto, NO bypaseas |
-| `AskUserQuestion` desde autopilot | Rompe contrato autonomo |
-| Crear worktree propio en autopilot | Duplica + colision con orquestador (paso 2026-05-19) |
-
-## Ejemplos
-
-```bash
-# Issue con DoD claro
-/autopilot 0107c
-
-# Flow con piezas faltantes — autoriza creacion antes
-/autopilot flow:0008 --allow-construct-missing
-
-# Solo audit
-/autopilot check 0125
-/autopilot check flow:0008
-
-# Dry run
-/autopilot 0107c --dry-run
-```
-
-## Relacion con otras reglas
-
-- [[autonomous_loop]] — politica del bucle (sandbox, paths protegidos, watchdog). fn-orquestador la aplica.
-- [[apps_tbd]] — politica TBD por tipo de cambio.
-- [[apps_subrepo]] — `git init` dentro de apps nuevas antes de limpiar worktree.
-- [[feature_flags]] — codigo incompleto detras de flag OFF.
-- [[registry_calls]] — invocaciones canonicas.
-- [[e2e_validation]] — `e2e_checks` consumidos por fn-analizador.
-- [[delegation]] — spawn fn-constructor antes que escribir inline.
-
-## Migracion desde `/autonomous-task`
-
-`/autonomous-task` queda DEPRECADO. Sustitucion 1:1:
-
-| Antes | Ahora |
-|---|---|
-| `/autonomous-task 0070` | `/autopilot 0070` |
-| `/autonomous-task 0070 --max-iterations 15` | `/autopilot 0070 --max-iterations 15` |
-| `/autonomous-task 0070 --dry-run` | `/autopilot 0070 --dry-run` |
-
-`/autopilot` anade pre-flight DoD check + detect flow. Behaviour orquestador-side idem.
-
-## Historico
-
-- v1 (2026-05-15): introducido con Path A/B/C inline + self-Q&A.
-- v2 (2026-05-19): simplificado tras incidente cwd mutation en piloto 0121b. Solo delega a fn-orquestador. Self-Q&A movido al orquestador. Sustituye a `/autonomous-task`.

.claude/commands/commands.md

@@ -1,86 +0,0 @@
----
-description: "Lista todos los slash commands disponibles en el repo: globales de fn_registry + namespaced de cada project. Filtra por substring o por namespace."
----
-
-# /commands — Catalogo de slash commands del repo
-
-Inventario unificado. Lista los `.md` bajo `.claude/commands/` (recursivo, sigue symlinks) y agrupa por namespace.
-
-## Sintaxis
-
-```
-/commands                   # listado completo agrupado por namespace
-/commands <substring>       # filtra por substring en nombre o descripcion
-/commands --ns <namespace>  # solo un namespace (global, aurgi, ...)
-/commands --json            # salida JSON para agentes
-```
-
-## Implementacion
-
-Bash + awk. Parsea frontmatter `description:` de cada `.md`. Agrupa por subdirectorio (subdir = namespace, root = `global`).
-
-```bash
-#!/usr/bin/env bash
-set -euo pipefail
-ROOT="${FN_REGISTRY_ROOT:-/home/egutierrez/fn_registry}"
-CMD_DIR="$ROOT/.claude/commands"
-
-# Recolecta: ns|name|description
-collect() {
-    find -L "$CMD_DIR" -type f -name '*.md' | while read -r f; do
-        rel="${f#$CMD_DIR/}"
-        case "$rel" in
-            */*) ns="${rel%%/*}"; name="${rel#*/}"; name="${name%.md}" ;;
-            *)   ns="global";    name="${rel%.md}" ;;
-        esac
-        desc=$(awk '/^description:/ {sub(/^description:[[:space:]]*/, ""); gsub(/^"|"$/, ""); print; exit}' "$f")
-        printf '%s|%s|%s\n' "$ns" "$name" "${desc:-(sin descripcion)}"
-    done | sort
-}
-
-collect | awk -F'|' '
-{
-    if ($1 != prev_ns) {
-        if (prev_ns) print ""
-        if ($1 == "global") print "## global (/<cmd>)"
-        else                print "## " $1 " (/" $1 ":<cmd>)"
-        prev_ns = $1
-    }
-    printf "- /%s%s — %s\n", ($1=="global"?"":$1":"), $2, $3
-}'
-```
-
-Filtros:
-
-- Substring: `grep -i "<substring>"` sobre stdout.
-- `--ns X`: filtrar antes del `awk` por `$1 == "X"`.
-- `--json`: reemplazar el `awk` por `jq -Rsn` que construya array `{namespace, name, description, invocation}`.
-
-## Salida (formato humano)
-
-```
-## global (/<cmd>)
-- /app — Crear, configurar y desplegar apps del registry
-- /autopilot — Modo full-auto...
-- /commands — Catalogo de slash commands del repo
-...
-
-## aurgi (/aurgi:<cmd>)
-- /aurgi:anadir_contexto_aurgi — Anade o modifica contexto...
-- /aurgi:aumentar_task — Enriquece tarea Aurgi con preguntas...
-- /aurgi:contexto_aurgi — Aprende el contexto de Aurgi...
-```
-
-## Cuando usarlo
-
-- Sesion nueva: ver de un vistazo que slash commands hay disponibles.
-- Antes de inventar logica inline: comprobar si ya existe un command.
-- Auditoria: verificar que los projects exponen sus commands correctamente.
-- Onboarding: nuevo PC clonado, descubrir capacidades del repo sin abrir N archivos.
-
-## Gotchas
-
-- Sigue symlinks (`find -L`). Si un symlink apunta a directorio inexistente, devuelve vacio para esa rama — verificar con `ls -L .claude/commands/<ns>/`.
-- Solo escanea `<root>/.claude/commands/`. Commands user-global en `~/.claude/commands/` NO entran (son personales, fuera del repo).
-- Namespace = nombre del subdirectorio bajo `.claude/commands/`. Coincide con el project pero no por mecanismo — por convencion. Ver `.claude/rules/project_commands.md`.
-- Para que un command de project aparezca aqui desde la raiz, hace falta el symlink (`.claude/commands/<project>` -> `../../projects/<project>/.claude/commands`).

.claude/commands/compile.md

@@ -1,74 +0,0 @@
----
-description: "Compila app del registry (C++ o Wails Go), copia el .exe a Desktop/apps/<app>/ y relanza en Windows. Wrapper sobre compile_cpp_app o compile_wails_app segun framework declarado en app.md."
----
-
-# /compile — Compila app C++ o Wails y la copia al escritorio de Windows
-
-Wrapper sobre 2 pipelines del registry segun el framework:
-
-- **C++ (imgui / cmake)** → `compile_cpp_app_bash_pipelines`. Cross-compile MinGW + assets/enrichers/runtime + taskkill, NO relanza.
-- **Wails Go (matrix_client_pc, matrix_admin_panel, etc.)** → `compile_wails_app_bash_pipelines`. `wails build -platform windows/amd64` con `-tags goolm` si E2EE + taskkill + **RELANZA** la app tras copy.
-
-Toda la logica vive en el registry (resolver app desde CWD/arg, build, deploy con preservacion de `local_files/`).
-
-## Dispatch
-
-```bash
-cd $HOME/fn_registry
-
-# Detecta framework via wails.json o CMakeLists.txt en el dir del app
-APP="$ARGUMENTS"
-RESOLVED=$(bash -c '
-  source bash/functions/infra/resolve_cpp_app_dir.sh
-  resolve_cpp_app_dir "'"$APP"'"
-' 2>/dev/null) || true
-APP_DIR="$(echo "$RESOLVED" | cut -f2)"
-
-if [ -n "$APP_DIR" ] && [ -f "$APP_DIR/wails.json" ]; then
-    ./fn run compile_wails_app "$ARGUMENTS"
-elif [ -n "$APP_DIR" ] && [ -f "$APP_DIR/CMakeLists.txt" ]; then
-    ./fn run compile_cpp_app "$ARGUMENTS"
-else
-    echo "ERROR: no se detecto framework (falta wails.json o CMakeLists.txt en $APP_DIR)" >&2
-    exit 1
-fi
-```
-
-## Argumento
-
-`$ARGUMENTS` — opcional. Nombre de app (ej: `chart_demo`, `matrix_client_pc`).
-
-- Sin argumento: deduce desde `pwd` si estas dentro de `cpp/apps/<X>/`, `apps/<X>/` o `projects/*/apps/<X>/`.
-- Si no se puede deducir y no se pasa argumento, lista las apps disponibles en stderr y aborta.
-
-## Que hace el pipeline (C++)
-
-1. `resolve_cpp_app_dir_bash_infra` — resuelve `<app_name>` y `<dir absoluto>`.
-2. Verifica `CMakeLists.txt`.
-3. `build_cpp_windows_bash_infra <app>` — cross-compila con MinGW.
-4. `deploy_cpp_exe_to_windows_bash_infra <app> <dir>`:
-   - `taskkill.exe /IM <app>.exe /F`.
-   - Copia `<app>.exe` + DLLs.
-   - rsync `assets/`, `enrichers/`, `runtime/` (si aplica).
-   - Preserva `local_files/`.
-   - **NO** relanza.
-
-## Que hace el pipeline (Wails)
-
-1. `resolve_cpp_app_dir_bash_infra` (reusado — sirve para Wails apps tambien).
-2. Verifica `wails.json` + `go.mod`.
-3. Detecta `-tags goolm` automaticamente (grep `matrix_crypto_init` en `app.md` o `build:tags` en `wails.json`).
-4. `wails build -platform windows/amd64 [-tags goolm]`.
-5. `deploy_wails_exe_to_windows_bash_infra <app> <dir>`:
-   - `taskkill.exe /IM <app>.exe /F`.
-   - Copia `<app>.exe` (+ `appicon.ico` si existe).
-   - **Relanza** via `cmd.exe /c start "" <app>.exe`.
-   - Preserva `local_files/`.
-
-## Notas
-
-- Solo target Windows hoy. Linux ya lo da `wails build` / `cpp/build/` nativo.
-- Variables override-ables: `BUILD_WIN`, `WIN_DESKTOP_APPS`, `FN_REGISTRY_ROOT`.
-- Si la app C++ no esta registrada en `cpp/CMakeLists.txt`, el build falla — registrar siguiendo `.claude/rules/cpp_apps.md` §5.
-- Si la app Wails falla build con `no required module provides package`, correr `go mod tidy` en el dir del app primero.
-- Para tocar la logica: editar `bash/functions/{infra,pipelines}/{resolve_cpp_app_dir,build_cpp_windows,deploy_{cpp,wails}_exe_to_windows,compile_{cpp,wails}_app}.sh`, no este wrapper.

.claude/commands/cpp-app.md

@@ -1,274 +0,0 @@
-# /cpp-app — Crear o modificar app C++ del registry sin olvidar nada
-
-Recopila TODOS los datos necesarios (frontmatter, trio app_hub, panels, AppConfig, service block, e2e_checks, uses_functions) **antes** de tocar el disco. Tras confirmar, ejecuta scaffolder o edits, regenera iconos, refresca app_hub, compila y deploya a Windows.
-
-Sustituye al flujo manual "edito main.cpp + app.md + CMakeLists.txt a mano". Wrapper sobre `init_cpp_app_bash_pipelines` (create) o edits directos sobre `app.md` (modify) + `regenerate_app_icons` + `refresh_app_hub` + `redeploy_cpp_app_windows`.
-
----
-
-## Uso
-
-```
-/cpp-app                       # interactivo, modo create
-/cpp-app <name>                # interactivo, modo create con name pre-rellenado
-/cpp-app modify <name>         # editar app existente
-```
-
----
-
-## Modo CREATE — flujo turno a turno
-
-Si `$ARGUMENTS` no empieza por `modify`, es create. Si trae `<name>`, lo usas como default; si no, pregunta name.
-
-### Paso 0 — verificar que no existe
-
-```bash
-test -d "$HOME/fn_registry/apps/<name>" \
- || ls $HOME/fn_registry/projects/*/apps/<name> 2>/dev/null
-```
-
-Si existe en cualquier ubicacion: **abortar** y sugerir `/cpp-app modify <name>`. NO sobreescribir.
-
-### Paso 1 — Identidad (AskUserQuestion)
-
-1. **name** (texto libre — valida snake_case + contiene verbo segun `ids_naming.md`). Verbos canonicos: `show, render, view, plot, edit, manage, monitor, browse, explore, run, launch, scan, audit, debug, profile, ...`. Si no trae verbo, sugerir alternativas (`viewer` -> `<name>_viewer`).
-2. **project** (select: ninguno / lista de `projects/*/`). Si ninguno -> `apps/<name>/`.
-3. **domain** (select: `tools` (default), `gfx`, `tui`, `infra`, `finance`, `datascience`, `cybersecurity`, `shell`, `pipelines`, `browser`).
-4. **description** 1 linea (texto libre, max 80 chars). **OBLIGATORIO** — sin esto el hub muestra tarjeta vacia.
-
-### Paso 2 — Trio app_hub OBLIGATORIO
-
-Regla dura `cpp_apps.md`: description + icon.phosphor + icon.accent SIEMPRE juntos.
-
-5. **icon.phosphor** glyph name. Antes de preguntar, ofrece busqueda:
-   ```bash
-   ls $HOME/fn_registry/sources/phosphor-core/assets/fill/ | grep -i "<keyword>"
-   ```
-   Sugiere 3-5 candidatos basados en `description`. Default segun domain: `gfx`->`palette`, `tui`->`terminal`, `tools`->`wrench`, `infra`->`gear`, `finance`->`chart-line-up`, `datascience`->`graph`, `cybersecurity`->`shield`.
-6. **icon.accent** hex `#rrggbb` (palette select):
-   - sky `#0ea5e9`, indigo `#4f46e5`, violet `#7c3aed`, pink `#ec4899`, rose `#f43f5e`, red `#dc2626`, orange `#ea580c`, amber `#d97706`, green `#16a34a`, teal `#0d9488`, cyan `#0891b2`, slate `#475569`. Default segun domain.
-
-### Paso 3 — Tags
-
-7. **tags** (multiSelect): `service`, `launcher`, `dashboard`, `viewer`, `editor`, `monitor`, `debug`, `prototype`. Si selecciona `service` -> activar bloque service (Paso 7).
-
-### Paso 4 — Panels iniciales
-
-8. **panels** (texto libre o select):
-   - Default: 1 panel `Main` (Ctrl+1).
-   - Opcion lista: hasta 4 paneles. Por cada uno: `{label, shortcut}`. Generara `PanelToggle k_panels[]` en `main.cpp`.
-
-### Paso 5 — AppConfig flags
-
-9. (multiSelect):
-   - `init_gl_loader` (true si la app llama `gl*` directo, ej. shaders, GPU renderer custom). Default false.
-   - `viewports` true (default) / false (single-window).
-   - `auto_dockspace` true (default) / false (solo si gestiona DockSpace propio tipo `shaders_lab`).
-   - `fps_overlay` activo de inicio? (controla solo el default; el menu Settings lo toggle).
-
-### Paso 6 — Funciones del registry a usar
-
-10. **uses_functions** lista IDs. Antes de preguntar, busca candidatas segun description:
-    ```
-    mcp__registry__fn_search query="<keyword>" entity="functions"
-    ```
-    Y muestra capability groups relevantes (`docs/capabilities/INDEX.md`). El usuario puede aceptar lista, anadir IDs, o dejar vacio (se rellena tras codear).
-
-    Cada ID que no este en el registry -> ofrecer spawn `fn-constructor` antes de continuar (regla `delegation.md`).
-
-### Paso 7 — Bloque `service:` (solo si tag=service)
-
-11. Si paso 3 marco `service`, recopilar (regla `function_tags.md` + issue 0105):
-    - `port` int o null
-    - `health_endpoint` ruta GET o null
-    - `health_timeout_s` (default 3)
-    - `runtime` (select: `systemd-user`, `systemd-system`, `docker-compose`, `stdio`, `manual`)
-    - `systemd_unit` (obligatorio si runtime empieza por `systemd-`)
-    - `systemd_scope` (`user|system|null`)
-    - `restart_policy` (select: `always` (Recommended — gotcha: `on-failure` NO reinicia SIGTERM limpio), `on-failure`, `none`)
-    - `pc_targets` (multiSelect de pc_locations actuales: `aurgi-pc`, `home-wsl`, ...)
-    - `is_local_only` (true/false default false)
-
-### Paso 8 — Persistencia
-
-12. (multiSelect):
-    - BD propia SQLite `<name>.db` en `local_files/`? -> recordar usar `fn::local_path("<name>.db")` (cpp_apps.md §7)
-    - operations.db (para entities/relations)? -> ejecutar `fn ops init` tras crear
-    - Archivos config en `local_files/`?
-
-### Paso 9 — e2e_checks (issue 0068)
-
-13. Default sugerido (modificable):
-    ```yaml
-    e2e_checks:
-      - id: build
-        cmd: "cmake --build cpp/build --target <name> -j"
-        timeout_s: 300
-      - id: self_test
-        cmd: "./cpp/build/apps/<name>/<name> --self-test"
-        timeout_s: 30
-        severity: warning  # si todavia no implementa --self-test
-    ```
-    Pregunta: ¿anadir mas checks (ops_audit, pytest, smoke)?
-
-### Paso 10 — Resumen y confirmacion
-
-Mostrar bloque YAML completo del `app.md` que se va a generar + flags del scaffolder + post-acciones. Pedir confirmacion antes de ejecutar.
-
----
-
-## Modo CREATE — ejecucion
-
-Una vez confirmado:
-
-```bash
-cd $HOME/fn_registry
-
-# 1. Scaffolder
-./fn run init_cpp_app <name> \
-  [--project <p>] \
-  [--domain <d>] \
-  --desc "<description>" \
-  [--tags "<csv>"]
-
-# 2. Editar app.md generado para anadir:
-#    - icon: {phosphor, accent}
-#    - service: {...}  (si aplica)
-#    - uses_functions: [...]
-#    - e2e_checks: [...]
-#    (el scaffolder no rellena estos; editarlos con Edit tool)
-
-# 3. Editar main.cpp generado para reflejar:
-#    - panels[] custom (si != default)
-#    - cfg.init_gl_loader / cfg.auto_dockspace / cfg.viewports
-#    - includes de funciones registry usadas
-
-# 4. Editar CMakeLists.txt para anadir paths de funciones del registry:
-#    ${CMAKE_SOURCE_DIR}/functions/<d>/<f>.cpp
-
-# 5. Si es service -> ofrecer crear systemd unit (skipear si runtime=stdio|manual)
-
-# 6. Si pidio operations.db
-./fn ops init apps/<name>  # o projects/<p>/apps/<name>
-
-# 7. Generar icono
-./fn run generate_app_icon "<phosphor>" "<accent>" "<dir>/appicon.ico"
-
-# 8. Indexar
-./fn index
-
-# 9. Compilar Windows
-./fn run redeploy_cpp_app_windows <name> <dir> --build
-
-# 10. Refrescar app_hub
-./fn run refresh_app_hub
-
-# 11. Auditoria
-./fn doctor cpp-apps
-[[ "<tag>" == *service* ]] && ./fn doctor services-spec
-```
-
----
-
-## Modo MODIFY — flujo
-
-`/cpp-app modify <name>`
-
-### Paso 0 — Localizar
-
-```bash
-# Buscar apps/<name>/ o projects/*/apps/<name>/
-sqlite3 $HOME/fn_registry/registry.db \
-  "SELECT id, dir_path FROM apps WHERE name='<name>' AND lang='cpp';"
-```
-
-Si no existe: abortar, sugerir `/cpp-app` (sin args) para crear.
-
-### Paso 1 — Mostrar config actual
-
-```bash
-mcp__registry__fn_show id="<id>"
-cat <dir>/app.md
-```
-
-### Paso 2 — Que cambiar (multiSelect)
-
-- `description` (1 linea)
-- `icon.phosphor` o `icon.accent`
-- `tags` (anadir/quitar; si toca `service` -> Paso 7 del create)
-- `uses_functions` (anadir/quitar — recordar editar CMakeLists.txt)
-- `panels` (anadir/quitar/renombrar)
-- `service:` block (si tag=service)
-- `e2e_checks`
-- `domain`
-- `rename` (cambia name, dir, IDs derivados, repo Gitea — operacion delicada, requiere doble confirmacion)
-
-### Paso 3 — Aplicar cambios
-
-Para cada cambio: usa `Edit` sobre los archivos correspondientes. NUNCA `Write` completo de `app.md` (preserva campos que no toques).
-
-### Paso 4 — Post-acciones (segun lo que toco)
-
-```bash
-# Siempre
-cd $HOME/fn_registry && ./fn index
-
-# Si toco icon.* -> regenerar appicon
-./fn run generate_app_icon "<phosphor>" "<accent>" "<dir>/appicon.ico"
-
-# Si toco trio o panels o uses_functions o cambia code:
-./fn run redeploy_cpp_app_windows <name> <dir> --build
-
-# Si toco description o icon o tags:
-./fn run refresh_app_hub
-
-# Si toco service: o tag service
-./fn doctor services-spec
-
-# Siempre al final
-./fn doctor cpp-apps
-```
-
----
-
-## Reglas duras
-
-- **NUNCA** crear `main.cpp` + `CMakeLists.txt` + `app.md` a mano. Siempre via `init_cpp_app_bash_pipelines` (regla `cpp_apps.md`).
-- **NUNCA** poner el codigo en `cpp/apps/<n>/`. Solo `apps/<n>/` o `projects/<p>/apps/<n>/`.
-- **NUNCA** dejar `app.md` sin el trio (description + icon.phosphor + icon.accent). Tarjeta del hub queda gris.
-- **NUNCA** declarar funciones del registry en `uses_functions` sin listar su `.cpp` en `CMakeLists.txt` (drift detectado por `fn doctor uses-functions`).
-- **NUNCA** usar `Restart=on-failure` en systemd unit de un service C++ — gotcha 2026-05-17 (`sqlite_api.service` cayo 20h). Default `Restart=always`.
-- Despues de **cualquier** cambio en el trio: `regenerate_app_icons <name>` + `refresh_app_hub`.
-
----
-
-## Auto-verificacion final
-
-Tras crear o modificar, reportar al usuario:
-
-```
-=== app <name> ===
-dir:           <abs_dir>
-domain:        <d>
-description:   "<desc>"
-icon:          <phosphor> + <accent>
-tags:          [<csv>]
-uses_functions: N funciones (<list_top_5>)
-panels:        N (<labels>)
-e2e_checks:    N checks
-service:       <si/no — port:<p> health:<h>>
-
-Acciones ejecutadas:
-  [✓] scaffolder / edits
-  [✓] generate_app_icon
-  [✓] fn index            (registry.db actualizado)
-  [✓] redeploy_cpp_app_windows  (Desktop/apps/<name>/<name>.exe)
-  [✓] refresh_app_hub     (tarjeta visible en hub)
-  [✓] fn doctor cpp-apps  (limpio | N warnings)
-
-Siguiente paso sugerido:
-  - Abrir app_hub_launcher en Windows y verificar tarjeta
-  - Anadir tests visuales si la app tiene paneles propios (cpp/PATTERNS.md §11)
-```
-
-$ARGUMENTS

.claude/commands/create_functions.md

@@ -38,19 +38,19 @@ Consultar `registry.db` para encontrar funciones existentes relevantes y evitar
 
 ```bash
 # Buscar funciones similares por nombre y descripcion (OBLIGATORIO — usar multiples terminos)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, lang, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO1* OR description:TERMINO1* OR name:TERMINO2* OR description:TERMINO2*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, lang, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:TERMINO1* OR description:TERMINO1* OR name:TERMINO2* OR description:TERMINO2*') ORDER BY name;"
 
 # Buscar tipos relacionados
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, algebraic, lang, description FROM types WHERE id IN (SELECT id FROM types_fts WHERE types_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, algebraic, lang, description FROM types WHERE id IN (SELECT id FROM types_fts WHERE types_fts MATCH 'name:TERMINO* OR description:TERMINO*') ORDER BY name;"
 
 # Funciones del dominio objetivo
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, signature, description FROM functions WHERE domain = 'DOMINIO' AND lang = 'LANG' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, signature, description FROM functions WHERE domain = 'DOMINIO' AND lang = 'LANG' ORDER BY name;"
 
 # Tipos del dominio objetivo
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE domain = 'DOMINIO' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, algebraic, description FROM types WHERE domain = 'DOMINIO' ORDER BY name;"
 
 # Funciones que podrian componerse (misma firma de retorno)
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, purity, signature FROM functions WHERE returns LIKE '%TIPO%' OR signature LIKE '%TIPO%' ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, purity, signature FROM functions WHERE returns LIKE '%TIPO%' OR signature LIKE '%TIPO%' ORDER BY name;"
 ```
 
 **Clasificar resultados en:**
@@ -103,7 +103,7 @@ Para cada batch del plan, lanzar agentes `fn-constructor` **en paralelo** (un ag
 Usar el Agent tool con `subagent_type: "fn-constructor"` pasando un prompt completo con:
 
 ```
-Crea la siguiente funcion para el registry fn_registry en $HOME/fn_registry:
+Crea la siguiente funcion para el registry fn_registry en /home/lucas/fn_registry:
 
 Funcion: {nombre}
 Kind: {kind}
@@ -149,7 +149,7 @@ Despues de que TODOS los fn-constructor terminen:
 
 ```bash
 # Indexar todo de una vez
-cd $HOME/fn_registry && ./fn index
+cd /home/lucas/fn_registry && ./fn index
 ```
 
 Si el indexer reporta errores, corregirlos antes de continuar. Errores comunes:
@@ -166,7 +166,7 @@ Si el indexer reporta errores, corregirlos antes de continuar. Errores comunes:
 
 ```bash
 # Verificar cada funcion creada
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 ./fn show {id_de_cada_funcion}
 
 # Verificar que no hay funciones sin params_schema
@@ -178,7 +178,7 @@ cd $HOME/fn_registry
 Para cada funcion con tests, ejecutar:
 
 ```bash
-cd $HOME/fn_registry
+cd /home/lucas/fn_registry
 
 # Go
 CGO_ENABLED=1 go test -tags fts5 -v -run TestNombreDelTest ./functions/{domain}/
@@ -197,13 +197,13 @@ bash bash/functions/{domain}/{nombre}_test.sh
 
 ```bash
 # Verificar que todas las funciones nuevas estan en la BD
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, kind, purity, tested FROM functions WHERE id IN ('id1','id2','id3') ORDER BY name;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, kind, purity, tested FROM functions WHERE id IN ('id1','id2','id3') ORDER BY name;"
 
 # Verificar que los tests estan indexados
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, function_id, name FROM unit_tests WHERE function_id IN ('id1','id2','id3') ORDER BY function_id;"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, function_id, name FROM unit_tests WHERE function_id IN ('id1','id2','id3') ORDER BY function_id;"
 
 # Verificar dependencias
-sqlite3 $HOME/fn_registry/registry.db "SELECT id, uses_functions, uses_types FROM functions WHERE id IN ('id1','id2','id3') AND uses_functions != '[]';"
+sqlite3 /home/lucas/fn_registry/registry.db "SELECT id, uses_functions, uses_types FROM functions WHERE id IN ('id1','id2','id3') AND uses_functions != '[]';"
 ```
 
 ### 6.4 Si algo fallo

.claude/commands/documentar.md

@@ -1,260 +0,0 @@
-# /documentar — Distribuir la conversacion en la documentacion del registry
-
-Documenta la **conversacion actual** repartiendo el contenido en TODOS los `.md` que correspondan: artefactos del registry (funciones, tipos, apps, projects, analysis, vaults) **y documentacion global del repo** (`docs/*`, `docs/adr/`, `CHANGELOG.md`, `dev/issues/*`, `.claude/rules/*`, `.claude/CLAUDE.md`, sub-CLAUDEs, READMEs/SPECs en apps). Cierra con una entrada en `/entrada_diario`. El objetivo es que **otro LLM (o yo en otra sesion) pueda continuar** sin haber visto la conversacion: contexto, decisiones, gotchas, paths, IDs, comandos exactos, "lo siguiente que pega".
-
-## Uso
-
-```
-/documentar                       # documenta todo lo relevante de la sesion
-/documentar shaders_lab fase 6    # acota a artefactos/temas concretos (opcional)
-```
-
-`$ARGUMENTS` es opcional: si va vacio, documenta toda la sesion. Si lleva texto, usalo como hilo conductor para decidir que es relevante.
-
----
-
-## Reglas duras
-
-1. **NUNCA** escribir secretos en ningun `.md` ni en el diario:
-   - Passwords, tokens, API keys, GPG keys, ssh private keys, valores reales de variables de entorno sensibles (`REGISTRY_API_TOKEN`, `*_SECRET`, `*_PASSWORD`, `*_TOKEN`, basicAuth en URLs).
-   - Si el usuario lo pide explicitamente, OK. Por defecto, redactar como `<token>` / `<password>` o referenciar el origen (`pass entry registry_api`, `~/.fn_pc`).
-   - URLs publicas, hosts, puertos, paths, IDs, nombres de servicios, env var **names** (no values), licencias, hashes de commit cortos: SI se documentan.
-2. **NUNCA** sobreescribir secciones existentes ni reordenar contenido previo. Solo **append** o seccion nueva con timestamp/fase si encaja.
-3. **SIEMPRE** consultar `registry.db` con FTS5 para encontrar el `.md` correcto antes de editar (no asumir paths).
-4. **SIEMPRE** cerrar invocando `/entrada_diario` con un resumen del bloque (a no ser que el usuario diga lo contrario).
-5. **Densidad util > prosa**: comandos exactos, IDs del registry, paths relativos, error messages literales, flags de build, decisiones (con el "porque"), bugs encontrados (con el fix), proximos pasos. Sin fluff.
-
----
-
-## PASO 0 — Recopilar el material de la sesion
-
-Antes de escribir nada, repasar la conversacion y juntar:
-
-1. **Artefactos tocados** (creados, editados, ejecutados, mencionados):
-   - Funciones / tipos del registry → IDs `{name}_{lang}_{domain}`.
-   - Apps (`apps/*` o `projects/*/apps/*`).
-   - Projects (`projects/*`).
-   - Analyses (`analysis/*` o `projects/*/analysis/*`).
-   - Vaults (`projects/*/vaults/vault.yaml`).
-   - Reglas (`.claude/rules/*.md`), ADRs (`docs/adr/*.md`), templates (`docs/templates/*`).
-   - Issues (`dev/issues/*.md`, `dev/issues/completed/*.md`).
-   - Docs globales (`docs/*.md`: architecture, integrity, execution_standard, fn_operations, sync_setup, init-pipelines, testing, functions, types, fn-registry-system-complete).
-   - CLAUDE.md raiz (`.claude/CLAUDE.md`) y sub-CLAUDEs (`apps/*/.claude/CLAUDE.md`, `projects/*/apps/*/.claude/CLAUDE.md`, `analysis/*/.claude/CLAUDE.md`, `projects/*/analysis/*/.claude/CLAUDE.md`).
-   - Docs sueltas en apps (`apps/*/SPEC.md`, `apps/*/README.md`, `apps/*/docs/*.md`, `cpp/DESIGN_SYSTEM.md`).
-   - `CHANGELOG.md` raiz.
-
-2. **Cambios concretos** desde git:
-   ```bash
-   cd $HOME/fn_registry
-   git status --short
-   git diff --stat
-   git log --since="6 hours ago" --oneline
-   ```
-   Cada path modificado mapea a un artefacto — convertir a su `.md`.
-
-3. **Material no codigo** que vale la pena dejar registrado:
-   - Decisiones de diseño y por que (anti-bitrot: el porque suele perderse).
-   - Bugs encontrados + raiz + fix (no solo "fix").
-   - Atajos / convenciones nuevas.
-   - Pendientes y "lo siguiente que pega" para la proxima sesion.
-   - Aprendizajes operativos (build flags, cross-compile gotchas, env requerido).
-
-4. **Filtrar secretos** segun la regla dura #1.
-
-Si el material es solo conversacion exploratoria sin artefactos tocados, ir directo a PASO 4 (solo diary).
-
----
-
-## PASO 1 — Mapear cada bloque de informacion a su `.md`
-
-Para cada artefacto identificado, localizar su `.md` consultando `registry.db`:
-
-```bash
-cd $HOME/fn_registry
-
-# Funcion / tipo
-sqlite3 registry.db "SELECT id, file_path FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:NAME* OR description:NAME*');"
-sqlite3 registry.db "SELECT id, file_path FROM types     WHERE id IN (SELECT id FROM types_fts     WHERE types_fts     MATCH 'name:NAME* OR description:NAME*');"
-
-# App / project / analysis (los .md son nombres fijos)
-sqlite3 registry.db "SELECT id, dir_path FROM apps      WHERE name = 'NAME';"  # → {dir_path}/app.md
-sqlite3 registry.db "SELECT id, dir_path FROM projects  WHERE name = 'NAME';"  # → projects/NAME/project.md
-sqlite3 registry.db "SELECT id, dir_path FROM analysis  WHERE name = 'NAME';"  # → {dir_path}/analysis.md
-sqlite3 registry.db "SELECT id, name, path FROM vaults  WHERE name = 'NAME';"  # → vault.yaml entry
-```
-
-Si el `.md` aun no existe (artefacto recien creado en la sesion y todavia no indexado), el path se deduce de la convencion:
-- Funcion: `functions/{domain}/{name}.md`, `python/functions/{domain}/{name}.md`, `bash/functions/{domain}/{name}.md`, `frontend/functions/{domain}/{name}.md`, `cpp/functions/{domain}/{name}.md`.
-- Tipo: `types/{domain}/{name}.md` (codigo en `functions/{domain}/{name}.go`).
-- App: `apps/{name}/app.md` o `projects/{proyecto}/apps/{name}/app.md`.
-- Project: `projects/{name}/project.md`.
-- Analysis: `analysis/{name}/analysis.md` o `projects/{proyecto}/analysis/{name}/analysis.md`.
-
-### Donde escribir dentro de cada `.md`
-
-| Tipo de `.md`         | Seccion preferida para append                                                                                  |
-|-----------------------|----------------------------------------------------------------------------------------------------------------|
-| Funcion / tipo        | `## Notas` al final. Si no existe, crearla. NO tocar el frontmatter salvo que el usuario pida cambiar metadata. |
-| App (`app.md`)        | `## Estado actual` con sub-fases si el app ya las usa (ej. `### Fase 7 — ... [done]`). Si no, `## Notas`. Tambien `## Lo siguiente que pega` para futuros pasos. |
-| Project (`project.md`)| `## Notas` o seccion del area afectada (`## Apps`, `## Operacion`, `## Troubleshooting`). |
-| Analysis (`analysis.md`)| `## Notas` o `## Hallazgos` (crearla si no existe).                                                         |
-| Vault (`vault.yaml`)  | Comentario al final del entry o crear `vaults/{name}/README.md` con notas operativas (NO meter datos sensibles). |
-| Regla (`.claude/rules/*`)| Solo si el usuario explicitamente formaliza una regla nueva — entonces archivo nuevo + entrada en `INDEX.md`. |
-| ADR (`docs/adr/*`)    | Solo si la decision es arquitectural y persistente — archivo nuevo numerado.                                   |
-
-### Documentacion global / cross-cutting (NO saltarse)
-
-Estos `.md` describen el sistema entero, no un artefacto concreto. Cuando un cambio impacta convenciones, comportamiento de agentes, decisiones, issues abiertos o features visibles al usuario, **tambien** se actualizan aqui:
-
-| Archivo / carpeta                     | Cuando tocarlo                                                                                                  | Como                                                                                              |
-|---------------------------------------|-----------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------|
-| `CHANGELOG.md` (raiz)                 | Cambio visible al usuario o agentes: nueva funcion/pipeline/app, breaking change, fix relevante, rename, deprecate. | Append bajo seccion del dia (`## YYYY-MM-DD`) con `### Added/Changed/Fixed/Removed/Deprecated`. NUNCA reescribir entradas previas. Si es trabajo en curso, usar `## [Unreleased]`. |
-| `docs/adr/NNNN-slug.md`               | **Decision arquitectural** persistente con alternativas descartadas (no es regla operativa, es historia del por que). | Archivo nuevo numerado siguiendo plantilla en `docs/adr/README.md`. Estado inicial: `accepted` o `proposed`. |
-| `docs/architecture.md`                | Cambia la arquitectura general (BDs, layers, flujo de datos, capas).                                             | Append en seccion afectada o nueva subseccion. Mantener tablas y diagramas existentes.            |
-| `docs/integrity.md`                   | Nueva regla de integridad / referencia cruzada que el indexer valida.                                            | Append a la lista de reglas. Reflejar tambien en codigo del indexer si toca.                      |
-| `docs/execution_standard.md`          | Cambia el estandar de ejecucion (`fn run`, despacho por lenguaje, env vars).                                     | Append seccion. Sincronizar con `.claude/CLAUDE.md` si menciona los mismos comandos.              |
-| `docs/sync_setup.md`                  | Cambia el flujo de `fn sync`, env vars (`FN_REGISTRY_API`, `REGISTRY_API_TOKEN`), `~/.fn_pc`, troubleshooting.   | Append. Recordatorio: NO escribir el valor del token, solo el nombre.                             |
-| `docs/init-pipelines.md`              | Nuevo pipeline de scaffolding o cambio en uno existente.                                                          | Append seccion del pipeline.                                                                       |
-| `docs/testing.md`                     | Cambia convencion de tests, runners, layout de `*_test.go`/`test_*.py`.                                          | Append seccion afectada.                                                                           |
-| `docs/functions.md` / `docs/types.md` | Cambia el schema de la tabla `functions` o `types` (columnas, FTS5, enums, `params_schema`).                     | Append. Sincronizar con `.claude/CLAUDE.md` schema rapido.                                         |
-| `docs/fn_operations.md`               | Cambia el schema/comportamiento de `operations.db` o el bucle reactivo (entities, relations, executions, assertions). | Append seccion afectada.                                                                       |
-| `docs/fn-registry-system-complete.md` | Snapshot completo del sistema — solo si la sesion implico un rediseño grande. Normalmente NO se toca por sesion. | Si toca, append seccion con timestamp.                                                             |
-| `docs/templates/*.md`                 | Cambia el frontmatter obligatorio de un tipo de artefacto (function/pipeline/component/type/app/project/analysis). | Editar la plantilla correspondiente. Tambien actualizar ejemplos en `.claude/CLAUDE.md`.          |
-| `dev/issues/NNNN-*.md`                | Sesion trabajo en un issue: progreso, blockers, decisiones del scope.                                             | Append `## Notas / Progreso` con timestamp. NO mover de `dev/issues/` a `dev/issues/completed/` salvo que el issue cierre. |
-| `dev/issues/completed/NNNN-*.md`      | Issue completado en esta sesion.                                                                                  | Mover el archivo a `completed/` (`git mv`) y actualizar la fila en `dev/issues/README.md` (estado `completado`, link a `completed/...`). |
-| `dev/issues/README.md`                | Issue creado, cambia estado, prioridad, dependencias.                                                              | Editar la fila correspondiente o anadir nueva al final de la tabla.                               |
-| `.claude/rules/*.md` + `INDEX.md`     | El usuario formaliza una nueva regla operativa.                                                                    | Archivo nuevo + fila en `INDEX.md`. Numerar en el indice manteniendo orden.                       |
-| `.claude/CLAUDE.md` (raiz)            | Cambio en convenciones globales del proyecto, comandos `fn` nuevos, env vars, estructura de carpetas, schema BDs. | Append en seccion afectada. Sincronizar con `docs/` si hay overlap.                               |
-| Sub-CLAUDE (`apps/*/.claude/CLAUDE.md`, `analysis/*/.claude/CLAUDE.md`, `projects/*/apps/*/.claude/CLAUDE.md`) | Cambio especifico en como un agente debe trabajar dentro de esa app/analysis (no global).        | Append. NO duplicar reglas que ya estan en CLAUDE.md raiz.                                        |
-| `cpp/DESIGN_SYSTEM.md`                | Cambia tokens, layout, primitivas visuales del stack C++.                                                          | Append seccion afectada.                                                                           |
-| `apps/*/SPEC.md`, `apps/*/README.md`, `apps/*/docs/*.md`, `apps/*/NEXT_STEPS_*.md` | App tiene docs propias mas alla de `app.md`.                                          | Append. Si el contenido encaja mejor en `app.md`, preferir `app.md` y mencionar el SPEC desde ahi. |
-
-### Reglas de decision rapidas
-
-- **¿Cambio visible / breaking / nueva feature?** → `CHANGELOG.md` SI.
-- **¿Decision con alternativas descartadas?** → ADR SI. Una regla operativa "haz X" sin alternativas → `.claude/rules/`.
-- **¿Cambia como un agente debe comportarse?** → `.claude/rules/` o `.claude/CLAUDE.md` (global) o sub-CLAUDE (local).
-- **¿Cambia el schema de BDs o columnas?** → `docs/functions.md`/`docs/types.md`/`docs/fn_operations.md` + `.claude/CLAUDE.md` schema rapido.
-- **¿Trabajo en un issue?** → `dev/issues/NNNN-*.md` + tabla en `dev/issues/README.md`.
-- **¿Cross-cutting sin artefacto y sin encajar arriba?** → solo diario (PASO 4).
-
----
-
-## PASO 2 — Escribir las actualizaciones
-
-Para cada `.md` identificado:
-
-1. `Read` el archivo para ver estructura actual y secciones.
-2. Decidir si **append a seccion existente** o **crear seccion nueva**.
-3. Usar `Edit` para append (preferible) o `Write` solo si es archivo nuevo.
-4. **Mantener el estilo** del archivo (markdown, viñetas cortas, bloques de codigo con lenguaje).
-5. **No tocar el frontmatter** salvo que el usuario haya cambiado metadata explicita (`description`, `tags`, `uses_functions`, `version`). Si se toca, re-indexar al final.
-
-### Plantilla de bloque para append en `.md` de artefacto
-
-```markdown
-
-### {Fase / Tema corto} `[done|wip|notes]`
-
-{1-3 lineas de contexto: que se hizo y por que.}
-
-- Hecho: {cambio concreto, con path y/o ID si aplica}.
-- Hecho: {cambio concreto}.
-- Bug + fix: {sintoma → raiz → fix} (si procede).
-- Decision: {opcion elegida vs alternativa} — porque {razon} (si procede).
-- Pendiente: {algo que queda} (si procede).
-
-{Comando(s) exacto(s) si la operacion vale la pena reproducir.}
-```
-
-### Plantilla para `## Lo siguiente que pega` (apps maduras)
-
-```markdown
-- {Tarea proxima}: {contexto minimo, que tocar, criterio de hecho}.
-```
-
----
-
-## PASO 3 — Reindexar si tocaste frontmatter o creaste artefacto
-
-Si los cambios de la sesion incluyen creacion de funciones/tipos/apps/projects/analysis/vaults o modificacion de frontmatter:
-
-```bash
-cd $HOME/fn_registry && ./fn index
-```
-
-Y verificar:
-
-```bash
-./fn show {id_creado_o_modificado}
-```
-
-Si solo se editaron secciones de prosa (Notas, Estado actual, etc.) sin tocar frontmatter, el indexado igual recoge `documentation`/`notes` actualizados — re-indexar es barato y deja la BD coherente.
-
----
-
-## PASO 4 — Cerrar con entrada al diario
-
-Invocar `/entrada_diario` con un resumen conciso de la sesion (3-6 viñetas, verbos en pasado para lo hecho, infinitivo para pendientes). Referenciar:
-
-- IDs de artefactos tocados.
-- Paths relativos clave.
-- Hashes de commit cortos si la sesion termino con commits.
-- ADRs / issues / proposals abiertos.
-
-Ejemplo de invocacion:
-
-```
-/entrada_diario shaders_lab fase 6 — menubar reusable (View + Layouts) cableado, persistencia de layouts en shaders_lab.db
-```
-
-Si el usuario ya invoco `/entrada_diario` antes en esta sesion para este bloque, **no duplicar**: solo añadir lo que no estaba.
-
----
-
-## PASO 5 — Reportar al usuario
-
-Resumen breve (formato texto, no tabla a no ser que sean muchos):
-
-```
-=== DOCUMENTADO ===
-
-Artefactos (.md de registry):
-  - apps/shaders_lab/app.md           (Fase 6 — menubar)
-  - cpp/functions/core/app_menubar.md (notas de uso)
-  - cpp/functions/core/layouts_menu.md (notas de cableado)
-
-Globales:
-  - CHANGELOG.md                      (Added: app_menubar, layouts_menu)
-  - docs/adr/0002-menubar-arch.md     (nuevo ADR — decision menubar reusable)
-  - dev/issues/README.md              (issue 0027 → completado)
-  - dev/issues/completed/0027-...md   (movido)
-  - .claude/rules/cpp_icons.md        (regla nueva, anadida a INDEX.md)
-
-Diario:  docs/diary/2026-04-25.md  (## 18:30 — ...)
-
-Re-indexado: si | no
-Pendientes registrados: {N}
-Secretos omitidos: {lista de tipos redactados, ej. "REGISTRY_API_TOKEN"}
-```
-
----
-
-## Checklist final
-
-- [ ] Cada artefacto tocado tiene su `.md` actualizado (append, no overwrite).
-- [ ] Ningun secreto, password, token o key en los archivos.
-- [ ] Comandos exactos, IDs y paths para que otro LLM reproduzca.
-- [ ] Decisiones con su "porque", bugs con su raiz+fix.
-- [ ] `CHANGELOG.md` actualizado si el cambio es visible al usuario / agentes.
-- [ ] ADR creado (`docs/adr/NNNN-*.md`) si hay decision arquitectural con alternativas descartadas.
-- [ ] `dev/issues/*.md` y `dev/issues/README.md` actualizados si la sesion toco issues.
-- [ ] `docs/{architecture,integrity,functions,types,fn_operations,execution_standard,sync_setup,init-pipelines,testing}.md` actualizado si el cambio afecta lo que cada uno documenta.
-- [ ] `.claude/CLAUDE.md` raiz actualizado si cambian convenciones / comandos / schema globales.
-- [ ] `.claude/rules/*` + `INDEX.md` actualizado si el usuario formaliza una regla nueva.
-- [ ] Sub-CLAUDE de la app/analysis afectada actualizado si cambia comportamiento agente local.
-- [ ] `/entrada_diario` invocado con resumen de la sesion.
-- [ ] `./fn index` corrido si hubo creacion o cambio de frontmatter.
-- [ ] Reporte final al usuario con la lista de archivos tocados (artefactos + globales).
-
-$ARGUMENTS

.claude/commands/e2e-cpp.md

@@ -1,227 +0,0 @@
-# /e2e-cpp — Crear/ejecutar tests e2e para apps C++
-
-Genera y corre tests e2e con **Dear ImGui Test Engine** sobre las apps C++ del registry. Cada app gana un ejecutable `<app>_tests` que reabre la app dentro de un harness de testing y ejecuta scripts de UI (clicks, escritura, asserts) sobre los componentes ImGui.
-
-Suite ya instalada en `cpp/vendor/imgui_test_engine/`. Integracion en framework: `fn::run_app_test()` (ver `cpp/framework/app_base.h`). Opt-in via `-DFN_BUILD_TESTS=ON`. Sin la opcion los builds normales de `/compile` no cambian.
-
-## Argumento
-
-`$ARGUMENTS` — formato libre. Casos:
-
-- `<app_name>` — solo el nombre. Si la app ya tiene tests, los ejecuta. Si no, pide al usuario que describa el flujo a testear.
-- `<app_name> <descripcion del flujo>` — genera un test nuevo para ese flujo y lo ejecuta. Ej: `chart_demo abrir cada tab y verificar que renderiza`.
-- vacio — detectar app desde `pwd` (si estas en `cpp/apps/<X>/` o `projects/*/apps/<X>/`); si no, listar apps disponibles.
-
-## Pasos
-
-### 1. Resolver app y directorio
-
-```bash
-ROOT=$HOME/fn_registry
-ARGS="$ARGUMENTS"
-APP_ARG="${ARGS%% *}"   # primera palabra
-FLOW_DESC="${ARGS#* }"  # resto (puede coincidir con APP_ARG si solo hay una palabra)
-[ "$FLOW_DESC" = "$APP_ARG" ] && FLOW_DESC=""
-
-# Detectar desde CWD si no hay arg
-if [ -z "$APP_ARG" ]; then
-  CWD="$(pwd)"
-  case "$CWD" in
-    "$ROOT"/cpp/apps/*|"$ROOT"/projects/*/apps/*)
-      APP_ARG="$(basename "$CWD")" ;;
-  esac
-fi
-
-if [ -z "$APP_ARG" ]; then
-  echo "Apps C++ disponibles:"
-  ls "$ROOT"/cpp/apps/ 2>/dev/null
-  ls "$ROOT"/projects/*/apps/ 2>/dev/null
-  echo "Uso: /e2e-cpp <app> [descripcion del flujo]"
-  exit 1
-fi
-
-APP_DIR=""
-for cand in "$ROOT/cpp/apps/$APP_ARG" "$ROOT"/projects/*/apps/"$APP_ARG"; do
-  [ -d "$cand" ] && [ -f "$cand/CMakeLists.txt" ] && APP_DIR="$cand" && break
-done
-[ -z "$APP_DIR" ] && { echo "App C++ no encontrada: $APP_ARG"; exit 1; }
-echo "App: $APP_ARG"
-echo "Dir: $APP_DIR"
-```
-
-### 2. Inspeccionar la app
-
-Lee:
-- `$APP_DIR/main.cpp` — identifica:
-  - El nombre de la funcion principal de render (suele ser `render()` o `static void render()`).
-  - El **window title** que aparece en `ImGui::Begin("...")` — sera el primer arg de `ctx->SetRef("...")` en los tests. Si tiene em-dash u otros UTF-8 no ASCII, anotar la secuencia de bytes (ej: `\xe2\x80\x94` para `—`).
-  - Los IDs/labels de los widgets candidatos: tabs (`BeginTabItem`), botones (`Button`), inputs (`InputText`), checkboxes, etc.
-- `$APP_DIR/app.md` — para entender el dominio y proposito.
-- `$APP_DIR/CMakeLists.txt` — para saber que `.cpp` del registry enlaza la app (los tests linkearan los mismos).
-
-### 3. Decidir tests a escribir
-
-**Si `$FLOW_DESC` esta vacio**: pregunta al usuario que flujo testear. Sugiere 2-3 candidatos basados en los widgets vistos en main.cpp. NO inventes flujos sin confirmacion.
-
-**Si `$FLOW_DESC` viene en el comando**: convierte la descripcion en una secuencia de pasos atomicos del Test Context API. Ejemplos canonicos:
-
-| Descripcion humano | Llamada Test Engine |
-|---|---|
-| "abrir tab X" | `ctx->ItemClick("##tabs/X")` o el path real del TabBar |
-| "escribir 'hola' en el input search" | `ctx->ItemInput("Search", "hola")` |
-| "click boton Aceptar" | `ctx->ItemClick("Aceptar")` |
-| "verificar que aparece el modal Y" | `IM_CHECK(ctx->WindowInfo("Y").ID != 0)` |
-| "checkbox Z marcado" | `IM_CHECK(ctx->ItemIsChecked("Z"))` |
-| "menu File > Open" | `ctx->MenuClick("File/Open")` |
-
-Ver `cpp/vendor/imgui_test_engine/imgui_te_context.h` para el catalogo completo de helpers.
-
-### 4. Preparar la app para tests (idempotente)
-
-Si es la primera vez que la app gana tests, hay que:
-
-**a) Hacer la funcion render() linkable desde otra TU**
-
-```cpp
-// Antes:    static void render() { ... }
-// Despues:  void render() { ... }
-```
-
-**b) Excluir `int main()` con guarda `FN_TEST_BUILD`**
-
-```cpp
-#ifndef FN_TEST_BUILD
-int main() {
-    return fn::run_app({...}, render);
-}
-#endif
-```
-
-Verifica con `grep -n "FN_TEST_BUILD\|^static void render" "$APP_DIR/main.cpp"`. Si ya esta, no toques nada.
-
-### 5. Generar/extender el archivo de tests
-
-`$APP_DIR/tests/<app>_tests.cpp` — un solo archivo por app, varias `IM_REGISTER_TEST` dentro de `register_tests()`.
-
-**Plantilla**:
-
-```cpp
-// E2E tests para <app> — Dear ImGui Test Engine.
-// Construido solo con -DFN_BUILD_TESTS=ON. Reusa el mismo main.cpp con
-// FN_TEST_BUILD definido para excluir su int main().
-
-#include "app_base.h"
-#include "imgui.h"
-#include "imgui_te_engine.h"
-#include "imgui_te_context.h"
-
-void render();   // definido en <app>/main.cpp
-
-static void register_tests(ImGuiTestEngine* e) {
-    ImGuiTest* t = nullptr;
-
-    t = IM_REGISTER_TEST(e, "<app>", "<test_name>");
-    t->TestFunc = [](ImGuiTestContext* ctx) {
-        ctx->SetRef("<window_title_exacto>");
-        // ... pasos del flujo
-    };
-
-    // mas tests aqui
-}
-
-int main() {
-    fn::AppConfig cfg{};
-    cfg.title  = "<app>_tests";
-    cfg.width  = 1280;
-    cfg.height = 800;
-    return fn::run_app_test(cfg, render, register_tests);
-}
-```
-
-Si el archivo ya existe: **AGREGA** un nuevo `IM_REGISTER_TEST` dentro de la funcion `register_tests` existente. NO sobreescribas tests previos.
-
-### 6. Actualizar CMakeLists.txt (idempotente)
-
-Si `$APP_DIR/CMakeLists.txt` no tiene aun el bloque de tests, agregar al final:
-
-```cmake
-# --- E2E tests (opt-in via -DFN_BUILD_TESTS=ON) ---
-if(FN_BUILD_TESTS)
-    add_imgui_app(<app>_tests
-        main.cpp
-        tests/<app>_tests.cpp
-        # mismos .cpp del registry que la app principal
-        ${CMAKE_SOURCE_DIR}/functions/<dom>/<func>.cpp
-        ...
-    )
-    target_compile_definitions(<app>_tests PRIVATE FN_TEST_BUILD)
-endif()
-```
-
-Las fuentes deben replicar las del target principal (mismas funciones del registry). Si la app ya tiene un bloque `if(FN_BUILD_TESTS)`, no lo dupliques.
-
-### 7. Build
-
-```bash
-cd "$ROOT/cpp"
-cmake -S . -B build/linux_tests -DFN_BUILD_TESTS=ON 2>&1 | tail -5
-cmake --build build/linux_tests --target ${APP_ARG}_tests -j4 2>&1 | tail -20
-```
-
-Si el build falla:
-- Errores de compilacion en `tests/...cpp` → revisa nombres de widgets/paths con el codigo real de main.cpp.
-- "undefined reference to render" → falta quitar `static` o falta el `#ifndef FN_TEST_BUILD` en main.cpp.
-- "multiple definition of main" → falta el `target_compile_definitions(... FN_TEST_BUILD)` en CMakeLists.
-
-### 8. Ejecutar (headless preferente — sin parpadeo)
-
-`fn::run_app_test` crea la ventana GLFW **oculta por defecto** (`GLFW_VISIBLE=FALSE`, ver `cpp/framework/app_base.cpp`). El contexto GL real se crea igual, así que el render que ejercita el Test Engine es fiel, pero la ventana nunca se mapea en pantalla: cero parpadeo, no roba foco. Por eso los tests de frontend C++ corren headless por defecto, sin tocar el código de cada app.
-
-Dos formas de lanzar, según el entorno:
-
-```bash
-cd "$ROOT/cpp/build/linux_tests"
-TEST_BIN="$(find . -name "${APP_ARG}_tests" -type f -executable | head -1)"
-[ -z "$TEST_BIN" ] && { echo "no encuentro el binario de tests"; exit 1; }
-
-if [ -n "$DISPLAY" ] && command -v glxinfo >/dev/null 2>&1 \
-   && glxinfo 2>/dev/null | grep -q "OpenGL core profile version"; then
-  # Host con GL nativo (PC enmanuel, X11 + GPU): binario directo.
-  # La ventana ya nace oculta -> sin parpadeo, y usa la GPU real (rapido).
-  timeout 90 "$TEST_BIN" 2>&1
-else
-  # CI / WSL sin GLX 4.3 nativo: display virtual en RAM + software Mesa.
-  timeout 90 xvfb-run -a -s "-screen 0 1280x800x24" \
-      env LIBGL_ALWAYS_SOFTWARE=1 GALLIUM_DRIVER=llvmpipe \
-      "$TEST_BIN" 2>&1
-fi
-EXIT=$?
-echo "EXIT: $EXIT"
-```
-
-Ambas vías son headless. `xvfb-run` sigue siendo seguro en host con display (corre en su propio display virtual), así que si el sniff de GL falla puedes usar siempre la rama xvfb.
-
-**Para depurar un test a ojo** (ver la UI mientras el engine la maneja), desactiva el headless con `FN_HEADLESS=0`:
-
-```bash
-FN_HEADLESS=0 timeout 90 "$TEST_BIN" 2>&1
-```
-
-### 9. Reportar
-
-- Si `EXIT == 0` y la salida contiene `Tests Result: OK` → reporta `N/M tests passed` con la lista de tests ejecutados.
-- Si `EXIT != 0` → muestra el bloque de log del test fallido (test engine imprime el path del widget que no encontro, el archivo y la linea del IM_CHECK que fallo). Sugiere correcciones (widget renombrado, path mal escrito, race entre frames — usar `ctx->Yield()`).
-
-### 10. Despues de añadir tests
-
-NO ejecutes `fn index` automaticamente — los tests no son funciones del registry, son artefactos de la app. Si el usuario los queria persistir, ya los tiene en `<app_dir>/tests/`.
-
-Si la app es un sub-repo (lo normal segun ADR 0002), recordar al usuario que los archivos nuevos viven dentro del repo de la app y necesitan un commit alli (no en `fn_registry`).
-
-## Referencias
-
-- API de Test Context: `cpp/vendor/imgui_test_engine/imgui_te_context.h`
-- API del engine: `cpp/vendor/imgui_test_engine/imgui_te_engine.h`
-- Implementacion del harness: `cpp/framework/app_base.cpp` (funcion `fn::run_app_test`)
-- Ejemplo canonico: `cpp/apps/chart_demo/tests/chart_demo_tests.cpp`
-- Licencia del test engine: personal/open-source gratis (`cpp/vendor/imgui_test_engine/LICENSE.txt`)

.claude/commands/entrada_diario.md

@@ -1,47 +0,0 @@
-# /entrada_diario — Añadir entrada al diario del día
-
-Wrapper sobre `append_diary_entry_bash_infra`. La función del registry maneja todo el manejo de archivos (crear `docs/diary/YYYY-MM-DD.md` si no existe, append seguro, formato exacto). Este comando solo decide el contenido.
-
-## Uso
-
-```
-/entrada_diario <descripción del bloque de trabajo>
-/entrada_diario                            # sin args → resume sesión actual
-```
-
-## Pasos del asistente
-
-1. **Componer `TITULO` (corto, una linea) y `CUERPO`** (viñetas markdown):
-   - Con `$ARGUMENTS`: derivar `TITULO` directo del argumento; `CUERPO` con viñetas concretas (`- Hecho:`, `- Pendiente:`).
-   - Sin `$ARGUMENTS`: revisar TaskList + `git log --since=today` + `git status` y resumir en 3-5 viñetas.
-
-2. **Llamar la función del registry**:
-   ```bash
-   cd $HOME/fn_registry
-   source bash/functions/infra/append_diary_entry.sh
-   append_diary_entry "<TITULO>" "$(cat <<'EOF'
-   <CUERPO>
-   EOF
-   )"
-   ```
-   La función imprime el path del archivo escrito.
-
-## Reglas de estilo
-
-- Viñetas breves, no párrafos. Verbos en pasado para lo hecho, infinitivo para pendientes.
-- Enlaces a artefactos: commits (SHA corto 7-8 chars), ADRs (`[0001](../adr/0001-...)`), funciones del registry por ID.
-- No duplicar con CHANGELOG: el diario es contexto operativo ("qué hice hoy"), el CHANGELOG es "qué cambió cara al usuario".
-- NUNCA editar secciones anteriores. La función solo append.
-
-## Relación con otras formas de registro
-
-| Si quieres documentar... | Usa |
-|--------------------------|-----|
-| Qué trabajé hoy | `/entrada_diario` → `docs/diary/` |
-| Qué cambió en el código (cara usuario/agentes) | Editar `CHANGELOG.md` directamente |
-| Por qué tomamos una decisión arquitectural | Nuevo ADR en `docs/adr/NNNN-*.md` |
-| Una regla operativa nueva del registry | Nuevo archivo en `.claude/rules/` + entrada en INDEX.md |
-
-## Para tocar la lógica
-
-Editar la función `append_diary_entry_bash_infra` en el registry, no este wrapper.

.claude/commands/extract-design.md

@@ -1,281 +0,0 @@
-# /extract-design — Mejorar @fn_library con exports de Claude Design
-
-Eres un agente mejorador del design system. Tu trabajo es analizar un export "standalone" de Claude Design (`sources/frontend_designs/*.html`), identificar componentes nuevos o mejoras sobre `@fn_library`, aplicarlos al registry y propagarlos al espejo público `subrepos/fn-design-system` (GitHub + Gitea).
-
-**Objetivo:** cada diseño exportado debería dejar el registry un poco mejor que antes. Lo que Claude Design inventó para cubrir un hueco hoy → componente reutilizable del registry mañana.
-
----
-
-## Argumento
-
-`$ARGUMENTS` — ruta al `.html` en `sources/frontend_designs/`. Si no se proporciona:
-1. Lista los `.html` bajo `sources/frontend_designs/` ordenados por fecha.
-2. Muestra fecha + nombre + tamaño.
-3. Pregunta cuál procesar. Default: el más reciente.
-
----
-
-## PASO 0 — Validar input
-
-```bash
-ls -lht sources/frontend_designs/*.html 2>/dev/null
-```
-
-Si no existe el fichero, abortar. Si existe, leer las primeras líneas para confirmar que es un export de Claude Design (`__bundler/manifest`, `__bundler/template` en el HTML).
-
----
-
-## PASO 1 — Decodificar el bundle
-
-Ejecutar el extractor:
-
-```bash
-python3 .claude/scripts/extract_design_bundle.py \
-  "sources/frontend_designs/<NOMBRE>.html" \
-  "sources/frontend_designs/<NOMBRE>_extracted/"
-```
-
-Esperado: directorio con `app.jsx`, `fn_library_emu.jsx`, `charts_emu.jsx`, `data.jsx` + fuentes woff2 + `manifest.json`.
-
-Si falta alguno de los 4 `.jsx` clave, inspeccionar por UUID; puede que Claude Design haya usado estructura distinta. Reportar al usuario.
-
----
-
-## PASO 2 — Inventariar el diseño
-
-Leer `app.jsx` y listar **todos los componentes React definidos** (funciones que empiezan con mayúscula o usan `function Xxx(`). Categorizar:
-
-### 2a. Componentes del export que YA existen en `@fn_library`
-- Grep el barrel: `cat frontend/functions/ui/index.ts | grep "^export"`.
-- Para cada componente del export, ver si aparece en el barrel. Registrar coincidencias.
-
-### 2b. Componentes nuevos (no existen en el registry)
-Componentes React del `app.jsx` cuyo nombre no aparece en el barrel. Estos son **candidatos a extracción**.
-
-### 2c. Uso de variantes / props no documentadas
-Leer `fn_library_emu.jsx` del export y comparar API con tus `.tsx` reales:
-
-```bash
-# Comprobar componentes específicos si el export los usa con props nuevas
-sqlite3 registry.db "SELECT id, signature, props FROM functions WHERE id = 'alert_ts_ui';"
-```
-
-Anotar discrepancias (variantes faltantes, props nuevas, tipos distintos).
-
-### 2d. Datos/patrones reutilizables en `data.jsx`
-- RNG determinista (mulberry32) → candidato a `frontend/functions/core/rng_seeded_ts_core` o `python/functions/core/`.
-- Helpers tipo `statusBadge()` → documentar como receta, no como componente.
-
----
-
-## PASO 3 — Consultar el registry para evitar duplicados
-
-Para cada componente candidato del paso 2b, búsqueda FTS5 antes de proponerlo:
-
-```bash
-sqlite3 registry.db "SELECT id, kind, description FROM functions WHERE id IN (SELECT id FROM functions_fts WHERE functions_fts MATCH 'name:<CANDIDATO>* OR description:<PALABRAS_CLAVE>') ORDER BY name;"
-```
-
-Si encuentras algo similar que pueda ser mejorado en lugar de duplicado, márcalo como **mejora** a ese existente.
-
----
-
-## PASO 4 — Presentar el diagnóstico al usuario
-
-Muestra en tablas separadas:
-
-### 🟢 Componentes nuevos candidatos
-
-| # | Nombre propuesto | Dominio | Líneas | Reutilizable en | API |
-|---|---|---|---|---|---|
-| 1 | `funnel_chart_ts_ui` | ui | ~35 | CRM, analytics, funnels genéricos | `(data: Array<{stage, value}>, variant?) → JSX` |
-
-### 🟡 Mejoras a componentes existentes
-
-| # | Componente | Mejora | Tipo | Riesgo |
-|---|---|---|---|---|
-| A | `alert_ts_ui` | Añadir variantes `success`, `warning`, `info` | Expandir enum | Bajo — no rompe API |
-| B | `data_table_ts_ui` | Prop `density: 'compact'|'cozy'|'roomy'` | Añadir prop opcional | Bajo |
-
-### 🔵 Patrones a documentar (no componente)
-
-| Patrón | Dónde registrar |
-|---|---|
-| `statusBadge` helper | `DESIGN_SYSTEM.md` sección "patterns" |
-
-**Esperar confirmación.** El usuario responde con sintaxis `1,2,A,B` (o `all`, o `nuevos only`, o descarta algunos). Si dice `all`, aplica todo lo listado.
-
----
-
-## PASO 5 — Aplicar mejoras aprobadas
-
-### 5a. Para componentes nuevos (candidatos 🟢)
-
-Por cada aprobado:
-
-1. **Leer código** del `app.jsx` / `fn_library_emu.jsx` / `charts_emu.jsx` del export.
-2. **Adaptar al stack real del registry:**
-   - Cambiar elementos SVG/HTML planos por primitivas de `@mantine/core` cuando corresponda (`Paper`, `Stack`, `Group`, `Text`).
-   - Cambiar `style={{...}}` por props Mantine (`p`, `m`, `fw`, `gap`, `radius`, `c`).
-   - Si es un chart, delegar en `@mantine/charts` cuando sea posible; solo usar SVG puro si Mantine no cubre el caso (ej: `Sparkline` en el registry ya es SVG puro por rendimiento).
-   - Iconos: `@tabler/icons-react`.
-3. **Crear los dos ficheros** siguiendo la convención:
-   - `frontend/functions/ui/<name>.tsx` — código React.
-   - `frontend/functions/ui/<name>.md` — frontmatter completo.
-4. **Frontmatter del .md** (campos clave):
-   ```yaml
-   id: <name>_ts_ui
-   name: <name>
-   kind: component
-   lang: ts
-   domain: ui
-   purity: impure
-   framework: react
-   version: 1.0.0
-   description: "..."
-   tags: [...]
-   props: {...}
-   emits: null
-   params: []
-   output: "JSX.Element — ..."
-   source_repo: "claude.ai/design"
-   source_license: ""
-   source_file: "sources/frontend_designs/<NOMBRE>.html"
-   file_path: frontend/functions/ui/<name>.tsx
-   tested: false
-   ```
-5. **Añadir al barrel** `frontend/functions/ui/index.ts`: `export { Xxx } from './<name>'`.
-
-### 5b. Para mejoras a componentes existentes (🟡)
-
-Por cada aprobada:
-
-1. **Leer** el `.tsx` actual.
-2. **Aplicar la mejora** sin romper la API existente: añade prop opcional, amplía enum de `variant`, etc.
-3. **Actualizar** el `.md` correspondiente para reflejar las nuevas variantes/props (campos `variant`, `props`, `description`).
-4. **Si la firma cambia**, actualizar también el `signature` del frontmatter.
-
-### 5c. Para patrones a documentar (🔵)
-
-1. Añadir una sección "Patterns" en `frontend/DESIGN_SYSTEM.md` si no existe.
-2. Registrar el patrón con un ejemplo corto.
-
----
-
-## PASO 6 — Indexar y verificar
-
-```bash
-./fn index
-```
-
-- Si falla por integridad, arreglar y reintentar.
-- Verificar cada componente nuevo: `./fn show <id>`.
-- Confirmar que el barrel compila haciendo `cd frontend && pnpm tsc --noEmit` (si tarda, al menos verificar imports manualmente).
-
----
-
-## PASO 7 — Sincronizar al espejo
-
-```bash
-cd subrepos/fn-design-system
-./sync_from_registry.sh
-git add -A
-git status --short   # Mostrar qué cambió en el espejo
-```
-
-Si hay cambios, preparar commit. Si no, el sync no recogió las modificaciones — investigar.
-
----
-
-## PASO 8 — Commit en ambos repos
-
-### 8a. Commit en `fn_registry`
-
-```bash
-git add frontend/functions/ui/ frontend/DESIGN_SYSTEM.md registry.db
-git commit -m "$(cat <<'EOF'
-feat(ui): extract <N> components / <M> improvements from design export
-
-From: sources/frontend_designs/<NOMBRE>.html
-
-New components:
-- <id> — <descripción corta>
-- ...
-
-Improvements:
-- <id> — <cambio>
-- ...
-
-Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
-EOF
-)"
-```
-
-### 8b. Commit en el espejo
-
-```bash
-cd subrepos/fn-design-system
-git commit -m "sync: <N> new components + <M> improvements from <NOMBRE>
-
-Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>"
-```
-
----
-
-## PASO 9 — Push
-
-### 9a. Push del espejo (ambos remotes)
-
-```bash
-cd subrepos/fn-design-system
-./push_all.sh
-```
-
-Esto propaga a:
-- `gitea/dataforge/fn-design-system`
-- `github/gutierenmanuel/fn-design-system` ← este es el que Claude Design consume
-
-### 9b. Push de fn_registry
-
-**Preguntar al usuario** antes — no push sin permiso (ver CLAUDE.md del proyecto). Si dice sí:
-
-```bash
-git push origin master
-```
-
----
-
-## PASO 10 — Resumen final
-
-Mostrar al usuario:
-
-```
-✓ Extracción completa.
-
-Nuevos componentes en @fn_library:
-  - <id> (frontend/functions/ui/<name>.tsx)
-  - ...
-
-Mejoras aplicadas:
-  - <id>: <qué cambió>
-
-Espejo actualizado:
-  - Commit gitea:  <sha>  → <url>
-  - Commit github: <sha>  → <url>
-
-Claude Design verá estas mejoras en su próxima lectura del repo enlazado.
-Siguiente acción sugerida: probar un prompt de dashboard que use <componente_nuevo>.
-```
-
----
-
-## Reglas críticas
-
-- **NUNCA extraer sin aprobación explícita del usuario** — siempre paso 4 con tabla y espera.
-- **NUNCA sobrescribir un componente existente** en el paso 5b — solo añadir variantes/props opcionales. Si la mejora es incompatible, proponerlo como propuesta aparte (`fn proposal add`) en vez de aplicarla.
-- **SIEMPRE `source_repo: "claude.ai/design"`** en el frontmatter de componentes nuevos, y `source_file` apuntando al `.html` original.
-- **SIEMPRE mantener el orden:** registry → index → verify → sync mirror → commit both → push mirror → (ask to push fn_registry).
-- **El barrel `index.ts`** debe estar actualizado antes de hacer `fn index` (hay apps que lo importan).
-- **NO committear** `operations.db*`, `node_modules/`, `dist/`, `.env` ni nada que `.gitignore` excluya. Usa `git add` con rutas explícitas, no `git add -A` a ciegas.
-- **Si el usuario cancela a mitad**, dejar el working tree limpio o documentar qué quedó pendiente. No medio-commits.
-- **Patrones que no tienen sentido como primitiva** (ej. envs, branding específico) → documentar, no componentizar.

.claude/commands/fix-issue.md

@@ -1,186 +0,0 @@
----
-name: fix-issue
-description: Implementar un issue de dev/issues/ end-to-end. Crea rama, ejecuta tareas, bumpa version si toca modulos/framework/apps (via /version), tests, cierra issue, integra a master.
----
-
-# /fix-issue
-
-Ejecuta el flujo completo de implementacion/cierre de un issue de `dev/issues/`. Adaptado al stack del registry: Go (`-tags fts5 CGO_ENABLED=1`), Python (`python/.venv/bin/python3`), Bash, TypeScript (`pnpm`), C++ (`cmake`+`mingw-w64` toolchain).
-
-## Inputs
-
-```
-/fix-issue <NNNN[a|b|c...]>
-```
-
-- `NNNN`: numero del issue (ej. `0107`).
-- Si es sub-issue, sufijo letra: `0107a`, `0107b`, ...
-
-Si no se proporciona, preguntar.
-
-## Flujo obligatorio
-
-### 1. Resolver el issue
-
-- `dev/issues/<NNNN>-*.md` → si no existe, STOP.
-- Si ya en `dev/issues/completed/`, STOP.
-- Si es sub-issue, leer tambien el principal para contexto.
-
-### 2. Leer y extraer
-
-- Objetivo, tareas, arquitectura, prerequisitos, riesgos.
-- Identificar archivos afectados — anotar si toca:
-  - `modules/<X>/` o `cpp/framework/` → bumpa version (paso 8).
-  - `functions/`, `python/functions/`, `bash/functions/`, `frontend/functions/` → indexer + `fn index` al cerrar.
-  - Apps en `apps/<X>/` o `projects/*/apps/<X>/` → requiere rama TBD (regla `apps_tbd.md`) **+ bumpa version per-app (paso 8)**. Si el issue toca multiples apps, una llamada `/version` por app.
-  - Registry meta (CLAUDE.md, rules, templates) → push directo a master OK.
-
-### 3. Estrategia de rama
-
-**Registry-only changes** (functions/types/docs/rules):
-- Push directo a master OK. NO crear rama.
-
-**Apps changes** (apps/, projects/*/apps/):
-- Crear rama TBD:
-  ```bash
-  git checkout master
-  git pull --rebase
-  git checkout -b issue/<NNNN>-<slug>
-  ```
-  La rama es del registry. Si la app es sub-repo, ademas crear rama dentro del sub-repo.
-
-**Modules/framework changes** (`modules/`, `cpp/framework/`):
-- Rama TBD obligatoria (afecta a todas las apps que linkean).
-
-### 4. Plan con TaskCreate
-
-- Crear tarea por bloque logico del issue.
-- Incluir SIEMPRE:
-  - Tarea de tests (unit + smoke).
-  - Tarea de `fn index` si toco metadata.
-  - Tarea de `/version` si toco `modules/`, `cpp/framework/`, `apps/<X>/` o `projects/*/apps/<X>/` (una llamada por target).
-  - Tarea de cleanup/docs.
-
-### 5. Implementar
-
-Reglas registry-first (CLAUDE.md):
-- ANTES de escribir codigo reutilizable → `mcp__registry__fn_search` para encontrar lo que existe.
-- Si falta funcion reutilizable → spawn `fn-constructor` (no escribir inline).
-- Si patron se repite >2x → propose nueva funcion.
-- NUNCA `sqlite3 registry.db "SELECT ..."` plano — usar MCP.
-
-Convenciones del stack:
-
-| Stack | Build/test |
-|---|---|
-| Go | `CGO_ENABLED=1 go build -tags fts5 -o fn ./cmd/fn/` y `CGO_ENABLED=1 go test -tags fts5 ./...` |
-| Python | `python/.venv/bin/python3 -m pytest <path>` |
-| Bash | `bash -n <script>.sh` + tests inline |
-| TypeScript | `cd frontend && pnpm build && pnpm test` |
-| C++ (Linux) | `cmake --build build --target <app>` |
-| C++ (Windows MinGW) | `cmake -B build/windows -DCMAKE_TOOLCHAIN_FILE=cpp/toolchains/mingw-w64.cmake && cmake --build build/windows --target <app>` |
-
-Commits atomicos por bloque logico con prefijos: `feat:`, `fix:`, `test:`, `docs:`, `refactor:`, `chore:`. Mensajes en espanol. NO WIP.
-
-### 6. Tests
-
-Stack-dependent (ver arriba). Si tests pasan parcialmente con failures pre-existentes no causadas por la rama, documentar en cuerpo del commit/PR.
-
-### 7. Feature flags (si aplica)
-
-Si el issue forma parte de un feature multi-issue:
-- Editar `dev/feature_flags.json` con el flag (desactivado).
-- Activar el flag en el ultimo sub-issue del set.
-
-Flag != WIP. Codigo detras de flag debe compilar + testear.
-
-### 8. Version bump (si toco modulos/framework/apps)
-
-**OBLIGATORIO si el issue toco** alguno de:
-- `modules/<X>/` → bumpa `modules/<X>/module.md::version`.
-- `cpp/framework/` → bumpa `modules/framework/module.md::version`.
-- `apps/<X>/` → bumpa `apps/<X>/app.md::version`.
-- `projects/<P>/apps/<X>/` → bumpa `projects/<P>/apps/<X>/app.md::version`.
-
-```
-/version <path> <major|minor|patch> "<reason>"
-```
-
-Reglas (modulos/framework):
-- Major: breaking ABI/API publica.
-- Minor: additive (nuevo helper, refactor interno sin cambio de API, nuevo miembro).
-- Patch: bugfix puro.
-
-Reglas (apps):
-- Major: breaking observable (CLI args, schema BBDD propia, formato wire).
-- Minor: feature aditiva visible (nuevo panel, endpoint, opcion).
-- Patch: bugfix sin cambio observable, refactor interno, mejora perf.
-
-**Una llamada `/version` por target afectado**. Si el issue toca 1 modulo + 2 apps -> 3 llamadas a `/version` (cada una con su `reason` y bump-type apropiado; pueden diferir).
-
-Diff guard: cambios que solo tocan el `app.md` (correccion typo descripcion, anadir tag) NO requieren bump — son metadata, no comportamiento. Detectar con `git diff --name-only | grep -v '\.md$'` para decidir si hay cambio de codigo real.
-
-`/version` solo edita + stage. NO commit. El bump va junto con el codigo correspondiente en el mismo commit (`feat:` o `fix:` o `refactor:`).
-
-Si NO toco modulos/framework/apps, saltar este paso.
-
-### 9. Cerrar el issue
-
-Mover archivo:
-```bash
-mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
-```
-
-Actualizar `dev/issues/README.md`:
-- Link → `completed/<NNNN>-<slug>.md`
-- Estado → `completado`
-
-Si es feature multi-issue y este es el ultimo sub-issue:
-- Flip flag en `dev/feature_flags.json` a `enabled: true` con `enabled_at: <YYYY-MM-DD>`.
-- Verificar que todos los sub-issues estan en `completed/`.
-
-### 10. Integrar
-
-**Registry-only changes**: push directo a master.
-
-**Apps/modules/framework changes**: `/full-git-push` o `/git-push` (merge --no-ff de la rama a master, push, delete rama). 
-
-### 11. Verificar post-cierre
-
-- `fn index` — registry.db al dia.
-- `fn doctor` (subcomandos relevantes: `artefacts`, `services`, `cpp-apps`, `uses-functions`).
-- Si toco modulos: `fn doctor modules` (post 0107a) — 0 drift.
-
-## Reglas criticas
-
-- **Registry-first**: SIEMPRE buscar antes de escribir; delegar a `fn-constructor` antes que inline.
-- **TBD para apps**: NUNCA push directo a master en apps. Rama corta, merge --no-ff.
-- **TBD NO para registry**: push directo OK para functions/types/docs/rules.
-- **`/version` obligatorio** si tocas modulos, framework o apps (con cambio de codigo real, no solo metadata). Si no, drift entre `version:` y `## Capability growth log` y se pierde trazabilidad.
-- **Tests siempre**: no cerrar issue sin tests pasando (salvo failures pre-existentes documentados).
-- **Commits atomicos**: 1 commit = 1 bloque logico. No mezclar `feat:` + `test:` en mismo commit.
-- **Cerrar siempre**: nunca dejar issue implementado sin mover a `completed/` + actualizar README.
-
-## Referenciado desde
-
-- `.claude/commands/version.md` — bump semver de modulos.
-- `.claude/commands/full-git-push.md` — push del registry + sub-repos.
-- `.claude/rules/apps_tbd.md` — politica de TBD por tipo de cambio.
-
-## Ejemplo: implementar 0107c (refactor data_table)
-
-```
-/fix-issue 0107c
-
-1. Resolver: dev/issues/0107c-split-data-table.md ✓
-2. Extraer: refactor 4777 LOC → 6 sub-funciones. Toca modules/ → /version obligatorio.
-3. Rama: issue/0107c-split-data-table desde master.
-4. Plan: 8 tareas (lectura + 6 sub-funciones + entrypoint thin + version bump).
-5. Implementar: spawn fn-constructor en paralelo si hay >1 sub-funcion independiente.
-6. Tests: build + smoke + primitives_gallery --capture diff.
-7. Flag: parte de modules-v2, NO activar todavia (espera 0107a-f cerrar).
-8. /version modules/data_table major "split data_table.cpp into 6 sub-functions"
-9. Cerrar: mv → completed/ + README.
-10. /git-push.
-11. fn index + fn doctor modules → 0 drift en consumidores limpiados.
-```

.claude/commands/flow.md

@@ -1,131 +0,0 @@
----
-description: "Gestiona flows (casos de uso multi-app reutilizables) en dev/flows/. Subcomandos: create, list, show, status, done. Runner automatizado en fase 2."
----
-
-# /flow — Gestionar flows del registry
-
-Flows = casos de uso end-to-end que prueban / ejercitan el sistema multi-app. Viven en `dev/flows/NNNN-<slug>.md`. Cada flow describe Goal + Flow steps + Acceptance checkboxes + Telemetria.
-
-**OBLIGATORIO antes de `create`**: lee `dev/flows/AGENT_GUIDE.md`. Define donde buscar piezas (capability groups, FTS por tag, apps existentes, vaults), reglas duras para no inventar IDs, y plantilla de razonamiento para recomendar extractor / transformer / sink / scheduler / notify por flow.
-
-Cada flow nuevo cita IDs reales del registry. Si una pieza falta, escribir `FALTA: crear <id>` en la tabla correspondiente. Nada de inventar nombres.
-
-Diferencia con `dev/issues/`:
-- Issues = bugs / features de implementacion.
-- Flows = trabajos reutilizables que cruzan varias apps.
-
-## Sintaxis
-
-```
-/flow create <slug>              # nuevo flow desde template, ID auto
-/flow list                        # tabla resumen
-/flow show <NNNN>                 # imprime contenido + acceptance %
-/flow status <NNNN>               # status + acceptance % + ultima run
-/flow done <NNNN> [--notes "..."] # cierra flow (status=done, mueve a completed/)
-/flow run <NNNN>                  # fase 2 — runner automatizado (NO IMPLEMENTADO)
-```
-
-## Implementacion por subcomando
-
-### `create <slug>`
-
-Pasos:
-1. Valida `<slug>` es kebab-case: `^[a-z][a-z0-9-]*$`. Si no, error.
-2. Comprueba que no existe ya: `ls dev/flows/*-<slug>.md`. Si existe, error.
-3. Calcula siguiente ID libre:
-   - `ls dev/flows/*.md dev/flows/completed/*.md | grep -oE '^dev/flows/(completed/)?[0-9]{4}' | sort -u | tail -1`
-   - Suma 1, zero-pad a 4 digitos.
-4. Lee `dev/flows/template.md`.
-5. Sustituye `<slug>`, `NNNN`, `YYYY-MM-DD` (hoy).
-6. Escribe `dev/flows/NNNN-<slug>.md`.
-7. Append fila a `dev/flows/INDEX.md` (mantener orden por ID asc).
-8. Reporta path nuevo + recordatorio "edita Goal / Flow / Acceptance".
-
-### `list`
-
-Lee `dev/flows/INDEX.md` y lo imprime tal cual. Si flag `--pending` solo pending, `--done` solo done, `--app <name>` filtra por app.
-
-Tambien anade columna `Accept%` calculada desde body:
-- Para cada flow .md, cuenta `[ ]` y `[x]` en seccion `## Acceptance`.
-- `% = checked / total * 100` redondeo entero.
-
-### `show <NNNN>`
-
-`cat dev/flows/NNNN-*.md` (busca con glob NNNN-*). Si no existe, prueba `dev/flows/completed/NNNN-*.md`. Si no, error.
-
-### `status <NNNN>`
-
-Imprime resumen del frontmatter + acceptance %:
-
-```
-=== flow 0001 ===
-name:        hn-top-stories
-status:      pending
-risk:        low
-priority:    high
-apps:        navegator_dashboard, dag_engine, data_factory, agents_and_robots
-acceptance:  2/6 (33%)
-updated:     2026-05-16
-
-Pending checks:
-- [ ] Recipe creada y validada
-- [ ] DAG corre OK 2 veces consecutivas via scheduler
-- [ ] data_factory.runs tiene >=2 entries
-- [ ] Schema extraido cubre 6/6 fields
-```
-
-### `done <NNNN> [--notes "..."]`
-
-Pasos:
-1. Verifica todos los `[ ]` estan checked. Si no, prompt "X checks pendientes, --force para cerrar igualmente".
-2. Edita frontmatter: `status: done`, `updated: <hoy>`.
-3. Si `--notes`, append a seccion `## Notas`.
-4. `git mv dev/flows/NNNN-<slug>.md dev/flows/completed/`.
-5. Actualiza `dev/flows/INDEX.md`: cambia status del flow + mueve fila a seccion Completed (mantener tabla principal solo con pending/running/failed/deferred).
-
-### `run <NNNN>` — FASE 2 (NO IMPLEMENTADO AUN)
-
-Hoy: imprime `/flow run no implementado todavia. Sigue los pasos manualmente y marca acceptance con sed/edit.`
-
-Diseño futuro:
-- Parsea `## Flow` en pasos.
-- Cada paso tipo `function: <id>` -> ejecuta `./fn run <id>`.
-- Cada paso tipo `cmd: <bash>` -> ejecuta subprocess.
-- Texto libre -> "MANUAL: <text>" + pause user input.
-- Persistencia ejecuciones en `dev/flows/runs/<id>-<timestamp>.jsonl`.
-- Update acceptance checkboxes automaticamente segun heuristics (count runs en data_factory, etc.).
-
-## Conventions
-
-- Numeracion 0001+, propia (no comparte con `dev/issues/`).
-- Status: `pending | running | done | failed | deferred`.
-- Risk: `low` (publico) | `medium` (auth no sensible) | `high` (datos personales).
-- Apps listadas en frontmatter — `/flow list --app navegator_dashboard` filtra.
-- Acceptance es la fuente de verdad del progreso.
-
-## Output style
-
-Caveman. Tablas markdown. Sin emojis. Sin verbosidad.
-
-Errores: 1 linea con el problema + sugerencia.
-
-## Ejemplos
-
-```
-/flow create reddit-sentiment-tracker
-# crea dev/flows/0008-reddit-sentiment-tracker.md
-# anade fila a INDEX
-
-/flow list --pending
-# muestra solo flows no cerrados
-
-/flow status 0001
-# acceptance 0/6, todos los checks pendientes
-
-# Tras correr el flow manualmente:
-# editas el .md, marcas [x] los checks completados
-/flow status 0001
-# acceptance 6/6
-/flow done 0001 --notes "smoke pass; LLM tardo 14s; recipe robusta"
-# mueve a completed/, marca status=done
-```

.claude/commands/fn_claude.md

@@ -1,240 +0,0 @@
----
-description: "Auto-auditoria: verifica que la sesion registra uso de funciones, detecta gaps (patrones inline repetidos, wrappers saltados, heredocs sin function_id), lanza fn-constructor en paralelo para crear las funciones que faltan, y valida que Claude usara las nuevas en el siguiente turno"
----
-
-# /fn_claude — auto-auditoria + auto-construccion del registry
-
-Comando meta: Claude se audita a si mismo. Verifica que su comportamiento en esta sesion (y las recientes) deja rastro en `call_monitor.operations.db`, detecta gaps reales del registry para el trabajo actual, lanza sub-agentes `fn-constructor` en paralelo para cerrar esos gaps, y verifica que la proxima vez usara las funciones nuevas.
-
-## Objetivos del registry (Norte) — Issues 0086 + 0087
-
-Cada corrida de `/fn_claude` optimiza 4 metricas visibles en Monitor tab del `registry_dashboard`:
-
-1. **MAXIMIZAR `Reg %`** — % de calls con `function_id != ''`. Cada heredoc/bash que reescribe logica baja el ratio. Target: subir cada semana.
-2. **MEJORAR uso del registry por Claude** — Claude busca y reusa antes de escribir. `MCP` (mcp/heredoc/fn run) sube, `violations` baja. Si una funcion existe pero Claude no la encuentra, mejorar su `description`/`tags`/`params_schema` (FTS indexa todo).
-3. **ACELERAR tareas comunes** — patrones inline repetidos >2x -> `fn-constructor` los convierte en funcion, Claude las usa el siguiente turno. Menos pasos por tarea = mas valor.
-4. **PROMOVER COMPOSICIONES A PIPELINES** (issue 0087) — el registry crece **promoviendo secuencias A->B(->C) que se repiten con exito** a pipelines one-shot. Una funcion que hace bien una cosa NO necesita crecer. Pattern detection: `call_monitor sequences --detect --propose` (cron 6h activo) + tab `Promotion candidates` del dashboard.
-
-Si `/fn_claude` no mueve estas 4 metricas, no esta haciendo su trabajo.
-
-## Infraestructura de discovery activa (issue 0087)
-
-Cada turno tienes capacidades ya cargadas SIN buscar. Si no las usas estas pagando el coste de FTS innecesariamente:
-
-| Senal | Donde | Que hacer |
-|---|---|---|
-| Linea `CAPABILITIES (cache 1h): TOP: ... FRESH (7d): ... PIPELINES: ...` en cada UserPromptSubmit | hook `hook_capabilities_inject.sh` | Antes de buscar con `mcp__registry__fn_search`, mira si la funcion que necesitas esta en TOP/FRESH/PIPELINES. Si si, ve directo a `fn show <id>` (1 read) o `./fn run <id>` (0 reads). |
-| `<system-reminder>FUZZY-MATCH (issue 0087): your Bash command may already be a function. USE: ./fn run <id> -> <signature>` aparecido mid-flight | hook `hook_fn_match.sh` (PreToolUse, Bash matcher) | El hook detecto que tu Bash inline coincide con una funcion del registry. **NO ignores el reminder** — abandona el inline, llama a `./fn run <id>` o `mcp__registry__fn_run id="<id>"`. Si crees que la sugerencia es falso positivo, justifica brevemente antes de seguir inline (queda en violations). |
-| Hint AUSENTE para una query corta (`rsi sma` < 3 tokens) | threshold `raw_score >= 4.0` no alcanzado | NO interpretar la ausencia de hint como "no existe funcion". Usa `mcp__registry__fn_search` con query mas rica (3+ tokens del dominio). |
-| Falso positivo conocido: `agent` token | `robots.txt user-agent` matchea `agent_scaffold` | Ignora el reminder y sigue. Cost = 1 reminder ignorable. |
-
-## Como combinar la 3 senales para minimizar pasos
-
-1. **User prompt llega** -> lees `CAPABILITIES` line. Si la tarea encaja claramente con TOP/FRESH -> usa directo.
-2. **Vas a escribir Bash inline** -> el hook PreToolUse lo intercepta. Si dispara FUZZY-MATCH -> usa `./fn run <id>`.
-3. **No hay match y necesitas codigo** -> `mcp__registry__fn_search` con 3+ tokens. Si sigue sin hit -> delega a `fn-constructor` (no escribas inline). Patron repetido detectado por `call_monitor sequences` se promovera a pipeline en proximas iteraciones.
-
-## Las 4 metricas norte (donde vigilarlas)
-
-- `Reg %` (Monitor KPI) — % calls con function_id no vacio. Sube cuando el registry se usa.
-- `MCP` (Monitor KPI) — count calls con tools registry-aware (mcp*/heredoc*/fn_cli_run). Adopcion de patrones canonicos.
-- `Errors` / `Violations` (Monitor KPI) — bajan cuando el bucle cierra.
-- `Failed Functions` (Monitor sub-tab) — registry-functions que fallaron: diagnostico de bugs prioritarios.
-
-Issue 0085 fase autocompleta. Reemplaza el flujo manual de "veo un patron, decido si extraer, escribo proposal, espero humano, fn-mejorador genera, fn-orquestador opera". Con `/fn_claude` Claude hace todo eso solo, **autonomamente para si mismo**.
-
----
-
-## Comportamiento (ejecutalo en este orden)
-
-### 1. AUDIT — ¿estoy siendo registrado?
-
-```bash
-ROOT="$HOME/fn_registry"
-MON="$ROOT/projects/fn_monitoring/apps/call_monitor/operations.db"
-
-# Pre-condiciones
-[ -f "$MON" ] || { echo "call_monitor.operations.db NO existe — issue 0085a no aplicado"; exit 1; }
-[ "$FN_TELEMETRY" = "1" ] || echo "WARNING: FN_TELEMETRY != 1 — wrappers Python/Bash inactivos"
-
-# Metricas de la sesion actual + ultimas 24h
-sqlite3 "$MON" <<SQL
-SELECT 'calls_session', COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}'
-UNION ALL SELECT 'calls_24h', COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)
-UNION ALL SELECT 'violations_24h', COUNT(*) FROM violations WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)
-UNION ALL SELECT 'tool_used_distribution_24h', NULL;
-SELECT tool_used, COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER) GROUP BY tool_used ORDER BY 2 DESC;
-SQL
-```
-
-Si `calls_session = 0` → algo esta mal (hook PostToolUse no fire o BD no escribible). Reporta y para.
-
-Si `mcp_*` / total < 0.4 → estas usando demasiado heredoc/sqlite directo. Reporta como warning.
-
-### 2. GAP — ¿que funciones faltan?
-
-Dos fuentes:
-
-#### 2a. Patrones repetidos en heredocs/Edit
-
-```sql
--- En call_monitor.operations.db
-SELECT tool_used, COUNT(*) AS hits
-FROM calls
-WHERE function_id = ''
-  AND ts >= CAST(strftime('%s','now','-7 days') AS INTEGER)
-  AND tool_used IN ('heredoc_py', 'heredoc_bash', 'sqlite_direct')
-GROUP BY tool_used;
-```
-
-Si `heredoc_py > 5` sin function_id → Claude esta componiendo logica que probablemente debe ser pipeline. Investigar el ultimo heredoc del transcript: si reescribe algo que ya es funcion del registry → violation candidate. Si no, es candidato a pipeline nuevo.
-
-#### 2b. Trabajo actual de la sesion — gap inferido del contexto
-
-Lee el ultimo prompt del usuario y los ultimos 10 turnos. Lista funciones que:
-
-- Has llamado inline (sed/awk/jq custom, transformaciones de datos, parsing).
-- Has reinventado (HTTP client raw, SQLite open con flags, FS walks).
-- Has compuesto >2 veces con el mismo shape.
-
-Para cada candidato:
-
-```bash
-# Verifica si ya existe algo similar en el registry
-mcp__registry__fn_search "<keyword del candidato>"
-```
-
-Si NO existe match relevante → candidato a `fn-constructor`.
-Si existe pero firma incompleta → candidato a `improve_function` (proposal, NO auto-construccion).
-
-### 3. PROPOSE — lista candidatos
-
-Genera tabla:
-
-```
-| Candidato | Razon | Lenguaje | Dominio | Evidencia (snippet) |
-|---|---|---|---|---|
-| <name>    | inline_repeated/wrapper_skip/new | go/py/bash | core/infra/... | <heredoc fragment> |
-```
-
-Si lista vacia → "no gaps detected, sesion saludable" + reporta metricas. Para.
-
-### 4. CONSTRUCT — lanza fn-constructor en paralelo
-
-Para cada candidato, dispara un sub-agente `fn-constructor` con prompt autocontenido:
-
-```
-Agent(subagent_type="fn-constructor", prompt=...)
-```
-
-Prompts en PARALELO en un mismo mensaje (varios Agent calls). Pasar:
-- nombre propuesto, lang, domain
-- firma esperada (params + return)
-- pureza
-- descripcion + ejemplo de uso (heredoc real detectado)
-- nota: "esta funcion la necesita Claude para auto-uso futuro"
-
-### 5. VALIDATE — ¿la proxima sesion la usara?
-
-Despues de que fn-constructor termine:
-
-```bash
-./fn index 2>&1 | tail -2
-# Verifica que las nuevas funciones existen
-for fn in <lista>; do
-    mcp__registry__fn_show "$fn" >/dev/null && echo "OK: $fn" || echo "FAIL: $fn"
-done
-```
-
-Tambien actualiza `call_monitor.copied_code` + `function_stats` corriendo:
-
-```bash
-cd "$ROOT/projects/fn_monitoring/apps/call_monitor" && ./call_monitor copied-code && ./call_monitor propose
-```
-
-### 5b. MEMORIZE — anadir cada funcion nueva a MEMORY.md (issue 0087 pieza 6)
-
-Por cada funcion creada con exito, llama:
-
-```bash
-bash "$ROOT/.claude/scripts/append_fn_to_memory.sh" "<fn_id>" "<one-line purpose>"
-```
-
-El script es idempotente (si la fn ya esta linkeada, no duplica). Crea `reference_fn_<id>.md` con metadata `type: reference` e indexa la entrada en `MEMORY.md` como linea `- [fn-<id>](reference_fn_<id>.md) — <purpose>`. Asi proximas sesiones cargan MEMORY.md y ven el catalogo de funciones recien creadas sin segunda lookup.
-
-`purpose` = 1 frase derivada del `description` del .md de la funcion (max 80 chars). Si description es larga, recorta. Ejemplo:
-- fn_id: `parse_http_log_go_infra`
-- purpose: "parsea log Apache/Nginx a struct; pure"
-
-Reporta:
-- N funciones nuevas creadas (con IDs)
-- N proposals nuevas en `registry.db.proposals`
-- Recomendacion al usuario: "proximo turno mencionar/usar `<fn_id>` para validar que el wrapper se invoca correctamente"
-
-### 6. SELF-TEST — telemetria del propio /fn_claude
-
-`/fn_claude` mismo debe quedar registrado. Tras ejecutar, query final:
-
-```bash
-sqlite3 "$MON" "SELECT COUNT(*) FROM calls WHERE session_id = '${CLAUDE_SESSION_ID:-unknown}' AND ts >= <inicio_comando>"
-```
-
-Si la cuenta no aumento → el comando esta operando fuera de la telemetria (bug). Reportar.
-
----
-
-## Reglas duras
-
-1. **NO ejecutar fn-constructor para algo que ya existe.** Buscar primero via `mcp__registry__fn_search`. Si match relevante → NO crear duplicado.
-2. **NO crear funciones especulativas.** Cada candidato debe tener evidencia real (snippet de heredoc o llamada inline detectada en esta sesion o en `call_monitor.calls` reciente).
-3. **PARALELO**: si hay >1 candidato, lanza todos los `fn-constructor` en un solo mensaje con multiples `Agent` calls. NO secuencial.
-4. **No autonomous merge**: las funciones nuevas viven en el branch local. NO push automatico. Humano revisa y push manual.
-5. **Limites duros**: max 5 funciones nuevas por invocacion. Si detectas mas, prioriza por evidence weight (`occurrences * recency`) y reporta el resto como pending.
-6. **Si la sesion no esta siendo registrada (`calls_session = 0`)**: ABORT antes de fase 2. No tiene sentido auto-construir sin telemetria.
-
----
-
-## Output canonico
-
-```
-=== /fn_claude — auto-auditoria ===
-session_id:        <id>
-calls_session:     N
-calls_24h:         M (mcp_ratio: 0.XX)
-violations_24h:    K
-pending_proposals: P (existentes en registry.db)
-
-GAPS DETECTADOS:
-  1. <name>_<lang>_<domain> — razon — evidencia
-  2. ...
-
-LANZADOS (en paralelo):
-  fn-constructor #1: <name1>  → en progreso
-  fn-constructor #2: <name2>  → en progreso
-  ...
-
-VALIDADAS tras ./fn index:
-  ✓ <name1>_<lang>_<domain>  
-  ✓ <name2>_<lang>_<domain>
-
-PROPOSALS NUEVAS: <count>
-
-PROXIMO TURNO: menciona `<name1>` para validar wrapper.
-```
-
----
-
-## Cuando usar
-
-- Al inicio de una sesion larga, para verificar telemetria activa.
-- A media sesion, cuando notes que estas reescribiendo el mismo bloque.
-- Antes de cerrar sesion, para capitalizar lo aprendido como funciones reutilizables.
-- Tras `/autonomous-task` para validar que el orquestador no genero ruido (proposals/funciones huerfanas).
-
----
-
-## Cuando NO usar
-
-- En sesiones cortas (<5 turnos) — no hay datos suficientes.
-- Si `call_monitor.operations.db` no esta inicializado (`call_monitor init` primero).
-- Si el usuario quiere control manual del proceso de extraccion. Este comando es agresivo.

.claude/commands/full-git-pull.md

@@ -1,38 +0,0 @@
-# /full-git-pull — Pull automático de fn_registry + sub-repos + submodules + fn sync
-
-Wrapper sobre el pipeline `full_git_pull_bash_pipelines`. Toda la lógica vive en el registry. Este comando solo ejecuta:
-
-```bash
-cd $HOME/fn_registry
-./fn run full_git_pull_bash_pipelines
-```
-
-## Argumento
-
-`$ARGUMENTS` — sin uso, ignorar.
-
-## Qué hace el pipeline
-
-1. `discover_git_repos_bash_infra` — lista repos locales (mismas exclusiones que push).
-2. `git_pull_with_stash_bash_infra` por repo: stash si dirty → fetch → pull --ff-only → pop. Estados posibles por repo: `[pulled]`, `[up-to-date]`, `[diverged]`, `[stash-conflict]`.
-3. `git submodule update --init --recursive` en root.
-4. `git_pull_with_stash` sobre `~/.password-store`.
-5. `CGO_ENABLED=1 ./fn index` para regenerar `registry.db`.
-6. `./fn sync` con credenciales de `pass`.
-
-## Notas
-
-- **Modo no-interactivo.** Auto-stash con `--include-untracked`.
-- **Fast-forward + merge auto.** Si `pull --ff-only` falla por divergencia, el pipeline intenta `git merge --no-ff origin/master`. Si el merge se aplica sin conflictos lo conserva como `[merged-auto]`. Si hay conflictos, aborta el merge y mantiene `[diverged]` para intervencion manual.
-- **No clona repos faltantes.** Cada PC tiene su subset. Para añadir uno, clonarlo a mano y mirar `pc_locations` para reproducir el path.
-- Para tocar la lógica: editar las funciones del registry, no este wrapper.
-
-## Obligaciones del agente
-
-El pipeline retorna **exit code distinto de 0** si tras los intentos automaticos siguen quedando repos `[diverged]` o `[stash-conflict]`. En ese caso el agente DEBE:
-
-1. Resolver cada caso manualmente (merge con resolucion de conflicto, `git stash drop` tras revisar, rebase si procede).
-2. Volver a ejecutar `/full-git-pull` hasta salida limpia.
-3. Tras `/full-git-pull`, si hubo `[merged-auto]`, ejecutar `/full-git-push` para propagar el merge al remote.
-
-Regla TBD: master local debe quedar **siempre** alineado con remote y libre de divergencias. Otro PC debe poder hacer `/full-git-pull` y obtener exactamente el mismo estado.

.claude/commands/full-git-push.md

@@ -1,41 +0,0 @@
-# /full-git-push — Push automático de fn_registry + sub-repos + fn sync
-
-Wrapper sobre el pipeline `full_git_push_bash_pipelines`. Toda la lógica vive en el registry. Este comando solo ejecuta:
-
-```bash
-cd "${FN_REGISTRY_ROOT:-$HOME/fn_registry}"
-./fn run full_git_push_bash_pipelines "$ARGUMENTS"
-```
-
-## Argumento
-
-`$ARGUMENTS` — opcional. Mensaje de commit fijo para todos los repos dirty. Sin argumento, el pipeline genera un mensaje automático por repo según los paths cambiados (ver `bash/functions/infra/git_auto_commit_dirty.sh`).
-
-## Qué hace el pipeline
-
-1. `discover_git_repos_bash_infra` — lista repos bajo `fn_registry` (excluye `node_modules`, `.venv`, `cpp/vendor`, `cpp/build`, `sources`, `temp`, `subrepos`).
-2. Auto-inicializa apps/analyses sin `.git` con `ensure_repo_synced_bash_infra` (Gitea `dataforge/<basename>`).
-3. `scan_secrets_in_dirty_bash_cybersecurity` — aborta si detecta nombres sospechosos (`.env*`, `*credentials*`, `*.key`, `*.pem`, `id_rsa*`, `*secret*`, `*token*.txt`).
-4. `git_auto_commit_dirty_bash_infra` — commitea cada repo dirty.
-5. `git_push_if_ahead_bash_infra` — push solo si `rev-list @{u}..HEAD > 0` (sin red previa).
-6. Push de `~/.password-store` (sin commitear, pass autocommitea).
-7. `./fn sync` con credenciales cargadas desde `pass`.
-
-## Notas
-
-- **Modo no-interactivo por diseño.** Auto-commitea sin preguntar.
-- **Único motivo de aborto antes de commitear:** secret detectado por nombre.
-- Si un pre-commit hook bloquea (ej. `audit_uses_functions` con drift), el pipeline reintenta con `--no-verify` para no perder cambios. Los bypasses se reportan en bloque `[!] Hook bypasses` al final.
-- Si un push es rechazado por non-fast-forward, el pipeline intenta `git merge --no-ff origin/master` automaticamente y vuelve a pushear. Si el merge tiene conflictos, lo aborta y reporta.
-- Para tocar la lógica: editar las funciones del registry, no este wrapper.
-
-## Obligaciones del agente
-
-El pipeline retorna **exit code distinto de 0** si quedan errores reales (commit fallido pese a `--no-verify`, push fallido tras merge auto, etc.) y los lista bajo `[!!] ERRORES`. Cuando esto ocurra el agente DEBE:
-
-1. Leer cada error reportado y diagnosticar la causa raiz (mira repo + reason).
-2. Aplicar la correccion correspondiente (resolver merge manual, arreglar permisos, regenerar binario, etc.).
-3. Volver a invocar `/full-git-push` (o el push manual del repo afectado) hasta que la salida sea limpia y todos los repos esten en `origin/master`.
-4. Si aparece bloque `[!] Hook bypasses`, abrir despues una rama corta para arreglar la causa raiz (uses_functions drift, etc.) y commitear con hooks activos. No es bloqueante para el push pero es deuda a saldar pronto.
-
-Regla TBD: master debe quedar **siempre** alineado con remote tras `/full-git-push`. Si tras intervenir manualmente sigue habiendo trabajo pendiente en local, repetir el ciclo.

.claude/commands/issue.md

@@ -1,93 +0,0 @@
----
-description: "Gestiona issues del registry en dev/issues/. Subcomandos: list, show, status, board, dep, roadmap, tag, done, stale, create. Frontmatter YAML canonico (issue 0100)."
----
-
-# /issue — Gestionar issues del registry
-
-Issues viven en `dev/issues/NNNN-<slug>.md` con frontmatter YAML canonico (id, title, status, type, domain, scope, priority, depends, blocks, related, created, updated, tags).
-
-Allowlists en `dev/TAXONOMY.md` (no inventar valores).
-
-Diferencia con `dev/flows/`:
-- **Issues** = bugs, features, refactors, chores, epics de implementacion.
-- **Flows** = casos de uso end-to-end multi-app.
-
-## Sintaxis
-
-```
-/issue list [--domain X] [--type Y] [--status Z] [--prio P] [--epic NNNN]
-/issue show NNNN
-/issue status NNNN              # acceptance % + estado deps
-/issue board                     # kanban pendiente/in-progress/bloqueado/done
-/issue dep NNNN                  # arbol bloquea/depende
-/issue roadmap NNNN              # epic + sub-IDs (NNNNa, NNNNb, ...)
-/issue tag NNNN +X -Y            # mantenimiento tags/domain
-/issue done NNNN                 # mueve a completed/, valida deps
-/issue stale [--days 30]
-/issue create <slug> --type T --domain D [--prio P] [--depends NNNN]
-```
-
-## Implementacion
-
-**Fase 1 (manual via Claude):**
-
-El agente lee `dev/issues/*.md`, parsea frontmatter YAML con `yaml.safe_load`, aplica el filtro, imprime tabla.
-
-```python
-import yaml, pathlib, re
-issues = []
-for f in pathlib.Path("dev/issues").glob("*.md"):
-    if f.name in {"README.md", "template.md"}: continue
-    txt = f.read_text()
-    m = re.match(r"^---\n(.*?)\n---", txt, re.S)
-    if not m: continue
-    fm = yaml.safe_load(m.group(1)) or {}
-    fm["_path"] = str(f)
-    issues.append(fm)
-# filter + print
-```
-
-**Fase 2 (cuando 0101 dev_console exista):**
-
-Cada subcomando se mapea a `./apps/dev_console/dev_console issue <subcomando> $ARGS`.
-
-## Subcomandos clave
-
-### `list`
-
-Imprime tabla `id | title | status | type | domain | priority | depends_pending`. Filtrable por flags.
-
-### `show NNNN`
-
-Read directo del .md + render del frontmatter como tabla + body como markdown.
-
-### `status NNNN`
-
-Cuenta checkboxes en `## Acceptance` + chequea si todos los `depends` estan en `status: completado`. Si alguno no, marca `bloqueado`.
-
-### `board`
-
-Tabla 4 columnas (pendiente / in-progress / bloqueado / completado_hoy). Card por issue: id + title + prio. Status `bloqueado` se calcula on-the-fly desde `depends`.
-
-### `roadmap NNNN`
-
-Si `type: epic`: lista sub-issues `NNNNa`, `NNNNb`, etc. con su estado. Si no epic: error "not an epic".
-
-### `done NNNN`
-
-1. Lee frontmatter.
-2. Verifica todos `depends` cerrados (sino, error).
-3. Cuenta `## Acceptance` 100% (sino, error).
-4. `git mv dev/issues/NNNN-*.md dev/issues/completed/`.
-5. Actualiza `status: completado` + `updated: today`.
-
-### `create <slug> --type T --domain D`
-
-Genera siguiente ID libre (max existing + 1, zero-padded 4). Scaffold desde plantilla minima con frontmatter rellenado.
-
-## Reglas
-
-- Domain debe estar en `dev/TAXONOMY.md` allowlist.
-- Scope/type/priority idem.
-- `id` siempre string `"NNNN"` (zero-padded, sub-IDs con sufijo `a-z`).
-- Modificar frontmatter SIEMPRE preserva campos no tocados (no overwrite).

.claude/commands/meta_bigq.md

@@ -109,296 +109,6 @@ metabase_update_dashboard(client, dash["id"], dashcards=[
 
 **Filtros de list_dashboards:** `all`, `mine`, `archived`
 
-### Dashboards — helpers compositivos (añadir KPIs a dashboard existente)
-
-Helpers para el flujo tipico "anadir N cards (KPI) al final de un tab existente reusando los mismos filtros que otro card vecino". Evitan los gotchas: replicar `parameter_mappings`, calcular `row` libre, escapado raro de `column_settings`, generacion de `lib/uuid` en MBQL.
-
-```python
-from metabase import (
-    metabase_mbql_from_source_card,
-    metabase_copy_dashcard_mappings,
-    metabase_dashboard_next_row,
-    metabase_dashboard_append_row,
-    metabase_viz_column_format,
-    metabase_smartscalar_anothercolumn_viz,
-)
-```
-
-#### `metabase_mbql_from_source_card`
-
-Construye `dataset_query` MBQL sobre una saved-card (`source-card`), con aggregations + joins + filters + breakouts + segunda stage de expressions. Genera `lib/uuid` automatico en cada nodo.
-
-```python
-dq = metabase_mbql_from_source_card(
-    database_id=6,
-    source_card_id=5305,
-    aggregations=[
-        {"op": "sum", "field": "PrecioVenta", "base_type": "type/Decimal"},
-        {"op": "sum", "field": "PrecioCompra", "base_type": "type/Decimal"},
-        {"op": "sum", "field": "PrecioTasas", "base_type": "type/Float"},
-    ],
-    joins=[
-        {"alias": "Centros - idCentro", "source_card_id": 4076,
-         "fields": "none", "local_field": "idCentro", "local_base_type": "type/Text",
-         "foreign_field_id": 17316, "foreign_base_type": "type/Text"},
-    ],
-    filters=[["not-empty", {}, ["field", {"base-type": "type/Text"},
-              "Centros - idCentro__Companies__name"]]],
-    expressions=[
-        {"name": "MasadeMargen", "expr":
-            {"op": "-", "args": [{"field": "sum"},
-                {"op": "+", "args": [{"field": "sum_2"}, {"field": "sum_3", "base_type": "type/Float"}]}]}},
-        {"name": "Margen", "expr":
-            {"op": "coalesce", "args": [
-                {"op": "/", "args": [
-                    {"op": "-", "args": [{"field": "sum"},
-                        {"op": "+", "args": [{"field": "sum_2"}, {"field": "sum_3", "base_type": "type/Float"}]}]},
-                    {"field": "sum"}]},
-                0]}},
-    ],
-)
-```
-
-Ops soportadas en expressions: `+`, `-`, `*`, `/`, `coalesce`, `case`. Referencia a otra expresion en la misma stage: `{"ref": "Margen"}`. Aliases de aggregations son posicionales: `sum`, `sum_2`, `sum_3`... (orden = declaracion).
-
-#### `metabase_copy_dashcard_mappings`
-
-Copia los `parameter_mappings` de un dashcard "donante" a un card nuevo. Devuelve lista lista para pegar en `dashcards_add`.
-
-```python
-mappings = metabase_copy_dashcard_mappings(
-    client,
-    dashboard_id=734,
-    source_card_id=9918,   # card donante con 18 filtros mapeados
-    dest_card_id=9947,     # card destino nueva
-)
-# Devuelve [{"parameter_id","card_id","target"}, ...] con card_id=9947
-```
-
-#### `metabase_dashboard_next_row`
-
-Calcula el primer `row` libre al final de un tab.
-
-```python
-row = metabase_dashboard_next_row(client, dashboard_id=734, tab_id=191)
-# row=12 si el ultimo card termina en row+size_y=12
-# tab_id=0 → dashboards sin tabs
-```
-
-#### `metabase_dashboard_append_row`
-
-Combo: append N cards en una fila horizontal al final del tab, copiando mappings de un donante. Una sola llamada hace `next_row` + grid math + `copy_mappings` + `update_dashboard_safe`.
-
-```python
-metabase_dashboard_append_row(
-    client,
-    dashboard_id=734,
-    tab_id=191,
-    card_ids=[9947, 9948, 9949],
-    height=4,
-    donor_card_id=9918,   # mismos 18 filtros del dashboard
-    grid_width=24,        # default Metabase v0.59
-)
-# Coloca 3 cards de size_x=8 en row=next, cols 0/8/16, con mappings copiados
-```
-
-#### `metabase_viz_column_format`
-
-Construye una entrada de `column_settings` con la clave JSON-escaped (`'["name","Margen"]'`) sin tener que recordar el formato exacto.
-
-```python
-metabase_viz_column_format("Margen", number_style="percent", decimals=2)
-# {'["name","Margen"]': {"number_style": "percent", "decimals": 2}}
-
-metabase_viz_column_format("MasadeMargen", number_style="currency",
-                            currency="EUR", decimals=0, currency_in_header=False)
-# {'["name","MasadeMargen"]': {...}}
-```
-
-Mergea varios resultados en `column_settings` de las visualization_settings.
-
-#### `metabase_smartscalar_anothercolumn_viz`
-
-Construye `visualization_settings` completo para `display=smartscalar` con comparativa tipo `anotherColumn` (compara dos columnas de la misma fila — no requiere breakout temporal).
-
-```python
-viz = metabase_smartscalar_anothercolumn_viz(
-    main_column="Margen",
-    compare_column="Margen_N1",
-    label="vs N-1",
-    number_style="percent",
-    decimals=2,
-)
-# Setear en /api/card via PUT visualization_settings=viz
-```
-
-**⚠ Gotcha smartscalar Metabase v0.59:** el visualization solo acepta `type: "anotherColumn"` cuando la query NO produce filas multiples. Si Metabase muestra el error *"Agrupa solo por un campo de tiempo para ver como ha cambiado con el tiempo"*, hace falta un **breakout temporal** en la MBQL (ej. `breakouts=[{"field":"fecha","base_type":"type/Date","temporal_unit":"month"}]`) y usar el comparison `previousValue` en lugar de `anotherColumn`. Alternativa: `metabase_smartscalar_kpi_sql` + `metabase_smartscalar_kpi_payload` (patron 2-row nativo) si la card es SQL nativo.
-
-#### Patron canonico — anadir 3 KPI cards a tab existente
-
-```python
-import os, sys
-sys.path.insert(0, "python/functions")
-from metabase import (
-    MetabaseClient, metabase_create_card, metabase_mbql_from_source_card,
-    metabase_dashboard_append_row, metabase_viz_column_format,
-    metabase_smartscalar_anothercolumn_viz,
-)
-
-c = MetabaseClient("https://reports.autingo.es", os.environ["MB_API_KEY"])
-
-# 1) MBQL reusando una saved-card como source
-def query():
-    return metabase_mbql_from_source_card(
-        database_id=6, source_card_id=5305,
-        aggregations=[
-            {"op":"sum","field":"PrecioVenta","base_type":"type/Decimal"},
-            {"op":"sum","field":"PrecioCompra","base_type":"type/Decimal"},
-            {"op":"sum","field":"PrecioTasas","base_type":"type/Float"},
-        ],
-        # joins/filters/expressions ...
-    )
-
-# 2) Crear cards
-card1 = metabase_create_card(c, "Masa de Margen", query(),
-    display="scalar", collection_id=500)
-viz1 = {"scalar.field": "MasadeMargen",
-        "column_settings": metabase_viz_column_format(
-            "MasadeMargen", number_style="currency", currency="EUR", decimals=0)}
-c._http.request("PUT", f"/api/card/{card1['id']}", json={"visualization_settings": viz1})
-
-card2 = metabase_create_card(c, "Margen", query(), display="smartscalar", collection_id=500)
-viz2 = metabase_smartscalar_anothercolumn_viz(
-    main_column="Margen", compare_column="Margen_N1", number_style="percent", decimals=2)
-c._http.request("PUT", f"/api/card/{card2['id']}", json={"visualization_settings": viz2})
-
-# 3) Append fila al tab con mappings copiados del donante
-metabase_dashboard_append_row(
-    c, dashboard_id=734, tab_id=191,
-    card_ids=[card1["id"], card2["id"]],
-    height=4, donor_card_id=9918,
-)
-```
-
-### Documents (ProseMirror)
-
-Los "documents" son páginas narrativas editables con texto rico y cards embebidas. **No hay helpers en fn_registry todavía** — usa el endpoint REST directamente a través de `client._http`.
-
-**Endpoints:**
-
-| Método | Ruta | Qué hace |
-|--------|------|---------|
-| GET    | `/api/document` | Lista documents (`{items: [...]}`) |
-| GET    | `/api/document/{id}` | Lee un document (incluye `document` con árbol ProseMirror) |
-| POST   | `/api/document` | Crea. Payload: `{name, collection_id, document}` |
-| PUT    | `/api/document/{id}` | Actualiza. Mismo payload que POST |
-| PUT    | `/api/document/{id}` con `{archived: true}` | Soft-delete |
-
-```python
-# Crear documento
-resp = client._http.request("POST", "/api/document", json={
-    "name": "Mi análisis",
-    "collection_id": 583,  # obligatorio — raíz no se acepta desde API
-    "document": {"type": "doc", "content": [
-        {"type": "heading", "attrs": {"level": 1}, "content": [{"type": "text", "text": "Título"}]},
-        {"type": "paragraph", "content": [{"type": "text", "text": "Cuerpo."}]},
-    ]},
-})
-doc_id = resp.json()["id"]
-print(f"https://reports.autingo.es/document/{doc_id}")
-```
-
-#### Tipos de nodo SOPORTADOS en Metabase v0.59.x
-
-Solo estos tipos renderizan. **Cualquier tipo fuera de esta lista hace que el documento se vea vacío al abrirlo.**
-
-```python
-ALLOWED_DOC_NODES = {
-    "doc", "heading", "paragraph", "text",
-    "horizontalRule", "blockquote",
-    "bulletList", "listItem",
-    "codeBlock",        # attrs.language ej: "sql"
-    "resizeNode",       # envuelve SIEMPRE a cardEmbed
-    "cardEmbed",        # solo dentro de resizeNode
-}
-```
-
-Marcas inline válidas en nodos `text`: `bold`, `italic`, `code`, `strike` (se aplican con `"marks": [{"type": "bold"}, ...]`).
-
-#### Tipos PROHIBIDOS (rompen el render)
-
-- `table`, `tableRow`, `tableHeader`, `tableCell` → en v0.59.x no están registrados en el schema del editor y el doc entero se vuelve invisible.
-- `callout` → idem (documentado en memoria `feedback_metabase_prosemirror.md`).
-- `image`, `video`, `iframe`, `mention`, cualquier embed de terceros → no registrados.
-
-Si necesitas una tabla, **emúlala con una `bulletList` de `**clave:** valor`**:
-
-```python
-def kv_list(pairs):
-    return {"type": "bulletList", "content": [
-        {"type": "listItem", "content": [
-            {"type": "paragraph", "content": [
-                {"type": "text", "text": k, "marks": [{"type": "bold"}]},
-                {"type": "text", "text": f": {v}"},
-            ]},
-        ]}
-        for k, v in pairs
-    ]}
-```
-
-#### cardEmbed SIEMPRE dentro de resizeNode
-
-Un `cardEmbed` suelto no renderiza. Patrón obligatorio:
-
-```python
-def card_embed(card_id, height=420):
-    import uuid
-    return {
-        "type": "resizeNode",
-        "attrs": {"height": height, "minHeight": 280},
-        "content": [{
-            "type": "cardEmbed",
-            "attrs": {"id": card_id, "name": None, "_id": str(uuid.uuid4())},
-        }],
-    }
-```
-
-#### Validación OBLIGATORIA antes de POST/PUT
-
-Nunca envíes un document a Metabase sin validar primero. Un solo nodo prohibido lo deja invisible sin devolver error HTTP:
-
-```python
-ALLOWED = {"doc","heading","paragraph","text","horizontalRule","blockquote",
-           "bulletList","listItem","codeBlock","resizeNode","cardEmbed"}
-
-def validate_doc(node, path=""):
-    errs = []
-    if isinstance(node, dict):
-        typ = node.get("type", "?")
-        if typ not in ALLOWED:
-            errs.append(f"{path}: tipo no permitido '{typ}'")
-        if typ == "resizeNode":
-            inner = node.get("content", [])
-            if not (len(inner) == 1 and inner[0].get("type") == "cardEmbed"):
-                errs.append(f"{path}: resizeNode debe contener exactamente un cardEmbed")
-            return errs  # no re-descender al cardEmbed interno
-        for i, c in enumerate(node.get("content", []) or []):
-            errs += validate_doc(c, f"{path}/{typ}[{i}]")
-    return errs
-
-errs = validate_doc(my_doc)
-assert not errs, f"Doc inválido:\n" + "\n".join(f"  - {e}" for e in errs)
-```
-
-#### Aprender estructura de un doc que ya funciona
-
-Si dudas sobre un nodo, **clónalo de un doc existente que renderice**:
-
-```python
-d = client._http.request("GET", "/api/document/2").json()
-# d["document"] contiene el árbol completo en ProseMirror
-```
-
 ### Databases
 
 ```python

.claude/commands/modo_launcher.md

@@ -1,159 +0,0 @@
----
-description: "Modo launcher: das ordenes en lenguaje natural y Claude responde SOLO con la procedencia (registry/bash/heredoc) + el comando exacto, y lo ejecuta. Agiliza el lanzamiento de comandos y audita en vivo el Reg % (uso real de funciones del registry)."
----
-
-# /modo_launcher — lanzamiento rápido registry-first
-
-Activa un **modo de comportamiento** persistente. Mientras estás dentro, el usuario da órdenes en lenguaje natural y Claude responde con el **mínimo absoluto**: la procedencia del comando + el comando exacto + por qué, y lo ejecuta. Sin prosa, sin explicaciones largas, sin preámbulos.
-
-El objetivo es doble:
-
-1. **Agilizar** el lanzamiento de comandos (cero verborrea entre orden y ejecución).
-2. **Auditar en vivo** que de verdad pasamos por funciones del registry antes que por bash inline — sube `Reg %` (objetivo 1 del Norte) y expone gaps reutilizables (objetivo 3).
-
-## Activación
-
-Al invocar `/modo_launcher` entras en **MODO LAUNCHER**. El modo permanece activo en todos los turnos siguientes hasta que el usuario escriba `salir` o `fin launcher`. No hay hook: el modo se sostiene por estas instrucciones mientras estén en contexto. Si el comportamiento se diluye tras muchos turnos, el usuario puede re-invocar `/modo_launcher` para reanclarlo.
-
-Al entrar, responde con una sola línea de confirmación y queda a la espera:
-
-```
-MODO LAUNCHER activo. Da ordenes. 'salir' para terminar.
-```
-
-## Comportamiento por orden (regla dura)
-
-Para CADA orden del usuario mientras el modo esté activo:
-
-1. **Registry-first.** Mapea la orden a una capacidad y busca primero en el registry vía FTS (`mcp__registry__fn_search`) o reconoce un ID conocido. Las funciones del registry SIEMPRE tienen prioridad sobre bash inline.
-2. **Clasifica la procedencia** según la taxonomía de abajo.
-3. **Ejecuta directo.** Identificado el comando, ejecútalo sin pedir permiso — salvo que sea destructivo (ver guarda).
-4. **Responde en el formato fijo** (abajo), con la salida cruda del comando. Nada más.
-
-## Formato de respuesta (OBLIGATORIO en cada orden)
-
-```
-FUENTE: <etiqueta>
-CMD:    <comando exacto>
-WHY:    <razón: match FTS, ID conocido, o "sin función → bash">
-──────────
-<salida cruda del comando>
-```
-
-- `FUENTE` es una de las etiquetas de la taxonomía.
-- `CMD` es el comando literal lanzado (forma `./fn run <id> [args]` para legibilidad aunque la ejecución real vaya por MCP).
-- `WHY` es una línea: qué match de búsqueda o qué ID justifica esa elección. Si fue un gap, dilo.
-- Tras la regla `──────────`, la salida cruda. Cero comentario después salvo que el usuario pregunte.
-
-## Taxonomía de procedencia
-
-| Etiqueta | Qué es | Cómo se ejecuta |
-|---|---|---|
-| `registry-run` | Ejecutar UNA función o pipeline del registry | `mcp__registry__fn_run <id> [args]` (preferido); fallback `./fn run <id> [args]` |
-| `registry-mcp` | Inspeccionar el registro (buscar, ver, código, deps, dominios) | `mcp__registry__fn_search` / `fn_show` / `fn_code` / `fn_uses` / `fn_list_domains` |
-| `heredoc` | Componer N funciones con lógica intermedia (loops, dispatch) | Heredoc `python/.venv/bin/python3 - <<'PY' ... PY` importando del registry |
-| `bash` | Comando shell puro: no existe función que lo cubra | Bash directo |
-| `gap` | No hay función Y el patrón parece reutilizable | Ejecuta el bash equivalente y marca el candidato (ver abajo) |
-
-### Preferencia de ejecución para `registry-run`
-
-- Usa `mcp__registry__fn_run` cuando esté disponible (queda registrado en `call_monitor`, alimenta el bucle reactivo).
-- Si el MCP `fn_run` no está habilitado (requiere `--enable-run`), cae a `./fn run <id>` por terminal. La línea `CMD` muestra siempre la forma `./fn run <id>` por legibilidad.
-
-## Gaps: orden sin función en el registry
-
-Cuando una orden no tenga función que la cubra:
-
-1. Ejecuta el bash equivalente (`FUENTE: bash`).
-2. Si el patrón parece **reutilizable** (firma genérica, se repetiría en otras tareas, ≥5 líneas de lógica), añade tras la salida UNA línea:
-
-```
-CANDIDATO → <nombre_propuesto>_<lang>_<domain>: <1 frase de qué haría>
-```
-
-No lances `fn-constructor` automáticamente dentro del modo (rompería el ritmo de lanzamiento). Solo marca. El usuario decide al salir si promueve los candidatos.
-
-## Guarda de comandos destructivos
-
-Ejecuta directo SALVO que el comando sea irreversible o de alto impacto. En esos casos, NO ejecutes: muestra el bloque con `FUENTE`/`CMD`/`WHY` y añade `⚠ DESTRUCTIVO — confirma con 'ok'` en vez de la salida. Espera el `ok` explícito del usuario antes de lanzar.
-
-Patrones que exigen confirmación:
-
-- `rm -rf`, borrado de archivos versionados, `> archivo` sobre archivos trackeados.
-- `git push --force`, `git reset --hard`, `git clean`, borrado de ramas.
-- SQL `DROP`, `DELETE` sin `WHERE`, `TRUNCATE`, borrar cualquier `.db`.
-- `deploy`, `systemctl stop/restart/disable` de services, `fn sync` (escribe en el servidor).
-- `kill -9` masivo, `format`, `mkfs`, `dd`, cambios en `fstab`.
-
-Para todo lo demás (lecturas, búsquedas, `fn run` de funciones puras o idempotentes, `git status/add/commit`, listados), ejecuta directo.
-
-## Salida del modo
-
-Cuando el usuario escriba `salir` o `fin launcher`, cierra el modo con un resumen caveman de una tabla:
-
-```
-=== fin MODO LAUNCHER ===
-ordenes:    N
-registry:   X  (run A / mcp B)
-bash:       Y
-gaps:       Z  → [lista de candidatos marcados]
-Reg %:      X/(X+Y) de las ordenes ejecutables golpearon el registry
-```
-
-Si hubo candidatos a función (`gap`), recuérdalos y pregunta si promover alguno vía `fn-constructor`.
-
-## Reglas duras del modo
-
-- **Registry-first siempre.** Nunca escribas bash inline para lógica que ya es función del registry. Busca antes de teclear.
-- **Cero prosa fuera del bloque.** Nada de "Claro, voy a…". Solo el bloque `FUENTE/CMD/WHY/salida`.
-- **Una orden = un bloque.** Si la orden necesita varios pasos, encadénalos en un solo `CMD` o numera los bloques, pero mantén el formato.
-- **No inventes IDs.** Si no encuentras función por búsqueda, es `gap`, no un `registry-run` falso.
-- **El modo no exime de las reglas del repo** (`registry_calls.md`, `purity.md`, etc.). Solo cambia el estilo de respuesta.
-
-## Ejemplo de sesión
-
-```
-tú: /modo_launcher
-yo: MODO LAUNCHER activo. Da ordenes. 'salir' para terminar.
-
-tú: busca funciones de slice
-yo: FUENTE: registry-mcp
-    CMD:    mcp__registry__fn_search query="slice"
-    WHY:    inspección directa del registro
-    ──────────
-    filter_slice_go_core — Filtra slice por predicado
-    chunk_slice_go_core   — Parte slice en lotes de N
-    ...
-
-tú: mata lo que escuche en el puerto 8484
-yo: FUENTE: registry-run
-    CMD:    ./fn run port_kill_bash_infra 8484
-    WHY:    match FTS 'port kill' → port_kill_bash_infra
-    ──────────
-    killed pid 33120 on :8484
-
-tú: enséñame el uso de disco de home
-yo: FUENTE: bash
-    CMD:    du -sh /home/enmanuel/* | sort -rh | head
-    WHY:    sin función → utilidad de sistema puntual
-    ──────────
-    12G   /home/enmanuel/fn_registry
-    ...
-    CANDIDATO → disk_usage_top_bash_shell: top-N directorios por tamaño en una ruta
-
-tú: salir
-yo: === fin MODO LAUNCHER ===
-    ordenes:    3
-    registry:   2  (run 1 / mcp 1)
-    bash:       1
-    gaps:       1  → disk_usage_top_bash_shell
-    Reg %:      2/3 (67%)
-    1 candidato marcado. ¿Promuevo disk_usage_top_bash_shell vía fn-constructor?
-```
-
-## Relación con otras reglas
-
-- `registry_calls.md` — el modo es una capa de estilo sobre los tres patrones canónicos (inspect / run / compose).
-- `registry_first.md` — el modo materializa "buscar antes de escribir" en cada orden.
-- `function_growth_and_self_docs.md` — los candidatos marcados alimentan la promoción de patrones inline a funciones.
-- `kiss.md` — sin hook, sin estado en disco: el modo vive solo en estas instrucciones.

.claude/commands/new-cpp-app.md

@@ -1,53 +0,0 @@
-# /new-cpp-app — Crear app C++ nueva con scaffolder estandar
-
-Wrapper sobre el pipeline `init_cpp_app_bash_pipelines`. Genera la estructura canonica que cumple `cpp/PATTERNS.md` y `.claude/rules/cpp_apps.md` (main.cpp con `cfg.about/log/panels`, sin `app_menubar` manual, dockspace via framework), registra la app en `cpp/CMakeLists.txt`, crea repo Gitea `dataforge/<name>` y ejecuta `fn index`.
-
-```bash
-cd $HOME/fn_registry
-./fn run init_cpp_app $ARGUMENTS
-```
-
-## Uso
-
-```
-/new-cpp-app <name> [--project <p>] [--domain <d>] [--desc "..."] [--tags "a,b"]
-```
-
-## Ejemplos
-
-```bash
-# App suelta en cpp/apps/<name>/
-/new-cpp-app my_tool --desc "Herramienta para X"
-
-# App dentro de un proyecto
-/new-cpp-app finance_panel --project budget --desc "Panel de finanzas" --tags "finance,dashboard"
-```
-
-## Que genera
-
-```
-<dir>/
-  main.cpp        # Plantilla canonica: panels[] + cfg.about + cfg.log + run_app(cfg, render)
-  CMakeLists.txt  # add_imgui_app(<name> main.cpp)
-  app.md          # Frontmatter completo (lang:cpp, framework:imgui, dir_path, repo_url)
-```
-
-Mas registro en `cpp/CMakeLists.txt`, repo Gitea con commit inicial, y `fn index` para que aparezca en `registry.db`.
-
-## Despues de crear
-
-1. Editar `app.md` y completar `uses_functions` cuando la app consuma funciones del registry.
-2. Anadir las funciones al `CMakeLists.txt` como paths absolutos: `${CMAKE_SOURCE_DIR}/functions/<dom>/<func>.cpp`.
-3. Build: `/compile <name>` o `cd cpp && cmake --build build --target <name> -j`.
-
-## Cuando NO usar
-
-NUNCA — esta es la unica via para crear apps C++ nuevas. Si el scaffolder no cubre un caso, modificar la plantilla en `bash/functions/pipelines/init_cpp_app.sh`. Escribir `main.cpp + CMakeLists.txt + app.md` a mano esta prohibido por `.claude/rules/cpp_apps.md`.
-
-## Auditoria post-creacion
-
-```
-fn doctor cpp-apps
-```
-
-Lista apps que se desvian del estandar (sin `cfg.about`, con `app_menubar` manual, dockspace duplicado, etc.).

.claude/commands/subagentes.md

@@ -1,97 +0,0 @@
----
-description: "Recordatorio operativo para usar subagentes fn (constructor/executor/recopilador/analizador/mejorador) y paralelizar trabajo independiente"
----
-
-# /subagentes — usa subagentes fn y paraleliza
-
-Recuerda: antes de escribir codigo nuevo o ejecutar pipelines en serie, **delega a subagentes** y **paraleliza** llamadas independientes (un mensaje, varios `Agent` calls).
-
----
-
-## Mapa de subagentes fn (ciclo reactivo)
-
-| Fase | Agente | Cuando dispararlo |
-|---|---|---|
-| 1 CONSTRUIR | `fn-constructor` | Falta funcion/tipo/test reutilizable. NUNCA escribir inline en `apps/` si es reutilizable |
-| 2 EJECUTAR | `fn-executor` | Correr pipeline/funcion del registry + registrar ejecucion en `operations.db` |
-| 3 RECOPILAR | `fn-recopilador` | Auditar integridad de `operations.db`. Modo `design-e2e <app>` propone bloque `e2e_checks` |
-| 4 ANALIZAR | `fn-analizador` | Ejecutar `e2e_checks` de `app.md`, veredicto pass/fail, persistir en `e2e_runs` |
-| 5 MEJORAR | `fn-mejorador` | Convertir fallos de `e2e_runs` en `proposals` con evidencia trazable |
-| 6 META | `fn-orquestador` | Recorrer fases 1-5 solo hasta convergencia. Sandbox `auto/<issue>`. Issue 0069 |
-
-**Pre-condiciones de `fn-orquestador`** (abortara si no se cumplen):
-- Migration `fn_operations/migrations/006_task_runs.sql` aplicada
-- Issue con criterios de aceptacion **verificables programaticamente** (no "funciona bien")
-- `master` local up-to-date con `origin/master`
-- Branch `auto/<issue>` NO existe ya (limpiar previo si hace falta)
-- `gh` autenticado (PR draft al converger)
-- Tipo soportado: `feature_app_simple`, `bugfix_with_repro`, `refactor_safe`, `add_e2e_check`
-
-**Aislamiento por worktree**: cada run crea `/tmp/fn_orq_<issue>_<ts>/` via `git worktree add`. Working tree principal del usuario queda intacto. N orquestadores paralelos = N worktrees independientes. `task_runs` persiste en BD del repo principal (auditoria sobrevive aunque borres worktree).
-
-## Otros subagentes utiles
-
-- `Explore` — busquedas amplias en codebase (>3 queries) sin contaminar contexto principal
-- `general-purpose` — research multi-step open-ended
-
-## Reglas duras
-
-1. **Paralelo real**: tareas independientes → un mensaje con varios `Agent` calls. NO en serie.
-2. **Briefing autocontenido**: subagente no ve historial. Pasar paths absolutos, IDs, criterio exito.
-3. **No delegar comprension**: nada de "haz lo que veas". Especificar que cambiar, donde, por que.
-4. **Verificar output**: leer diff/resultado, no confiar en resumen del subagente.
-5. **No duplicar**: si delegas research, no lo repitas tu.
-
-## Patrones canonicos de paralelismo
-
-- 3 funciones de registry independientes → 3 `fn-constructor` en paralelo
-- Auditar N apps → N `fn-recopilador` en paralelo
-- Validar varias apps → N `fn-analizador` en paralelo
-- Build cpp + tests py + audit operations.db → 3 calls paralelos
-- Tras `fn-analizador` con fallos → `fn-mejorador` por cada `run_id`
-- Tarea multi-fase autonoma (issue con criterios verificables) → `fn-orquestador` (1 sola run, NO recursivo)
-
-## Anti-patrones
-
-- Escribir funcion reutilizable inline en `apps/` (debe ir a `functions/` via `fn-constructor`)
-- Lanzar subagentes en serie cuando son independientes
-- Prompt de 1 linea sin contexto ("arregla esto")
-- Invocar subagente y luego hacer tu mismo el trabajo
-- Spawn `fn-orquestador` sin migration 006 o sin issue verificable (abortara)
-- `fn-orquestador` recursivo (un orquestador no spawn-ea otro)
-
-## Checklist pre-respuesta
-
-- ¿>1 tarea independiente? → paralelizar
-- ¿Hace falta funcion/tipo nuevo? → `fn-constructor`, NO inline
-- ¿Hay que ejecutar/auditar/validar? → fase 2/3/4 segun toque
-- ¿`e2e_runs` con fallos? → `fn-mejorador`
-- ¿Issue con criterios verificables + tipo soportado? → `fn-orquestador` (chequear pre-condiciones)
-- ¿Research amplio (>3 queries)? → `Explore`
-
-## Plantilla minima de prompt para subagente
-
-```
-Contexto: <que repo, que app, que objetivo>
-Input: <paths absolutos, IDs registry, run_id si aplica>
-Tarea: <accion concreta y acotada>
-Criterio exito: <como sabe que termino>
-Limites: <que NO debe tocar>
-Telemetria: tus tool calls quedan registradas en projects/fn_monitoring/apps/call_monitor/operations.db
-            via hook PostToolUse heredado de settings.local.json. Sigue patrones canonicos
-            (mcp__registry__fn_*, ./fn run, heredoc importando) — los antipatrones se loguean
-            como violations.
-```
-
-## Telemetria heredada (issue 0085 hardening 5)
-
-Los hooks de `.claude/settings.local.json` se heredan automaticamente por cada sub-agente que Claude Code lance via la tool `Agent`. Eso significa:
-
-- Cada Bash, Edit, Write, MultiEdit, `mcp__registry__*` del sub-agente dispara `hook_call_monitor.sh` exactamente igual que en la sesion principal.
-- El `session_id` del JSON de input del hook viene del sub-agente, distinto al de la sesion padre. Util para auditar comportamiento por agente.
-- Las violations detectadas (sqlite3 directo, heredoc reinventando, etc) cuentan tambien para sub-agentes — un `fn-constructor` que reescribe inline en lugar de delegar a otro `fn-constructor` queda registrado.
-- `FN_TELEMETRY=1` esta en el `env` block de settings.local.json — los heredocs Python/Bash de sub-agentes ya tienen wrappers activos automaticamente.
-
-Implicacion: NO necesitas pasar flags `--telemetry` a sub-agentes. Solo asegurate de que el prompt sigue patrones canonicos. La regla `.claude/rules/registry_calls.md` se aplica igual.
-
-Si un sub-agente abre un proceso hijo que escapa al hook (ej. `nohup ... &`, daemons), ese subproceso queda fuera de la telemetria — documentalo en el prompt si es un caso valido.

.claude/commands/validate-app.md

@@ -1,135 +0,0 @@
-# /validate-app — Validar end-to-end una app del registry
-
-Orquesta la cadena `fn-executor → fn-recopilador → fn-analizador → fn-mejorador` (fases 2-5 del bucle reactivo) sobre una app concreta. Devuelve veredicto pass/fail + IDs de proposals creadas si hay fallos.
-
-## Argumento
-
-`$ARGUMENTS` — `<app_id>` o `<dir_path>`. Ejemplos:
-- `kanban_go_tools`
-- `apps/kanban`
-- `graph_explorer_cpp_viz`
-- `projects/osint_graph/apps/graph_explorer`
-
-Si vacio: detectar app desde `pwd` (si estas dentro de `apps/<X>/` o `projects/*/apps/<X>/`); si no, listar apps con `e2e_checks` declarado y pedir.
-
-## Pasos
-
-### 1. Resolver app objetivo
-
-```bash
-ROOT=$HOME/fn_registry
-ARG="$ARGUMENTS"
-
-if [ -z "$ARG" ]; then
-  CWD="$(pwd)"
-  case "$CWD" in
-    "$ROOT"/apps/*|"$ROOT"/projects/*/apps/*)
-      ARG="$(realpath --relative-to="$ROOT" "$CWD")"
-      ;;
-    *)
-      sqlite3 "$ROOT/registry.db" "SELECT id, dir_path FROM apps ORDER BY id;"
-      echo "Especifica app_id o dir_path"
-      exit 1
-      ;;
-  esac
-fi
-
-# Resolver a (id, dir_path)
-if echo "$ARG" | grep -q "^apps/\|^projects/"; then
-  APP_DIR="$ARG"
-  APP_ID=$(sqlite3 "$ROOT/registry.db" "SELECT id FROM apps WHERE dir_path = '$ARG';")
-else
-  APP_ID="$ARG"
-  APP_DIR=$(sqlite3 "$ROOT/registry.db" "SELECT dir_path FROM apps WHERE id = '$ARG';")
-fi
-
-[ -z "$APP_ID" ] || [ -z "$APP_DIR" ] && { echo "App no encontrada: $ARG"; exit 1; }
-```
-
-### 2. Verificar contrato `e2e_checks`
-
-```bash
-HAS_CHECKS=$(awk '/^e2e_checks:/,/^[a-z_]+:|^---$/' "$ROOT/$APP_DIR/app.md" | grep -c "^  - id:")
-
-if [ "$HAS_CHECKS" -eq 0 ]; then
-  echo "App $APP_ID no tiene e2e_checks declarados."
-  echo "Invocar fn-recopilador design-e2e para generar contrato:"
-  echo ""
-  echo "  Agent(subagent_type=fn-recopilador, prompt=\"design-e2e $APP_DIR\")"
-  exit 0
-fi
-```
-
-### 3. Fase 3 — RECOPILAR (auditar operations.db)
-
-Invocar `fn-recopilador` para confirmar que los datos operativos estan integros antes de validar. Si recopilador reporta FAIL critical, NO continuar.
-
-```
-Agent(subagent_type=fn-recopilador,
-      prompt="Auditar app $APP_DIR. Reportar OK/WARN/FAIL en formato corto.
-              Si hay FAIL critical, advertirlo claramente. Solo lectura.")
-```
-
-Si reporta FAIL critical → abortar con mensaje y no llegar a fn-analizador.
-
-### 4. Fase 4 — ANALIZAR (correr e2e_checks)
-
-```
-Agent(subagent_type=fn-analizador,
-      prompt="Validar end-to-end la app $APP_ID (dir_path: $APP_DIR).
-              Leer e2e_checks del app.md, ejecutar via e2e_run_checks_go_infra,
-              evaluar assertions, calcular drift, persistir en e2e_runs.
-              triggered_by: manual.
-              git_sha: $(git rev-parse --short HEAD 2>/dev/null || echo '')
-
-              Devolver veredicto caveman + run_id.")
-```
-
-Capturar `RUN_ID` del output. Capturar `STATUS` (`pass`|`partial`|`fail`).
-
-### 5. Fase 5 — MEJORAR (proposals si hay fallos)
-
-Solo si `STATUS != pass`:
-
-```
-Agent(subagent_type=fn-mejorador,
-      prompt="App $APP_ID tuvo fallos en run_id $RUN_ID.
-              Leer e2e_runs y summary_json de $APP_DIR/operations.db.
-              Por cada fail critical: crear proposal kind=new_function|improve_function
-              en registry.db con created_by=reactive_loop, evidence con run_id+check_id.
-              Sugerir fix concreto en description.
-              Devolver lista de proposal_ids creados.")
-```
-
-Capturar `PROPOSAL_IDS`.
-
-### 6. Reporte final al usuario
-
-Tabla resumen:
-
-```
-=== /validate-app: $APP_ID ===
-
-Fase 3 RECOPILAR:  ✓ datos operativos integros
-Fase 4 ANALIZAR:   <STATUS> (run_id: <RUN_ID>)
-                   <P>/<T> checks pass, <W> warn, <F> fail
-Fase 5 MEJORAR:    <N> proposals creadas: <PROPOSAL_IDS>
-
-Detalle por check:
-  build_frontend  ✓ 42s
-  build_backend   ✓ 18s
-  smoke_api       ✓ 1.2s
-  tests_go        ✗ 12s — 3/45 fails
-
-Siguientes pasos:
-  - Revisar proposals: fn proposal list -s pending
-  - Ver run completo: sqlite3 $APP_DIR/operations.db "SELECT * FROM e2e_runs WHERE id='<RUN_ID>'"
-```
-
-## Notas
-
-- **fn-mejorador no existe todavia** (paso 6 del issue 0068). Mientras tanto, si STATUS != pass, solo imprime el detalle del fallo y sugerir crear proposal manual.
-- Si un agente subagente devuelve respuesta ambigua (no extrae RUN_ID claramente), pedir clarificacion al usuario antes de continuar.
-- Para apps sin `operations.db` (ej. kanban usa `kanban.db`), `e2e_runs` se persiste en `/tmp/<app>_e2e_runs.db` con la misma migracion 005.
-- Caveman OK en stdout salvo en mensajes de error donde claridad supera brevedad.
-- Tras correr la cadena, NO commitear nada automaticamente. La decision de mergear es del humano.

.claude/commands/version.md

@@ -1,170 +0,0 @@
----
-name: version
-description: Bumpear semver de un modulo, framework, paquete o app del registry. Edita <target>.md::version + ## Capability growth log. NO commitea.
----
-
-# /version
-
-Bumpea la version de un **modulo, framework, paquete o app** del registry siguiendo SemVer estricto y mantiene el `## Capability growth log` sincronizado con `<target>.md::version`.
-
-Disenado para usarse desde `/fix-issue` cuando el cambio afecte:
-- `modules/<X>/` (cualquier modulo C++) — edita `module.md`
-- `cpp/framework/` — edita `modules/framework/module.md`
-- `apps/<X>/` o `projects/<P>/apps/<X>/` — edita `app.md`
-- Otros paquetes versionados con `<target>.md` y campo `version:`
-
-## Inputs
-
-```
-/version <path> <major|minor|patch> "<reason>"
-```
-
-- `<path>`: directorio del target (ej. `modules/data_table`, `cpp/framework`, `apps/chart_demo`, `projects/fn_monitoring/apps/registry_dashboard`).
-- `<major|minor|patch>`: tipo de bump SemVer.
-- `<reason>`: 1-frase humana — lo que cambia. Se inserta en el log.
-
-## Resolucion del archivo target
-
-| Path empieza por | Archivo a editar |
-|---|---|
-| `modules/` | `<path>/module.md` |
-| `cpp/framework` | `modules/framework/module.md` |
-| `apps/` | `<path>/app.md` |
-| `projects/*/apps/` | `<path>/app.md` |
-| `projects/*/analysis/` | `<path>/analysis.md` |
-
-Si no encuentra archivo target -> ERROR.
-
-## Reglas SemVer
-
-### Modulos / framework
-
-| Bump | Cuando |
-|---|---|
-| `major` | Cambios breaking en API publica: firma de entry function, layout de State struct expuesto, eliminacion de members, cambio incompatible de comportamiento. |
-| `minor` | Adiciones backwards-compatible: nuevo evento opt-in, nuevo renderer, nuevo helper, nuevo miembro. |
-| `patch` | Bugfix sin cambio de API. |
-
-Refactor interno SIN cambio de API publica -> `minor` (no major).
-
-### Apps
-
-| Bump | Cuando |
-|---|---|
-| `major` | Breaking observable por usuarios: CLI args incompatibles, schema BBDD propia rompe lectores viejos, formato wire (HTTP/gRPC) incompatible, eliminacion de panel/feature que la gente usaba. |
-| `minor` | Feature aditiva: nuevo panel, nuevo endpoint, nueva opcion CLI, nueva tab, mejora visible no rompedora. |
-| `patch` | Bugfix sin cambio observable. Refactor interno. Mejoras de perf. |
-
-Bump de **dependencia** (modulo/funcion del registry) que mejora la app pero la app no cambia su API -> `patch` (la app no es responsable de la mejora; el modulo si).
-
-## Flujo
-
-### 1. Validar input
-
-- `<target_file>` existe -> si no, ERROR.
-- Bump type en {major, minor, patch} -> si no, ERROR.
-- Reason no vacia -> si no, ERROR.
-
-### 2. Leer version actual
-
-Parsear frontmatter. Buscar `version: X.Y.Z`. Si no existe:
-- Para `module.md` -> ERROR "module.md sin campo version".
-- Para `app.md` -> asumir `0.1.0` (baseline) e insertar el campo despues de `domain:`.
-
-### 3. Calcular proxima version
-
-```
-1.4.0 + major = 2.0.0
-1.4.0 + minor = 1.5.0
-1.4.0 + patch = 1.4.1
-```
-
-Major bump -> minor y patch a 0. Minor bump -> patch a 0.
-
-### 4. Editar `<target_file>`
-
-Cambiar linea `version: <old>` por `version: <new>`.
-
-### 5. Anadir entrada a `## Capability growth log`
-
-Insertar al inicio de la lista (lineas posteriores al header `## Capability growth log`):
-
-```markdown
-- v<new> (<fecha YYYY-MM-DD>) — <reason>
-```
-
-Si la seccion no existe -> crearla al final del archivo antes de `## Notes` (o al final si no hay Notes).
-
-### 6. Verificar drift de members (solo modulos, opcional)
-
-Si la herramienta `fn doctor modules` existe (post 0107a) y el target es modulo:
-- Compara `members:` actual vs ultima version registrada en `registry.db::modules_history`.
-- Si hay diff en members y bump es `patch` -> WARNING.
-- Si hay diff en API publica y bump no es `major` -> ERROR (require `--force`).
-
-No aplica a apps (no tienen `members:`).
-
-### 7. Stage en git
-
-`git add <target_file>`. NO commit. El commit final lo hace el flujo padre.
-
-### 8. Reportar
-
-```
-/version apps/chart_demo minor "anade tab radar chart"
-
-apps/chart_demo/app.md
-  version: 1.2.0 -> 1.3.0
-  ## Capability growth log: + v1.3.0 (2026-05-18) — anade tab radar chart
-
-Staged. NO committed.
-Next: terminar el fix-issue y hacer commit con el resto de cambios.
-```
-
-## Reglas criticas
-
-- **NUNCA commit**. `/version` solo edita + stage. El commit lo hace el flujo padre (`/fix-issue`, `/git-push`).
-- **NUNCA saltar version**. No 1.4.0 -> 1.4.2 directo.
-- **NUNCA bajar version**. Si rollback, crea nueva version superior con comportamiento viejo restaurado.
-- **fecha = HOY** (`date +%Y-%m-%d`).
-- **reason** comprensible sin contexto del PR actual.
-
-## Referenciado desde
-
-- `/fix-issue` — al detectar cambios en `modules/`, `cpp/framework/`, `apps/<X>/` o `projects/*/apps/<X>/`, sugiere ejecutar `/version` antes del commit final.
-- `.claude/rules/cpp_apps.md` — politica de bump.
-- `dev/issues/0107-modules-standardization.md` — origen del flujo (modulos).
-
-## Ejemplos
-
-```
-# Bug fix en data_table (modulo)
-/version modules/data_table patch "fix off-by-one en seleccion multi-row con shift+click"
-# -> 1.4.0 -> 1.4.1
-
-# Feature opt-in en framework
-/version cpp/framework minor "anade cfg.auto_dockspace para overlay de paneles flotantes"
-# -> 1.1.0 -> 1.2.0
-
-# Feature en app C++
-/version apps/chart_demo minor "anade tab radar chart con datos sinteticos"
-# -> 1.2.0 -> 1.3.0
-
-# Bug fix en app de proyecto
-/version projects/fn_monitoring/apps/registry_dashboard patch "fix tooltip que mostraba duration_ms en segundos"
-# -> 0.4.1 -> 0.4.2
-
-# Breaking en app: cambia schema de su BBDD propia
-/version apps/kanban major "cards.assignee_id pasa a ser TEXT[] (era TEXT); requiere migracion 008"
-# -> 1.0.0 -> 2.0.0
-```
-
-## Anti-patrones
-
-| Anti-patron | Por que es malo |
-|---|---|
-| Editar `version:` a mano sin `## Capability growth log` | Drift entre version y log; nadie sabe que cambio. |
-| Bumpear major en app por refactor interno | Confunde al usuario; refactor es patch. |
-| Patch para feature visible | Usuario no se entera que esta disponible. |
-| Reason "cambios varios" / "mejoras" | Inutil para auditar. Una frase concreta. |
-| Bump de app sin tocar codigo de la app (solo dep) | Bump va al modulo, no a la app. |

.claude/commands/work.md

@@ -1,67 +0,0 @@
----
-description: "Vista cross-cutting de issues + flows. Subcomandos: today, weekly, search, dashboard. Mezcla los dos universos en una lista priorizable."
----
-
-# /work — Vista cross-cutting issues + flows
-
-Issues = trabajo de implementacion. Flows = casos de uso multi-app. `/work` los muestra juntos para responder "que hago ahora" sin saltar entre dos sitios.
-
-## Sintaxis
-
-```
-/work today                       # top items prio alta + deps satisfechas (issues + flows)
-/work weekly                      # review semanal: closed vs planeados
-/work search "texto"              # FTS sobre issues + flows + completed
-/work dashboard                   # JSON consumible por tab Work (issue 0102)
-```
-
-## Implementacion
-
-**Fase 1 (manual via Claude):**
-
-El agente lee `dev/issues/*.md` + `dev/flows/*.md`, parsea frontmatter YAML, ordena por:
-
-1. `priority: alta` primero.
-2. `status: pendiente` con `depends` todos `completado` (no bloqueados).
-3. Items con DoD/Acceptance >=80% (a punto de cerrar).
-4. Fecha `updated` mas reciente.
-
-Imprime tabla unificada:
-
-```
-KIND | ID   | TITLE                                    | PRIO  | STATUS    | NEXT STEP
-issue| 0099 | datahub app launcher                     | alta  | pendiente | revisar deps
-flow | 0001 | hn-top-stories                           | high  | pending   | cerrar DoD user-facing
-issue| 0100 | migrate issue frontmatter                | alta  | pendiente | ejecutar pipeline
-...
-```
-
-**Fase 2 (cuando 0101 dev_console exista):**
-
-`./apps/dev_console/dev_console work <subcomando> $ARGS`.
-
-## Subcomandos
-
-### `today`
-
-Filtro: `priority in (alta, media)` + `status: pendiente` + dependencias resueltas. Max 10 items. Si hay >10, prioriza `alta` y avisa "N items pendientes en cola".
-
-### `weekly`
-
-Git log `--since='1 week ago'` sobre `dev/issues/completed/` y `dev/flows/completed/` -> tabla de items cerrados. Comparado con `created: <esta semana>` -> ratio in/out.
-
-### `search "texto"`
-
-`grep -ri` sobre `dev/issues/` + `dev/flows/` (incluido completed/), filtra por title/body. Output: `path:line: match`.
-
-### `dashboard`
-
-Output JSON estructurado para consumo por tab Work del `registry_dashboard` (issue 0102). Estructura:
-
-```json
-{
-  "issues": {"pendiente": [...], "in-progress": [...], "bloqueado": [...], "completado_24h": [...]},
-  "flows": [{"id": "0001", "dod_percent": 50, "user_facing_percent": 0, "...": ...}],
-  "telemetry": {"calls_24h": N, "violations_24h": N, "pending_proposals": N}
-}
-```

.claude/rules/INDEX.md

@@ -17,26 +17,3 @@ Reglas operativas del proyecto. Cada archivo es una regla independiente.
 | 11 | [sources.md](sources.md) | Extraccion de funciones desde repos externos |
 | 12 | [notebook_collaboration.md](notebook_collaboration.md) | Colaboración en notebooks Jupyter via funciones del registry |
 | 13 | [frontend_theming.md](frontend_theming.md) | Componentes propios y sistema de temas en frontends |
-| 14 | [deploy.md](deploy.md) | Deploy de apps a VPS remotos via SSH + systemd + rsync |
-| 15 | [projects.md](projects.md) | Projects: agrupar apps, analysis y vaults bajo un tema |
-| 16 | [kiss.md](kiss.md) | KISS en proyectos y apps: cuestionar herramientas externas, sin abstracciones especulativas |
-| 17 | [apps_tbd.md](apps_tbd.md) | Trunk-based development obligatorio en apps generadas con `fn` (registry exento) |
-| 17b | [apps_subrepo.md](apps_subrepo.md) | Apps son sub-repos Gitea (apps/* gitignored). El padre NUNCA trackea contenido de artefactos hijos (solo `.gitkeep`); nada de `git add -f` sobre apps/analysis/projects o deja el padre dirty. `git init` dentro de cada app nueva ANTES de limpiar worktree, sino se pierde el codigo |
-| 18 | [uses_functions.md](uses_functions.md) | Convencion de uses_functions para C++: el .md del consumidor declara las dependencias |
-| 19 | [cpp_apps.md](cpp_apps.md) | Estandarizacion de apps C++: estructura, CMake, app.md, sub-repo, runtime — apunta a cpp/PATTERNS.md y cpp/DESIGN_SYSTEM.md como autoritativas |
-| 20 | [artefactos.md](artefactos.md) | Termino paraguas para apps, analysis, vaults, projects y playgrounds (todo lo que no es codigo reutilizable) |
-| 21 | [playgrounds.md](playgrounds.md) | Prototipos rapidos dentro de un artefacto padre — heredan entorno, no se indexan, no tienen repo propio |
-| 22 | [registry_first.md](registry_first.md) | Antes de escribir codigo en un artefacto: buscar en el registry, reutilizar si existe, delegar a `fn-constructor` si falta |
-| 23 | [fn_doctor.md](fn_doctor.md) | `fn doctor`: diagnostico read-only de artefactos, services, sync drift, uses_functions, unused — wrappers de funciones del registry |
-| 24 | [feature_flags.md](feature_flags.md) | TBD: feature flags para mergear codigo incompleto sin romper master. Patrones por stack (Go/TS/Bash/Py), branch-by-abstraction, anti-patrones |
-| 25 | [db_migrations.md](db_migrations.md) | Migraciones SQLite obligatorias para cualquier cambio de schema. Aditivas, idempotentes, archivos numerados. Nunca borrar .db ni modificar migraciones existentes |
-| 26 | [e2e_validation.md](e2e_validation.md) | Contrato `e2e_checks` en `app.md` consumido por fn-analizador (fase 4 del bucle reactivo). Issue 0068 |
-| 27 | [registry_calls.md](registry_calls.md) | Patrones canonicos para invocar funciones del registry (MCP inspect / MCP run / heredoc compose), antipatrones, excepciones, telemetria. Issue 0085 |
-| 28 | [delegation.md](delegation.md) | Si vas a escribir logica reutilizable inline -> spawn fn-constructor inmediato + tag de grupo + usar en mismo turno. Issue 0086 |
-| 29 | [capability_groups.md](capability_groups.md) | Tags planos + paginas madre `docs/capabilities/<grupo>.md` para desbloquear clusters de funciones en un read. Issue 0086 |
-| 30 | [function_growth_and_self_docs.md](function_growth_and_self_docs.md) | Contrato self-doc de cada `.md` (Ejemplo + Cuando usarla + Gotchas + Growth log) + crecimiento del registry por **promocion de composiciones** a pipelines, NO por inflado de funciones. Issue 0087 |
-| 31 | [autonomous_loop.md](autonomous_loop.md) | Reglas para `fn-orquestador` + `/autonomous-task`: sandbox obligatorio, paths protegidos, filtro proposals auto-aplicables, watchdog, idempotencia. Issue 0069 |
-| 32 | [../../dev/TAXONOMY.md](../../dev/TAXONOMY.md) | Allowlist canonica para dominios/tipos/scopes/estados/prioridades + flow patterns. Aplica a `dev/issues/` y `dev/flows/`. Issues 0100 + 0103 |
-| 33 | [project_commands.md](project_commands.md) | Slash commands por project (`.claude/commands/<project>/`) expuestos via symlink. Desde fn_registry: `/<project>:foo`. Desde el project: `/foo`. Sin colision. |
-| 34 | [dod_quality.md](dod_quality.md) | DoD Quality Triada: Mecanica + Cobertura (golden + edge + error path con evidencia ejecutable) + Vida util validada (>=7 dias uso real). Cierra anti-criterios contra checkbox vago. Aplica a `dev/flows/` y issues user-facing. |
-| 35 | [llm_invocation.md](llm_invocation.md) | Invocacion de LLM: SIEMPRE `ask_llm` (grupo `claude-direct`, API directa, arranque 0), NUNCA `claude -p` (lento, cold start). One-shot/streaming/tool-loop + legacy `claude_stream_go_core` deprecado. |

.claude/rules/apps_subrepo.md

@@ -1,104 +0,0 @@
-## Apps son sub-repos Gitea independientes — gotcha al usar worktrees
-
-**Regla operativa critica** descubierta el 2026-05-18 durante implementacion del flow 0008.
-
-### El gotcha
-
-`apps/*/` esta en `.gitignore` del repo `fn_registry`. Cada app es **su propio repo Gitea** en `dataforge/<app_name>` con su `.git/` dentro de `apps/<app_name>/`. Esto significa:
-
-- Cuando un agente trabaja en un git **worktree** del repo padre y crea `apps/<nueva_app>/`, los archivos viven SOLO en el working directory del worktree.
-- Como `apps/*/` esta gitignored en el repo padre, los archivos **no se pueden commitear** al worktree del repo padre.
-- Cuando se hace `git worktree remove --force worktrees/<slug>/`, el working directory entero se borra — **el codigo de la app desaparece**.
-
-**Consecuencia**: una app creada dentro de un worktree del repo padre se pierde al limpiar el worktree salvo que se haya promovido a su propio sub-repo Gitea ANTES.
-
-### El patron correcto al crear apps en worktrees
-
-```bash
-# 1. Agente trabaja en worktree del repo padre
-cd $HOME/fn_registry/worktrees/<slug>
-
-# 2. Scaffold la app via pipeline canonico
-./fn run init_cpp_app <name>           # apps C++
-# o ./fn run init_jupyter_analysis ... # analysis
-# o crear apps/<name>/ a mano (Go service, etc.)
-
-# 3. ANTES de salir del worktree: inicializa la app como sub-repo
-cd apps/<name>
-git init -b master
-git add -A
-git -c user.email="agent@fn_registry" -c user.name="agent" \
-    commit -m "feat: initial scaffold of <name>"
-
-# 4. Trabajo continua en sub-repo (commits dentro de apps/<name>/.git)
-# 5. Cerrar issue en repo padre (mv .md a completed/), commit del padre con cambios en cpp/CMakeLists.txt, etc.
-```
-
-Cuando el humano corre `/full-git-push` despues del merge, el script `ensure_repo_synced_bash_infra` detecta que `apps/<name>/.git` existe + no tiene remote + crea repo Gitea en `dataforge/<name>` + pushea master.
-
-### Que ESTA SI versionado en el repo padre
-
-- `cpp/CMakeLists.txt` (el `if(EXISTS ...) add_subdirectory(apps/<name>) endif()`).
-- `dev/issues/completed/<NNNN>-<slug>.md` (cierre del issue).
-- `docs/capabilities/*.md` si la app aporta a un capability group.
-- `dev/feature_flags.json` si introduce flags.
-
-Todo lo demas (codigo de la app + app.md + appicon + service unit + tests propios de la app) vive en `apps/<name>/.git` independiente.
-
-### REGLA DURA: el repo padre NUNCA trackea contenido de artefactos hijos
-
-El repo padre `fn_registry` solo versiona codigo del registry (`functions/`, `types/`, `registry/`, `cmd/`, `docs/`, `.claude/`, `dev/`, `migrations/`, y el framework/functions/vendor de `cpp/`). NUNCA debe trackear el contenido de un artefacto hijo:
-
-- apps: `apps/*`, `cpp/apps/*`, `projects/*/apps/*`
-- analyses: `analysis/*`, `projects/*/analysis/*`
-- projects: `projects/*`
-
-Cada artefacto es un sub-repo Gitea independiente con su propio `.git`; su contenido completo (codigo, `app.md`, `analysis.md`, `appicon.*`, binarios, frontend, `local_files/`, tests propios) vive SOLO en ese sub-repo. `fn index` lee los `.md` de registro directamente del disco — no necesitan estar en el git del padre. Lo unico que el padre versiona dentro de esos arboles son los marcadores `.gitkeep` (mantienen `apps/` y `analysis/` presentes cuando estan vacios) y, en `projects/`, los `project.md` template si los hubiera.
-
-**Como se rompe (sintoma = repo padre permanentemente dirty):** un `git add -f apps/<x>/...` (forzado, saltandose el `.gitignore`) o un commit que mete contenido del hijo al padre. Como el archivo ya queda en el indice, el `.gitignore` NO lo vuelve a ignorar y aparece para siempre en `git status` del padre como modificado cada vez que el sub-repo cambia (doble-tracking). Caso real (2026-06-03): `apps/dag_engine/` (31 archivos: Go + frontend + app.md) y `apps/shaders_lab/` (app.md + un binario `.exe` de 23 MB) quedaron forzados al indice del padre y lo dejaban dirty en cada cambio del sub-repo.
-
-**Auditoria (cero salida = sano):**
-
-```bash
-git ls-files 'apps/*' 'analysis/*' 'projects/*/apps/*' 'projects/*/analysis/*' 'cpp/apps/*' \
-  | grep -vE '(^|/)\.gitkeep$'
-```
-
-**Fix si aparece contenido trackeado:**
-
-```bash
-# --cached SIEMPRE: saca del indice del padre sin borrar el working tree.
-# El codigo sigue a salvo en el .git del sub-repo.
-git rm -r --cached apps/<x>
-git commit -m "chore: untrack contenido del artefacto <x> (es sub-repo Gitea)"
-```
-
-NUNCA `git rm` sin `--cached` (borraria el working tree del sub-repo). **Prevencion:** jamas usar `git add -f` sobre paths de artefactos; las reglas `apps/*/`, `analysis/*/`, `projects/*/` del `.gitignore` ya cubren el caso por defecto y solo un force las salta.
-
-### Sintomas de la perdida
-
-Si limpias el worktree y luego corres `ls apps/<name>/`, devuelve "No such file or directory" pese a que el issue aparece cerrado en `dev/issues/completed/`. **Patron** = scaffold sin sub-repo init = trabajo perdido.
-
-### Recovery si pasa
-
-1. Re-crear worktree desde master.
-2. Re-spawn agente con instruccion explicita: **`git init` dentro de la app antes de terminar**.
-3. NO eliminar el worktree hasta confirmar que `apps/<name>/.git` esta inicializado con al menos un commit.
-
-### Aplica tambien a analysis
-
-`analysis/*/` y `projects/*/analysis/*/` siguen mismo patron (cada analysis es repo Gitea). El pipeline `init_jupyter_analysis_bash_pipelines` ya hace `git init` automatico — por eso no hubo perdidas alli. Las apps C++/Go scaffolded a mano NO inicializan el sub-repo automaticamente — es responsabilidad del agente.
-
-### Lo que aprende `parallel-fix-issues`
-
-El template del prompt de cada agente DEBE incluir la instruccion:
-
-> "Si tu issue crea una app nueva en `apps/<name>/`, inicializa el sub-repo (`cd apps/<name> && git init -b master && git add -A && git commit ...`) antes de terminar. Sin esto, `apps/*` esta gitignored y el codigo se perdera cuando el orquestador limpie el worktree."
-
-Aplicar este parrafo al template del skill — ver `.claude/skills/parallel-fix-issues/SKILL.md` (o equivalente).
-
-### Relacion con otras reglas
-
-- [[apps_tbd]] — TBD en apps, esta regla complementa con el patron de sub-repo init.
-- [[artefactos]] — apps son artefactos, esta regla especifica gotcha de su sub-repo.
-- [[apps_vs_functions]] — apps en `apps/`, esta regla refuerza por que apps/* gitignored.

.claude/rules/apps_tbd.md

@@ -1,58 +0,0 @@
-## Trunk-based development (TBD) en apps generadas con `fn`
-
-**El registry NO usa TBD** (push directo a master OK). Pero **toda app generada con `fn`** que viva en `apps/`, `projects/<name>/apps/` o que se despliegue a un VPS via `deploy_server` **DEBE seguir TBD** mientras se desarrolla.
-
-**Tronco unico: `master`** en todos los repos `dataforge/<name>` del ecosistema (apps + analyses). Ver ADR 0002. El default de `git init` debe estar en `master` (`git config --global init.defaultBranch master`) — los pipelines de scaffolding y `ensure_repo_synced_bash_infra` ya pasan `master` explicitamente.
-
-```
-master ← siempre deployable
-  ↑
-  └── issue/<NNNN>-<slug>   ← rama efimera (horas)
-  └── quick/<slug>          ← cambios rapidos sin issue
-        commits atomicos (feat:, fix:, test:, docs:, refactor:, chore:)
-      merge --no-ff → master → push → delete branch
-```
-
-### Reglas
-
-1. **Nunca trabajar directo en master para una app**. Crear `issue/<NNNN>-<slug>` o `quick/<slug>` primero.
-2. **Commits atomicos** por bloque logico (no WIP, no mezclar tipos).
-3. **Tests obligatorios** antes de mergear (los que aplique al stack: ctest/go test/pytest/...).
-4. **`merge --no-ff`** preserva la historia paralela. `git log --first-parent master` da la vista limpia.
-5. **Feature flags** (no WIP) cuando una feature no cabe en una sola rama. Archivo: `dev/feature_flags.json`. Detalle: `feature_flags.md`.
-
-### Que hacer cuando aparece WIP en el working tree
-
-Doctrina TBD: **master siempre desplegable**. Si tras implementar un issue queda codigo a medias en otros archivos (modificado pero no terminado), HAY DOS opciones legales:
-
-| Caso | Accion |
-|---|---|
-| WIP no relacionado al issue, pequeño, ya estable (ej. null-guards de un bug menor) | Incluirlo en el commit del issue **solo si compila + tests pasan**. Mencionarlo en el cuerpo del commit. |
-| WIP relacionado al issue pero incompleto | Envolver en feature flag OFF (`enabled: false` en `dev/feature_flags.json`). Mergear codigo terminado y testeado. Activar flag en commit posterior. |
-| WIP de otra feature distinta, no terminada | NO mergear con el issue. `git stash` o crear `issue/<otro>-...` para llevarlo aparte. NO romper master. |
-| Pre-existing failing tests (no causados por la rama) | Documentar en cuerpo del commit/PR. Crear issue separado para el fix. NO bloquea merge si tu cambio no los introduce. |
-
-**Regla de oro:** ningun commit pusheado a master debe romper el deployment. Si el codigo no esta terminado pero compila + pasa tests, viaja detras de un flag OFF. Si rompe, no sale.
-
-### Por que el registry esta exento
-
-El registry es un repo de funciones reutilizables, no un servicio en produccion. Los cambios son atomicos por su propia naturaleza (una funcion = uno o dos archivos). Imponer TBD a cada `fn add` añadiria fricion sin ganancia: la BD se regenera con `fn index`, no hay deployment, no hay usuarios consumiendo master en directo.
-
-### Cuando aplica TBD
-
-| Cambio | TBD obligatorio |
-|---|---|
-| Funcion nueva en `cpp/functions/`, `python/functions/`, etc. | NO — push directo a master |
-| Tipo nuevo en `types/` | NO |
-| Doc/regla en `.claude/`, `docs/` | NO |
-| Issue del registry mismo (`dev/issues/`) | NO — issue cerrado y push directo |
-| App nueva o modificacion de app en `apps/` o `projects/*/apps/` | **SI** |
-| Service desplegable (`tag: service`) | **SI** |
-| Analysis en `analysis/` o `projects/*/analysis/` | NO — son exploraciones efimeras |
-
-### Comandos
-
-- `/git-branch` — crea rama desde master actualizado (para apps).
-- `/git-push` — tests → merge `--no-ff` → push → eliminar rama (para apps).
-
-Para el registry, push directo a master con commits atomicos.

.claude/rules/apps_vs_functions.md

@@ -7,12 +7,3 @@ Criterios para decidir:
 - **apps/**: orquesta funciones del registry para un caso concreto, tiene config/credenciales, layout fijo
 
 Las apps Python importan funciones del registry con: `sys.path.insert(0, os.path.join(os.path.dirname(__file__), "..", "..", "python", "functions"))` y luego `from <paquete> import ...` (sin prefijo `functions.`).
-
-## temp/ — workspace efimero
-
-`temp/` es un espacio de trabajo desechable para pruebas rapidas: probar una API, un script exploratorio, un analisis puntual, prototipos. Todo gitignored.
-
-- **NO es codigo del registry** — nada en `temp/` se indexa ni se versiona
-- **Estructura libre** — subcarpetas por tema: `temp/api_test/`, `temp/quick_analysis/`, etc.
-- **Extraccion**: si algo en `temp/` resulta util, se extrae al registry con el flujo normal (como si fuera `sources/`)
-- **Limpieza**: se puede borrar el contenido en cualquier momento sin consecuencias

.claude/rules/artefactos.md

@@ -1,41 +0,0 @@
-## Artefactos: termino colectivo
-
-**"Artefacto"** es el termino paraguas para todo lo que vive en el registry pero NO es codigo reutilizable de `functions/` o `types/`. Sirve para no repetir "apps, analysis, vaults, projects, playgrounds" cada vez.
-
-Tipos de artefacto:
-
-| Tipo | Donde vive | Indexado en registry.db | Repo Gitea propio |
-|---|---|---|---|
-| **app** | `apps/`, `cpp/apps/`, `projects/<p>/apps/<a>/` | tabla `apps` | si (`dataforge/<a>`) |
-| **analysis** | `analysis/<t>/`, `projects/<p>/analysis/<t>/` | tabla `analysis` | si (`dataforge/<t>`) |
-| **vault** | `projects/<p>/vaults/<v>` (symlink) | tabla `vaults` | no (datos fuera del repo) |
-| **project** | `projects/<p>/` | tabla `projects` | no (vive dentro de fn_registry) |
-| **playground** | `<artefacto_padre>/playground/` | NO se indexa | no (vive dentro del padre) |
-
-Caracteristicas comunes de los artefactos:
-- NO son codigo reutilizable. La reutilizacion vive en `functions/`.
-- Tienen ciclo de vida propio (crear, modificar, archivar, borrar).
-- `pc_locations` los unifica via `entity_type` (app, analysis, project, vault).
-- Pueden importar funciones del registry; el registry NUNCA importa de un artefacto.
-
-### Cuando usar el termino
-
-Usa "artefacto" cuando hablas de varios tipos a la vez o cuando la afirmacion aplica a todos:
-
-- "Cada artefacto declara sus funciones del registry en su `.md`" (vale para apps y analyses).
-- "Los artefactos no se importan desde `functions/`."
-- "Esta regla aplica a cualquier artefacto desplegable" (apps + services).
-
-Cuando hables de UN tipo concreto, usa el nombre concreto: "esta app...", "este analysis...". No abuses del termino paraguas — es para evitar listas, no para difuminar.
-
-### Que NO es un artefacto
-
-- `functions/`, `python/functions/`, `bash/functions/`, `frontend/functions/` — codigo reutilizable.
-- `types/`, `python/types/`, `frontend/types/` — tipos del registry.
-- `sources/` — repos externos clonados para extraer funciones (gitignored).
-- `temp/` — workspace efimero, ni siquiera versionado.
-- `subrepos/` — espejos de repos externos para referencia.
-
-### Relacion con `pc_locations`
-
-Los artefactos con presencia en disco (app, analysis, project, vault) ya estan unificados en `pc_locations` via la columna `entity_type`. Los **playgrounds** NO entran en `pc_locations` porque son hijos de otro artefacto y se mueven con el (no tienen identidad propia entre PCs).

.claude/rules/autonomous_loop.md

@@ -1,102 +0,0 @@
-## Bucle autonomo (`fn-orquestador` + `/autonomous-task`) — issue 0069
-
-`fn-orquestador` recorre el ciclo reactivo (CONSTRUIR → EJECUTAR → RECOPILAR → ANALIZAR → MEJORAR) sin intervencion humana, hasta convergencia (suite verde), estancamiento (no progreso N iteraciones), timeout, o tope de iteraciones. Trabaja SIEMPRE en sandbox `auto/<issue>`, NUNCA merge a master.
-
-### Cuando se invoca
-
-- Skill `/autonomous-task <issue_id>` (humano lanza explicitamente).
-- Cron / dag_engine (`schedule:` en YAML; planificable, no implementado por defecto).
-- NO se invoca como reaccion a hooks ni a fallos de tests "en caliente". Siempre tarea explicita.
-
-### Reglas duras
-
-1. **Sandbox obligatorio**: rama `auto/<issue_id>-<slug>`. Si la rama existe -> reset hard contra master y reanudar. NUNCA commits a master, NUNCA push --force-with-lease a master.
-2. **Paths protegidos**: respetar `dev/autonomous_protected_paths.json` exactamente. Cualquier intento de modificar un path protegido aborta la iteracion y registra `task_runs.status='aborted_protected_path'`.
-3. **Filtro de proposals auto-aplicables**: el orquestador SOLO aplica proposals que cumplen:
-   - `kind in (bug_fix, e2e_check_add, doc_update, capability_tag_add)` -> auto-aplicable.
-   - `kind in (new_function, deprecate_function, refactor, schema_change)` -> NO auto-aplicable (queda `pending` para humano).
-   - `priority in (low, medium)` -> auto-aplicable. `high|critical` -> requiere humano salvo override `--allow-high`.
-4. **Watchdog**: si la metrica de progreso (`checks_pass / checks_total`) no sube en `N=3` iteraciones consecutivas -> abort. Registrar `task_runs.status='stalled'`.
-5. **Tiempo**: cada `task_run` con timeout default 30 min. Override con `--timeout-min N` hasta max 4h.
-6. **Idempotencia**: re-ejecutar `/autonomous-task <id>` sobre la misma issue reanuda desde la ultima iteracion exitosa, NO reinicia desde cero (lookup en `task_runs` por `issue_id`).
-7. **Trazabilidad**: cada decision se persiste en `task_runs.events_json[]` con `{ts, agent, action, evidence, diff_summary}`. El humano puede leer el log entero para auditar.
-8. **No self-modification**: orquestador NUNCA modifica `.claude/agents/`, `.claude/commands/`, `.claude/rules/`, `.claude/scripts/`, `.claude/CLAUDE.md`. Reforzado en `autonomous_protected_paths.json`.
-9. **NUNCA paths absolutos fuera del worktree**. Refuerzo del piloto 1 (2026-05-15): el orquestador uso `/home/lucas/fn_registry/bash/functions/...` para fixear hooks bash y contamino el repo principal. Solucion correcta: fix vive solo en el worktree. Post-cada-iteracion: `git -C <main_repo> status --short` debe permanecer igual al baseline; cualquier diff = `status=sandbox_breach` -> ABORT.
-10. **Pre-commit hooks compartidos**. Worktrees comparten `.git/hooks/` con main. Si un hook llama scripts via path absoluto, ejecutara la version de main. Si el hook bloquea progreso por bug en main: aplica el fix EN EL WORKTREE (commit en auto/*); si el bug del hook excede scope: `git commit --no-verify` para ESE commit con `task_runs.events_json[].decision="skip_hook"` + razon. NO editar main.
-
-### Sub-repos vs worktree padre
-
-Cuando el issue toca `app.md` o codigo dentro de `apps/<name>/`, `projects/<p>/apps/<name>/`, `cpp/apps/<name>/`, o `analysis/<a>/` — estos directorios son **sub-repos Gitea independientes** y estan `.gitignore`d en el repo padre `fn_registry` (regla `apps_subrepo.md`). El orquestador:
-
-- **Crea worktree padre** `auto/<issue>` en `/tmp/fn_orq_<issue>_<ts>/` por protocolo, **pero no escribe alli** porque los cambios no se versionan en el padre.
-- **Opera DIRECTAMENTE en el sub-repo** de la app/analysis target. Branch `auto/<issue>-<slug>` se crea dentro de `apps/<name>/.git`, NO en el padre.
-- **PR draft sale al sub-repo** en `dataforge/<name>` (NO a `dataforge/fn_registry`). Humano revisa+mergea en el sub-repo.
-- **Worktree padre queda vacio** y se limpia normal con `git worktree remove` al terminar.
-
-Validado en piloto 0120 (`add_e2e_check` sobre `chart_demo`): PR creado en `dataforge/chart_demo/pulls/1`, sanity check del main repo `fn_registry` confirmo cero contaminacion.
-
-Si el issue toca AMBOS lados (codigo del registry padre + app de sub-repo), el orquestador commitea separado: cambios del padre en `auto/<issue>` (worktree padre), cambios de la app en `auto/<issue>-<slug>` (sub-repo). Dos PRs draft. Humano coordina merge.
-
-### Gitea API vs `gh`
-
-Pre-condicion `gh auth status` es smoke check (target github.com). Mecanismo real de PR es `curl` a Gitea API:
-
-```bash
-GITEA_TOKEN=$(pass gitea/dataforge-git-token | head -n1)
-curl -X POST -H "Authorization: token $GITEA_TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{"title":"...","head":"auto/<issue>-<slug>","base":"master","draft":true,"body":"..."}' \
-  "https://gitea-.../api/v1/repos/dataforge/<repo>/pulls"
-```
-
-Validado en pilotos 0076 y 0120.
-
-### Estructura task_run
-
-Migration `fn_operations/migrations/006_task_runs.sql`. Campos minimos: `id`, `issue_id`, `branch`, `started_at`, `finished_at`, `status` (`running|done|failed|aborted_protected_path|stalled|timeout`), `iterations`, `checks_pass`, `checks_fail`, `proposals_applied_json`, `proposals_skipped_json`, `events_json`, `final_diff_sha`.
-
-### Fases por iteracion
-
-```
-loop:
-  1. fn-constructor (Read+Edit+Write+Bash limitados) - aplica fix segun ultima proposal seleccionada
-  2. fn-executor - corre build + tests + smoke
-  3. fn-recopilador - audita operations.db de la app
-  4. fn-analizador - corre e2e_checks (registra e2e_runs)
-  5. SI todos los checks pasan -> commit + push rama + abre PR. status=done. exit.
-  6. SI no progreso N iteraciones -> abort. status=stalled.
-  7. fn-mejorador - crea proposals desde fallos
-  8. orquestador filtra proposals auto-aplicables -> selecciona la primera -> goto 1.
-```
-
-### Output al humano
-
-```
-=== /autonomous-task 0068 ===
-task_run_id:        run_e2e_a1b2c3
-branch:             auto/0068-e2e-validation
-iterations:         4
-status:             done
-checks_pass:        8/8
-proposals_applied:  3 (run_e2e_run_001, run_e2e_run_002, run_e2e_run_003)
-proposals_skipped:  1 (refactor — needs human review)
-PR:                 https://gitea.../pulls/42
-```
-
-### Anti-patrones
-
-| Anti-patron | Por que es malo |
-|---|---|
-| Mergear `auto/<issue>` a master sin PR + humano | Salta gate, riesgo de regresion |
-| Auto-aplicar proposal `kind=refactor` | Cambios sistemicos requieren revision |
-| Modificar `go.sum`, `package-lock.json`, `uv.lock` | Cambios de deps requieren CVE/license review |
-| Bucle infinito sin watchdog | Coste descontrolado de tokens |
-| Borrar archivos sin backup en `task_runs.events_json` | Pierde auditoria |
-| Override de paths protegidos via env var | Bypass de seguridad |
-
-### Relacion con otras reglas
-
-- [[e2e_validation]] — fn-analizador (fase 4) lee el contrato `e2e_checks` que el orquestador usa como gate.
-- [[apps_tbd]] — el orquestador opera en rama `auto/*`, no exenta de TBD.
-- [[feature_flags]] — si el fix no esta terminado, el orquestador puede meterlo detras de flag OFF antes de PR.
-- [[registry_calls]] — toda invocacion del orquestador y sub-agentes pasa por MCP/`fn run`/heredoc canonico, registrada en call_monitor.

.claude/rules/capability_groups.md

@@ -1,60 +0,0 @@
-## Capability groups: tags + paginas madre en docs/capabilities/
-
-Un **capability group** es un cluster de >=3 funciones del registry que comparten un dominio operativo (ej. `notebook`, `metabase`, `deploy`). Cada grupo tiene un **tag plano** (sin prefijo) y una **pagina madre** en `docs/capabilities/<grupo>.md`. La pagina madre desbloquea el conjunto entero en un solo read.
-
-### Para que existen
-
-Sin grupos, Claude redescubre funciones via FTS5 una a una cada sesion ("¿como interactuo con Jupyter? ¿como subo deploy?"). Con grupos, Claude lee `docs/capabilities/<grupo>.md` y carga las 5-10 funciones del cluster con su ejemplo canonico — menos turnos perdidos en discovery.
-
-### Convencion de tag
-
-- **Slug del grupo** = tag plano. Ej: `notebook`, `metabase`, `android-emu`.
-- **No prefijos** (`cap:`, `group:`). Ya hay namespacing implicito porque convivirian con tags semanticos sueltos.
-- **Una funcion puede llevar varios tags de grupo** si pertenece a dos clusters (raro pero valido).
-- Filtro MCP: `mcp__registry__fn_search query="" tag="notebook"` lista el grupo.
-
-### Cuando crear grupo nuevo
-
-- **Minimo 3 funciones** afines. Con 2 no compensa pagina madre — quedan tags sueltos.
-- **Dominio operativo claro**: el grupo debe ser describible en 1 frase ("operar Jupyter colaborativo", "deploy via SSH+systemd").
-- **Frontera neta** con grupos existentes. Si solapa con otro -> reorganizar, no duplicar.
-
-### Como crear grupo
-
-1. Anadir el tag al frontmatter `.md` de >=3 funciones afines. `fn index` lo registra.
-2. Crear `docs/capabilities/<grupo>.md` con plantilla:
-   - **Lista de funciones**: tabla `ID | firma corta | que hace`.
-   - **Ejemplo canonico**: 1-2 bloques de codigo end-to-end con los IDs reales.
-   - **Fronteras**: que NO cubre el grupo.
-   - **Prerequisitos** y **notas** si aplica.
-3. Anadir fila al `docs/capabilities/INDEX.md`.
-4. Correr `fn doctor capabilities` para auditar drift.
-
-### Auto-generacion
-
-`fn doctor capabilities --update` (TBD) reescribe la tabla de funciones de cada pagina madre preservando bloques curated (`Ejemplo canonico`, `Fronteras`, `Notas`). Las secciones curated nunca se sobrescriben.
-
-### Como Claude usa los grupos
-
-Cuando una tarea cae en un dominio conocido:
-
-1. `Read docs/capabilities/INDEX.md` para localizar grupo.
-2. `Read docs/capabilities/<grupo>.md` para cargar funciones + ejemplo.
-3. Solo si el grupo no cubre lo necesario, `mcp__registry__fn_search` para funciones sueltas.
-4. Si el grupo deberia cubrir pero falta funcion -> `fn-constructor` + tagear con el grupo en el frontmatter.
-
-### Auditoria
-
-```bash
-fn doctor capabilities                # lista grupos + drift
-fn doctor capabilities --json         # para agentes
-```
-
-Comprueba:
-- Tag con N >=3 funciones pero sin pagina madre -> "tag huerfano".
-- Pagina madre sin tag respaldo -> "grupo fantasma".
-- Funcion con tag de grupo pero la pagina madre no la lista (autogen desfasada) -> "drift".
-
-### Relacion con dominios
-
-Los **dominios** del registry (`core`, `infra`, `finance`, `datascience`, `cybersecurity`, `shell`, `tui`, `pipelines`, `browser`) son taxonomia ortogonal — un grupo puede atravesar varios dominios (ej. `deploy` toca `infra` y `shell`). NO renombrar dominio a grupo ni viceversa.

.claude/rules/cpp_apps.md

@@ -1,484 +0,0 @@
-## Estandarizacion de apps C++ del registry
-
-**Fuentes autoritativas:**
-- `cpp/PATTERNS.md` — checklist y esqueleto del app shell (`fn::run_app`, AppConfig, panels, layouts, Settings, About).
-- `cpp/DESIGN_SYSTEM.md` — identidad visual (`fn_tokens`, ThemeMode, equivalencias `@fn_library` ↔ C++).
-
-Esta regla NO duplica esos documentos — los señala como obligatorios y añade convenciones estructurales que no aparecen alli.
-
-### Scaffolder canonico — OBLIGATORIO
-
-**REGLA DURA:** crear apps C++ nuevas SIEMPRE con `fn run init_cpp_app <name> [--project <p>] [--desc "..."]`. NUNCA escribir `main.cpp` + `CMakeLists.txt` + `app.md` desde cero a mano en `cpp/apps/` ni `projects/*/apps/`. Tampoco copiar otra app y renombrar — la deriva entre patrones es lo que estamos eliminando.
-
-Si el scaffolder no cubre un caso (ej. necesitas plantilla diferente, layout custom desde el primer dia), **modificas el scaffolder**, no escribes la app a mano. La plantilla canonica es codigo, no decoracion.
-
-Razones:
-- Garantiza `cfg.about` + `cfg.log` + `cfg.panels` + framework defaults aplicados.
-- Genera frontmatter `app.md` valido (framework, dir_path, repo_url) para `fn index`.
-- Registra `add_subdirectory` en `cpp/CMakeLists.txt` (raiz o bloque `_DIR` para projects).
-- Crea repo Gitea `dataforge/<name>` con master + commit inicial.
-
-Pipeline: `init_cpp_app_bash_pipelines`. Slash command equivalente: `/new-cpp-app`. Auditoria: `fn doctor cpp-apps`.
-
-### 1. Ubicacion (issue 0096 estandarizada)
-
-| Caso | Donde vive |
-|---|---|
-| App independiente | `apps/<nombre>/` |
-| App de un proyecto | `projects/<proyecto>/apps/<nombre>/` |
-
-NUNCA en `cpp/apps/<nombre>/` (deprecado tras issue 0096) ni en cualquier otra carpeta nombrada por lenguaje (`python/apps/`, `bash/apps/`, etc.). Las carpetas por lenguaje son solo para codigo del registry (`cpp/functions/`, `python/functions/`, etc.), nunca para artefactos. Ver `apps_location` en memoria + regla `apps_vs_functions.md`.
-
-### 2. Estructura minima
-
-```
-<app_dir>/
-  CMakeLists.txt        # usa add_imgui_app(target ...)
-  app.md                # frontmatter de registro (ver §4)
-  main.cpp              # entry: parseo de args + fn::run_app + render()
-  [data.{h,cpp}]        # opcional: capa de datos (DB / HTTP / archivos)
-  [views.{h,cpp}]       # opcional: composicion de paneles
-  [<modulo>.{h,cpp}]    # opcional: dominio especifico
-  [vendor/]             # opcional: deps no comunes (se prefieren las globales en cpp/vendor/)
-  [.git/]               # cada app es su propio repo Gitea (ver §6)
-```
-
-**Reglas de split:**
-- `main.cpp` SIEMPRE — punto de entrada con `int main()` + `fn::run_app(...)` + funcion `render()`.
-- Si la app supera ~400 lineas en `main.cpp`, partir en `data.{h,cpp}` (carga/persistencia) + `views.{h,cpp}` (UI por panel).
-- Modulos especificos del dominio en archivos propios (`compiler.cpp` en `shaders_lab`, `data_http.cpp` en `registry_dashboard`).
-- NO crear archivos de "utilidades genericas" dentro de la app — eso va al registry como funcion (`cpp/functions/...`).
-
-### 3. CMakeLists.txt
-
-Patron canonico:
-
-```cmake
-add_imgui_app(<target>
-    main.cpp
-    [extra_modules.cpp]
-    # Funciones del registry usadas (paths absolutos):
-    ${CMAKE_SOURCE_DIR}/functions/<dominio>/<funcion>.cpp
-    ...
-)
-target_include_directories(<target> PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
-target_link_libraries(<target> PRIVATE [SQLite::SQLite3] [imgui_node_editor] ...)
-
-if(WIN32)
-    set_target_properties(<target> PROPERTIES WIN32_EXECUTABLE TRUE)
-endif()
-```
-
-Reglas:
-- Usar SIEMPRE la macro `add_imgui_app(target ...)` — gestiona enlace con `fn_framework` y copia de TTFs.
-- Listar explicitamente cada `.cpp` del registry usado (no glob). Hace visible el grafo de dependencias.
-- NO listar `tokens.cpp`, `icon_font.cpp`, `app_settings.cpp`, `app_about.cpp`, `fps_overlay.cpp`, `panel_menu.cpp`, `app_menubar.cpp`, `layouts_menu.cpp`, `gl_loader.cpp`, `layout_storage.cpp` — viven en `fn_framework` y dan multiple-definition si se duplican.
-- En `WIN32`, marcar `WIN32_EXECUTABLE TRUE` para apps GUI (sin consola).
-
-### 4. app.md (frontmatter)
-
-Plantilla minima para apps C++:
-
-```yaml
----
-name: <name>
-lang: cpp
-domain: <gfx|tui|tools|infra|...>
-version: 0.1.0                        # semver per-app, bumped via /version
-description: "Frase corta — lo que hace y por que existe."
-tags: [imgui, ...]                    # si es service, anadir 'service'
-uses_functions:                       # IDs del registry — el indexer NO deduce C++
-  - <nombre>_cpp_<dominio>
-  - ...
-uses_types: []
-framework: "imgui"
-entry_point: "main.cpp"
-dir_path: "cpp/apps/<name>" o "projects/<proyecto>/apps/<name>"
-repo_url: "https://gitea-.../dataforge/<name>"
----
-```
-
-Reglas:
-- `uses_functions` se rellena a mano con los IDs de las funciones del registry usadas en `CMakeLists.txt`. Auditar con: `sqlite3 registry.db "SELECT id FROM apps WHERE id='<id>';"` + revisar diffs.
-- `framework: "imgui"` siempre que use `fn::run_app`. Otros valores solo si la app NO usa el shell (raro).
-- `tags`: incluir `service` si es daemon de larga duracion (ver `function_tags.md`).
-- `repo_url` apunta al sub-repo en Gitea (ver §6).
-- `version`: semver per-app. Baseline `0.1.0` para apps nuevas. Bump obligatorio via `/version apps/<name> {major|minor|patch} "<reason>"` cuando `/fix-issue` toque codigo de la app. Trazabilidad humana en seccion `## Capability growth log` al final del `app.md` (una linea por bump). Ver `.claude/commands/version.md`.
-
-### 5. Registro en `cpp/CMakeLists.txt`
-
-Cada app nueva se registra al final de `cpp/CMakeLists.txt`:
-
-```cmake
-# --- <app_name> ---
-if(EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/apps/<name>/CMakeLists.txt)
-    add_subdirectory(apps/<name>)
-endif()
-```
-
-Para apps en proyectos (fuera del arbol `cpp/`):
-
-```cmake
-# --- <app_name> (lives in projects/<proj>/apps/) ---
-set(_<NAME>_DIR ${CMAKE_SOURCE_DIR}/../projects/<proj>/apps/<name>)
-if(EXISTS ${_<NAME>_DIR}/CMakeLists.txt)
-    add_subdirectory(${_<NAME>_DIR} ${CMAKE_BINARY_DIR}/apps/<name>)
-endif()
-```
-
-El `if(EXISTS ...)` hace el registro tolerante a apps no clonadas (cada app es sub-repo separado).
-
-### 6. Sub-repo Gitea (TBD obligatorio)
-
-Cada app C++ es su propio repo en `dataforge/<name>` con branch `master`. Esto significa:
-- TODO el directorio `<app_dir>/` (incluido `app.md`, `appicon.*`, binarios y `local_files/`) esta en el `.gitignore` de `fn_registry`: el repo padre NUNCA versiona contenido del artefacto. `fn index` lee `app.md` directo del disco, no del git. NO forzar con `git add -f` — deja el padre dirty. Ver la regla dura en `apps_subrepo.md`.
-- El propio directorio tiene `.git/` apuntando al sub-repo.
-- TBD obligatorio mientras se desarrolla la app: ver `apps_tbd.md`. Trabajar en `issue/<NNNN>-<slug>` o `quick/<slug>`, mergear a `master` con `--no-ff`.
-- Sync entre PCs y push/pull se gestionan con `/full-git-push` y `/full-git-pull`.
-
-### 7. Convencion `local_files/` — separacion de distribuible vs estado local
-
-**OBLIGATORIO**: TODA app coloca sus archivos escribibles bajo
-`<exe_dir>/local_files/`. Los archivos distribuibles (`.exe`, `.dll`,
-`.ttf`, `enrichers/`, `runtime/`) viven directos en `<exe_dir>/`.
-
-```
-<exe_dir>/
-├── <app>.exe
-├── duckdb.dll, *.ttf, runtime/, enrichers/    ← read-only, ships con el zip
-└── local_files/                                ← writable, per-PC
-    ├── imgui.ini                               ← gestionado por fn::run_app
-    ├── app_settings.ini                        ← gestionado por fn_ui::settings_*
-    └── <lo que la app escriba>                 ← usar fn::local_path("nombre")
-```
-
-`fn::run_app` lo gestiona automaticamente para `imgui.ini` y
-`app_settings.ini` y migra desde `<exe_dir>/` o `cwd` si vienen de
-una version previa.
-
-Apps que escriban archivos extra (DBs, caches, proyectos del
-usuario) **DEBEN** usar `fn::local_path("nombre")` al construir
-sus paths. Ejemplo:
-
-```cpp
-// MAL
-sqlite3_open("graph_explorer.db", &db);
-fopen("graph_explorer.ini", "r");
-
-// BIEN
-sqlite3_open(fn::local_path("graph_explorer.db"), &db);
-fopen(fn::local_path("graph_explorer.ini"), "r");
-```
-
-API en `cpp/framework/app_base.h`:
-- `fn::exe_dir()` — directorio del ejecutable.
-- `fn::local_dir()` — `<exe_dir>/local_files/`, creado on-demand.
-- `fn::local_path(name)` — `<local_dir>/<name>`.
-- `fn::migrate_to_local_files(names, n)` — mueve archivos viejos.
-
-Beneficios:
-- Carpeta del .exe limpia para distribuir (zip portable).
-- Reset trivial (basta borrar `local_files/`).
-- Separacion clara para backup/sync (solo `local_files/` es propio del PC).
-
-### 7.1 Anti-jitter automatico (AltSnap, tiling WMs)
-
-`fn::run_app` aplica tres capas de proteccion contra jitter al mover la
-ventana con herramientas externas (AltSnap en Windows, snap-assist, tiling
-WMs). Activado por defecto, sin opt-in:
-
-1. **GLFW pos/size callbacks** — `vp->Pos/Size` se sincronizan al instante
-   con `glfwSetWindowPos/Size` (no espera al siguiente NewFrame).
-2. **Per-frame viewport sync** al inicio del main loop — cubre viewports
-   secundarios (paneles drag-out) que la backend crea dinamicamente.
-3. **Win32 WndProc subclass per HWND** (`#ifdef _WIN32`) — observa
-   `WM_ENTERSIZEMOVE` / `WM_EXITSIZEMOVE` que AltSnap fakea alrededor de cada
-   drag. El subclass se instala en la ventana principal Y en cada HWND
-   secundario que el backend de ImGui crea cuando un panel se arrastra fuera
-   del main (escaneo per-frame de `pio.Viewports`). Mientras el bracket esta
-   abierto en CUALQUIER HWND propio, el main loop SKIPEA `render_fn` +
-   `glfwSwapBuffers` globalmente, replicando el contrato del title-bar drag
-   native (DefWindowProc bloquea el hilo, DWM compositor mueve el framebuffer
-   existente). El flag `g_in_sizemove` es global a proposito: una sola
-   sesion de sizemove externo pausa todo el render para que ninguna ventana
-   compita con el OS.
-
-   Estado del subclass:
-   - `g_subclassed` = `unordered_map<HWND, WNDPROC>`. Chain a la proc
-     original via `CallWindowProcW`.
-   - `install_sizemove_subclass_hwnd(HWND)` idempotente (skip si ya en mapa).
-   - Per-frame: `prune_dead_subclassed()` con `IsWindow` + install en cada
-     `pio.Viewports[i]->PlatformHandle` nuevo.
-   - `uninstall_sizemove_subclass_all()` restaura cada HWND al exit.
-
-#### Iconified main no pierde paneles flotantes (2026-05-16)
-
-El legacy `glfwWaitEvents + continue` al detectar `GLFW_ICONIFIED` paraba TODO
-el frame loop. Con multi-viewport activo eso significa que
-`ImGui::UpdatePlatformWindows + RenderPlatformWindowsDefault` dejan de
-refrescar los viewports secundarios — los floating panels aparecen congelados
-o son agrupados/ocultados por el WM. Fix actual: el iconified-gate cuenta
-viewports secundarios primero; si hay alguno, fall-through al frame normal
-(la swap del main HWND minimizado es harmless, los contexts GL secundarios
-siguen pintando). Solo cuando NO hay flotantes dormimos en `glfwWaitEvents`.
-
-#### Alt + RMB / Alt + LMB anywhere → modal nativo (2026-05-16)
-
-WndProc del subclass tambien intercepta clicks con Alt held (`GetAsyncKeyState(VK_MENU) & 0x8000`):
-
-- `WM_LBUTTONDOWN` + Alt → `ReleaseCapture()` +
-  `PostMessage(WM_SYSCOMMAND, SC_MOVE | HTCAPTION)`. Modal MOVE nativo.
-- `WM_RBUTTONDOWN` + Alt → calcula direccion por cuadrante (TOPLEFT/TOPRIGHT/
-  BOTTOMLEFT/BOTTOMRIGHT relativo al centro del client rect) y emite
-  `PostMessage(WM_SYSCOMMAND, SC_SIZE | dir)`. Modal RESIZE nativo.
-
-Ambos retornan 0 (consumen el click — ImGui NO lo ve). Aplica a main y a
-cada viewport flotante porque el subclass per-frame ya cubre todos los HWND.
-El modal nativo dispara `WM_ENTERSIZEMOVE`, que el gate existente pausa
-render → cero jitter automatico, mismo contrato que el title-bar drag.
-
-**Caveat**: cualquier Alt+click se consume — perdes Alt+click como shortcut
-UI. Aceptable porque Alt-modifier en clicks UI es muy raro.
-
-#### Title-bar-only move para ImGui windows (2026-05-16)
-
-`fn::run_app` setea `io.ConfigWindowsMoveFromTitleBarOnly = true`. Critico
-para viewports secundarios: un viewport flotante = OS window borderless con
-UNA ventana ImGui rellenandolo. Sin el flag, ImGui mueve sus ventanas
-arrastrando cualquier client-pixel — como la ventana ImGui ES el viewport
-entero, el OS window sigue al cursor sin modifier. Con el flag, floating
-panels obedecen el contrato "solo header arrastra" (igual que main que tiene
-title bar nativo de Windows). Alt+LMB anywhere sigue funcionando (consumido
-antes por el subclass).
-
-#### Test observability — `fn::internal::*` (2026-05-16)
-
-Counters monotonicos para validar el subclass desde tests headless,
-zero-cost en prod:
-
-```cpp
-namespace fn::internal {
-    int  sizemove_enter_count();   // ++ en cada WM_ENTERSIZEMOVE
-    int  alt_rmb_resize_count();   // ++ en cada Alt+RMB consumido
-    int  alt_lmb_move_count();     // ++ en cada Alt+LMB consumido
-    int  rbuttondown_seen_count(); // diagnostico — todo WM_RBUTTONDOWN
-    void set_force_alt_for_test(bool); // bypass GetAsyncKeyState para tests
-}
-```
-
-En test mode (`set_force_alt_for_test(true)`), los handlers de Alt cuentan
-pero NO postean `SC_SIZE`/`SC_MOVE` — el harness no se queda atrapado en el
-modal de Windows. Path real en prod sigue posteandolos.
-
-Tests: `apps/altsnap_jitter_test/` corre seis fases:
-- `p1.sync` (cross-platform): drives `glfwSetWindowPos` cada frame, asserta
-  `vp->Pos` sigue OS dentro de 1px.
-- `p2.altsnap` (Windows): worker thread fakea `WM_ENTERSIZEMOVE` +
-  burst de `SetWindowPos(SWP_ASYNCWINDOWPOS)` + `WM_EXITSIZEMOVE` sobre el
-  HWND principal, asserta que `render()` no se llama durante el bracket.
-- `p3.secondary` (Windows): fuerza viewport secundario
-  (`ConfigViewportsNoAutoMerge=true`), localiza su HWND y repite el bracket
-  sobre el. Valida que el subclass per-viewport tambien pausa el render.
-- `p4.minimize` (Windows): state machine 4 steps — captura
-  `IsWindow(secondary_hwnd)` antes/durante/despues de `glfwIconifyWindow +
-  glfwRestoreWindow`. Asserta los 3 estados vivos y `renders_iconified > 0`.
-- `p5.alt_rmb` (Windows): `set_force_alt_for_test(true)` +
-  `SendMessage(WM_RBUTTONDOWN)` sincrono mismo-hilo. Asserta
-  `alt_rmb_resize_count` incrementa.
-- `p6.alt_lmb` (Windows): mismo patron para `WM_LBUTTONDOWN`. Asserta
-  `alt_lmb_move_count` incrementa.
-
-Lanzar con `source bash/functions/infra/e2e_run_cpp_windows.sh &&
-e2e_run_cpp_windows altsnap_jitter_test`.
-
-NO hace falta nada en cada app — toda `fn::run_app` lo hereda. Si una app
-necesita renderizar incluso durante external move (caso raro: telemetria
-en vivo, video stream), tendria que evitar el bypass — actualmente no hay
-flag para desactivarlo (anadir `cfg.pause_on_external_sizemove = true` por
-default si surge necesidad).
-
-### 8. Convenciones de runtime
-
-Cumplir el checklist completo de `cpp/PATTERNS.md`. Resumen de lo que NUNCA debe aparecer en una app:
-
-| Anti-patron | Sustituir por |
-|---|---|
-| `glfwInit()` en `main` | `fn::run_app(cfg, render)` |
-| `ImGui::StyleColorsDark()` | `cfg.theme = ThemeMode::FnDark` (default) |
-| `ImVec4(0.5,0.5,0.5,1)` | `fn_tokens::colors::*` |
-| `ImGui::Begin(u8"\xEF...")` | `ImGui::Begin(TI_HOME " ...")` |
-| Menubar inline cada frame | `cfg.panels` + `cfg.layouts_cb` |
-| About hardcoded en un panel | `cfg.about = {...}` |
-| `gl*` directo sin loader | `cfg.init_gl_loader = true` |
-| Tabla SQLite en la raiz del repo | `<app_dir>/<app>.db` (operations.db es solo para entities/relations/executions) |
-| `fopen("foo.ini", ...)` con path relativo | `fopen(fn::local_path("foo.ini"), ...)` (ver §7) |
-
-### 8. Tests visuales (recomendado, no obligatorio)
-
-Si la app tiene componentes que se quieren proteger contra regresiones visuales, anadir un demo en `cpp/apps/primitives_gallery/demos_<dominio>.cpp` que use los mismos componentes/funciones del registry. El sistema de capture-and-compare de `primitives_gallery --capture` funciona como golden-image gate (ver final de `cpp/PATTERNS.md`).
-
-### 9. Decisiones que cada app debe tomar y documentar en su `app.md`
-
-- `viewports`: `true` (default) si las ventanas pueden arrastrarse fuera del main; `false` si la app necesita estar siempre embebida.
-- `init_gl_loader`: `true` si llama `gl*` directo (renderers GPU custom como `graph_renderer`); `false` si solo usa ImGui/ImPlot.
-- `about` info: nombre, version (semver), descripcion 1 frase.
-- Persistencia: `<app>.db` SQLite junto al exe; nunca tocar `registry.db` ni `operations.db` salvo lectura.
-- Modo CLI: si la app acepta args, documentarlos en el `app.md` con ejemplos.
-
-### 10. Layouts persistentes (default)
-
-`fn::run_app` provee menu Layouts (Save current as.../Apply/Delete/Reset) sin
-codigo. Crea `<exe_dir>/local_files/layouts.db` (tabla `imgui_layouts` +
-`layout_meta`) y persiste el `imgui.ini` serializado por nombre.
-
-**Restore-on-open / save-on-close (1.1.0+):** al cerrar la app, el slot del
-layout activo se reescribe con el `imgui.ini` actual (los retoques de
-docking sobreviven). Al abrir, si habia un layout activo persistido en
-`layout_meta.last_active`, se carga en el primer frame. Si la app no usa
-named layouts (nunca clico Save/Apply), el comportamiento sigue siendo el
-de antes: `imgui.ini` es la unica fuente.
-
-- App nueva: nada que tocar — Layouts viene activo.
-- App quiere personalizar `on_reset` (ej. re-mostrar paneles especificos como
-  `shaders_lab`): abre su propio `LayoutStorage`, llama
-  `layout_storage_make_callbacks`, override `on_reset`, y pasa
-  `cfg.layouts_cb = &cb`. Cuando se pasa `layouts_cb`, el auto-storage se
-  desactiva y la app es responsable de `layout_storage_apply_pending` al
-  inicio de su `render`.
-- App headless / capture mode: `cfg.auto_layouts = false`.
-- Cambiar nombre del archivo: `cfg.auto_layouts_db = "<algo>.db"` (relativo a
-  `local_files/`).
-
-### 11. Icono Windows (.ico embebido en el .exe) — 2026-05-16
-
-Cada app C++ desplegada a Windows tiene su propio icono. El icono vive en
-`<app_dir>/appicon.ico` (multi-resolucion: 16/24/32/48/64/128/256). El macro
-`add_imgui_app` de `cpp/CMakeLists.txt` lo detecta automaticamente: si
-`WIN32` + existe `<CMAKE_CURRENT_SOURCE_DIR>/appicon.ico`, genera un
-`<target>_appicon.rc` en `CMAKE_CURRENT_BINARY_DIR` apuntando al `.ico` con
-`IDI_ICON1 ICON "<path>"` y lo anade a `add_executable`. El compilador RC
-(`x86_64-w64-mingw32-windres` configurado en `cpp/toolchains/mingw-w64.cmake`)
-lo enlaza al `.exe` como recurso `.rsrc`.
-
-Verificar: `x86_64-w64-mingw32-objdump -h <app>.exe | grep rsrc` debe
-mostrar la seccion. El project line en `cpp/CMakeLists.txt` declara
-`LANGUAGES C CXX RC` solo en WIN32 (Linux ignora la `.rc`).
-
-#### Crear `.ico` para una app nueva
-
-Fuente de glyphs: **Phosphor Icons** (`sources/phosphor-core/`, clonado de
-`https://github.com/phosphor-icons/core.git`). 1512 SVGs en weight `regular`,
-`bold`, `fill`, `light`, `thin`, `duotone`. Usamos `fill` por defecto — mejor
-legibilidad a 16/24px.
-
-Funcion del registry: `generate_app_icon_py_infra` rasteriza un SVG Phosphor
-sobre fondo redondeado del color accent y exporta `.ico` multi-res. Una
-linea por app:
-
-```python
-from infra import generate_app_icon
-generate_app_icon(
-    phosphor_icon_name="chart-bar",
-    accent_hex="#0ea5e9",
-    out_ico_path="apps/chart_demo/appicon.ico",
-)
-```
-
-Mapping vive en el frontmatter de cada `app.md` C++:
-
-```yaml
-description: "Frase corta de 1 linea — que hace la app y por que existe."
-icon:
-  phosphor: "chart-bar"
-  accent: "#0ea5e9"
-```
-
-### Trio obligatorio: description + icon.phosphor + icon.accent
-
-**REGLA DURA:** TODA app C++/imgui declara los **3 campos JUNTOS** en su `app.md`:
-1. `description:` (string corta, 1 linea) — texto que el `app_hub_launcher` muestra en la tarjeta y que el dashboard usa para tooltips.
-2. `icon.phosphor:` (nombre del glyph Phosphor sin sufijo `-fill`) — glyph del icono.
-3. `icon.accent:` (hex `#rrggbb`) — color del fondo redondeado del icono **Y** color del boton/border de la tarjeta en `app_hub_launcher`.
-
-Los 3 se consumen como un set unico: el icono visual + el texto + el color de marca de la app. Una app sin descripcion aparece como tarjeta gris sin texto; sin `icon:` cae al default (`app-window` slate); sin accent el boton del hub aparece blanco. **Documentar uno sin los otros es bug**, no estilo.
-
-### Refrescar el App Hub tras editar el trio
-
-`app_hub_launcher` cachea iconos (PNG) y manifest (TSV) al arrancar. Cambiar `description`/`icon.*` en un `app.md` requiere regenerar ambos sidecars + relanzar el hub. Pipeline canonico:
-
-```bash
-./fn run refresh_app_hub                    # icons + manifest + restart hub
-./fn run refresh_app_hub --no-restart       # solo regenera, util si el hub esta cerrado
-./fn run refresh_app_hub --size 128         # PNGs 128px en vez de 64
-```
-
-ID: `refresh_app_hub_bash_pipelines`. Compone `export_hub_icons_py_infra` + `export_hub_manifest_py_infra` + `is_cpp_app_running_windows_bash_infra` + `launch_cpp_app_windows_bash_infra`.
-
-Regeneracion batch via pipeline del registry — escanea `app.md`s y compone
-`generate_app_icon` por app. Anadir app nueva: declarar `icon:` en su
-`app.md` y lanzar:
-
-```bash
-./fn run regenerate_app_icons               # todas
-./fn run regenerate_app_icons chart_demo    # solo una
-```
-
-Convenciones:
-- **Glyph weight**: `fill` (mas legible a 16px que `regular` o `bold`).
-- **Color**: 1 accent_hex distinto por app — Tailwind palette 500-700
-  funciona bien (`#0ea5e9` sky-500, `#16a34a` green-600, etc.).
-- **Padding**: glyph ocupa ~70% del canvas, fondo redondeado al 16% del lado.
-- **Glyph color**: siempre blanco sobre el fondo accent.
-
-Si Phosphor no tiene el icono adecuado: buscar en `sources/phosphor-core/assets/fill/`
-con `ls | grep <keyword>` antes de inventar — 1512 disponibles.
-
-#### Re-deploy tras cambiar icono
-
-```bash
-# 1. Editar icon: en apps/chart_demo/app.md y regenerar
-./fn run regenerate_app_icons chart_demo
-#    (o ./fn run generate_app_icon "chart-bar" "#0ea5e9" "apps/chart_demo/appicon.ico" para uno suelto sin tocar app.md)
-
-# 2. Rebuild + redeploy (build dispara windres → nuevo .rsrc)
-./fn run redeploy_cpp_app_windows chart_demo apps/chart_demo --build
-```
-
-Windows cachea iconos en `iconcache.db`. Si el nuevo icono no aparece tras
-desplegar, refresh con `ie4uinit.exe -show` o reiniciar Explorer.
-
-#### Runtime attach: taskbar + title bar + Alt+Tab (2026-05-16)
-
-Embeber `.ico` en el `.exe` (windres) basta para File Explorer / shortcuts —
-pero GLFW crea su WNDCLASS sin icono, asi que la **barra de tareas**, el
-**header de la ventana** y **Alt+Tab** muestran el icono GLFW por defecto a
-menos que adjuntemos el recurso al HWND en runtime.
-
-`fn::run_app` lo hace automaticamente, sin opt-in. Tras `glfwCreateWindow`:
-
-```cpp
-HICON hSmall = LoadImageW(GetModuleHandleW(NULL), MAKEINTRESOURCEW(101),
-                          IMAGE_ICON, GetSystemMetrics(SM_CXSMICON),
-                          GetSystemMetrics(SM_CYSMICON), LR_SHARED);
-HICON hBig   = LoadImageW(..., SM_CXICON, SM_CYICON, LR_SHARED);
-SendMessageW(hwnd, WM_SETICON, ICON_SMALL, (LPARAM)hSmall); // title bar
-SendMessageW(hwnd, WM_SETICON, ICON_BIG,   (LPARAM)hBig);   // taskbar
-SetClassLongPtrW(hwnd, GCLP_HICONSM, (LONG_PTR)hSmall);
-SetClassLongPtrW(hwnd, GCLP_HICON,   (LONG_PTR)hBig);
-```
-
-Resource ID `101` lo emite `add_imgui_app` en el `.rc` generado
-(`101 ICON "<app_dir>/appicon.ico"`). Si la app no tiene `appicon.ico`, el
-`.rc` no se genera, `LoadImageW` devuelve NULL y el HWND queda con el icono
-GLFW por defecto (sin error).
-
-Cobertura multi-viewport: el per-frame scan de `pio.Viewports` (mismo que
-instala el sizemove subclass) tambien llama `attach_app_icon_to_hwnd` sobre
-cada HWND secundario nuevo. Floating panels dragged-out heredan el icono
-sin codigo extra en la app.
-
-Cache shell: el pipeline `redeploy_cpp_app_windows` llama
-`refresh_windows_icon_cache_bash_infra` tras copiar el .exe — invoca
-`ie4uinit.exe -show` para que Explorer recargue `iconcache.db` sin esperar
-a que detecte el cambio por timestamp. Si Explorer sigue mostrando el
-icono viejo: borrar `%LOCALAPPDATA%\IconCache.db` + reiniciar Explorer.

.claude/rules/db_migrations.md

@@ -1,165 +0,0 @@
-## Migraciones de BBDD: nunca perder datos
-
-**Regla absoluta:** todo cambio de schema en SQLite (apps con `kanban.db`, `operations.db` propia, registry.db, etc.) DEBE ir en un archivo de migración versionado. Nunca borrar/recrear tablas, nunca cambiar tipos sin proceso seguro, nunca confiar en "borra el .db y vuelve a empezar".
-
-### Por que
-
-- Las apps almacenan **datos vivos** (cards, entities, executions, assertions, columns, sessions).
-- Borrar = perder horas/dias/semanas de trabajo del usuario.
-- Lo que es trivial en dev (`rm operations.db`) es destructivo en produccion (deploys + sync entre PCs).
-- Sync entre PCs (`fn sync`, `/full-git-pull`) trae bases de datos de otros equipos: si tu schema asume tabla recreada, los datos del otro PC desaparecen.
-
-### Patrones obligatorios
-
-#### 1. Archivos numerados en `migrations/`
-
-Cada cambio de schema = un archivo nuevo `migrations/NNN_<accion>.sql`. Numeracion zero-padded de 3 digitos. Nombre descriptivo.
-
-```
-apps/<app>/migrations/
-  001_init.sql                      # CREATE TABLE inicial (no se modifica nunca)
-  002_add_stickers.sql               # ALTER TABLE cards ADD COLUMN stickers
-  003_add_assignees.sql              # ALTER TABLE cards ADD COLUMN assignee_id
-  004_create_lock_history.sql        # CREATE TABLE card_lock_history
-  ...
-```
-
-#### 2. Solo operaciones aditivas seguras
-
-| Operacion | Seguro | Notas |
-|---|---|---|
-| `CREATE TABLE IF NOT EXISTS` | si | idempotente |
-| `CREATE INDEX IF NOT EXISTS` | si | idempotente |
-| `ALTER TABLE ... ADD COLUMN` | si | aditivo, default obligatorio |
-| `INSERT INTO ... ON CONFLICT IGNORE` | si | seed data idempotente |
-| `DROP TABLE` | NO | destructivo |
-| `DROP COLUMN` | NO | destructivo (SQLite < 3.35 ni siquiera lo soporta) |
-| `ALTER TABLE ... RENAME COLUMN` | precaucion | rompe codigo viejo si rollback |
-| `ALTER TABLE ... DROP/ALTER constraint` | NO sin backup | requiere recreate-and-copy |
-
-Si necesitas cambiar tipo, eliminar columna, o cambiar PK: hacer **migracion en pasos** (Branch by Abstraction):
-1. Crear nueva columna/tabla con la forma deseada (migration N).
-2. App escribe en ambas (migration N+1, codigo).
-3. Backfill de datos viejos (migration N+2, script).
-4. App lee solo de la nueva (migration N+3, codigo).
-5. Eliminar la vieja (migration N+4, despues de tener backups verificados).
-
-Cada paso = una rama TBD corta + commit + verificacion. Nunca un solo PR que rompa lectores.
-
-#### 3. Aplicacion idempotente al arrancar
-
-La app aplica todas las migraciones en orden al iniciar. Patron canonico (Go):
-
-```go
-//go:embed migrations/*.sql
-var migrationsFS embed.FS
-
-func applyMigrations(conn *sql.DB) error {
-    files, err := fs.Glob(migrationsFS, "migrations/*.sql")
-    if err != nil { return err }
-    sort.Strings(files)
-    for _, f := range files {
-        b, err := migrationsFS.ReadFile(f)
-        if err != nil { return err }
-        if _, err := conn.Exec(string(b)); err != nil {
-            // SQLite ALTER TABLE ADD COLUMN no es idempotente nativamente.
-            // Si ya existe, ignorar el error de "duplicate column".
-            if !strings.Contains(err.Error(), "duplicate column") &&
-               !strings.Contains(err.Error(), "already exists") {
-                return fmt.Errorf("%s: %w", f, err)
-            }
-        }
-    }
-    return nil
-}
-```
-
-Alternativa: tabla `_migrations` con las versiones aplicadas (mas robusta para schemas grandes). Para apps pequeñas (kanban, operations.db), bastan los archivos numerados + `IF NOT EXISTS` / catch de "duplicate column".
-
-#### 4. Migracion + cambios en codigo en el mismo commit
-
-Cuando añades una columna:
-- `migrations/NNN_<accion>.sql` (nueva)
-- `db.go` (lee/escribe la columna)
-- `types.ts` (frontend type)
-- Tests
-
-Todo en el mismo commit/rama. Si solo mergeas la migracion pero no el codigo, otros PCs aplican la migracion al sync y luego el codigo viejo no la usa. OK. Si mergeas el codigo sin la migracion, la app peta al arrancar en otros PCs. Mal. **Migracion antes que codigo en el orden de archivos** (no de tiempo).
-
-#### 5. Tests sobre la migracion
-
-Cada migracion debe tener test que:
-- Arranca con DB vacia → aplica todas → verifica schema.
-- Arranca con DB en estado N-1 (datos previos) → aplica migracion N → verifica que los datos se conservan.
-
-Esto detecta migraciones destructivas antes de mergear.
-
-### Que NO hacer
-
-| Anti-patron | Consecuencia |
-|---|---|
-| Borrar `*.db` durante dev y commitear "schema actualizado" | Otros PCs pierden datos al sync. |
-| Modificar `001_init.sql` para añadir columnas | Las DBs ya creadas no se actualizan. Datos divergentes. |
-| `DROP TABLE x; CREATE TABLE x ...` | Borra todo lo que el usuario tenga. |
-| Usar `ensureColumns` sin archivo SQL paralelo | El cambio de schema vive solo en codigo Go, no auditable, no migrable manualmente. |
-| Cambiar tipo de columna in-place | SQLite necesita recreate-and-copy. Asume que pierde datos si no se hace bien. |
-| "fn index" como solucion para regenerar registry.db | OK para `registry.db` (regenerable). NUNCA para `operations.db`, `kanban.db`, etc. |
-
-### Casos especiales
-
-#### registry.db (raiz del fn_registry)
-
-`registry.db` SE PUEDE regenerar con `fn index` desde los `.go` y `.md`. Para cambios de schema del registry: actualizar `registry/migrations.go` o el codigo de creacion + `fn index`. NO hace falta archivo de migracion porque la fuente de verdad son los `.md`/`.go`. Excepcion: tablas con datos vivos (`proposals`, `pc_locations`) — esas SI requieren migracion preservando datos.
-
-#### operations.db (por app)
-
-Cada app tiene su `operations.db` con entities/relations/executions. Schema definido en `fn_operations/`. Cambios al schema → archivo de migracion en `fn_operations/migrations/` aplicado al abrir la BD. Idempotente.
-
-#### apps con BD propia (kanban, etc.)
-
-Mismo patron: `apps/<app>/migrations/NNN_*.sql`, embebido y aplicado al arrancar.
-
-### Comandos utiles
-
-```bash
-# Ver schema actual
-sqlite3 apps/kanban/operations.db ".schema"
-
-# Ver columnas de una tabla
-sqlite3 apps/kanban/operations.db "PRAGMA table_info(cards);"
-
-# Backup antes de migracion arriesgada
-sqlite3 apps/kanban/operations.db ".backup apps/kanban/operations.db.bak.$(date +%Y%m%d)"
-
-# Aplicar una migracion manual (si la app no esta corriendo)
-sqlite3 apps/kanban/operations.db < apps/kanban/migrations/00X_<accion>.sql
-
-# Listar archivos de migracion en orden
-ls apps/kanban/migrations/*.sql | sort
-```
-
-### Resumen
-
-- Cada cambio de schema = archivo numerado nuevo en `migrations/`.
-- Aditivo siempre que se pueda. Destructivo solo en pasos verificados con backup.
-- App aplica migraciones al arrancar, idempotente.
-- Migracion + codigo + tests en el mismo commit.
-- Nunca borrar `.db` para "arreglar" schema. Nunca modificar migraciones existentes.
-
-### Estado retroactivo (2026-05-09)
-
-Inventario de BDs del ecosistema y conformidad con la regla:
-
-| Repo / App | BD | `migrations/` | Estado |
-|---|---|---|---|
-| `registry/` | `registry.db` | si (11 archivos) | ✓ |
-| `fn_operations/` | `operations.db` por app | si (4 archivos) | ✓ |
-| `apps/kanban/` | `operations.db` (kanban) | si (5 archivos: 001 init, 002 stickers, 003 columns_extras, 004 cards_extras, 005 history_actor) | ✓ |
-| `apps/deploy_server/` | `operations.db` (deploys) | si (2 archivos: 001 init, 002 target_extras) | ✓ |
-| `apps/dag_engine/store/` | DB del dag_engine | si (001_init) | ✓ |
-| `projects/element_agents/.../shell/memory/` | memoria del agente | si (001_init) | ✓ |
-| `projects/osint_graph/apps/graph_explorer/` | DBs C++ inline (project_manager, layout_store, jobs, node_groups) | NO | **pendiente** — refactor C++ multi-archivo, mover schema inline a `migrations/*.sql` aplicado al abrir cada DB. |
-
-Las apps marcadas ✓ usan el patron canonico `embed.FS + applyMigrations()` (Go) o equivalente. La C++ pendiente requiere ronda dedicada — tracker via issue cuando se aborde.
-
-`apps/kanban/db.go::ensureColumns` se mantiene como **backstop idempotente** para DBs muy antiguas creadas antes del refactor de migraciones. NO añadir columnas nuevas alli — siempre via archivo SQL.

.claude/rules/delegation.md

@@ -1,42 +0,0 @@
-## Delegacion: spawn fn-constructor en vez de escribir inline
-
-**REGLA DURA.** Si vas a escribir logica reutilizable inline en un artefacto (app, analysis, playground) o heredoc, STOP y delega a `fn-constructor`. La misma sesion debe crear + usar la funcion. No acumular huerfanas.
-
-### Cuando un patron es candidato a funcion
-
-- Aparece >=2 veces en esta sesion o en heredocs recientes.
-- Firma generica (no depende de tipos internos del artefacto).
-- 1 responsabilidad clara (CRUD, parse, transform, http call, formato fijo, etc.).
-- No es one-liner idiomatico de stdlib (`time.Now().UTC().Format(...)` queda fuera).
-
-### Flujo obligatorio (mismo turno)
-
-1. **Detectar**. Si vas a escribir >=5 lineas de logica reutilizable inline -> STOP.
-2. **Spawn `fn-constructor` inmediato** via `Agent(subagent_type="fn-constructor", ...)`:
-   - **Sin preguntar al usuario** (autorizado por defecto).
-   - Si hay >1 funcion independiente -> una sola llamada al Agent tool con **N tool_use blocks paralelos** en el mismo mensaje. NO serializar.
-3. **Tagear con grupo de capacidad** al menos UN tag de grupo (`notebook`, `metabase`, `deploy`, etc.). Ver `capability_groups.md`.
-4. **`fn index`** para registrar.
-5. **Importar + invocar en el mismo turno** — no dejar funcion huerfana recien creada.
-6. **Auto-verificar** con `fn doctor uses-functions` y `fn doctor unused` si tocas >=3 funciones nuevas.
-
-### Anti-patrones auditables
-
-| Anti-patron | Consecuencia | Sustituir por |
-|---|---|---|
-| Escribir helper inline en artefacto en vez de delegar | Reinvento por sesion | Spawn fn-constructor |
-| Crear N funciones serialmente | Latencia x N | Multiples `Agent()` en mismo mensaje |
-| Crear funcion y no usarla en el turno | Huerfana desde dia 1 (`calls_90d=0`) | Importar + invocar antes de cerrar turno |
-| Crear funcion sin tag de grupo | Imposible descubrir en bloque proxima sesion | Anadir tag de grupo (capability group) |
-| Reescribir en heredoc logica que ya existe | Capitalizacion perdida | `mcp__registry__fn_search` antes de escribir |
-
-### Excepciones
-
-- **Logica de dominio especifica del artefacto** (CRUD de tabla concreta, layout de UI, flujo unico de la app) -> queda en el artefacto. Solo lo reutilizable se delega.
-- **Stub temporal con `not implemented`**: aceptable si la dependencia externa no esta disponible. Documentar en `.md` (ver `stubs.md`).
-
-### Telemetria
-
-Cada `code_writes` + `calls` se registra en `call_monitor/operations.db` (issue 0085). Vista `session_capability_growth` mide ratio creadas vs usadas por sesion. Hook `UserPromptSubmit` inyecta `CAPABILITY-GROWTH: created_this_session=X used=Y orphan=Z` en cada turno.
-
-Si `orphan>0` al cerrar la sesion -> revisar: o la funcion era especulativa (no debio crearse) o falta integrarla en el codigo del artefacto.

.claude/rules/deploy.md

@@ -1,134 +0,0 @@
-## Deploy de apps a VPS remotos
-
-### Arquitectura
-
-El sistema de deploy usa SSH + systemd + rsync. No Docker, no Kubernetes.
-
-- **Conexiones SSH** → `~/.ssh/config` (alias, IP, user, key). Ya hay funciones CRUD: `ssh_config_read`, `ssh_config_find`, `ssh_config_parse`.
-- **Config de deploy** → `apps/deploy_server/operations.db` tabla `deploy_targets` (app, host, remote_dir, build_cmd, port, health_path, env).
-- **Logs de deploy** → misma BD, tabla `deploy_logs` (app, host, status, trigger, duration_ms, error).
-
-### App: `deploy_server` (`apps/deploy_server/`)
-
-CLI + servidor HTTP. Binario: `deploy_server`. Build: `CGO_ENABLED=1 go build -o deploy_server .`
-
-```bash
-cd apps/deploy_server
-
-# Gestionar targets
-./deploy_server target add --app <app> --host <ssh_alias> --port <N> --health /path --build "comando" [--user deploy] [--env '{"K":"V"}']
-./deploy_server target list
-./deploy_server target remove <app>
-
-# Setup inicial (primera vez, crea dirs + systemd unit)
-./deploy_server setup <app> --host <ssh_alias>
-
-# Deploy continuo (build local → rsync → restart → health check)
-./deploy_server deploy <app> [--host <ssh_alias>]
-
-# Estado del servicio remoto
-./deploy_server status <app>
-./deploy_server status --all
-
-# Servidor webhook (auto-deploy en cada push a Gitea)
-./deploy_server serve --port 9090
-```
-
-### Funciones del registry involucradas
-
-| Función | Qué hace | Purity |
-|---|---|---|
-| `rsync_deploy_bash_infra` | rsync local→remoto con exclusiones | impure |
-| `systemd_generate_unit_go_infra` | Genera texto .service | **pure** |
-| `systemd_install_go_infra` | Sube unit + daemon-reload + enable + start | impure |
-| `systemd_restart_go_infra` | Reinicia servicio remoto | impure |
-| `systemd_status_go_infra` | Estado + logs de servicio remoto | impure |
-| `vps_setup_app_go_infra` | Crea dirs + usuario en VPS | impure |
-| `gitea_create_webhook_bash_infra` | Crea webhook push en Gitea | impure |
-| `setup_vps_app_go_infra` | Pipeline: setup completo primera vez | impure |
-| `deploy_app_remote_go_infra` | Pipeline: deploy continuo | impure |
-
-Tipo: `DeployConfig_go_infra` — struct con toda la config de deploy.
-
-### Workflow para un agente
-
-Cuando el usuario diga **"sube esta app a este VPS"** o **"deploya X en Y"**:
-
-#### 1. Verificar que el host SSH existe
-
-```bash
-grep "^Host " ~/.ssh/config
-# Si no existe el alias, añadirlo:
-# Usar ssh_config_add_entry o editar ~/.ssh/config directamente
-```
-
-#### 2. Verificar conectividad
-
-```bash
-ssh -o BatchMode=yes -o ConnectTimeout=5 <alias> true
-```
-
-#### 3. Registrar el target en deploy_server
-
-```bash
-cd apps/deploy_server
-# Build deploy_server si no existe el binario
-CGO_ENABLED=1 go build -o deploy_server .
-
-./deploy_server target add \
-  --app <nombre_app> \
-  --host <ssh_alias> \
-  --port <puerto> \
-  --health <path_o_vacio> \
-  --build "CGO_ENABLED=0 GOOS=linux go build -o <binario> ." \
-  --user deploy
-```
-
-#### 4. Setup inicial
-
-```bash
-./deploy_server setup <app> --host <ssh_alias>
-```
-
-Esto crea dirs en `/opt/apps/<app>/`, sube el código, genera el unit systemd e instala el servicio.
-
-#### 5. Deploys posteriores
-
-```bash
-./deploy_server deploy <app>
-```
-
-Build local → rsync → restart systemd → health check.
-
-#### 6. Auto-deploy con webhook (opcional)
-
-```bash
-# Lanzar servidor
-./deploy_server serve --port 9090
-
-# Crear webhook en Gitea
-source bash/functions/infra/gitea_create_webhook.sh
-gitea_create_webhook "<owner>" "<repo>" "http://<ip_deploy_server>:9090/webhook/push" "<secret>"
-```
-
-### Requisitos en el VPS
-
-- SSH accesible con key auth (configurado en `~/.ssh/config` local)
-- El usuario SSH debe tener **sudo sin password** para: `systemctl`, `mv` a `/etc/systemd/system/`, `mkdir` en `/opt/apps/`, `useradd`, `chown`
-- `rsync` instalado en el VPS
-- Puerto del servicio abierto en el firewall del VPS
-
-### Builds por lenguaje
-
-| Lenguaje | Build command típico |
-|---|---|
-| Go | `CGO_ENABLED=0 GOOS=linux go build -o <nombre> .` |
-| Go + SQLite | `CGO_ENABLED=1 GOOS=linux go build -tags fts5 -o <nombre> .` |
-| Python | No build — rsync sube los .py, systemd ejecuta `python3 main.py` |
-| Bash | No build — rsync sube los .sh, systemd ejecuta `bash main.sh` |
-
-Para Go con CGO (SQLite), el VPS debe tener `gcc` y `libc-dev`, o cross-compilar con `CGO_ENABLED=0` si la app no usa SQLite.
-
-### Exclusiones de rsync
-
-El deploy excluye automáticamente: `.git`, `operations.db*`, `*.exe`, `node_modules`, `.venv`, `__pycache__`, `build/`, `*.db-shm`, `*.db-wal`, `registry.db`.

.claude/rules/dod_quality.md

@@ -1,131 +0,0 @@
-# DoD Quality Triada
-
-**Definition of Done no es un checkbox que se marca a mano. Es un contrato de calidad con 3 capas obligatorias + evidencia ejecutable + uso real >=7 dias.**
-
-Aplica a todos los `dev/flows/` y, por extension, a issues que cierran capabilities user-facing (`dev/issues/`). El registry mismo (funciones puras, tipos) queda exento: su DoD vive en sus tests unitarios.
-
----
-
-## Por que existe esta regla
-
-El antipatron a eliminar: "tarea hecha porque pase los tests una vez". Despues:
-- El flow funciona en `home-wsl` pero falla en `pc-aurgi`.
-- El error path declarado nunca se ejercito y cuando ocurre en produccion no esta manejado.
-- El dashboard de observabilidad lleva 30 dias sin abrirse.
-- El proceso muere cada noche y nadie lo ve hasta que el operador intenta usarlo.
-- El approval flow se salta porque "para test es mas comodo".
-
-Resultado: deuda invisible. Cada flow "done" se rompe al primer uso real, el operador pierde confianza en el sistema, y el bucle reactivo no detecta nada porque la telemetria esta verde (los tests sintenticos pasan).
-
-DoD Quality Triada cambia las reglas: cerrar = probar comportamiento + sobrevivir uso real, no = compilar verde.
-
----
-
-## Las 3 capas
-
-### Capa 1: Mecanica (pre-requisito, NO es DoD por si misma)
-
-Compilar verde, tests verdes, indexado limpio, `fn doctor` verde, `uses_functions` sin drift.
-
-**Regla**: la mecanica NO basta. Es la base para empezar a probar comportamiento. Si te quedas aqui, el flow no esta hecho.
-
-### Capa 2: Cobertura de comportamiento
-
-Cada escenario relevante con prueba ejecutable y assert material. NO smoke "el comando no peto". Minimo:
-
-- **1 golden path** — el caso feliz documentado con assert sobre output concreto.
-- **>=2 edge cases** — inputs limite, estados raros, condiciones de borde.
-- **>=1 error path** — fallo provocado intencionalmente, manejado y observable (sin crash, sin silent-fail).
-
-Formato canonico (tabla en `## Definition of Done` del flow/issue):
-
-```markdown
-| Escenario | Tipo | Comando / evidencia | Resultado esperado |
-|---|---|---|---|
-| Golden: <desc> | unit / e2e | `<cmd>` | <output concreto> |
-| Edge 1: <desc> | unit / e2e | `<cmd>` | <comportamiento concreto> |
-| Error 1: <desc> | e2e | `<cmd que rompe>` | <fallo manejado, no crash> |
-```
-
-Cuando aplique, cada fila genera un `e2e_check` en el `app.md` correspondiente (issue 0068). `fn-analizador` los corre periodicamente y deja entry en `e2e_runs`.
-
-### Capa 3: Vida util validada
-
-El flow no esta hecho hasta que sobrevive **uso real durante >=7 dias** sin romperse silenciosamente. Cada metrica con umbral medible y dashboard observable.
-
-Formato canonico:
-
-```markdown
-| Metrica | Umbral | Donde se observa | Ventana |
-|---|---|---|---|
-| <metrica 1> | `>=N` | `<dashboard URL / app panel>` | 7 dias |
-| crashes | `0` | `journalctl -u <unit>` | 7 dias |
-| huecos audit chain | `0` | `cmd: <verify>` | continuo |
-```
-
-Reglas:
-- Metricas NO se auto-reportan; las lee el operador del dashboard real.
-- Si el dashboard no existe o no se ha abierto en 30 dias, el item se invalida.
-- Crashes del proceso = 0, huecos en audit = 0, error_rate < umbral declarado.
-
-### Capa transversal: User-facing reforzado
-
-- Surface concreta NO BD ni log (UI app, room Matrix, dashboard, archivo en vault).
-- Usage real: humano usa en su PC, su contexto, >=N veces variadas en >=7 dias.
-- Variado: >=3 capabilities/casos distintos (no solo "abre dashboard y mira").
-- Onboarding: parrafo en `## Notas` que explica como usar la cosa sin leer el flow.
-- Latencia medida (no declarada).
-
----
-
-## Reglas duras para marcar `status: done`
-
-`/flow done` (y por extension cierres de issues user-facing) DEBE rechazar el cierre si:
-
-1. Falta cualquiera de las 3 capas (mecanica + cobertura + vida).
-2. Cobertura tiene <1 golden, <2 edge, o <1 error path con evidencia.
-3. Vida util tiene tabla vacia o sin dashboard observable real.
-4. User-facing usage real <7 dias o <N usos declarados.
-5. Cualquier anti-criterio marcado como cierto.
-6. `## Notas` sin parrafo onboarding.
-7. Algun item de DoD sin comando/URL/log query asociado — solo texto.
-
-Hoy parte de esta validacion es manual (revision humana del operador). La validacion programatica vive en `audit_dod_schema_go_infra` (issue 0114) + `fn doctor dod` y se ampliara hasta cubrir las 3 capas (TBD).
-
----
-
-## Antipatrones (invalidan la DoD aunque los checkboxes esten verdes)
-
-| Antipatron | Por que es malo | Sustituir por |
-|---|---|---|
-| Marcar `done` porque pasa una vez | Tarea "hecha" se rompe al primer uso real | Capa 3: >=7 dias de uso real |
-| Checkbox sin evidencia ejecutable | DoD se convierte en placebo | Cada item con `cmd:` / URL / log query |
-| Test que solo verifica camino feliz | El error path es donde se pierden datos | Capa 2: >=1 error path ejercitado |
-| Observabilidad declarada pero dashboard no abierto en 30 dias | Telemetria muerta = ceguera | Capa 3: dashboard real, operador lo abre |
-| "Repetible 3 veces consecutivas" con BD efimera | No prueba sobre datos reales acumulados | Capa 3: PC real del operador, datos vivos |
-| Approval saltado en algun camino | Security gate roto pero invisible | Anti-criterio explicito: `audit_log` lo prueba |
-| Error path manejado solo "en teoria" | Cuando ocurra en produccion el manejo no existe | Capa 2: entry real en `e2e_runs` o audit |
-| Solo-en-mi-PC | Falla en otra maquina del operador | Anti-criterio explicito, probar >=2 PCs |
-| Self-test que retorna `pass` sin asserts materiales | False positive sistemico | Asserts sobre output concreto, no exit-0 |
-| Silent-fail (proceso muere sin alerta) | Operador no se entera hasta intentar usar | Capa 3: crashes=0 + alerta visible |
-
----
-
-## Relacion con otras reglas
-
-- [[e2e_validation]] — los escenarios de Capa 2 cuando aplican a apps se materializan como `e2e_checks` en `app.md`. `fn-analizador` (fase 4 del bucle reactivo) los corre.
-- [[registry_calls]] — la evidencia de uso (`call_monitor.calls`) alimenta los umbrales de Capa 3.
-- [[function_growth_and_self_docs]] — cada funcion del registry tiene su propio contrato self-doc (Ejemplo + Cuando usarla + Gotchas). DoD del flow NO sustituye al self-doc de la funcion; lo complementa para el nivel sistema.
-- [[autonomous_loop]] — `fn-orquestador` autonomo NO puede marcar `done` sin que se cumplan las 3 capas. Su criterio de convergencia incluye DoD Quality.
-- [[apps_tbd]] — TBD garantiza master desplegable; DoD garantiza que lo desplegado funciona en uso real.
-
----
-
-## TL;DR
-
-1. **Mecanica** = compilar verde (pre-requisito, NO suficiente).
-2. **Cobertura** = golden + >=2 edge + >=1 error path con evidencia ejecutable.
-3. **Vida util** = >=7 dias de uso real sin romper silenciosamente, dashboard observable abierto.
-4. **User-facing reforzado** = humano usa en PC real, >=N veces variadas.
-5. **Anti-criterios** invalidan la DoD aunque todo este verde.
-6. Sin evidencia ejecutable (cmd/URL/log), NO es DoD: es deseo.

.claude/rules/e2e_validation.md

@@ -1,162 +0,0 @@
-## Validacion end-to-end de apps (bucle reactivo, fase 4)
-
-**Contrato obligatorio para apps que vayan a master con gate automatico**: declarar `e2e_checks` en su `app.md`. Sin contrato, `fn-analizador` no puede validar y la app cae al modo "manual": el humano sigue iterando.
-
-Ver tambien: `apps_tbd.md`, `feature_flags.md`, issue 0068.
-
-### Por que
-
-El bucle reactivo del registry tiene 5 fases. Las 3 primeras (`fn-constructor`, `fn-executor`, `fn-recopilador`) cubren CONSTRUIR/EJECUTAR/RECOPILAR. La fase 4 (ANALIZAR) y la 5 (MEJORAR) no funcionan sin un contrato explicito de "como sabe el agente que esta app esta sana". Ese contrato es `e2e_checks`.
-
-### Donde vive
-
-En el frontmatter de cada `app.md`, lista `e2e_checks`. Convencion: `id` unico por check, ejecucion en orden declarado, falla = stop o continue segun severidad (TBD por implementar).
-
-### Tipos de check
-
-| Campo | Que hace |
-|---|---|
-| `id` | Identificador unico del check dentro de la app (`build`, `smoke`, `tests_unit`, ...) |
-| `cmd` | Comando shell. Exit 0 = pass salvo override de `expect_exit`. |
-| `health` | URL HTTP. Hace GET, espera 200, util tras un `cmd` que arranca un servicio en background (con `&`). |
-| `ref` | Referencia a otro agente / funcion del registry (ej. `fn-recopilador:apps/X`, `fn-doctor:artefacts`). |
-| `timeout_s` | Timeout en segundos. Default 60. |
-| `expect_exit` | Codigo de salida esperado (default 0). |
-| `expect_stdout_contains` | Substring que debe aparecer en stdout. |
-| `expect_stdout_json` | JSONPath o key=value que debe satisfacer la salida. |
-| `severity` | `critical` (default) o `warning`. Critical = bloquea merge; warning = registra y sigue. |
-
-### Patrones por stack
-
-#### Go service con frontend embebido
-
-```yaml
-e2e_checks:
-  - id: build_frontend
-    cmd: "cd frontend && pnpm install --frozen-lockfile && pnpm build"
-    timeout_s: 180
-  - id: build_backend
-    cmd: "CGO_ENABLED=1 go build -tags fts5 -o myapp ."
-  - id: smoke
-    cmd: "./myapp --port 8200 --db /tmp/myapp_e2e.db &"
-    health: "http://127.0.0.1:8200/api/health"
-  - id: tests
-    cmd: "go test -tags fts5 -count=1 ./..."
-```
-
-#### C++ ImGui app
-
-```yaml
-e2e_checks:
-  - id: build
-    cmd: "cmake --build build --target myapp -j"
-    timeout_s: 300
-  - id: self_test
-    cmd: "./build/myapp --self-test"
-    timeout_s: 30
-  - id: pytest
-    cmd: "cd tests && python3 -m pytest -x -q"
-```
-
-Apps C++ deben implementar `--self-test` que arranca, verifica subsistemas (GL loader, fonts, DBs locales), y sale con codigo 0/1.
-
-#### Python pipeline / CLI
-
-```yaml
-e2e_checks:
-  - id: import
-    cmd: "python3 -c 'import myapp'"
-  - id: cli_help
-    cmd: "python3 -m myapp --help"
-    expect_stdout_contains: "usage:"
-  - id: dry_run
-    cmd: "python3 -m myapp --dry-run --input examples/sample.json"
-```
-
-#### App con operations.db
-
-Anadir siempre:
-
-```yaml
-  - id: ops_audit
-    ref: "fn-recopilador:apps/myapp"
-```
-
-Esto invoca al recopilador en modo audit sobre `apps/myapp/operations.db`.
-
-### Reglas
-
-1. **Idempotente**: cada check debe poderse correr N veces sin efectos secundarios. Usar BDs en `/tmp/`, puertos altos, `--port 0` cuando se pueda.
-2. **Sin credenciales reales**: ningun check toca produccion ni servicios externos sensibles. Si necesita HTTP de prueba, usar `httpbin.org` o un mock local.
-3. **Tiempo acotado**: cada check declara `timeout_s`. Suma total de la app < 10 min como objetivo razonable.
-4. **Determinista**: si el check depende de red flaky, marcalo `severity: warning` o usalo solo como diagnostico, no como gate.
-5. **Cleanup implicito**: si el check arranca un proceso en background (`&`), debe morir al final. `fn-analizador` mata el grupo de procesos al terminar la suite.
-
-### Como diseñar `e2e_checks` para una app existente
-
-`fn-recopilador` tiene un modo `design-e2e <app_id>` que:
-
-1. Inspecciona `app.md` (lang, framework, entry_point, uses_functions).
-2. Revisa estructura del directorio (presencia de `tests/`, `frontend/`, `Makefile`, `CMakeLists.txt`, etc.).
-3. Audita `operations.db` (si existe) para sugerir `ops_audit`.
-4. Devuelve bloque `e2e_checks_suggested:` listo para copiar al `app.md` tras revision humana.
-
-Comando indicativo:
-```
-Agent(subagent_type="fn-recopilador",
-      prompt="design-e2e apps/<app>")
-```
-
-El recopilador NO escribe directo al `app.md`; deja la propuesta para que el humano apruebe (similar a `proposals`).
-
-### Adopcion gradual
-
-- Apps SIN `e2e_checks` declarado: `fn doctor` muestra warning, no bloquea nada.
-- Apps CON `e2e_checks`: `fn-analizador` corre la suite. Si critical falla → `fn-mejorador` crea proposal. Gate opcional en `/git-push`.
-- Pilotos iniciales: `apps/kanban`, `projects/osint_graph/apps/graph_explorer`. Resto de apps van migrando segun necesidad.
-
-### Anti-patrones
-
-| Anti-patron | Por que es malo |
-|---|---|
-| `cmd: "make test"` con make-target opaco | Ilegible. El check debe ser ejecutable directo y auditable. |
-| Check que tarda > 5 min sin razon (smoke pesado) | Bloquea iteracion. Mover a CI nocturno con tag `slow`. |
-| Smoke que toca produccion | Riesgo. Smoke usa BD efimera, puertos altos, mocks. |
-| `expect_stdout_contains: ""` | Vacio = siempre pass. No es un check. |
-| Anidar checks (uno depende de side-effects de otro sin declararlo) | Frigil. Cada check arranca lo que necesita. |
-| Usar `e2e_checks` como sustituto de tests unitarios | Son cosas distintas. Unit tests viven en `*_test.go`/`pytest`. e2e valida que el sistema arranque y haga su trabajo. |
-
-### Tabla `e2e_runs` en operations.db
-
-Cada corrida de `fn-analizador` se persiste:
-
-```sql
-CREATE TABLE IF NOT EXISTS e2e_runs (
-    id            TEXT PRIMARY KEY,
-    app_id        TEXT NOT NULL,
-    started_at    INTEGER NOT NULL,
-    finished_at   INTEGER,
-    status        TEXT NOT NULL,        -- pass|fail|partial
-    checks_total  INTEGER NOT NULL,
-    checks_pass   INTEGER NOT NULL,
-    checks_fail   INTEGER NOT NULL,
-    summary_json  TEXT NOT NULL
-);
-```
-
-Migracion: `fn_operations/migrations/006_e2e_runs.sql` (issue 0068, paso 3).
-
-### Output canonico de fn-analizador
-
-Tabla caveman, una linea por check:
-
-```
-build           ✓ 42s
-smoke           ✓ 0.8s
-ops_audit       ✓
-tests           ✗ 12s   exit 1, 3/45 failures
-assertion:R1    ✗       warning  duration drift +47% vs p50
-golden:home     ✓
-```
-
-Rojo cuando `severity: critical` y status fail. Esto es lo que el agente principal lee y reenvia al humano.

.claude/rules/feature_flags.md

@@ -1,191 +0,0 @@
-## Feature flags: enviar codigo incompleto a master sin romperlo
-
-Doctrina oficial de **trunk-based development**: master siempre desplegable. Cuando una feature no cabe en una sola rama corta, o cuando hay WIP que no esta terminado pero el resto si, **el codigo viaja detras de un flag OFF**. Asi master sigue verde y el codigo a medio terminar no llega a usuarios reales.
-
-Refs: [trunkbaseddevelopment.com/feature-flags/](https://trunkbaseddevelopment.com/feature-flags/), [trunkbaseddevelopment.com/branch-by-abstraction/](https://trunkbaseddevelopment.com/branch-by-abstraction/).
-
-### Cuando usar feature flag
-
-| Situacion | Accion |
-|---|---|
-| Feature multi-issue (`0015a`, `0015b`, `0015c`) que llevan dias | Cada sub-issue mergea con flag OFF. Ultimo sub-issue activa flag. |
-| Refactor grande tipo "Branch by Abstraction" (ej. cambiar driver DB) | Crear abstraccion + impl nueva con flag. Eliminar antigua + flag al final. |
-| Cambio con riesgo en produccion que necesita rollback rapido | Flag para apagar sin redeploy. |
-| Despliegue gradual (un PC primero, luego todos) | Flag por PC/usuario/grupo. |
-| WIP detectado al cerrar otra rama | Envolver el codigo a medias en flag OFF, mergear, terminar despues. |
-
-### Cuando NO usar feature flag
-
-- Bug fix autocontenido → mergear directo, sin flag.
-- Refactor que cabe en una rama corta → directo.
-- Docs, comments, type signatures → directo.
-- Codigo que no compila o no pasa tests → **NO viaja a master, ni con flag**. Flag protege codigo terminado, no roto.
-
-### Flag != WIP
-
-- **WIP**: codigo a medias, no compila o no testea. NO va a master.
-- **Flag**: codigo terminado y testeado, pero no expuesto al usuario. SI va a master.
-
-Si hay 80% terminado y 20% pendiente: completar al menos un slice vertical funcional (compila, pasa tests, se puede activar end-to-end), mergear con flag OFF, dejar el 20% para otra rama. NO mergear el 20% sin proteger.
-
-### Archivo de flags
-
-`dev/feature_flags.json` en la raiz del repo (registry o app). Formato canonico:
-
-```json
-{
-  "flags": {
-    "<flag-name>": {
-      "enabled": false,
-      "issue": "0063",
-      "description": "Descripcion 1 linea de la feature",
-      "added": "2026-05-08",
-      "enabled_at": null
-    }
-  }
-}
-```
-
-Cuando se activa: cambiar `enabled: true` y rellenar `enabled_at` con fecha. Cuando la feature ya es estable y no necesita rollback (semanas/meses despues): borrar el flag y todas sus ramas condicionales del codigo. **Los flags caducan**; documentar fecha de revision para evitar que se acumulen.
-
-### Patron por stack
-
-#### Go (apps/services)
-
-Cargar flags al arrancar. Patron simple — hashmap en memoria + helper `Enabled(name)`:
-
-```go
-// pkg/flags/flags.go (puro hasta donde se pueda)
-package flags
-
-import (
-	_ "embed"
-	"encoding/json"
-)
-
-type Flag struct {
-	Enabled     bool   `json:"enabled"`
-	Issue       string `json:"issue"`
-	Description string `json:"description"`
-}
-
-type Flags struct{ Flags map[string]Flag `json:"flags"` }
-
-func Parse(b []byte) (Flags, error) {
-	var f Flags
-	err := json.Unmarshal(b, &f)
-	return f, err
-}
-
-func (f Flags) Enabled(name string) bool {
-	flag, ok := f.Flags[name]
-	return ok && flag.Enabled
-}
-```
-
-Uso:
-
-```go
-if flags.Enabled("kanban-stickers") {
-	registerStickerRoutes(router)
-}
-```
-
-Para flags en frontend embebido: serializar a `/api/flags` y leer desde el cliente (ver TS).
-
-#### TypeScript / React
-
-Inyectar en build (Vite) o exponer endpoint `/api/flags`:
-
-```ts
-// src/flags.ts
-let cache: Record<string, boolean> | null = null;
-
-export async function loadFlags(): Promise<Record<string, boolean>> {
-	if (cache) return cache;
-	const res = await fetch("/api/flags");
-	const data = await res.json();
-	cache = Object.fromEntries(Object.entries(data.flags).map(([k, v]: [string, any]) => [k, !!v.enabled]));
-	return cache;
-}
-
-export function isEnabled(name: string): boolean {
-	return !!(cache?.[name]);
-}
-```
-
-Render condicional:
-
-```tsx
-{isEnabled("kanban-stickers") && <StickerToolbar ... />}
-```
-
-Para flags en build-time (constantes del bundle), usar `import.meta.env.VITE_FLAG_X` o un plugin Vite que reemplace simbolos.
-
-#### Bash / pipelines
-
-Lectura directa con `jq`:
-
-```bash
-ENABLED=$(jq -r '.flags["my-feature"].enabled' dev/feature_flags.json)
-if [ "$ENABLED" = "true" ]; then
-	run_new_path
-else
-	run_legacy_path
-fi
-```
-
-#### Python
-
-```python
-import json
-from pathlib import Path
-
-def flags() -> dict:
-    return json.loads(Path("dev/feature_flags.json").read_text())["flags"]
-
-def enabled(name: str) -> bool:
-    f = flags().get(name)
-    return bool(f and f.get("enabled"))
-
-if enabled("nuevo-pipeline"):
-    run_new()
-else:
-    run_legacy()
-```
-
-### Branch by Abstraction (caso especial)
-
-Para cambios grandes (ej. swap iBatis → Hibernate, swap libreria, swap protocolo):
-
-1. **Abstraer**: crear interfaz que envuelve la implementacion antigua. Master sigue verde con la antigua. Mergear.
-2. **Implementar nueva**: bajo la misma interfaz, detras de flag OFF. Tests para ambas. Mergear.
-3. **Activar**: flip flag a ON en commit pequeño. Si rompe, flip OFF de inmediato.
-4. **Eliminar antigua**: borrar codigo legacy + flag + abstraccion. Mergear.
-
-Cada paso es un merge corto, master nunca esta roto, hay rollback en cada punto.
-
-### Reglas operativas
-
-- **Un flag = un proposito**. Si necesitas dos toggles independientes, usa dos flags.
-- **Flag bool por defecto**. Si necesitas A/B/C, sigue siendo bool por nombre (`my-feature-v2`, `my-feature-v3`).
-- **Tests con flag ON y OFF**. CI corre ambos paths cuando el flag toca codigo critico.
-- **Documenta en el issue**: que flag protege que codigo, cuando se va a activar, cuando se va a borrar.
-- **No anidar flags**. Si una rama esta detras de dos flags, simplifica.
-- **Borra el flag**. Cuando la feature lleva semanas activa sin rollback, eliminar el flag es trabajo real, no opcional.
-
-### Anti-patrones
-
-| Anti-patron | Por que es malo |
-|---|---|
-| `if (flag) { ... } else { ... }` esparcido por 30 archivos | Imposible de borrar. Usar inyeccion / strategy pattern. |
-| Flag que lleva 6 meses ON sin borrar | Deuda tecnica. Borrar el flag y simplificar. |
-| Flag para WIP que no compila | Master roto. Eso no es flag, es WIP — no debe estar en master. |
-| Flag condicional sobre tipos / esquemas DB | Migrations son irreversibles. No se "apaga" una columna. Usar branch-by-abstraction sobre la lectura/escritura, no sobre el schema. |
-| Flag con nombre del autor o del issue (`lucas-experiment`, `flag-0063`) | Sin contexto al releerlo. Nombrarlo por la feature: `kanban-stickers`. |
-
-### Comandos relacionados
-
-- `/git-branch` — crea rama desde master.
-- `/git-push` — merge --no-ff + push.
-- Para registrar / activar un flag: editar `dev/feature_flags.json` directamente y commitear con el codigo correspondiente. No hay CLI dedicada todavia.

.claude/rules/fn_doctor.md

@@ -1,89 +0,0 @@
-## fn doctor: diagnostico del registry y artefactos
-
-`fn doctor` es el entrypoint unico para auditar la salud del sistema de forma read-only. Compone funciones del registry (`functions/infra/`) y formatea su salida. No modifica nada.
-
-### Cuando usar
-
-- Despues de un deploy: confirmar que servicios siguen vivos y artefactos intactos.
-- Despues de `git pull` o `fn sync`: detectar drift entre BD y disco.
-- Antes de `fn index` masivo: confirmar que apps Go/Py siguen declarando bien sus deps.
-- Periodicamente (cron): listar funciones del registry sin consumidores para limpiar.
-- Como gate antes de crear proposals: si `fn doctor` esta verde, las metricas del bucle reactivo son fiables.
-
-### Comandos
-
-```bash
-fn doctor                  # Corre TODOS los checks (artefacts + services + sync + uses-functions + unused + cpp-apps)
-fn doctor artefacts        # Solo artefactos: git/venv/app.md/upstream
-fn doctor services         # Solo apps con tag 'service' + systemctl + puerto
-fn doctor sync             # Solo drift pc_locations BD vs disco local
-fn doctor uses-functions   # Solo audit imports reales vs uses_functions
-fn doctor unused           # Solo funciones huerfanas del registry
-fn doctor cpp-apps         # Conformidad C++ con cpp/PATTERNS.md (cfg.about/log, no app_menubar manual, no DockSpace duplicado)
-                           # + check BeginTable inline: CANDIDATE (no migrado) / MIXED (parcial) / silencio (limpio)
-
-fn doctor --json           # Salida JSON (cualquier subcomando) — para agentes/scripts
-```
-
-`fn doctor cpp-apps` produce dos secciones:
-1. Conformance (cfg.about/log, fn::run_app, menubar, DockSpace) — una fila por app imgui.
-2. BeginTable migration (issue 0081) — solo apps con `ImGui::BeginTable` inline:
-   - `CANDIDATE`: N tablas inline sin `data_table_cpp_viz` en uses_functions. Considerar migracion.
-   - `MIXED`: N tablas inline con `data_table_cpp_viz` ya declarado. Migracion parcial OK.
-   - silencio: 0 BeginTable inline (limpio o completamente migrado).
-
-### Mapeo subcomando → funcion del registry
-
-| Subcomando | Funcion |
-|---|---|
-| `artefacts` | `artefact_doctor_go_infra` |
-| `services` | `services_status_go_infra` |
-| `sync` | `pc_locations_drift_go_infra` |
-| `uses-functions` | `audit_uses_functions_go_infra` |
-| `unused` | `find_unused_functions_go_infra` |
-| `cpp-apps` (conformance) | `audit_cpp_apps_go_infra` |
-| `cpp-apps` (table migration) | `audit_cpp_table_migration_go_infra` (inline en `audit_cpp_apps.go`) |
-
-Cada subcomando es un wrapper fino. Toda la logica vive en la funcion. Si quieres usar la salida en otro programa Go, importa la funcion directamente.
-
-### Salida
-
-Texto humano por defecto (tabwriter). `--json` produce array/objeto serializable para `jq`, agentes o pipes.
-
-### Idempotente y seguro
-
-- Read-only: ningun subcomando escribe, mata procesos ni cambia estado.
-- `services` abre conexiones TCP a `127.0.0.1:<port>` con timeout 500ms — no genera trafico saliente.
-- `artefacts` ejecuta `git rev-parse @{u}` con timeout 3s por artefacto.
-
-### Acciones complementarias (NO son `fn doctor`)
-
-`fn doctor` solo diagnostica. Las acciones derivadas son verbos separados:
-
-| Si `fn doctor` reporta... | Accion |
-|---|---|
-| `directory_missing` | Marcar `pc_locations.status='missing'` o re-clonar via `/full-git-pull` |
-| `git_not_initialized` | `gitea_create_repo_bash_infra` + `ensure_repo_synced_bash_infra` |
-| `venv_broken_path` | `cd <analysis_dir> && rm -rf .venv && uv sync` |
-| `service active=inactive` | `systemctl --user start <unit>` o investigar logs |
-| `port not listening` | `port_kill_bash_infra <port>` (si zombie) y relanzar |
-| `missing_in_app_md` | Editar `app.md` y añadir el ID a `uses_functions` |
-| `unused` (funcion huerfana) | Decidir: usar, deprecar (tag), o borrar |
-| `manual_app_menubar_call` | Borrar `fn_ui::app_menubar(...)` del render — el framework ya lo dibuja |
-| `manual_DockSpaceOverViewport_*` | Borrar la llamada o setear `cfg.auto_dockspace = false` si la app gestiona docking propio |
-| `missing_cfg_about` / `missing_cfg_log` | Anadir `cfg.about = {...}` / `cfg.log = {"<name>.log", 1}` antes de `fn::run_app` |
-| `app.md_missing_*` | Regenerar via plantilla del scaffolder (`/new-cpp-app`) o anadir campos a mano |
-| cpp-apps BeginTable `CANDIDATE` | App tiene N `ImGui::BeginTable` sin migrar. Abrir rama TBD, reemplazar tablas por `data_table::render()` via `fn_table_viz`, añadir `data_table_cpp_viz` a `uses_functions` en `app.md` |
-| cpp-apps BeginTable `MIXED` | Migracion parcial en curso. Continuar wave por wave hasta que no queden BeginTable inline |
-| Backup viejo | `backup_all_bash_pipelines ~/backups/fn_registry` |
-
-### Para agentes
-
-Patron recomendado tras una accion no trivial (deploy, sync, mass edit):
-
-```bash
-fn doctor --json > /tmp/doctor.json
-# Agente parsea JSON, decide si crear proposals o avisar al humano
-```
-
-Si el agente quiere actuar sobre los hallazgos, abre proposals con `fn proposal add` referenciando los IDs afectados — NO toca artefactos directamente sin aprobacion humana.

.claude/rules/frontend_theming.md

@@ -9,19 +9,3 @@ El sistema de UI es Mantine v9. Todos los componentes de @fn_library wrappean co
 **Iconos:** Se usa `@tabler/icons-react` (el set nativo de Mantine), no lucide-react.
 
 **Layout:** Se usan los componentes de layout de Mantine: `Group`, `Stack`, `Grid`, `Flex`, `SimpleGrid`, `AppShell`, `Container`, `Box`, `Paper`.
-
-**AppShell.Navbar / AppShell.Aside (gotchas v9):**
-
-- NO override `position` via `style` (ej. `style={{ position: "relative" }}`). Mantine aplica `position: fixed` con CSS class; si lo pisas, el slot cae al flow normal y empuja el resto del layout abajo (root altura 2x).
-- Para anclar children `position: absolute` (drag handle, badge flotante), el `position: fixed` del propio slot ya actua como containing block — no necesitas relative.
-- Por defecto el navbar **empuja** el main (anade `padding-inline-start: navbar-width`). Para **overlay** (navbar tapa main):
-  ```tsx
-  <AppShell styles={{ main: { paddingInlineStart: 0 } }}>
-  ```
-  Idem `paddingInlineEnd: 0` para aside overlay.
-- Si quieres backdrop dimming + click-outside-close: usa `<Drawer position="left">` en lugar de `AppShell.Navbar`.
-- **Memoizar configs**: `header`/`navbar`/`aside`/`styles` aceptan objetos. Si el componente padre se re-renderiza cada N (tick, ws, etc.), los objetos literales se recrean y Mantine regenera el `<style>` inline. Wrap con `useMemo([deps])`:
-  ```tsx
-  const navbarCfg = useMemo(() => ({ width, breakpoint: "md", collapsed: { ... } }), [width, navOpen]);
-  <AppShell navbar={navbarCfg} ...>
-  ```

.claude/rules/function_growth_and_self_docs.md

@@ -1,115 +0,0 @@
-## Function growth + self-documenting capability
-
-Dos doctrinas hermanas. Una define **como deben ser** las funciones (auto-descubribles y lanzables sin segunda lectura). La otra define **como crece** el registry (no inflando funciones — promoviendo composiciones a pipelines).
-
-Issue 0087.
-
----
-
-### Parte A — `.md` autosuficiente (contrato OBLIGATORIO)
-
-Cuando Claude (o un humano) encuentra una funcion via FTS / fuzzy match / capability page / TOP block, el `.md` debe bastar para **lanzarla sin abrir el codigo**. Esto es lo que hace que descubrir = lanzar y elimina el coste del second lookup.
-
-**Secciones obligatorias** en cada `.md` del registry (functions + pipelines + types con uso practico):
-
-| Seccion | Contenido | Tamaño |
-|---|---|---|
-| Frontmatter | `name`, `signature`, `params` (con `desc` por param), `output`, `tags`, `uses_functions`, etc. Lo de hoy. | — |
-| `## Ejemplo` | Bloque de codigo lanzable con args **concretos**. Copiar+pegar produce ejecucion real. NO placeholders abstractos. | 3-10 lineas |
-| `## Cuando usarla` | 1-2 frases con triggers: "cuando hagas X / antes de Y / si necesitas Z". Verbos imperativos. Ayuda al fuzzy match y a Claude a saber sin leer el codigo. | 1-3 lineas |
-| `## Gotchas` | Problemas conocidos / no-go cases. Obligatoria para funciones impuras o con efectos (Windows-side, red, FS write, GPU). Omisible para funciones puras triviales. | 0-5 puntos |
-| `## Capability growth log` | Solo SI la funcion ha crecido. Una linea por version: `v1.1.0 (YYYY-MM-DD) — anade --build flag para skip build`. No se rellena en v1.0.0. | crece con el tiempo |
-
-**Anti-patrones del .md:**
-
-- Ejemplo con `<arg1>`, `<arg2>` placeholders abstractos — NO. Ejemplos con valores reales (`registry_dashboard`, `/home/lucas/...`).
-- "Cuando usarla" vacio o "ver descripcion arriba" — NO. Frase nueva con trigger explicito.
-- `notes` lleno + `## Gotchas` vacio cuando la funcion tiene efectos — mover de `notes` a `## Gotchas`.
-- Capability growth log inventado (sin que la funcion haya cambiado) — NO. Solo se rellena cuando hay version bump real.
-
-**Verificacion** (TBD: convertir a check de `fn doctor`): cada .md de `functions/`/`pipelines/` debe tener `## Ejemplo` y `## Cuando usarla`. `## Gotchas` obligatoria solo si `purity: impure`. `## Capability growth log` libre.
-
----
-
-### Parte B — Crecimiento por composicion (no por inflado)
-
-**Principio:** una funcion que hace bien UNA cosa NO necesita crecer. Anadir params "por si acaso" la hace peor (Inner Platform Effect). Lo que crece es el **registry**: pipelines nuevos que componen funciones existentes.
-
-#### Ejemplo del principio
-
-- **Hoy:** Claude para hacer una transferencia bancaria llama `bank_login` -> `bank_list_accounts` -> `bank_make_transfer`. 3 calls, 3 decisiones, 3 puntos de fallo.
-- **Manana:** pipeline `bank_transfer_oneshot(account, amount, target)` que compone las 3 internamente. 1 call, 1 decision.
-
-Misma capacidad, 3x menos pasos. **Esto es lo que multiplica la velocidad de Claude**, no anadir flags a `bank_login`.
-
-#### Como se promueve una composicion
-
-Senal detectable en `call_monitor.operations.db`: secuencia A→B(→C) con
-
-- **Mismo session_id**.
-- **Intervalo entre calls < N segundos** (default 30s).
-- **Occurrences > K** (default 5) en ventana de **D dias** (default 30).
-- **Success rate > S** (default 0.9 — falla < 10%).
-- **No existe ya un pipeline** que la cubra (validar con FTS sobre `uses_functions`).
-
-Cuando se cumple → **proposal `new_pipeline`** con evidencia (sequence_ids, session_ids, occurrence count). Humano (o `fn-orquestador` autonomo) decide promover.
-
-#### Implementacion (issue 0087 tanda A)
-
-- `call_monitor sequences --detect` subcomando: escanea `calls` table, agrupa por session+window, computa secuencias, upserta en tabla `function_sequences`.
-- Cron diario que ejecuta el detector + genera proposals automaticas.
-- Visible en Monitor tab del `registry_dashboard`: sub-tab "Promotion candidates".
-
-#### Cuando SI inflar una funcion
-
-Casos legitimos para anadir feature a una funcion existente:
-
-1. **Generalizar firma** sin romper consumidores (anadir param opcional con default sensato).
-2. **Mejor manejo de error** (mensajes mas claros, retry sensible).
-3. **Default mas inteligente** (autodetectar lo que antes era arg obligatorio).
-4. **Eliminar gotcha conocido** (fix de bug que estaba en `## Gotchas`).
-
-NO infles para casos hipoteticos. NO anadas params "por flexibilidad". Si dudas, separa la responsabilidad en una funcion nueva o un pipeline.
-
-#### Capability growth log — cuando se rellena
-
-- Se rellena **solo cuando la funcion crece** (alguno de los 4 casos arriba).
-- Cada bump de `version` -> 1 linea en `## Capability growth log` con fecha y resumen 1-frase.
-- Una funcion estable de hace 6 meses puede seguir en v1.0.0 sin log: indica madurez, no abandono.
-- Telemetria (call_monitor) decide si una funcion estable es huerfana (`calls_90d=0`) o usada-y-buena (`calls_30d>10, error_rate<0.05`). Las primeras se deprecan; las segundas se respetan.
-
----
-
-### Parte C — Output de discovery
-
-Cuando un mecanismo de discovery (fuzzy match / FRESH hook / TOP block / capability page) surfacea una funcion, el payload **minimo** es:
-
-```
-<id>  →  <signature>  →  <ejemplo de 1 linea>
-```
-
-Ejemplo concreto:
-```
-redeploy_cpp_app_windows_bash_pipelines
-  ./fn run redeploy_cpp_app_windows registry_dashboard /path/to/app [--build]
-  use: tras compilar cpp/build/windows, antes de smoke test manual
-```
-
-Si Claude necesita mas (gotchas, params completos, codigo), un `mcp__registry__fn_show <id>` adicional. Pero el primer hit ya basta para el 80% de casos.
-
----
-
-### Parte D — Relacion con otras reglas
-
-- [[registry_first]] dice CUANDO buscar/usar/delegar. Esta regla dice **COMO** debe ser la funcion para que esa busqueda valga.
-- [[ids_naming]] hace ID predictible. Esta regla hace metadata predictible.
-- [[delegation]] dice cuando spawnar fn-constructor. Esta regla es lo que fn-constructor debe producir.
-- [[capability_groups]] agrupa funciones afines. Las paginas madre de cada grupo deben respetar el mismo contrato self-doc (mejor con su propio ejemplo end-to-end por grupo).
-
-### Resumen TL;DR
-
-1. Cada `.md` autosuficiente: Ejemplo + Cuando usarla + Gotchas (si impura) + Growth log (si crecio).
-2. Las funciones que hacen bien una cosa NO necesitan crecer.
-3. El registry crece **promoviendo composiciones repetidas a pipelines**, no inflando funciones.
-4. Telemetria de `call_monitor` detecta secuencias candidatas y abre proposals automaticas.
-5. Discovery devuelve siempre: `id + signature + 1-line example`. Resto on-demand.

.claude/rules/function_tags.md

@@ -28,26 +28,3 @@ Documentar en el `app.md` del service:
 - El puerto que usa (si expone HTTP/gRPC)
 - Como lanzarlo y pararlo
 - Como comprobar que esta vivo (health check)
-
-### Bloque `service:` obligatorio (issue 0105)
-
-Toda app con `tag: service` declara el bloque `service:` en su frontmatter. El indexer lo persiste en columnas dedicadas de `apps` + tabla `service_targets`. Consumido por `services_api`/`services_monitor` (issue 0106) y por `fn doctor services-spec`.
-
-```yaml
-service:
-  port: 8484                       # null si no expone HTTP (stdio, daemon sin API)
-  health_endpoint: /api/databases  # ruta GET, 2xx/3xx = sano; null si no aplica
-  health_timeout_s: 3
-  systemd_unit: sqlite_api.service # obligatorio si runtime empieza con `systemd-`
-  systemd_scope: user              # user|system|null (docker-compose)
-  restart_policy: always           # always|on-failure|none
-  runtime: systemd-user            # systemd-user|systemd-system|docker-compose|stdio|manual
-  pc_targets:                      # >=1, pc_id de pc_locations
-    - aurgi-pc
-    - home-wsl
-  is_local_only: false             # true => no se monitoriza por SSH (siempre local)
-```
-
-Validacion: `fn doctor services-spec` (`functions/infra/audit_services_spec.go`). Hoy 11/11 services con bloque completo.
-
-**Gotcha critico:** usar `Restart=always` (no `on-failure`) en el unit systemd. Un `SIGTERM` limpio es exit success → `on-failure` NO reinicia y el service se queda muerto silenciosamente. `sqlite_api.service` cayo 20h asi el 2026-05-17.

.claude/rules/ids_naming.md

@@ -1,35 +1,3 @@
-## ids_naming — formato predictible
+IDs siguen el formato `{name}_{lang}_{domain}` (ej: `filter_slice_go_core`).
 
-IDs: `{name}_{lang}_{domain}` (ej: `filter_slice_go_core`). Predictibilidad alta -> Claude descubre por fuzzy match sin lookup. Issue 0087.
-
-### Reglas
-
-1. **snake_case**: `[a-z0-9_]+`. Nada de PascalCase, kebab-case, dot.notation.
-2. **Verbo obligatorio**: al menos un token del `name` debe ser un verbo de accion. El verbo puede ir delante (`get_user`) o detras (`user_lookup`). Ejemplos validos: `filter_slice`, `bank_login`, `metabase_get_dashboard`, `redeploy_cpp_app`. Invalidos: `slice` (sustantivo solo), `user` (sustantivo solo), `data` (sustantivo solo).
-3. **Dominio canonico**: el `domain` debe estar en la lista canonica (ver `mcp__registry__fn_list_domains`). Crear dominio nuevo solo si el bucket es claramente distinto y se anade en el mismo turno a CLAUDE.md.
-4. **Tipos en PascalCase Go**: `ResultGoCore`, `ErrorGoCore`. Aplica solo al codigo Go; el ID en el registry sigue siendo snake_case (`result_go_core`).
-
-### Verbos canonicos (allowlist)
-
-Lista no exhaustiva pero cubre la mayoria. Anadir aqui (y al validator en `apps/registry_mcp/naming.go`) cuando se introduzca un verbo nuevo recurrente.
-
-`get, set, list, find, search, show, read, load, fetch, scan, query, lookup, parse, format, encode, decode, marshal, unmarshal, serialize, deserialize, validate, check, ensure, verify, audit, diagnose, test, match, filter, map, reduce, sort, group, count, sum, aggregate, compute, calculate, score, rank, cluster, classify, detect, init, create, make, build, generate, scaffold, install, setup, configure, register, add, insert, append, prepend, update, upsert, modify, edit, patch, replace, delete, remove, clear, drop, prune, clean, copy, move, rename, sync, clone, extract, inject, import, export, send, post, put, call, dispatch, exec, run, launch, start, stop, kill, restart, redeploy, deploy, open, close, connect, disconnect, login, logout, authenticate, enable, disable, toggle, lock, unlock, propose, promote, deprecate, approve, reject, emit, render, draw, paint, serve, host, pull, push, checkout, commit, tag, merge, rebase, watch, monitor, observe, log, trace, profile, benchmark, snapshot, backup, restore, archive, compress, decompress, hash, encrypt, decrypt, sign, taskkill, recopile, vault, propose, apply, gather, collect, fold, head, tail, take, drop, slice, chunk, batch, debounce, throttle, retry, await, sleep, ping, kill, prime, warm, refresh, invalidate, reload, reset, rollback, fork, spawn, daemon, observe, plot, draw, capture, replay, recopilate`
-
-### Excepciones
-
-- **Operadores matematicos/estadisticos** ampliamente reconocidos por acronimo: `sma`, `ema`, `rsi`, `vwap`, `adx`. Validator hace allowlist explicita.
-- **Tipos** (entity_type `type`): no requieren verbo. Validator lo salta cuando `kind=type`.
-- **Components** (`kind: component`): nombre describe artefacto UI (`button_primary`, `chat_panel`). Permite forma `<noun>_<modifier>`. Validator salta el check de verbo si `kind=component`.
-
-### Validator
-
-`mcp__registry__fn_create_function` ejecuta el validator antes de escribir archivos. Rechaza con error si:
-- name no es snake_case.
-- name no contiene verbo (excepto component/type).
-- domain no esta en lista canonica.
-
-Error tipico:
-```
-naming: name "slice" lacks action verb. Add verb prefix/suffix (e.g. filter_slice, slice_window). See .claude/rules/ids_naming.md.
-naming: domain "bizops" not in canonical list (core, infra, finance, ...). Add it to CLAUDE.md and rules first.
-```
+Nombres de funciones en snake_case. Tipos en PascalCase para Go.

.claude/rules/kiss.md

@@ -1,30 +0,0 @@
-## KISS en proyectos y apps
-
-**Mantener proyectos (`projects/`) y apps (`apps/`, `projects/*/apps/`) simples**. La complejidad no solicitada es deuda — cada línea, cada dependencia y cada herramienta externa se justifican o no entran.
-
-### Reglas
-
-1. **Preferir herramientas ya presentes en el sistema o en el registry** antes que paquetes/CLI externos.
-   - ¿Lo hace `git` / `bash` / una función del registry? Úsalo.
-   - Antes de añadir una dependencia nueva, buscar en `registry.db` (FTS5) si ya existe algo similar.
-
-2. **Cuestionar cada nueva herramienta externa**. Antes de instalarla preguntar:
-   - ¿Qué problema concreto resuelve que NO podemos resolver con lo que ya tenemos?
-   - ¿El coste (instalar, mantener, aprender, conflictos con nuestro flujo) compensa el beneficio real?
-   - ¿Qué pasa si el proyecto upstream se abandona / rompe compatibilidad?
-
-3. **Sin abstracciones ni features especulativas**. No generalizar "por si acaso". Tres líneas similares son mejores que una abstracción prematura.
-
-4. **Ser consciente del flujo de trabajo actual**. Si algo funciona bien con `git` / submódulos / `fn` CLI, no lo sustituyas por una herramienta que prometa "mejorarlo" sin evidencia de mejora concreta en tu contexto.
-
-5. **Escritura de apps**: una responsabilidad clara, layout mínimo (`main.*`, `app.md`, y lo estrictamente necesario), sin config ni estructuras que no se usen hoy.
-
-### Caso aprendido (GitButler)
-
-Se probó GitButler (virtual branches) pensando en paralelizar trabajo. Resultado:
-- Bugs con submódulos (git submodule add + gitlinks) — commits vacíos o contenido cruzado.
-- Auto-commits con el texto del chat como commit message.
-- Pre-commit hook que bloquea `git commit` directo y exige otro CLI (`but`).
-- Un binario externo de 37 MB + un plugin en Claude Code + skill propio + hooks en `settings.json`.
-
-Al volver a `git` + ramas normales + `fn` CLI: cero fricción, commits limpios, submódulos funcionan. **Lección**: antes de adoptar una capa nueva, medir la fricción real actual. Si no la hay, no vale la pena añadir complejidad.

.claude/rules/llm_invocation.md

@@ -1,50 +0,0 @@
-## Invocación de LLM: SIEMPRE `ask_llm`, NUNCA `claude -p`
-
-**REGLA DURA.** Para ejecutar un modelo LLM desde cualquier código del ecosistema (scripts, heredocs, apps, pipelines, agentes), usa el grupo `claude-direct` — empezando por `ask_llm_py_core`. **NUNCA** uses `claude -p` ni lances el binario `claude` como subproceso para obtener una respuesta del modelo.
-
-### Por qué
-
-| | `claude -p` | `ask_llm` / `claude-direct` |
-|---|---|---|
-| Mecanismo | Lanza Claude Code entero (proceso `claude`) | Habla directo a `api.anthropic.com/v1/messages` |
-| Arranque | ~7-15s (carga MCP + `CLAUDE.md` ~100k tokens) | **0 — request HTTP directa** |
-| Latencia/msg | ~9-15s | **~2.5s** |
-| Coste | Alto (re-carga contexto cada vez) | Mínimo (solo tu prompt) |
-| Tools | Las de Claude Code (no controlables) | **Las que tú defines** (`run_claude_tool_loop`) |
-| Streaming | indirecto | nativo (`stream_anthropic_messages`) |
-
-`claude -p` es lento, caro y arranca todo Claude Code para una completion. `ask_llm` es la API directa: arranque 0, rápido, con tus propias tools. Usa el token OAuth que Claude Code ya guarda en `~/.claude/.credentials.json`.
-
-### Cómo (según el caso)
-
-| Caso | Usa |
-|---|---|
-| Pregunta/chat one-shot | `fn run ask_llm "..."` o `from core.ask_llm import ask_llm` |
-| Streaming de eventos crudos (text/tool_use deltas) | `stream_anthropic_messages_py_core` |
-| Agente con TUS tools (tool-use loop) | `run_claude_tool_loop_py_core` (defines `tools` + `dispatch`) |
-| Token OAuth | `load_claude_oauth_token_py_core` (automático dentro de las anteriores) |
-| Distribuir fuera del registry | `apps/llm_cli/llm.py` (versión standalone autocontenida) |
-
-```python
-import sys, os
-sys.path.insert(0, os.path.join("python", "functions"))
-from core.ask_llm import ask_llm
-respuesta = ask_llm("resume esto en 3 lineas: ...", model="claude-haiku-4-5-20251001", echo=False)
-```
-
-### Legacy
-
-`claude_stream_go_core` (lanza `claude -p --output-format stream-json`) es el **camino antiguo**. No usarlo en código nuevo — preferir las funciones `claude-direct`. Queda solo para compatibilidad de consumidores existentes.
-
-### Excepción acotada
-
-Si una tarea necesita **genuinamente las capacidades de Claude Code** (sus tools nativas, los MCP del repo, plan mode, el contexto del proyecto) y no basta con el modelo + tus propias tools via `run_claude_tool_loop`, entonces NO es una "invocación LLM" simple: documenta por qué en el código. El **default sin excepción es `ask_llm`**.
-
-### Telemetría / auditoría
-
-Un `claude -p` o un `subprocess(["claude", "-p", ...])` en código nuevo es un antipatrón auditable: sustituir por `ask_llm` / `claude-direct`. Buscar usos: `grep -rn 'claude -p' --include='*.py' --include='*.sh' --include='*.go'`.
-
-### Relación con otras reglas
-
-- [[registry_calls]] — patrones canónicos de invocación de funciones; esta regla fija el patrón para la sub-tarea "invocar un LLM".
-- [[registry_first]] — reusar antes que reescribir; `ask_llm` es la función reutilizable para LLM.

.claude/rules/playgrounds.md

@@ -1,58 +0,0 @@
-## Playgrounds: prototipos rapidos dentro de un artefacto
-
-Un **playground** es un mini-artefacto efimero que vive **dentro** de otro artefacto (analysis, app o project) y reutiliza su entorno. Sirve para probar visualmente una idea (webapp, demo, dashboard, ejercicio interactivo) antes de decidir si se promueve a app independiente.
-
-Ejemplo canonico: `projects/osint_graph/analysis/gliner_glirel_tuning/playground/` — server FastAPI + index.html + JS vendored que reutiliza el `.venv` del analisis padre para visualizar las recetas del notebook 08 con UI interactiva.
-
-### Estructura
-
-```
-<artefacto_padre>/
-  playground/                  # Un solo playground por padre (si necesitas mas, usa subdirs)
-    server.py | server.go | ...   # Punto de entrada (single-file preferido)
-    index.html                    # UI si la hay
-    static/                       # JS/CSS vendored (no node_modules ni pnpm)
-    server.log                    # Log local (gitignorable)
-```
-
-Si el playground crece a varios subdirs/modulos, ya no es playground — promover a app.
-
-### Reglas
-
-1. **Hereda el entorno del padre**. NO crea su propio `.venv`, `package.json`, ni dependencias. Si el padre es un analysis Python, usa `../.venv/bin/python3`. Si el padre es una app Go, comparte el `go.mod`.
-2. **NO se indexa**. No tiene `app.md`, no aparece en `registry.db`, no tiene entrada en `pc_locations`.
-3. **NO tiene repo propio**. Vive dentro del repo Gitea del artefacto padre y se mueve con el.
-4. **Single-file preferido**. Un `server.py` o `main.go` con todo dentro. Si hace falta partir, considera promover a app.
-5. **Vendor deps front**. JS/CSS como `.min.js` en `static/`, sin `node_modules`. Si necesitas pnpm/vite, ya no es playground.
-6. **Reutiliza funciones del registry** igual que el padre — `sys.path` al `python/functions`, importar paquetes, etc.
-7. **Ciclo de vida**: vive mientras la idea esta cruda. Una vez probada, dos caminos:
-   - **Promover a app** (extraer logica reutilizable como funciones del registry, crear `app.md`, mover a `apps/`).
-   - **Borrar** sin contemplaciones si el experimento no llevo a nada.
-
-### Cuando NO usar playground
-
-- Si necesitas correr en un VPS / tener systemd / health check → es un app + service, no playground.
-- Si la idea ya esta clara y el codigo va a sobrevivir meses → arrancar como app desde el primer dia ahorra una migracion.
-- Si necesitas operations.db, assertions, o el bucle reactivo → es app.
-- Si el padre seria un proyecto entero solo para contener el playground → probablemente sea app standalone con `tags: [prototype]`.
-
-### Relacion con `temp/`
-
-| Cuando | Donde |
-|---|---|
-| Idea suelta sin contexto, prueba de API, snippet desechable | `temp/<lo_que_sea>/` (gitignored, sin contexto) |
-| Prototipo ligado a un analysis/app/proyecto que reutiliza su entorno | `<padre>/playground/` (versionado con el padre) |
-| Codigo que sobrevive y se reutiliza en otros sitios | extraer a `functions/` |
-| Aplicacion ejecutable con identidad propia | `apps/` o `projects/<p>/apps/<a>/` |
-
-`temp/` es para cosas sin padre. Playground es para cosas con padre. Si dudas entre los dos, empieza en `temp/` y mueve a `playground/` cuando quede claro de que artefacto depende.
-
-### Lanzar un playground
-
-Sin convencion fija — depende del stack. El propio `server.py` o un README en el playground documenta como arrancarlo. Ejemplo del playground de OSINT:
-
-```bash
-cd projects/osint_graph/analysis/gliner_glirel_tuning/playground
-../.venv/bin/python3 server.py
-# http://localhost:7878
-```

.claude/rules/project_commands.md

@@ -1,52 +0,0 @@
-## Slash commands por project (namespaced)
-
-Cada `projects/<p>/` puede tener su propio `.claude/commands/*.md`. Para invocarlos desde la raiz de `fn_registry` sin que pisen los comandos globales, se exponen via **symlink namespaced** en `fn_registry/.claude/commands/<project>/`.
-
-### Patron canonico
-
-```
-projects/aurgi/.claude/commands/foo.md         # archivo real (viaja con el sub-repo del project)
-fn_registry/.claude/commands/aurgi  -> symlink -> ../../projects/aurgi/.claude/commands
-```
-
-Resultado:
-
-| cwd | Invocacion |
-|---|---|
-| `cd projects/aurgi && claude` | `/foo` (sin namespace) |
-| `cd fn_registry && claude` | `/aurgi:foo` (namespaced, no colisiona con `/foo` global) |
-
-Subdirs dentro de `.claude/commands/` se exponen como namespace en el slash command. Por eso `aurgi/foo.md` -> `/aurgi:foo`.
-
-### Como anadir un project nuevo
-
-1. `mkdir -p projects/<p>/.claude/commands/`.
-2. Crear `<comando>.md` con frontmatter `description:` + cuerpo.
-3. Symlink: `ln -sf ../../projects/<p>/.claude/commands /home/egutierrez/fn_registry/.claude/commands/<p>`.
-4. Versionar el `.claude/commands/` del project en su propio sub-repo (NO en fn_registry — projects estan gitignored).
-5. Versionar SOLO el symlink en fn_registry (`git add .claude/commands/<p>`).
-
-### Reglas
-
-- Cada project mantiene autonomia: sus commands viajan con el sub-repo y funcionan tanto en `cd projects/<p>` como desde la raiz.
-- El symlink en fn_registry da acceso global con namespace — sin colision con commands del registry.
-- NO duplicar contenido: archivo real solo en `projects/<p>/.claude/commands/`. fn_registry solo guarda el symlink.
-- Si el project se mueve/elimina, borrar el symlink en fn_registry.
-
-### Listado actual
-
-| Project | Symlink | Commands disponibles desde fn_registry |
-|---|---|---|
-| aurgi | `.claude/commands/aurgi` | `/aurgi:aumentar_task`, `/aurgi:contexto_aurgi`, `/aurgi:anadir_contexto_aurgi` |
-
-Anadir filas aqui al introducir un project nuevo con commands.
-
-### Catalogo dinamico
-
-Para listado en tiempo real (sin tener que actualizar esta tabla a mano): `/commands` escanea `.claude/commands/` recursivo y agrupa por namespace. Filtros: `/commands <substring>`, `/commands --ns <ns>`, `/commands --json`.
-
-### Gotchas
-
-- Claude Code lista los commands disponibles al inicio de sesion. Si un symlink apunta a un directorio inexistente, los commands no aparecen — verificar con `ls -L .claude/commands/<project>/`.
-- El namespace usa el nombre del subdirectorio (`aurgi/`), no del project en `projects/`. Mantenerlos iguales para evitar confusion.
-- Los commands del project se ejecutan con el cwd de la sesion actual. Un `/aurgi:aumentar_task` invocado desde `fn_registry/` corre con cwd `fn_registry/` — paths relativos en el `.md` deben asumir esto (siempre usar paths relativos al repo, ej. `projects/aurgi/vaults/...`).

.claude/rules/projects.md

@@ -1,105 +0,0 @@
-## Projects: apps, analysis y vaults bajo un tema comun
-
-Un project agrupa apps, analyses y vaults relacionados. Vive en `projects/{nombre}/` con esta estructura:
-
-```
-projects/{nombre}/
-  project.md                    # Frontmatter obligatorio (name, description, tags)
-  apps/                         # Apps del proyecto (cada una con app.md)
-    {app_name}/
-      app.md
-      ...
-  analysis/                     # Analyses del proyecto (cada uno con analysis.md)
-    {analysis_name}/
-      analysis.md
-      .venv/
-      notebooks/
-      run-jupyter-lab.sh
-      ...
-  vaults/                       # Datos del proyecto
-    vault.yaml                  # Manifest de vaults (nombre, descripcion, path, tags)
-    {vault_name} -> /abs/path   # Symlinks a directorios reales de datos
-```
-
-### Reglas
-
-- `project.md` sigue el template de `docs/templates/project.md` — campos: `name`, `description`, `tags`, `repo_url`
-- `analysis.md` sigue el template de `docs/templates/analysis.md` — `dir_path` debe apuntar a `projects/{nombre}/analysis/{tema}/`
-- `vault.yaml` lista los vaults con nombre, descripcion, path absoluto y tags
-- Los vaults reales viven fuera del repo (ej: `~/vaults/{nombre}/`) con symlinks en el proyecto
-- `fn index` escanea `projects/*/` y setea `project_id` automaticamente en apps, analyses y vaults
-
-### Cada project es su propio repo Gitea (sub-repo)
-
-Desde 2026-06-05 cada `projects/<nombre>/` es un **repo Gitea independiente** `dataforge/<nombre>` (branch `master`), igual que las apps y los analyses. El repo del project versiona **solo las docs de nivel-project** (`project.md`, `CONVENTIONS.md` y demás `.md`/`.claude/` propios del project). El contenido de los hijos NO se versiona aquí: cada `apps/<app>/` y cada `analysis/<a>/` es su propio sub-repo Gitea y queda excluido por el `.gitignore` del project:
-
-```gitignore
-apps/*/
-analysis/*/
-vaults/*
-!vaults/.gitkeep
-```
-
-- **Crear el repo del project**: `ensure_repo_synced_bash_infra projects/<nombre> dataforge <nombre> master "init: project <nombre>"` (necesita `GITEA_URL` + `GITEA_TOKEN`; el token está en `pass gitea/dataforge-git-token`). Crear el `.gitignore` de arriba ANTES, para no trackear el contenido de los sub-repos hijos.
-- **Push/pull**: `/full-git-push` y `/full-git-pull` ya lo manejan automáticamente — `discover_git_repos_bash_infra` descubre cualquier `.git` bajo `fn_registry`, incluidos los projects.
-- **`repo_url`** en `project.md` apunta al repo del project; los `repo_url` de cada app viven en su `app.md`. Así el project "referencia" sus sub-repos sin git submodules (KISS).
-- El repo padre `fn_registry` sigue ignorando `projects/*/` entero (regla `apps_subrepo.md`): nunca trackea contenido de projects.
-- Estado actual: `dataforge/web_scraping`, `dataforge/fn_monitoring`, `dataforge/message_bus`.
-- Apps y analyses sueltos (sin proyecto) siguen en `apps/` y `analysis/` en la raiz
-
-### Raiz vs proyecto
-
-| Ubicacion | Para que |
-|-----------|---------|
-| `apps/` | Apps independientes que no pertenecen a ningun proyecto |
-| `analysis/` | Analyses independientes |
-| `projects/{nombre}/apps/` | Apps de un proyecto — `project_id` se setea automaticamente |
-| `projects/{nombre}/analysis/` | Analyses de un proyecto — `project_id` se setea automaticamente |
-
-### Crear un proyecto nuevo
-
-```bash
-# 1. Crear estructura
-mkdir -p projects/{nombre}/{apps,analysis,vaults}
-
-# 2. Crear project.md con frontmatter
-fn add -k project  # genera template
-
-# 3. Crear vault (datos fuera del repo, symlink dentro)
-mkdir -p ~/vaults/{vault_name}/{raw,processed,exports}
-ln -s ~/vaults/{vault_name} projects/{nombre}/vaults/{vault_name}
-# Crear vault.yaml con la entrada
-
-# 4. Crear analysis dentro del proyecto (un solo comando; ya indexa)
-fn run init_jupyter_analysis --project {nombre} {nombre_analysis} --desc "..." [paquetes...]
-
-# 5. Verificar
-fn show {nombre}  # verifica el project y sus componentes
-
-# NUNCA: crear el analisis en analysis/ y luego mv al proyecto.
-# Al mover se rompe el .venv (paths hardcodeados en activate).
-# Si ya te paso: cd projects/{nombre}/analysis/{tema} && rm -rf .venv && uv sync
-```
-
-### Consultas utiles
-
-```sql
--- Listar proyectos
-SELECT id, description FROM projects;
-
--- Analysis de un proyecto
-SELECT id, name, dir_path FROM analysis WHERE project_id = 'app_turismo';
-
--- Vaults de un proyecto
-SELECT id, name, path, symlink FROM vaults WHERE project_id = 'app_turismo';
-
--- Apps de un proyecto
-SELECT id, name, dir_path FROM apps WHERE project_id = 'app_turismo';
-
--- Todo lo que pertenece a un proyecto
-SELECT 'analysis' as tipo, id, name FROM analysis WHERE project_id = ?
-UNION ALL
-SELECT 'vault', id, name FROM vaults WHERE project_id = ?
-UNION ALL
-SELECT 'app', id, name FROM apps WHERE project_id = ?;
-```

.claude/rules/registry_calls.md

@@ -1,147 +0,0 @@
-## Como invocar funciones del registry — patrones canonicos
-
-Toda invocacion del agente al registry sigue uno de **tres patrones**. Cualquier otro patron es antipatron auditable. Las invocaciones se loguean en `projects/fn_monitoring/apps/call_monitor/operations.db` (issue 0085) para alimentar el bucle reactivo.
-
-### Patrones canonicos
-
-| Caso | Patron | Cuando |
-|---|---|---|
-| **Inspeccionar** (buscar, leer codigo, ver dependencias, listar dominios, leer proposals) | `mcp__registry__fn_search` / `fn_show` / `fn_code` / `fn_uses` / `fn_list_domains` / `fn_proposal` | SIEMPRE para descubrimiento, lectura de codigo, exploracion. |
-| **Ejecutar** UNA funcion/pipeline con sus args | `mcp__registry__fn_run <id> [args]` (preferido) o `./fn run <id> [args]` (fallback CLI) | ID conocido + args planos. Despacho automatico por lenguaje. |
-| **Componer** ad-hoc multi-funcion con logica intermedia | Heredoc `python/.venv/bin/python3 - <<'PYEOF' ... PYEOF` IMPORTANDO funciones del registry | Solo si hay loops/conditionals/dispatch entre N funciones. Las funciones del registry **se importan**, no se reescriben. |
-
-### Antipatrones prohibidos (audit-targeted)
-
-| Patron | Razon | Sustituir por |
-|---|---|---|
-| `sqlite3 registry.db "SELECT ..."` para buscar funciones/tipos | Salta MCP, FTS5 gotchas, sin trazabilidad | `mcp__registry__fn_search` |
-| `sqlite3 registry.db "SELECT ... FROM proposals"` | Mismo problema | `mcp__registry__fn_proposal` |
-| `python -c "import metabase; dir(metabase)"` para descubrir helpers | Fuente de verdad = registry, no `__init__.py` | `mcp__registry__fn_search "metabase"` + `mcp__registry__fn_show <id>` |
-| Heredoc que reescribe logica que ya existe como funcion del registry | Reinvento + perdida de capitalizacion | Buscar primero; si falta, delegar a `fn-constructor` (no escribir inline) |
-| `client._http.request(...)` saltando wrapper del registry | Salta validacion del wrapper y telemetria | Usar wrapper; si firma incompleta, `fn proposal add --kind improve_function` |
-| Scripts en `temp/` para composiciones que se repiten >2 veces | Codigo perdido + sin monitoreo | Pipeline en `python/functions/pipelines/` o `bash/functions/pipelines/` |
-| `from <pkg> import *` en heredoc | Imposible identificar funciones usadas | Imports explicitos `from <domain> import <name1>, <name2>` |
-
-### Excepciones autorizadas para `sqlite3` directo
-
-Casos donde el MCP no aplica y `sqlite3 registry.db` es legitimo:
-
-- Introspeccion de schema: `.schema`, `.tables`, `PRAGMA table_info(...)`, `PRAGMA index_list(...)`.
-- Agregaciones: `COUNT(*)`, `GROUP BY`, `SUM(...)`, `AVG(...)`.
-- JOINs custom entre tablas que el MCP no expone (`functions JOIN unit_tests ON ...`).
-- Columnas que el MCP no devuelve (rare; preferir proponer ampliacion del MCP).
-
-El hook `PreToolUse` (`.claude/scripts/hook_registry_mcp.sh`) ya deja pasar estas excepciones y solo avisa cuando ve `sqlite3 registry.db "SELECT ..."` plano.
-
-### Excepcion: hooks e infraestructura de telemetria (issue 0087)
-
-Los **hooks** (`PreToolUse`, `PostToolUse`, `UserPromptSubmit`, etc.) y los **binarios de infraestructura** que sirven al agente (`fn_match`, `fn doctor`, `call_monitor`) **pueden leer `registry.db` directo** via `sqlite3` o `database/sql` con conexion read-only. NO estan sujetos a la regla MCP-first porque:
-
-- No son acciones del agente — son inspeccion automatizada del entorno.
-- El MCP requiere tool invocation por Claude; un hook no puede invocar tools.
-- Latencia objetivo (50-200ms) incompatible con round-trip MCP.
-
-**Restricciones:**
-- SOLO lectura. Conexion debe abrirse con `?mode=ro` o `?_query_only=1`.
-- NUNCA escritura a `registry.db` desde hooks.
-- Si un hook necesita escribir (cache, telemetria propia), usa su propia DB (`operations.db` del app de hooks, o `~/.fn_hooks/cache.db`).
-
-Esta excepcion es **explicita y acotada** — no aplica al agente, que sigue regido por la regla MCP-first.
-
-### Verificacion previa — `fn doctor`
-
-Antes de empezar trabajo no trivial sobre el registry, ejecutar `fn doctor` para confirmar que el ecosistema esta sano:
-
-- Artefactos OK (sin `git_not_initialized`, `venv_broken_path`, etc.).
-- Services activos cuando se necesiten (`sqlite_api`, `registry_api`, `registry_mcp`).
-- Sin drift `pc_locations` vs disco.
-- Sin drift `uses_functions` vs imports reales.
-
-Si `fn doctor` reporta `service inactive` para `registry_mcp.service`, el MCP estara siendo invocado en modo stdio por Claude Code (normal); el systemd unit solo aplica al modo HTTP. Si el binario no responde, rebuild: `cd apps/registry_mcp && CGO_ENABLED=1 go build -tags fts5 -o registry_mcp .`.
-
-### Tools MCP disponibles
-
-| Tool | Lectura/escritura | Gating |
-|---|---|---|
-| `fn_search` | read | siempre on |
-| `fn_show` | read | siempre on |
-| `fn_code` | read | siempre on |
-| `fn_uses` | read | siempre on |
-| `fn_list_domains` | read | siempre on |
-| `fn_proposal` | read | siempre on |
-| `fn_doctor` | read | siempre on |
-| `fn_run` | execute (mutating side-effects) | requiere `--enable-run` |
-| `fn_create_function` | write | requiere `--enable-write` |
-
-### Heredoc Python — convenciones obligatorias
-
-Cuando el caso 3 (composicion) sea inevitable:
-
-1. **Imports explicitos** desde paquetes del registry. Nunca `import *`.
-2. **No reescribir** la firma de una funcion del registry — importarla.
-3. **Args via env vars o stdin JSON**, nunca interpolacion shell directa (inyeccion).
-4. **Output a stdout JSON** cuando vaya a ser consumido por el siguiente paso.
-5. **Si el heredoc supera ~30 lineas**, extraer a `python/functions/pipelines/`. El monitor avisara automaticamente cuando un patron similar se repita >5 veces.
-
-### Trazabilidad — bucle reactivo
-
-Cada evento alimenta a `call_monitor.db` (event-log append-only) y se rollupea en una vista `function_stats` con contadores por funcion del registry. Tablas event-log:
-
-| Tabla | Captura |
-|---|---|
-| `calls` | Cada invocacion (heredoc/mcp/fn_run): function_id, tool_used, duration_ms, success, error_class, args_hash |
-| `code_writes` | Cada Edit/Write sobre archivo del registry: function_id, session_id, lines_added/removed |
-| `test_runs` | Cada `go test`/`pytest` que toca codigo del registry: function_id, test_id, passed, duration_ms |
-| `e2e_runs_fn` | Cada check `e2e_checks` de app que usa la funcion: function_id, app_id, check_id, passed |
-| `violations` | Antipatron detectado: rule_id, session_id, command_snippet, severity |
-| `patterns` | Heredocs clusterizados: pattern_hash, session_ids[], occurrences, representative_snippet |
-| `sessions` | session_id, cwd, started_at, ended_at, health_score, mcp_ratio |
-
-Vista agregada `function_stats` por `function_id`:
-
-- **Uso:** `calls_total`, `calls_24h/7d/30d/90d`, `last_used_at`
-- **Errores:** `errors_total`, `error_rate`, `last_error_class`, `last_error_ts`
-- **Performance:** `mean_duration_ms`, `p95_duration_ms`
-- **Codigo:** `writes_count`, `last_write_at`
-- **Tests:** `tests_total`, `tests_failed`, `test_fail_rate`, `last_test_failed_at`
-- **E2E:** `e2e_total`, `e2e_failed`, `e2e_fail_rate`, `consumer_apps_count`
-- **Salud:** `violations_caused`
-
-Assertions derivadas → proposals automaticas:
-
-| Regla | Threshold | Proposal |
-|---|---|---|
-| Huerfana absoluta | `calls_90d=0 AND writes_count=0` | `deprecate_function` |
-| Bug prioritario | `error_rate>0.1 AND calls_7d>5` | `improve_function` (bug) |
-| Regresion performance | `p95_24h > 1.5 * p95_30d` | `improve_function` (perf) |
-| Test flaky | `test_fail_rate>0.1 AND tests_total>10` | `improve_function` (flaky) |
-| Wrapper saltado | `violations_caused>3` | `improve_function` (API gap) |
-| Patron inline sin funcion | `patterns.occurrences>5 AND no match FTS` | `new_function` con snippet |
-| Blast radius alto | `e2e_fail_rate>0 AND consumer_apps_count>=3` | `improve_function` (critical) |
-
-Datos sensibles: solo `args_hash`, NUNCA valores concretos. Snippets de error redactados via allowlist.
-
-### Capas de monitorizacion (issue 0085)
-
-Cobertura por capa, no todas activas a la vez:
-
-| # | Capa | Activacion | Cobertura |
-|---|---|---|---|
-| 1 | Hook PostToolUse Bash | siempre (settings.local.json) | mcp, fn_cli_run, edit_registry, violations |
-| 2 | Wrapper Python `registry_telemetry` | `FN_TELEMETRY=1` env var | heredocs + notebooks Jupyter |
-| 3 | Wrapper Bash `telemetry_prelude.sh` | `source` explicito o `FN_TELEMETRY=1` | heredoc bash + apps bash |
-| 4 | Interceptor en `fn run` | siempre (binario Go) | duration/error real de invocacion CLI |
-| 5 | `fn doctor copied-code` | comando manual / cron | drift estatico: codigo copiado en apps |
-| 6 | `function_versions` + snapshot | poblado por `fn index` + edit-hook | historial de versiones |
-| 7-8 | Build-tag Go / macro C++ | opt-in por app | runtime de app (futuro) |
-
-**Boundary:** monitorizamos al **agente** y a **invocaciones canonicas**. Runtime de apps Go/C++ compiladas queda fuera. Compensar con tests + `e2e_checks` (issue 0068).
-
-### Que NO se monitoriza
-
-- Funcion Go/C++ llamada internamente por app ya compilada.
-- Funcion ejecutada por systemd timer / cron / dag_engine **step `command:`** (no `function:`) sin pasar por `fn run`. Nota: dag_engine steps con `function:` SI quedan trazados — el executor invoca `fn run <id>` y guarda `function_id` en `dag_step_results`.
-- Sub-agente (`Agent` tool) — sus tools no propagan a hook del padre.
-- Service de produccion recibiendo HTTP.
-
-**Implicacion:** una funcion con `calls_90d=0` puede ser huerfana real O usada en runtime invisible. Antes de proponer `deprecate_function`, cruzar con `consumer_apps_count > 0` (e2e) o con `fn doctor uses-functions` (declaraciones estaticas).

.claude/rules/registry_first.md

@@ -1,50 +0,0 @@
-## Registry-first: reutilizar antes que escribir, delegar antes que escribir inline
-
-**OBLIGATORIO para todos los artefactos** (apps, analyses, projects, playgrounds, services). El registry existe para que las apps se compongan a partir de funciones probadas. No respetar esto convierte cada app en una isla con codigo duplicado y bugs unicos.
-
-### Flujo obligatorio antes de escribir codigo en un artefacto
-
-1. **Consultar registry.db con FTS5** para encontrar funciones existentes que cubran el caso. No es opcional. Buscar por `name`, `description`, `tags`, `signature`, `code` y `params_schema`. Probar varios sinonimos (`http`, `serve`, `router`; `id`, `uuid`, `random_hex`; etc.).
-
-2. **Reutilizar lo que existe**. Importar la funcion del registry y declararla en `uses_functions` del `app.md`. NO reescribir logica inline cuando ya hay una funcion.
-
-3. **Si falta una pieza reutilizable → delegar a `fn-constructor`** (subagent_type `fn-constructor`). NO escribir la funcion inline en el artefacto. El agente construye la funcion en su sitio (`functions/{domain}/`, `python/functions/{domain}/`, etc.) con `.go/.py/.sh/.ts` + `.md` correctos, tests, y respetando las reglas de pureza/firma.
-
-4. **Solo despues** se escribe el codigo del artefacto, que orquesta funciones del registry y aporta unicamente la logica especifica del dominio (CRUD de tablas concretas, layout de UI, flujo de la app).
-
-### Que va al registry vs que va al artefacto
-
-| Tipo de codigo | Donde |
-|---|---|
-| Logica reutilizable, primitiva, generica (parser, helper http, abrir SQLite, generar IDs, formatear timestamps con politica fija, middleware, etc.) | `functions/{domain}/` — delegar a `fn-constructor` si no existe |
-| Composicion de varias funciones del registry para un flujo concreto | `pipelines` (registry) o codigo del artefacto segun reusabilidad |
-| Schema SQL especifico del artefacto | Migraciones del artefacto |
-| Handlers HTTP que solo hacen sentido para este artefacto (ej. `/api/board` de un kanban) | Codigo del artefacto, pero usando `http_json_response_go_infra`, `http_parse_body_go_infra`, etc. del registry |
-| Layout/components especificos de la UI del artefacto | Codigo del artefacto, pero consumiendo componentes de `frontend/functions/ui/` (`@fn_library`) |
-
-Regla practica: **si dos artefactos ya hacen o haran lo mismo, es funcion del registry**. One-liners idiomaticos de la stdlib (`time.Now().UTC().Format(...)`) NO necesitan ser registry — se ven en cualquier sitio. Pero un patron como "abrir SQLite con WAL + foreign keys + ping" SI (y por eso existe `sqlite_open_go_infra`).
-
-### Cuando delegar a `fn-constructor`
-
-Delegar SIEMPRE que se necesite una funcion reutilizable que no existe. El prompt del subagente debe incluir:
-- Lenguaje, dominio, nombre propuesto.
-- Firma esperada (params + return).
-- Pureza (`pure` o `impure`).
-- Una breve descripcion del proposito y del comportamiento.
-- Si hay funciones similares en el registry, listarlas para evitar duplicados.
-
-El agente construye la funcion siguiendo las reglas del registry (`purity.md`, `ids_naming.md`, `types_in_signatures.md`, etc.) y deja `fn index` listo para ejecutar.
-
-### Auditoria
-
-Despues de implementar el artefacto, verificar que `uses_functions` del `app.md` (o equivalente) declara TODAS las funciones del registry consumidas. Esto se puede cruzar con los `import` reales del codigo:
-
-```bash
-# Para Go:
-grep -rh '"fn-registry/functions/' apps/<app>/ | sort -u
-# Cada paquete importado tiene que tener al menos una funcion declarada en uses_functions.
-```
-
-### Por que esta regla
-
-Sin esta regla cada app reinventa: helpers SQLite, middleware HTTP, generacion de IDs, parsers, validadores, formateo de fechas. El registry pierde su razon de ser. Con esta regla, una funcion bien hecha se reutiliza en N apps; un bug se arregla una vez; la velocidad de cada app nueva crece a medida que el registry crece.

.claude/rules/uses_functions.md

@@ -1,35 +0,0 @@
-## uses_functions
-
-Cuando un .cpp llama a otra funcion del registry, el `.md` del CONSUMIDOR
-debe anadir la dependencia a `uses_functions`. El indexer NO lo deduce
-automaticamente para C++ (parser no trivial).
-
-Como auditar (funciones huerfanas):
-  sqlite3 registry.db "SELECT id FROM functions WHERE lang='cpp' AND uses_functions='[]';"
-
-Como auditar (drift entre `CMakeLists.txt` y `app.md`):
-- Cruzar los `${CMAKE_SOURCE_DIR}/functions/<dom>/<name>.cpp` listados en el
-  `CMakeLists.txt` con el `uses_functions` del `app.md`. Cada `.cpp` linkado
-  debe aparecer como `<name>_cpp_<dom>` en el `.md`. Excepciones: ver mas abajo.
-
-Convencion:
-- **Framework code** (`cpp/framework/app_base.cpp`) — no esta indexado.
-- **Funciones bundled en `fn_framework`** — son funciones del registry cuyo
-  `.cpp` se compila dentro del static lib `fn_framework` (lista en
-  `cpp/CMakeLists.txt`, target `add_library(fn_framework STATIC ...)`):
-  `tokens`, `icon_font`, `app_settings`, `app_about`, `fps_overlay`,
-  `panel_menu`, `app_menubar`, `layouts_menu`, `logger`, `log_window`,
-  `gl_loader`, `layout_storage`, `selectable_text`. Las apps las usan
-  transitivamente (incluyen `core/logger.h`, llaman `fn_log::log_info`),
-  pero NO listan estos `.cpp` en su `CMakeLists.txt` (multiple-definition)
-  ni los declaran en `uses_functions` del `app.md`. Excepcion: si una app
-  toca una API que no este en fn_framework (raro), declara la dep.
-- **TU adicional de un parent function** (ej. `graph_labels_select.cpp` que
-  va con `graph_labels.cpp`) — desde 2026-05-04 se registra como entrada
-  propia con su `.md` (ver ADR 0003). El parent declara la nueva entrada
-  en su `uses_functions`. Las apps que enlazan ambos `.cpp` listan ambas
-  IDs en `uses_functions` del `app.md`.
-- **Apps** (`apps/`, `cpp/apps/`, `projects/*/apps/`) son leaves del grafo:
-  declaran `uses_functions` en `app.md` pero ninguna funcion del registry
-  las cita.
-- DEMO_ONLY en `primitives_gallery` se etiqueta `notes: scaffolding/demo`.

.claude/scripts/append_fn_to_memory.sh

@@ -1,53 +0,0 @@
-#!/usr/bin/env bash
-# Append a one-liner [[fn_id]] — purpose to MEMORY.md after fn-constructor
-# creates a new registry function. Idempotent: skips if id already present.
-# Used by /fn_claude step 5b (issue 0087, pieza 6).
-#
-# Usage: append_fn_to_memory.sh <fn_id> "<one-line purpose>"
-
-set -euo pipefail
-
-FN_ID="${1:-}"
-PURPOSE="${2:-}"
-
-if [ -z "$FN_ID" ] || [ -z "$PURPOSE" ]; then
-    echo "usage: append_fn_to_memory.sh <fn_id> <purpose>" >&2
-    exit 2
-fi
-
-MEM_DIR="${CLAUDE_MEMORY_DIR:-/home/lucas/.claude/projects/-home-lucas-fn-registry/memory}"
-MEM_FILE="$MEM_DIR/MEMORY.md"
-
-[ -d "$MEM_DIR" ] || { echo "memory dir missing: $MEM_DIR" >&2; exit 1; }
-[ -f "$MEM_FILE" ] || { echo "MEMORY.md missing: $MEM_FILE" >&2; exit 1; }
-
-# Per-function reference file slug
-SLUG="reference_fn_${FN_ID}.md"
-REF_FILE="$MEM_DIR/$SLUG"
-
-# Idempotency: if already linked in MEMORY.md, exit 0
-if grep -qF "[fn-$FN_ID]" "$MEM_FILE" 2>/dev/null; then
-    echo "already in MEMORY.md: $FN_ID"
-    exit 0
-fi
-
-# 1. Create reference memory file
-cat > "$REF_FILE" <<EOF
----
-name: fn-$FN_ID
-description: Registry function $FN_ID — $PURPOSE
-metadata:
-  type: reference
----
-
-Registry function: \`$FN_ID\`
-
-$PURPOSE
-
-Invoke via \`./fn run $FN_ID [args]\` or \`mcp__registry__fn_run id="$FN_ID"\`. Inspect with \`mcp__registry__fn_show id="$FN_ID"\` / \`mcp__registry__fn_code id="$FN_ID"\`.
-EOF
-
-# 2. Append index line to MEMORY.md
-printf -- '- [%s](%s) — %s\n' "fn-$FN_ID" "$SLUG" "$PURPOSE" >> "$MEM_FILE"
-
-echo "appended: $FN_ID -> $MEM_FILE"

.claude/scripts/extract_design_bundle.py

@@ -1,159 +0,0 @@
-#!/usr/bin/env python3
-"""
-Extract Claude Design "standalone" HTML exports.
-
-Claude Design packs the whole React app as base64+gzip blobs inside
-<script type="__bundler/manifest"> tags. This script decompresses them
-and writes each asset (JSX, CSS, fonts) to a target directory.
-
-Usage:
-    python3 extract_design_bundle.py <path/to/export.html> <output_dir>
-
-The output dir will contain:
-    data.jsx              (if detected by header comment)
-    fn_library_emu.jsx    (lib emulation)
-    charts_emu.jsx        (charts emulation)
-    app.jsx               (main tree)
-    <uuid>.<ext>          (anything else — fonts, unknown js)
-    manifest.json         (summary of all assets: uuid, mime, bytes, filename)
-
-JSX files are named heuristically from their leading comment. If names
-cannot be inferred from headers, they keep their uuid prefix.
-"""
-from __future__ import annotations
-
-import base64
-import gzip
-import json
-import pathlib
-import re
-import sys
-
-
-MIME_TO_EXT = {
-    "text/javascript": "js",
-    "application/javascript": "js",
-    "text/babel": "jsx",
-    "application/json": "json",
-    "text/css": "css",
-    "image/svg+xml": "svg",
-    "font/woff2": "woff2",
-    "font/woff": "woff",
-    "text/html": "html",
-}
-
-# Order matters: first matching hint wins. Put MORE SPECIFIC patterns first.
-HEADER_HINTS = [
-    ("charts_emu.jsx",     [r"Emulaci(ó|o)n de @fn_library/\{", r"LineChart, AreaChart, BarChart"]),
-    ("fn_library_emu.jsx", [r"Emulaci(ó|o)n visual de @fn_library"]),
-    ("data.jsx",           [r"mock data \(determinista\)", r"window\.\w+Data\s*="]),
-    ("app.jsx",            [r"ReactDOM\.createRoot", r"arbol principal", r"function App\s*\("]),
-]
-
-
-def pick_name(content: str, used_names: set[str]) -> str | None:
-    head = content[:2000]
-    for name, patterns in HEADER_HINTS:
-        if name in used_names:
-            continue
-        if any(re.search(p, head, re.IGNORECASE) for p in patterns):
-            return name
-    return None
-
-
-def grab_script(html: str, kind: str) -> str | None:
-    m = re.search(
-        r'<script type="__bundler/' + kind + r'">\s*(.*?)\s*</script>',
-        html, re.DOTALL,
-    )
-    return m.group(1) if m else None
-
-
-def extract(html_path: pathlib.Path, out_dir: pathlib.Path) -> dict:
-    html = html_path.read_text(encoding="utf-8")
-
-    manifest_raw = grab_script(html, "manifest")
-    if not manifest_raw:
-        raise SystemExit(f"No <script type='__bundler/manifest'> found in {html_path}")
-    manifest = json.loads(manifest_raw)
-
-    ext_raw = grab_script(html, "ext_resources")
-    ext_resources = json.loads(ext_raw) if ext_raw else []
-    id_map = {e["uuid"]: e.get("id", e["uuid"]) for e in ext_resources}
-
-    out_dir.mkdir(parents=True, exist_ok=True)
-
-    summary = []
-    used_names: set[str] = set()
-
-    # First pass: decode all assets and collect jsx blobs (so we can name them by header hint)
-    decoded: list[tuple[str, str, bytes]] = []  # (uuid, mime, bytes)
-    for uuid, entry in manifest.items():
-        raw = base64.b64decode(entry["data"])
-        if entry.get("compressed"):
-            raw = gzip.decompress(raw)
-        decoded.append((uuid, entry.get("mime", "application/octet-stream"), raw))
-
-    # Second pass: write files with heuristic names for known jsx
-    for uuid, mime, raw in decoded:
-        ext = MIME_TO_EXT.get(mime, "bin")
-        filename = None
-
-        # Heuristic for JSX / JS that represents the app
-        if ext in ("jsx", "js"):
-            try:
-                text = raw.decode("utf-8", errors="replace")
-                name = pick_name(text, used_names)
-                if name:
-                    filename = name
-                    used_names.add(name)
-            except Exception:
-                pass
-
-        if not filename:
-            # Fall back to ext_resources id if present, or uuid
-            base = id_map.get(uuid, uuid)
-            safe = re.sub(r"[^A-Za-z0-9._-]", "_", base)[:80]
-            filename = f"{safe}.{ext}"
-
-        path = out_dir / filename
-        # Avoid collisions
-        i = 2
-        while path.exists():
-            stem = path.stem
-            path = out_dir / f"{stem}_{i}.{ext}"
-            i += 1
-        path.write_bytes(raw)
-        summary.append({
-            "uuid": uuid,
-            "mime": mime,
-            "bytes": len(raw),
-            "filename": path.name,
-        })
-
-    (out_dir / "manifest.json").write_text(
-        json.dumps({"source": str(html_path), "assets": summary}, indent=2),
-        encoding="utf-8",
-    )
-    return {"assets": summary, "out": str(out_dir)}
-
-
-def main():
-    if len(sys.argv) < 3:
-        print(__doc__)
-        sys.exit(2)
-    html = pathlib.Path(sys.argv[1])
-    out = pathlib.Path(sys.argv[2])
-    if not html.exists():
-        sys.exit(f"Input not found: {html}")
-    result = extract(html, out)
-    print(f"✓ Extracted {len(result['assets'])} assets to {result['out']}")
-    print(f"  Manifest: {out}/manifest.json")
-    print()
-    # Short preview per asset
-    for a in result["assets"]:
-        print(f"  {a['mime']:28s} {a['bytes']:>8} B  {a['filename']}")
-
-
-if __name__ == "__main__":
-    main()

.claude/scripts/hook_call_monitor.sh

@@ -1,243 +0,0 @@
-#!/usr/bin/env bash
-# PostToolUse hook: registra cada invocacion del agente en
-# projects/fn_monitoring/apps/call_monitor/operations.db (issue 0085b).
-#
-# Identifica tool, extrae function_id cuando es posible, clasifica el patron
-# (mcp_*, fn_cli_run, heredoc_py, sqlite_direct, edit_registry, ...) y
-# detecta antipatrones para registrar violations.
-#
-# NUNCA bloquea la herramienta. Falla silenciosamente si la BD no esta lista.
-# Solo guarda args_hash, jamas valores concretos.
-
-set -euo pipefail
-
-# ---- Resolve registry root (walks up from cwd looking for registry.db) ----
-resolve_root() {
-    local d="${PWD}"
-    while [ "$d" != "/" ]; do
-        if [ -f "$d/registry.db" ]; then
-            printf '%s' "$d"
-            return 0
-        fi
-        d=$(dirname "$d")
-    done
-    return 1
-}
-
-ROOT=$(resolve_root) || exit 0
-DB="$ROOT/projects/fn_monitoring/apps/call_monitor/operations.db"
-
-# Si la BD aun no existe, el hook no hace nada (esperando init).
-[ -f "$DB" ] || exit 0
-
-# ---- Read stdin JSON ----
-INPUT=$(cat)
-if [ -z "$INPUT" ]; then exit 0; fi
-
-# Required jq presence
-command -v jq >/dev/null 2>&1 || exit 0
-command -v sqlite3 >/dev/null 2>&1 || exit 0
-
-TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // ""')
-SESSION_ID=$(printf '%s' "$INPUT" | jq -r '.session_id // ""')
-TS=$(date -u +%s)
-
-# Tool response success/error
-SUCCESS=1
-ERROR_CLASS=""
-ERROR_SNIPPET=""
-RESP_IS_ERROR=$(printf '%s' "$INPUT" | jq -r 'if (.tool_response | type) == "object" then (.tool_response.is_error // false) else false end')
-if [ "$RESP_IS_ERROR" = "true" ]; then
-    SUCCESS=0
-    ERROR_SNIPPET=$(printf '%s' "$INPUT" | jq -r 'if (.tool_response | type) == "object" then (.tool_response.error // .tool_response.content // "") else "" end' | head -c 240 | tr '\n' ' ')
-fi
-
-# args_hash: sha256 truncado del tool_input (sin valores)
-ARGS_HASH=$(printf '%s' "$INPUT" | jq -c '.tool_input // {}' | sha256sum | cut -c1-16)
-
-# Helpers SQL
-sql_escape() { printf '%s' "$1" | sed "s/'/''/g"; }
-
-insert_call() {
-    local fn_id="$1" tool_used="$2" duration_ms="${3:-0}" snippet="${4:-}"
-    local fn_esc tu_esc ec_esc es_esc sid_esc ah_esc snip_esc
-    # Politica issue 0087: command_snippet solo se rellena cuando function_id
-    # esta vacio. Si la call golpea una funcion del registry, su ID y
-    # tool_used bastan; no duplicamos el comando.
-    if [ -n "$fn_id" ]; then snippet=""; fi
-    # Redact common secrets antes de persistir
-    snippet=$(printf '%s' "$snippet" \
-        | sed -E 's/(password|token|secret|api[_-]?key|bearer)([[:space:]]*[=:][[:space:]]*)[^[:space:]]+/\1\2<REDACTED>/Ig' \
-        | head -c 200)
-    fn_esc=$(sql_escape "$fn_id")
-    tu_esc=$(sql_escape "$tool_used")
-    ec_esc=$(sql_escape "$ERROR_CLASS")
-    es_esc=$(sql_escape "$ERROR_SNIPPET")
-    sid_esc=$(sql_escape "$SESSION_ID")
-    ah_esc=$(sql_escape "$ARGS_HASH")
-    snip_esc=$(sql_escape "$snippet")
-    sqlite3 "$DB" "INSERT INTO calls (session_id, function_id, tool_used, args_hash, duration_ms, success, error_class, error_snippet, command_snippet, ts) VALUES ('$sid_esc','$fn_esc','$tu_esc','$ah_esc',$duration_ms,$SUCCESS,'$ec_esc','$es_esc','$snip_esc',$TS);" 2>/dev/null || true
-}
-
-insert_code_write() {
-    local fn_id="$1" file_path="$2" added="${3:-0}" removed="${4:-0}"
-    local fn_esc fp_esc sid_esc
-    fn_esc=$(sql_escape "$fn_id")
-    fp_esc=$(sql_escape "$file_path")
-    sid_esc=$(sql_escape "$SESSION_ID")
-    sqlite3 "$DB" "INSERT INTO code_writes (session_id, function_id, file_path, lines_added, lines_removed, ts) VALUES ('$sid_esc','$fn_esc','$fp_esc',$added,$removed,$TS);" 2>/dev/null || true
-}
-
-# Snapshot a function version row when an edit lands on a registry file.
-# Uses sha256 of file bytes as content_hash (separate namespace from index source).
-insert_edit_version() {
-    local fn_id="$1" abs_path="$2"
-    [ -f "$abs_path" ] || return 0
-    command -v sha256sum >/dev/null 2>&1 || return 0
-    local hash
-    hash=$(sha256sum "$abs_path" 2>/dev/null | awk '{print $1}')
-    [ -z "$hash" ] && return 0
-    local fn_esc h_esc
-    fn_esc=$(sql_escape "$fn_id")
-    h_esc=$(sql_escape "$hash")
-    sqlite3 "$DB" "INSERT OR IGNORE INTO function_versions (function_id, content_hash, version, snapped_at, source, lines_added, lines_removed) VALUES ('$fn_esc','$h_esc','',$TS,'edit_hook',0,0);" 2>/dev/null || true
-}
-
-insert_violation() {
-    local rule_id="$1" fn_id="$2" snippet="$3" severity="${4:-warning}"
-    local r_esc fn_esc sn_esc sev_esc sid_esc
-    r_esc=$(sql_escape "$rule_id")
-    fn_esc=$(sql_escape "$fn_id")
-    sn_esc=$(sql_escape "$(printf '%s' "$snippet" | head -c 240 | tr '\n' ' ')")
-    sev_esc=$(sql_escape "$severity")
-    sid_esc=$(sql_escape "$SESSION_ID")
-    sqlite3 "$DB" "INSERT INTO violations (session_id, rule_id, function_id, command_snippet, severity, ts) VALUES ('$sid_esc','$r_esc','$fn_esc','$sn_esc','$sev_esc',$TS);" 2>/dev/null || true
-}
-
-# ---- Derive function_id from registry file path ----
-# Matches paths under functions/<domain>/<name>.<ext>, python/functions/<domain>/<name>.py,
-# bash/functions/<domain>/<name>.sh, frontend/functions/<domain>/<name>.ts(x)
-derive_fn_id_from_path() {
-    local p="$1"
-    [ -z "$p" ] && return 1
-    case "$p" in
-        functions/*/*.go|*/functions/*/*.go)
-            local dom name
-            dom=$(printf '%s' "$p" | sed -E 's|.*functions/([^/]+)/.*|\1|')
-            name=$(printf '%s' "$p" | sed -E 's|.*functions/[^/]+/([^/.]+)\..*|\1|')
-            [ -n "$dom" ] && [ -n "$name" ] && printf '%s_go_%s' "$name" "$dom" && return 0 ;;
-        python/functions/*/*.py)
-            local dom name
-            dom=$(printf '%s' "$p" | sed -E 's|python/functions/([^/]+)/.*|\1|')
-            name=$(printf '%s' "$p" | sed -E 's|python/functions/[^/]+/([^/.]+)\..*|\1|')
-            [ -n "$dom" ] && [ -n "$name" ] && printf '%s_py_%s' "$name" "$dom" && return 0 ;;
-        bash/functions/*/*.sh)
-            local dom name
-            dom=$(printf '%s' "$p" | sed -E 's|bash/functions/([^/]+)/.*|\1|')
-            name=$(printf '%s' "$p" | sed -E 's|bash/functions/[^/]+/([^/.]+)\..*|\1|')
-            [ -n "$dom" ] && [ -n "$name" ] && printf '%s_bash_%s' "$name" "$dom" && return 0 ;;
-        frontend/functions/*/*.ts|frontend/functions/*/*.tsx)
-            local dom name
-            dom=$(printf '%s' "$p" | sed -E 's|frontend/functions/([^/]+)/.*|\1|')
-            name=$(printf '%s' "$p" | sed -E 's|frontend/functions/[^/]+/([^/.]+)\..*|\1|')
-            [ -n "$dom" ] && [ -n "$name" ] && printf '%s_ts_%s' "$name" "$dom" && return 0 ;;
-    esac
-    return 1
-}
-
-# ---- Dispatch by tool ----
-case "$TOOL_NAME" in
-    mcp__registry__fn_search)
-        insert_call "" "mcp_fn_search"
-        ;;
-    mcp__registry__fn_show)
-        ID=$(printf '%s' "$INPUT" | jq -r '.tool_input.id // ""')
-        insert_call "$ID" "mcp_fn_show"
-        ;;
-    mcp__registry__fn_code)
-        ID=$(printf '%s' "$INPUT" | jq -r '.tool_input.id // ""')
-        insert_call "$ID" "mcp_fn_code"
-        ;;
-    mcp__registry__fn_uses)
-        ID=$(printf '%s' "$INPUT" | jq -r '.tool_input.id // ""')
-        insert_call "$ID" "mcp_fn_uses"
-        ;;
-    mcp__registry__fn_run)
-        ID=$(printf '%s' "$INPUT" | jq -r '.tool_input.id // ""')
-        insert_call "$ID" "mcp_fn_run"
-        ;;
-    mcp__registry__fn_list_domains)
-        insert_call "" "mcp_fn_list_domains"
-        ;;
-    mcp__registry__fn_proposal)
-        insert_call "" "mcp_fn_proposal"
-        ;;
-    mcp__registry__fn_doctor)
-        insert_call "" "mcp_fn_doctor"
-        ;;
-    mcp__registry__fn_create_function)
-        insert_call "" "mcp_fn_create_function"
-        ;;
-
-    Edit|Write|MultiEdit)
-        FILE_PATH=$(printf '%s' "$INPUT" | jq -r '.tool_input.file_path // ""')
-        ABS_PATH="$FILE_PATH"
-        # Make path relative to root if absolute and inside root
-        case "$FILE_PATH" in
-            "$ROOT"/*) FILE_PATH="${FILE_PATH#$ROOT/}" ;;
-            /*) ABS_PATH="$FILE_PATH" ;;
-            *) ABS_PATH="$ROOT/$FILE_PATH" ;;
-        esac
-        FN_ID=$(derive_fn_id_from_path "$FILE_PATH" || true)
-        if [ -n "$FN_ID" ]; then
-            insert_code_write "$FN_ID" "$FILE_PATH" 0 0
-            insert_call "$FN_ID" "edit_registry"
-            insert_edit_version "$FN_ID" "$ABS_PATH"
-        fi
-        ;;
-
-    Bash)
-        CMD=$(printf '%s' "$INPUT" | jq -r '.tool_input.command // ""')
-        CMD_HEAD=$(printf '%s' "$CMD" | head -c 200 | tr '\n' ' ')
-
-        # Classify
-        TOOL_USED="bash_other"
-        FN_ID=""
-
-        if printf '%s' "$CMD" | grep -qE '(^|[[:space:]])\./fn[[:space:]]+run[[:space:]]+'; then
-            TOOL_USED="fn_cli_run"
-            FN_ID=$(printf '%s' "$CMD" | sed -nE 's/.*\.\/fn[[:space:]]+run[[:space:]]+([A-Za-z0-9_]+).*/\1/p' | head -n1)
-        elif printf '%s' "$CMD" | grep -qE 'python/\.venv/bin/python3[[:space:]]+-[[:space:]]+<<'; then
-            TOOL_USED="heredoc_py"
-        elif printf '%s' "$CMD" | grep -qE 'sqlite3[[:space:]][^|]*\bregistry\.db\b'; then
-            TOOL_USED="sqlite_direct"
-        fi
-
-        insert_call "$FN_ID" "$TOOL_USED" 0 "$CMD_HEAD"
-
-        # ---- Violation rules ----
-        # 1. sqlite3 directo SELECT sobre registry.db (excepto schema/pragma/count/join)
-        if [ "$TOOL_USED" = "sqlite_direct" ]; then
-            if ! printf '%s' "$CMD" | grep -qiE '(\.schema|\.tables|PRAGMA[[:space:]]+(table_info|index_list)|COUNT\(|GROUP[[:space:]]+BY|JOIN[[:space:]])'; then
-                insert_violation "sqlite3_registry_select" "" "$CMD_HEAD" "warning"
-            fi
-        fi
-
-        # 2. python -c "import X; dir(X)"
-        if printf '%s' "$CMD" | grep -qE 'python[3]?[[:space:]]+-c[[:space:]]+["'\''].*import.*(dir|help)\('; then
-            insert_violation "python_dir_inspect" "" "$CMD_HEAD" "info"
-        fi
-
-        # 3. from <pkg> import *  (en heredoc python)
-        if [ "$TOOL_USED" = "heredoc_py" ]; then
-            if printf '%s' "$CMD" | grep -qE 'from[[:space:]]+[A-Za-z0-9_.]+[[:space:]]+import[[:space:]]+\*'; then
-                insert_violation "import_star_in_heredoc" "" "$CMD_HEAD" "warning"
-            fi
-            if printf '%s' "$CMD" | grep -qE 'client\._http\.request\('; then
-                insert_violation "client_http_request_direct" "" "$CMD_HEAD" "warning"
-            fi
-        fi
-        ;;
-esac
-
-exit 0

.claude/scripts/hook_capabilities_inject.sh

@@ -1,121 +0,0 @@
-#!/usr/bin/env bash
-# UserPromptSubmit hook: inyecta capacidades calientes (TOP/FRESH/PIPELINES)
-# del registry como additionalContext en cada turno del usuario.
-#
-# Cache: ~/.cache/fn_registry/capabilities.txt (TTL 1h).
-# Fuente: `./fn doctor capabilities --emit-claude-md` desde la raiz del repo.
-#
-# NUNCA bloquea: si algo falla, emite contexto vacio y sale 0.
-
-set -uo pipefail
-
-CACHE_DIR="${HOME}/.cache/fn_registry"
-CACHE_FILE="${CACHE_DIR}/capabilities.txt"
-TTL_SECONDS=3600
-
-# Resolve registry root (walks up from cwd, fallback CLAUDE_PROJECT_DIR)
-resolve_root() {
-    local d="${PWD}"
-    while [ "$d" != "/" ]; do
-        if [ -f "$d/registry.db" ] && [ -x "$d/fn" ]; then
-            printf '%s' "$d"
-            return 0
-        fi
-        d=$(dirname "$d")
-    done
-    if [ -n "${CLAUDE_PROJECT_DIR:-}" ] && [ -f "${CLAUDE_PROJECT_DIR}/registry.db" ]; then
-        printf '%s' "${CLAUDE_PROJECT_DIR}"
-        return 0
-    fi
-    return 1
-}
-
-# Consume stdin (UserPromptSubmit payload) — we don't need it but keep stdin clean
-cat >/dev/null 2>&1 || true
-
-ROOT=$(resolve_root) || exit 0
-mkdir -p "$CACHE_DIR" 2>/dev/null || exit 0
-
-# Cache freshness check
-need_refresh=1
-if [ -f "$CACHE_FILE" ]; then
-    now=$(date +%s)
-    mtime=$(stat -c %Y "$CACHE_FILE" 2>/dev/null || stat -f %m "$CACHE_FILE" 2>/dev/null || echo 0)
-    age=$((now - mtime))
-    if [ "$age" -lt "$TTL_SECONDS" ]; then
-        need_refresh=0
-    fi
-fi
-
-if [ "$need_refresh" -eq 1 ]; then
-    # Regenerate: call fn doctor capabilities --emit-claude-md and process
-    raw=$("$ROOT/fn" doctor capabilities --emit-claude-md 2>/dev/null || true)
-    if [ -z "$raw" ]; then
-        exit 0
-    fi
-
-    # Extract top 5 from each section using awk.
-    # Sections detected by "## ... Top" / "## ... Fresh" / "## ... Pipelines".
-    line=$(printf '%s\n' "$raw" | awk '
-        BEGIN { sec=""; n_top=0; n_fresh=0; n_pipe=0; }
-        /^## .*Top 20/   { sec="TOP";    next }
-        /^## .*Fresh/    { sec="FRESH";  next }
-        /^## .*Pipelines/ { sec="PIPE"; next }
-        /^## /           { sec="";       next }
-        /^- `/ {
-            # extract first backticked token
-            s = $0
-            sub(/^- `/, "", s)
-            i = index(s, "`")
-            if (i == 0) next
-            id = substr(s, 1, i-1)
-            if (sec == "TOP"   && n_top   < 5) { tops[n_top++]     = id }
-            if (sec == "FRESH" && n_fresh < 5) { fresh[n_fresh++]  = id }
-            if (sec == "PIPE"  && n_pipe  < 5) { pipes[n_pipe++]   = id }
-        }
-        END {
-            out = "CAPABILITIES (cache 1h):"
-            if (n_top > 0) {
-                line = "  TOP: " tops[0]
-                for (i=1; i<n_top; i++) line = line ", " tops[i]
-                out = out "\n" line
-            }
-            if (n_fresh > 0) {
-                line = "  FRESH (7d): " fresh[0]
-                for (i=1; i<n_fresh; i++) line = line ", " fresh[i]
-                out = out "\n" line
-            }
-            if (n_pipe > 0) {
-                line = "  PIPELINES: " pipes[0]
-                for (i=1; i<n_pipe; i++) line = line ", " pipes[i]
-                out = out "\n" line
-            }
-            print out
-        }
-    ')
-
-    if [ -z "$line" ]; then
-        exit 0
-    fi
-    printf '%s\n' "$line" >"$CACHE_FILE" 2>/dev/null || exit 0
-fi
-
-# Emit cached content as additionalContext
-if [ ! -s "$CACHE_FILE" ]; then
-    exit 0
-fi
-
-ctx=$(cat "$CACHE_FILE")
-if command -v jq >/dev/null 2>&1; then
-    jq -n --arg ctx "$ctx" '{
-      hookSpecificOutput: {
-        hookEventName: "UserPromptSubmit",
-        additionalContext: $ctx
-      }
-    }'
-else
-    # Fallback: print raw text (Claude Code prints stdout as context too)
-    printf '%s\n' "$ctx"
-fi
-
-exit 0

.claude/scripts/hook_capability_tag_gate.sh

@@ -1,107 +0,0 @@
-#!/usr/bin/env bash
-# PostToolUse hook: gate "tag de capability group obligatorio" tras crear/modificar
-# funciones del registry. Issue 0086 paso 9/gate.
-#
-# Comportamiento:
-#   - Detecta .md de funciones (functions/, python/functions/, bash/functions/,
-#     frontend/functions/, cpp/functions/) modificados en los ultimos 60s.
-#   - Lee frontmatter `tags:` y verifica si al menos uno coincide con un capability
-#     group declarado en docs/capabilities/INDEX.md.
-#   - Si NO hay match -> emite additionalContext con la lista de funciones afectadas.
-#   - NUNCA bloquea. Solo warning visible.
-#
-# Salida JSON consumida por Claude Code:
-#   { "hookSpecificOutput": { "hookEventName": "PostToolUse",
-#                             "additionalContext": "..." } }
-
-set -euo pipefail
-
-resolve_root() {
-    local d="${PWD}"
-    while [ "$d" != "/" ]; do
-        if [ -f "$d/registry.db" ]; then
-            printf '%s' "$d"
-            return 0
-        fi
-        d=$(dirname "$d")
-    done
-    return 1
-}
-
-ROOT=$(resolve_root) || exit 0
-INDEX="$ROOT/docs/capabilities/INDEX.md"
-
-# Si no existe el INDEX aun, no hay grupos definidos -> nada que verificar.
-[ -f "$INDEX" ] || exit 0
-
-# Consume stdin (sin parsear — no necesitamos session_id para este gate)
-cat >/dev/null
-
-# Solo correr si hay jq disponible
-command -v jq >/dev/null 2>&1 || exit 0
-
-# 1. Cargar lista de capability groups desde el INDEX.
-#    Formato esperado en INDEX.md:  | [name](name.md) | N | descripcion |
-CAP_GROUPS=$(grep -oE '\[[a-z][a-z0-9_-]*\]\([a-z][a-z0-9_-]*\.md\)' "$INDEX" \
-    | sed -E 's/^\[([^]]+)\].*/\1/' \
-    | sort -u)
-
-[ -z "$CAP_GROUPS" ] && exit 0
-
-# 2. Encontrar .md de funciones modificados en ultimos 60s.
-RECENT=$(find "$ROOT/functions" "$ROOT/python/functions" "$ROOT/bash/functions" \
-    "$ROOT/frontend/functions" "$ROOT/cpp/functions" \
-    -maxdepth 4 -type f -name '*.md' -mmin -1 2>/dev/null || true)
-
-[ -z "$RECENT" ] && exit 0
-
-# 3. Para cada .md reciente: extraer tags del frontmatter, comparar con groups.
-MISSING=""
-while IFS= read -r mdfile; do
-    [ -z "$mdfile" ] && continue
-    # Extrae el bloque entre los dos `---` del inicio
-    front=$(awk '/^---$/{c++; next} c==1 {print} c>=2 {exit}' "$mdfile" 2>/dev/null || true)
-    [ -z "$front" ] && continue
-
-    # tags: [a, b, c]  o  tags:\n  - a\n  - b
-    tags_inline=$( { printf '%s\n' "$front" | grep -E '^tags:[[:space:]]*\[' | head -1 \
-        | sed -E 's/^tags:[[:space:]]*\[(.*)\].*$/\1/' \
-        | tr ',' '\n' | sed -E 's/^[[:space:]"]+|[[:space:]"]+$//g'; } || true )
-
-    tags_block=$( { printf '%s\n' "$front" | awk '
-        /^tags:[[:space:]]*$/ {intag=1; next}
-        intag && /^[[:space:]]*-[[:space:]]/ {sub(/^[[:space:]]*-[[:space:]]*/, ""); print; next}
-        intag && !/^[[:space:]]/ {intag=0}
-    ' | sed -E 's/^[[:space:]"]+|[[:space:]"]+$//g'; } || true )
-
-    tags=$( { printf '%s\n%s\n' "$tags_inline" "$tags_block" | grep -v '^$'; } || true )
-
-    matched=0
-    while IFS= read -r g; do
-        [ -z "$g" ] && continue
-        if printf '%s\n' "$tags" | grep -qx "$g"; then
-            matched=1
-            break
-        fi
-    done <<< "$CAP_GROUPS"
-
-    if [ "$matched" -eq 0 ]; then
-        rel="${mdfile#$ROOT/}"
-        MISSING="${MISSING}${rel}\n"
-    fi
-done <<< "$RECENT"
-
-# 4. Si hay funciones sin tag de grupo, emitir aviso.
-if [ -n "$MISSING" ]; then
-    CAP_GROUPS_CSV=$(printf '%s' "$CAP_GROUPS" | tr '\n' ',' | sed 's/,$//')
-    WARN="CAPABILITY-GAP (issue 0086): funcion(es) recien tocada(s) sin tag de capability group: $(printf '%b' "$MISSING" | tr '\n' ' ')"
-    WARN+="| Grupos disponibles: ${CAP_GROUPS_CSV}. Anade al menos uno al frontmatter \`tags:\` y corre \`./fn index\`. Si la funcion no encaja en ningun grupo existente, considera crear grupo nuevo (>=3 funciones) o dejarla con tag plano (no de grupo)."
-    jq -n --arg ctx "$WARN" '{
-      hookSpecificOutput: {
-        hookEventName: "PostToolUse",
-        additionalContext: $ctx
-      }
-    }'
-fi
-
-exit 0

.claude/scripts/hook_fn_match.sh

@@ -1,133 +0,0 @@
-#!/usr/bin/env bash
-# PreToolUse hook: sugiere funciones del registry cuando un comando Bash
-# inline probablemente reinventa una funcion existente (issue 0087).
-#
-# Llama a `./fn match "<cmd>"` con timeout 200ms. Si encaja con alta
-# confianza, imprime un <system-reminder> a stderr para que Claude Code
-# lo lea como recordatorio. NUNCA bloquea la tool — exit 0 siempre.
-
-set -euo pipefail
-
-# ---- Always exit 0, no matter what ----
-trap 'exit 0' ERR
-
-# ---- Resolve registry root (walks up from cwd) ----
-resolve_root() {
-    local d="${PWD}"
-    while [ "$d" != "/" ]; do
-        if [ -f "$d/registry.db" ]; then
-            printf '%s' "$d"
-            return 0
-        fi
-        d=$(dirname "$d")
-    done
-    return 1
-}
-
-ROOT=$(resolve_root) || exit 0
-FN_BIN="$ROOT/fn"
-[ -x "$FN_BIN" ] || exit 0
-
-# ---- Read stdin JSON ----
-command -v jq >/dev/null 2>&1 || exit 0
-INPUT=$(cat)
-[ -z "$INPUT" ] && exit 0
-
-TOOL_NAME=$(printf '%s' "$INPUT" | jq -r '.tool_name // ""' 2>/dev/null || echo "")
-[ "$TOOL_NAME" = "Bash" ] || exit 0
-
-CMD=$(printf '%s' "$INPUT" | jq -r '.tool_input.command // ""' 2>/dev/null || echo "")
-[ -z "$CMD" ] && exit 0
-
-# Single-line for matching against denylist patterns
-CMD_FLAT=$(printf '%s' "$CMD" | tr '\n' ' ')
-
-# ---- Denylist (skip antes de llamar fn match para ahorrar el invoke) ----
-
-# Comandos demasiado cortos -> trivial
-CMD_LEN=${#CMD_FLAT}
-[ "$CMD_LEN" -lt 20 ] && exit 0
-
-# Trivial single-utility commands
-case "$CMD_FLAT" in
-    "ls"|"ls "*|"cd"|"cd "*|"pwd"|"pwd "*|"cat"|"cat "*|"echo"|"echo "*)
-        exit 0 ;;
-    "grep"|"grep "*|"head"|"head "*|"tail"|"tail "*|"wc"|"wc "*)
-        exit 0 ;;
-    "mkdir"|"mkdir "*|"rm"|"rm "*|"mv"|"mv "*|"cp"|"cp "*)
-        exit 0 ;;
-    "git"|"git "*)
-        exit 0 ;;
-    "go"|"go "*)
-        # go build / go test corrientes — el agente ya los maneja
-        exit 0 ;;
-esac
-
-# Comandos que ya usan el registry: ./fn ..., fn run ..., mcp__registry__*
-if printf '%s' "$CMD_FLAT" | grep -qE '(^|[[:space:]])\./fn([[:space:]]|$)'; then
-    exit 0
-fi
-if printf '%s' "$CMD_FLAT" | grep -qE '(^|[[:space:]])fn[[:space:]]+(run|search|show|code|uses|doctor|index|match|list|add|proposal|sync|ops|check)'; then
-    exit 0
-fi
-
-# Pure-cd (movement only, no logic)
-if printf '%s' "$CMD_FLAT" | grep -qE '^[[:space:]]*cd[[:space:]]+[^&|;]+$'; then
-    exit 0
-fi
-
-# ---- Llamar fn match con timeout 200ms ----
-command -v timeout >/dev/null 2>&1 || exit 0
-
-# Truncar el comando a algo razonable para fn match (evitar args huge)
-CMD_TRUNC=$(printf '%s' "$CMD_FLAT" | head -c 500)
-
-MATCH_JSON=$(timeout 0.2 "$FN_BIN" match "$CMD_TRUNC" --format json --top 3 2>/dev/null) || exit 0
-[ -z "$MATCH_JSON" ] && exit 0
-
-# ---- Parsear JSON ----
-HIGH_CONF=$(printf '%s' "$MATCH_JSON" | jq -r '.high_confidence // false' 2>/dev/null || echo "false")
-TOP_ID=$(printf '%s' "$MATCH_JSON" | jq -r '.top[0].id // ""' 2>/dev/null || echo "")
-TOP_SCORE=$(printf '%s' "$MATCH_JSON" | jq -r '.top[0].score // 0' 2>/dev/null || echo "0")
-TOP_SIG=$(printf '%s' "$MATCH_JSON" | jq -r '.top[0].signature // ""' 2>/dev/null || echo "")
-TOP_SNIP=$(printf '%s' "$MATCH_JSON" | jq -r '.top[0].snippet // ""' 2>/dev/null || echo "")
-
-[ -z "$TOP_ID" ] && exit 0
-
-# Trigger condition: (high_confidence==true OR score>=0.85) AND score>=0.6
-# - high_confidence requires top1/top2 gap > 1.5 (set por fn match)
-# - score>=0.85 cubre matches muy fuertes donde el gap es modesto
-SCORE_HI=$(awk -v s="$TOP_SCORE" 'BEGIN{ print (s+0 >= 0.85) ? "1" : "0" }')
-SCORE_MIN=$(awk -v s="$TOP_SCORE" 'BEGIN{ print (s+0 >= 0.6) ? "1" : "0" }')
-
-[ "$SCORE_MIN" = "1" ] || exit 0
-if [ "$HIGH_CONF" != "true" ] && [ "$SCORE_HI" != "1" ]; then
-    exit 0
-fi
-
-# Truncar snippet a 100 chars y limpiar saltos de linea
-SNIP_SHORT=$(printf '%s' "$TOP_SNIP" | tr '\n' ' ' | head -c 100)
-
-# Formatear score con 2 decimales
-SCORE_FMT=$(awk -v s="$TOP_SCORE" 'BEGIN{ printf "%.2f", s+0 }')
-
-# ---- Emitir <system-reminder> a stderr ----
-cat >&2 <<EOF
-<system-reminder>FUZZY-MATCH (issue 0087): your Bash command may already be a function.
-USE: ./fn run $TOP_ID  ->  $TOP_SIG
-SNIPPET: $SNIP_SHORT
-Confidence: $SCORE_FMT. If you proceed inline, the violation will be logged.
-</system-reminder>
-EOF
-
-exit 0
-
-# Test manual:
-# echo '{"tool_name":"Bash","tool_input":{"command":"taskkill.exe /IM registry_dashboard.exe /F"},"session_id":"test"}' \
-#   | bash .claude/scripts/hook_fn_match.sh
-#
-# Casos silenciosos:
-# echo '{"tool_name":"Bash","tool_input":{"command":"ls -la"},"session_id":"test"}' \
-#   | bash .claude/scripts/hook_fn_match.sh
-# echo '{"tool_name":"Bash","tool_input":{"command":"./fn run filter_slice_go_core 1 2 3"},"session_id":"test"}' \
-#   | bash .claude/scripts/hook_fn_match.sh

.claude/scripts/hook_registry_first_reminder.sh

@@ -1,72 +0,0 @@
-#!/usr/bin/env bash
-# UserPromptSubmit hook: recordatorio compacto de patrones canonicos del registry.
-# Inyectado como additionalContext en cada turno del usuario.
-# Issue 0085 (hardening 2).
-#
-# NUNCA bloquea. Solo printf de additionalContext.
-
-set -euo pipefail
-
-# Resolve registry root (walks up from cwd)
-resolve_root() {
-    local d="${PWD}"
-    while [ "$d" != "/" ]; do
-        if [ -f "$d/registry.db" ]; then
-            printf '%s' "$d"
-            return 0
-        fi
-        d=$(dirname "$d")
-    done
-    return 1
-}
-
-ROOT=$(resolve_root) || exit 0
-
-# Read input, extract session_id (UserPromptSubmit payload includes it)
-INPUT=$(cat)
-SESSION_ID=""
-if command -v jq >/dev/null 2>&1; then
-    SESSION_ID=$(printf '%s' "$INPUT" | jq -r '.session_id // ""' 2>/dev/null || true)
-fi
-
-# Count current pending proposals + recent violations for situational awareness
-PROPOSALS_PENDING="?"
-VIOLATIONS_24H="?"
-CALLS_24H="?"
-CAP_CREATED=0
-CAP_USED=0
-CAP_ORPHAN=0
-
-if command -v sqlite3 >/dev/null 2>&1; then
-    REG="$ROOT/registry.db"
-    MON="$ROOT/projects/fn_monitoring/apps/call_monitor/operations.db"
-    [ -f "$REG" ] && PROPOSALS_PENDING=$(sqlite3 "$REG" "SELECT COUNT(*) FROM proposals WHERE status='pending'" 2>/dev/null || echo "?")
-    if [ -f "$MON" ]; then
-        VIOLATIONS_24H=$(sqlite3 "$MON" "SELECT COUNT(*) FROM violations WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)" 2>/dev/null || echo "?")
-        CALLS_24H=$(sqlite3 "$MON" "SELECT COUNT(*) FROM calls WHERE ts >= CAST(strftime('%s','now','-1 day') AS INTEGER)" 2>/dev/null || echo "?")
-        if [ -n "$SESSION_ID" ]; then
-            sid_esc=$(printf '%s' "$SESSION_ID" | sed "s/'/''/g")
-            CAP_CREATED=$(sqlite3 "$MON" "SELECT COUNT(*) FROM session_capability_growth WHERE session_id='$sid_esc'" 2>/dev/null || echo 0)
-            CAP_USED=$(sqlite3 "$MON" "SELECT COUNT(*) FROM session_capability_growth WHERE session_id='$sid_esc' AND calls_in_session>0" 2>/dev/null || echo 0)
-            CAP_ORPHAN=$(sqlite3 "$MON" "SELECT COUNT(*) FROM session_capability_growth WHERE session_id='$sid_esc' AND calls_in_session=0" 2>/dev/null || echo 0)
-        fi
-    fi
-fi
-
-REMINDER="REGISTRY-FIRST (issue 0085 telemetry active): "
-REMINDER+="Inspect → mcp__registry__fn_search/show/code/uses/proposal. "
-REMINDER+="Execute one fn → mcp__registry__fn_run or ./fn run. "
-REMINDER+="Compose multi-fn → heredoc python IMPORTANDO del registry. "
-REMINDER+="NUNCA sqlite3 registry.db directo (salvo schema/PRAGMA/COUNT/JOIN). "
-REMINDER+="NUNCA reescribir inline logica que ya es funcion. "
-REMINDER+="Si patron se repite >2x → propose nueva funcion via fn-constructor. "
-REMINDER+="Estado: pending_proposals=${PROPOSALS_PENDING} violations_24h=${VIOLATIONS_24H} calls_24h=${CALLS_24H}. "
-REMINDER+="CAPABILITY-GROWTH (issue 0086): created_this_session=${CAP_CREATED} used=${CAP_USED} orphan=${CAP_ORPHAN}. Si orphan>0 -> integra la funcion en el codigo o documenta por que se quedo huerfana. "
-REMINDER+="Comando autocheck: /fn_claude."
-
-jq -n --arg ctx "$REMINDER" '{
-  hookSpecificOutput: {
-    hookEventName: "UserPromptSubmit",
-    additionalContext: $ctx
-  }
-}'

.claude/scripts/hook_registry_mcp.sh

@@ -1,28 +0,0 @@
-#!/usr/bin/env bash
-# PreToolUse hook: NO bloquea. Inyecta recordatorio cuando ve sqlite3 sobre registry.db
-# para que el modelo prefiera el MCP `registry` la proxima vez.
-
-input="$(cat)"
-cmd="$(printf '%s' "$input" | jq -r '.tool_input.command // ""')"
-
-# Solo nos importa registry.db (NO operations.db, NO otros .db).
-if ! printf '%s' "$cmd" | grep -Eq 'sqlite3[^|]*\bregistry\.db\b'; then
-  exit 0
-fi
-
-# Casos legitimos donde el MCP no aplica: introspeccion de schema, agregaciones, JOINs.
-if printf '%s' "$cmd" | grep -Eq '(\.schema|\.tables|PRAGMA[[:space:]]+(table_info|index_list))'; then
-  exit 0
-fi
-if printf '%s' "$cmd" | grep -Eqi '(COUNT\(|GROUP[[:space:]]+BY|JOIN[[:space:]])'; then
-  exit 0
-fi
-
-# Caso a redirigir: emitir nota como additionalContext y dejar pasar el comando.
-jq -n '{
-  hookSpecificOutput: {
-    hookEventName: "PreToolUse",
-    additionalContext: "Aviso: sqlite3 directo sobre registry.db detectado. Para futuras consultas usa el MCP registry (mcp__registry__fn_search / fn_show / fn_code / fn_uses / fn_list_domains). Fallback a sqlite3 SOLO para .schema, PRAGMA, COUNT/GROUP BY, JOINs custom."
-  }
-}'
-exit 0

.claude/settings.local.json

@@ -1,63 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(CGO_ENABLED=1 go test *)",
-      "Bash(sqlite3 *)"
-    ]
-  },
-  "enabledMcpjsonServers": [
-    "registry",
-    "jupyter"
-  ],
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Bash",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_registry_mcp.sh"
-          },
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_fn_match.sh"
-          }
-        ]
-      }
-    ],
-    "PostToolUse": [
-      {
-        "matcher": "Bash|Edit|Write|MultiEdit|mcp__registry__.*",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_call_monitor.sh"
-          }
-        ]
-      },
-      {
-        "matcher": "Edit|Write|MultiEdit|mcp__registry__fn_create_function",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_capability_tag_gate.sh"
-          }
-        ]
-      }
-    ],
-    "UserPromptSubmit": [
-      {
-        "hooks": [
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_capabilities_inject.sh"
-          },
-          {
-            "type": "command",
-            "command": "$CLAUDE_PROJECT_DIR/.claude/scripts/hook_registry_first_reminder.sh"
-          }
-        ]
-      }
-    ]
-  }
-}

.claude/skills/parallel-fix-issues/scripts/integrate-worktrees.sh

@@ -1,121 +0,0 @@
-#!/bin/bash
-# integrate-worktrees.sh — Integra branches de worktrees a master con --no-ff
-#
-# Uso: ./integrate-worktrees.sh <slug-1> <slug-2> ...
-# Ejemplo: ./integrate-worktrees.sh 0026-split-runtime 0027-prune-config-schema
-#
-# Para cada slug:
-#   1. git merge --no-ff issue/<slug> a master
-#   2. Verificar que master compila después del merge
-#   3. Si hay conflict o fallo de build, PARAR inmediatamente
-#
-# Los slugs deben pasarse en el orden correcto (waves ya resueltas).
-# NO hace push — eso lo decide el usuario.
-
-set -euo pipefail
-
-REPO_ROOT="$(git rev-parse --show-toplevel)"
-
-if [ $# -eq 0 ]; then
-  echo "ERROR: se necesita al menos un slug"
-  echo "Uso: $0 <slug-1> <slug-2> ..."
-  exit 1
-fi
-
-# Asegurar que estamos en master
-echo "=== Cambiando a master ==="
-cd "$REPO_ROOT"
-git checkout master
-
-MERGED=0
-FAILED_AT=""
-
-for slug in "$@"; do
-  branch="issue/${slug}"
-
-  echo ""
-  echo "=== Integrando: ${branch} ==="
-
-  # Verificar que la branch existe
-  if ! git show-ref --verify --quiet "refs/heads/${branch}"; then
-    echo "FAIL: branch ${branch} no existe"
-    FAILED_AT="$slug"
-    break
-  fi
-
-  # Merge --no-ff
-  if ! git merge --no-ff "$branch" -m "merge: ${branch} — implementación paralela"; then
-    echo ""
-    echo "CONFLICT: merge de ${branch} tiene conflictos"
-    echo "Resolver manualmente y luego continuar con los slugs restantes"
-    echo ""
-    echo "Para resolver:"
-    echo "  1. git status  (ver archivos en conflicto)"
-    echo "  2. Resolver conflictos en cada archivo"
-    echo "  3. git add <archivos>"
-    echo "  4. git commit"
-    echo ""
-    echo "Slugs pendientes después de ${slug}:"
-    FOUND=0
-    for remaining in "$@"; do
-      if [ "$FOUND" -eq 1 ]; then
-        echo "  - ${remaining}"
-      fi
-      if [ "$remaining" = "$slug" ]; then
-        FOUND=1
-      fi
-    done
-    exit 1
-  fi
-
-  echo "MERGED: ${branch}"
-
-  # Verificar que master sigue compilando (si BUILD_CMD esta definido)
-  if [ -n "${BUILD_CMD:-}" ]; then
-    echo "--- Verificando build post-merge ($BUILD_CMD) ---"
-    if ! (cd "$REPO_ROOT" && bash -c "$BUILD_CMD" 2>&1); then
-      echo ""
-      echo "FAIL: master no compila despues de mergear ${branch}"
-      echo "Revertir con: git reset --hard HEAD~1"
-      echo "Investigar el problema antes de continuar."
-      FAILED_AT="$slug"
-      break
-    fi
-    echo "OK: build post-merge exitoso"
-  else
-    echo "--- Build post-merge SKIPPED (BUILD_CMD no definido) ---"
-  fi
-
-  MERGED=$((MERGED + 1))
-done
-
-echo ""
-echo "=== Resumen de integración ==="
-echo "Mergeados: ${MERGED} de $#"
-
-if [ -n "$FAILED_AT" ]; then
-  echo "Falló en: ${FAILED_AT}"
-  echo ""
-  echo "Worktrees NO limpiados (resolver primero el fallo)"
-  exit 1
-fi
-
-# Limpieza de worktrees y branches
-echo ""
-echo "=== Limpieza ==="
-for slug in "$@"; do
-  path="${REPO_ROOT}/worktrees/${slug}"
-  branch="issue/${slug}"
-
-  if [ -d "$path" ]; then
-    git worktree remove "$path" 2>/dev/null && echo "REMOVED: worktree ${path}" || echo "WARN: no se pudo eliminar worktree ${path}"
-  fi
-
-  git branch -d "$branch" 2>/dev/null && echo "DELETED: branch ${branch}" || echo "WARN: no se pudo eliminar branch ${branch}"
-done
-
-echo ""
-echo "=== Integración completa ==="
-echo "Master tiene ${MERGED} merges nuevos."
-echo ""
-echo "Para publicar: git push"

.claude/skills/parallel-fix-issues/scripts/setup-worktrees.sh

@@ -1,74 +0,0 @@
-#!/bin/bash
-# setup-worktrees.sh — Crea git worktrees para ejecución paralela de issues
-#
-# Uso: ./setup-worktrees.sh <slug-1> <slug-2> ...
-# Ejemplo: ./setup-worktrees.sh 0026-split-runtime 0027-prune-config-schema
-#
-# Cada slug genera:
-#   worktrees/<slug>/  (worktree completo)
-#   branch: issue/<slug>
-
-set -euo pipefail
-
-REPO_ROOT="$(git rev-parse --show-toplevel)"
-WORKTREE_DIR="${REPO_ROOT}/worktrees"
-
-if [ $# -eq 0 ]; then
-  echo "ERROR: se necesita al menos un slug de issue"
-  echo "Uso: $0 <slug-1> <slug-2> ..."
-  exit 1
-fi
-
-# Verificar master (NO pull --rebase: rompe merges locales convirtiendolos
-# en cherry-picks contra origin/master viejo). Detectado 2026-05-18.
-echo "=== Verificando master ==="
-CURRENT_BRANCH="$(git branch --show-current)"
-if [ "$CURRENT_BRANCH" != "master" ] && [ -n "$CURRENT_BRANCH" ]; then
-  echo "WARN: estas en branch '${CURRENT_BRANCH}', no master. Worktrees nuevos saldran de master ref de todos modos."
-fi
-# NO auto-pull. Usuario decide sync con remote.
-
-mkdir -p "$WORKTREE_DIR"
-
-CREATED=0
-SKIPPED=0
-FAILED=0
-
-for slug in "$@"; do
-  branch="issue/${slug}"
-  path="${WORKTREE_DIR}/${slug}"
-
-  if [ -d "$path" ]; then
-    echo "SKIP: worktree ya existe: ${path}"
-    SKIPPED=$((SKIPPED + 1))
-    continue
-  fi
-
-  # Verificar que la branch no existe ya
-  if git show-ref --verify --quiet "refs/heads/${branch}" 2>/dev/null; then
-    echo "WARN: branch ${branch} ya existe, creando worktree desde ella"
-    git worktree add "$path" "$branch" 2>/dev/null || {
-      echo "FAIL: no se pudo crear worktree para ${slug}"
-      FAILED=$((FAILED + 1))
-      continue
-    }
-  else
-    echo "CREATE: worktree ${path} (branch ${branch})"
-    git worktree add -b "$branch" "$path" master 2>/dev/null || {
-      echo "FAIL: no se pudo crear worktree para ${slug}"
-      FAILED=$((FAILED + 1))
-      continue
-    }
-  fi
-
-  CREATED=$((CREATED + 1))
-done
-
-echo ""
-echo "=== Resumen ==="
-echo "Creados: ${CREATED}"
-echo "Existentes: ${SKIPPED}"
-echo "Fallidos: ${FAILED}"
-echo ""
-echo "=== Worktrees activos ==="
-git worktree list

.claude/skills/parallel-fix-issues/scripts/verify-worktree.sh

@@ -1,165 +0,0 @@
-#!/bin/bash
-# verify-worktree.sh — Verifica build, tests y cierre de issue en un worktree.
-#
-# Uso:
-#   ./verify-worktree.sh <worktree-path> [build-cmd] [test-cmd]
-#
-# Ejemplos:
-#   ./verify-worktree.sh worktrees/0026-foo
-#   ./verify-worktree.sh worktrees/0026-foo "go build -tags fts5 ./..." "go test -tags fts5 ./..."
-#   BUILD_CMD="cmake --build cpp/build" TEST_CMD="ctest --test-dir cpp/build" ./verify-worktree.sh worktrees/0026-foo
-#
-# Resolucion de comandos (en orden de prioridad):
-#   1. Argumentos posicionales (build-cmd, test-cmd)
-#   2. Variables de entorno BUILD_CMD / TEST_CMD
-#   3. Archivo .parallel-fix-issues.yml en la raiz del worktree (claves: build, test)
-#   4. Auto-deteccion segun ficheros del proyecto:
-#        - go.mod          → "go build ./..."          + "go test ./..."
-#        - CMakeLists.txt  → "cmake -S . -B build && cmake --build build" + "ctest --test-dir build"
-#        - Cargo.toml      → "cargo build"             + "cargo test"
-#        - package.json    → "npm run build"           + "npm test"
-#        - pyproject.toml  → ""                         + "pytest"
-#   5. Si nada se detecta, salta build/test con WARN.
-#
-# Auto-deteccion adicional: si hay go.mod, intenta extraer build tag de //go:build.
-#
-# Exit codes:
-#   0 = todo OK
-#   1 = error de argumento
-#   2 = build fallo
-#   3 = tests fallaron
-#   4 = issue no cerrado (solo WARN, no falla)
-#   5 = sin commits propios
-
-set -euo pipefail
-
-if [ $# -lt 1 ]; then
-  echo "ERROR: se necesita el path del worktree"
-  echo "Uso: $0 <worktree-path> [build-cmd] [test-cmd]"
-  exit 1
-fi
-
-WORKTREE="$1"
-ARG_BUILD_CMD="${2:-}"
-ARG_TEST_CMD="${3:-}"
-
-# Resolver path absoluto
-if [[ "$WORKTREE" != /* ]]; then
-  REPO_ROOT="$(git rev-parse --show-toplevel)"
-  WORKTREE="${REPO_ROOT}/${WORKTREE}"
-fi
-
-if [ ! -d "$WORKTREE" ]; then
-  echo "ERROR: worktree no encontrado: ${WORKTREE}"
-  exit 1
-fi
-
-SLUG="$(basename "$WORKTREE")"
-echo "=== Verificando: ${SLUG} ==="
-
-# --- Resolver build/test commands ---
-BUILD_CMD="${ARG_BUILD_CMD:-${BUILD_CMD:-}}"
-TEST_CMD="${ARG_TEST_CMD:-${TEST_CMD:-}}"
-
-# Manifest opcional
-MANIFEST="${WORKTREE}/.parallel-fix-issues.yml"
-if [ -z "$BUILD_CMD" ] && [ -f "$MANIFEST" ]; then
-  M_BUILD=$(grep -E "^build:" "$MANIFEST" 2>/dev/null | sed -E 's/^build:[[:space:]]*"?([^"]*)"?[[:space:]]*$/\1/' | head -1 || true)
-  if [ -n "$M_BUILD" ]; then BUILD_CMD="$M_BUILD"; echo "INFO: build desde manifest"; fi
-fi
-if [ -z "$TEST_CMD" ] && [ -f "$MANIFEST" ]; then
-  M_TEST=$(grep -E "^test:" "$MANIFEST" 2>/dev/null | sed -E 's/^test:[[:space:]]*"?([^"]*)"?[[:space:]]*$/\1/' | head -1 || true)
-  if [ -n "$M_TEST" ]; then TEST_CMD="$M_TEST"; echo "INFO: test desde manifest"; fi
-fi
-
-# Auto-deteccion
-if [ -z "$BUILD_CMD" ] || [ -z "$TEST_CMD" ]; then
-  AUTO_BUILD=""
-  AUTO_TEST=""
-  if [ -f "${WORKTREE}/go.mod" ]; then
-    # Detectar build tag
-    AUTO_TAG=$(grep -rh "^//go:build " --include="*.go" "$WORKTREE" 2>/dev/null \
-      | sed -E 's|^//go:build ([a-zA-Z0-9_]+).*|\1|' \
-      | sort -u | head -1 || true)
-    TAG_FLAG=""
-    [ -n "$AUTO_TAG" ] && TAG_FLAG="-tags $AUTO_TAG"
-    AUTO_BUILD="go build $TAG_FLAG ./..."
-    AUTO_TEST="go test $TAG_FLAG ./..."
-    echo "INFO: stack detectado: Go${TAG_FLAG:+ ($TAG_FLAG)}"
-  elif [ -f "${WORKTREE}/CMakeLists.txt" ] || ls "${WORKTREE}"/cpp/CMakeLists.txt >/dev/null 2>&1; then
-    CMAKE_DIR="."
-    [ -f "${WORKTREE}/cpp/CMakeLists.txt" ] && [ ! -f "${WORKTREE}/CMakeLists.txt" ] && CMAKE_DIR="cpp"
-    AUTO_BUILD="cmake -S ${CMAKE_DIR} -B ${CMAKE_DIR}/build -DCMAKE_BUILD_TYPE=Release && cmake --build ${CMAKE_DIR}/build -j"
-    AUTO_TEST="ctest --test-dir ${CMAKE_DIR}/build --output-on-failure || true"
-    echo "INFO: stack detectado: C++/CMake (dir=${CMAKE_DIR})"
-  elif [ -f "${WORKTREE}/Cargo.toml" ]; then
-    AUTO_BUILD="cargo build"
-    AUTO_TEST="cargo test"
-    echo "INFO: stack detectado: Rust"
-  elif [ -f "${WORKTREE}/package.json" ]; then
-    AUTO_BUILD="npm run build --if-present"
-    AUTO_TEST="npm test --if-present"
-    echo "INFO: stack detectado: Node"
-  elif [ -f "${WORKTREE}/pyproject.toml" ] || [ -f "${WORKTREE}/setup.py" ]; then
-    AUTO_BUILD=""  # python normalmente no tiene build step
-    AUTO_TEST="pytest"
-    echo "INFO: stack detectado: Python"
-  else
-    echo "WARN: no se detecto stack; usar BUILD_CMD/TEST_CMD env o manifest .parallel-fix-issues.yml"
-  fi
-  [ -z "$BUILD_CMD" ] && BUILD_CMD="$AUTO_BUILD"
-  [ -z "$TEST_CMD"  ] && TEST_CMD="$AUTO_TEST"
-fi
-
-# 1. Verificar commits propios
-echo ""
-echo "--- Commits propios ---"
-COMMIT_COUNT=$(cd "$WORKTREE" && git log master..HEAD --oneline 2>/dev/null | wc -l)
-if [ "$COMMIT_COUNT" -eq 0 ]; then
-  echo "FAIL: sin commits propios en la branch"
-  exit 5
-fi
-echo "OK: ${COMMIT_COUNT} commits desde master"
-cd "$WORKTREE" && git log master..HEAD --oneline
-
-# 2. Build
-echo ""
-if [ -n "$BUILD_CMD" ]; then
-  echo "--- Build ($BUILD_CMD) ---"
-  if (cd "$WORKTREE" && bash -c "$BUILD_CMD" 2>&1); then
-    echo "OK: build exitoso"
-  else
-    echo "FAIL: build fallo"
-    exit 2
-  fi
-else
-  echo "--- Build SKIPPED (sin comando) ---"
-fi
-
-# 3. Tests
-echo ""
-if [ -n "$TEST_CMD" ]; then
-  echo "--- Tests ($TEST_CMD) ---"
-  if (cd "$WORKTREE" && bash -c "$TEST_CMD" 2>&1); then
-    echo "OK: tests pasaron"
-  else
-    echo "FAIL: tests fallaron"
-    exit 3
-  fi
-else
-  echo "--- Tests SKIPPED (sin comando) ---"
-fi
-
-# 4. Issue cerrado
-echo ""
-echo "--- Cierre de issue ---"
-COMPLETED_FILES=$(cd "$WORKTREE" && git diff --name-only master -- dev/issues/completed/ 2>/dev/null | wc -l)
-if [ "$COMPLETED_FILES" -gt 0 ]; then
-  echo "OK: issue movido a completed/"
-  cd "$WORKTREE" && git diff --name-only master -- dev/issues/completed/
-else
-  echo "WARN: no se detecto issue movido a completed/ (verificar manualmente)"
-fi
-
-echo ""
-echo "=== RESULTADO: ${SLUG} — OK ==="

.gitignore

@@ -1,8 +1,6 @@
-# SQLite index — regenerable con `fn index` + completable con `fn sync`
-registry.db
+# SQLite index — journal/wal temporales
 registry.db-journal
 registry.db-wal
-registry.db-shm
 
 # operations.db — datos vivos, cada app genera el suyo con fn ops init
 **/operations.db
@@ -39,37 +37,14 @@ python/.venv/
 apps/*/
 analysis/*/
 
-# Projects (each is its own git repo, only project.md templates are versioned)
-projects/*/
-
-# Vaults — data stores (symlinks, dirs, files); only vault.yaml manifest is versioned
-vaults/*/
-!vaults/vault.yaml
-
 # Node / pnpm
 **/node_modules/
 
 # Sources — repos externos clonados (solo se versiona el manifest)
 sources/*/
 
-# Subrepos — mirrors/espejos externos (cada uno su propio git remote)
-subrepos/*/
-
-# External — symlinks a repos ajenos (ej: repo_Claude con skills/commands)
-external/
-
-# Worktrees — git worktrees para issues paralelos (parallel-fix-issues)
-worktrees/
-
-# Claude runtime locks
-.claude/scheduled_tasks.lock
-
-# Temp — workspace efimero para pruebas rapidas (APIs, scripts, analisis)
-temp/
-
-# C++ build artifacts (build/, build-tests/, build-windows/, etc.)
-cpp/build*/
-/build/
+# C++ build artifacts
+cpp/build/
 
 # OS
 .DS_Store
@@ -80,11 +55,3 @@ Thumbs.db
 
 broken_paths.txt
 imgui.ini
-prompts/
-
-# Module versioning auto-generated headers (written by `fn index`, issue 0097)
-**/version_generated.h
-**/app_modules_generated.h
-
-# Issue migration backups (0100)
-dev/issues/.backup_pre_*

.gitmodules

@@ -1,29 +1,13 @@
 [submodule "cpp/vendor/imgui"]
 	path = cpp/vendor/imgui
 	url = https://github.com/ocornut/imgui.git
-	shallow = true
 	branch = docking
 [submodule "cpp/vendor/implot"]
 	path = cpp/vendor/implot
 	url = https://github.com/epezent/implot.git
-	shallow = true
 [submodule "cpp/vendor/tracy"]
 	path = cpp/vendor/tracy
 	url = https://github.com/wolfpld/tracy.git
-	shallow = true
-[submodule "cpp/vendor/glfw"]
-	path = cpp/vendor/glfw
+[submodule "/home/lucas/fn_registry/cpp/vendor/glfw"]
+	path = /home/lucas/fn_registry/cpp/vendor/glfw
 	url = https://github.com/glfw/glfw.git
-	shallow = true
-[submodule "cpp/vendor/implot3d"]
-	path = cpp/vendor/implot3d
-	url = https://github.com/brenocq/implot3d.git
-	shallow = true
-[submodule "cpp/vendor/sdl3"]
-	path = cpp/vendor/sdl3
-	url = https://github.com/libsdl-org/SDL.git
-	shallow = true
-[submodule "emsdk"]
-	path = emsdk
-	url = https://github.com/emscripten-core/emsdk.git
-	shallow = true

.jupyter/collaboration_sessions.json

@@ -1,7 +0,0 @@
-{
-  "0ea5e69b-9607-4f11-b740-005e835faef6": {
-    "version": "2.4.0",
-    "created_at": "2026-06-03T17:52:16.077873+00:00",
-    "document_version": "2.0.0"
-  }
-}

.mcp.json

@@ -1,12 +0,0 @@
-{
-  "mcpServers": {
-    "registry": {
-      "command": "./apps/registry_mcp/registry_mcp",
-      "args": ["--enable-run", "--enable-write"]
-    },
-    "jupyter": {
-      "command": "bash",
-      "args": ["/home/enmanuel/fn_registry/bash/functions/infra/jupyter_mcp_serve.sh"]
-    }
-  }
-}

CHANGELOG.md

@@ -1,334 +0,0 @@
-# Changelog
-
-Todos los cambios notables de `fn_registry` se documentan aquí.
-
-Formato basado en [Keep a Changelog](https://keepachangelog.com/es-ES/1.1.0/). Al no haber releases semver formales, las entradas se ordenan por fecha.
-
-Para contexto detallado del trabajo diario ver `docs/diary/`. Para decisiones arquitecturales ver `docs/adr/`.
-
-## [Unreleased]
-
-## 2026-05-17
-
-### Added
-
-- **Bloque `service:` en frontmatter de `app.md`** (issue 0105) — toda app con `tag: service` declara ahora `port`, `health_endpoint`, `health_timeout_s`, `systemd_unit`, `systemd_scope`, `restart_policy`, `runtime` (`systemd-user|systemd-system|docker-compose|stdio|manual`), `pc_targets[]`, `is_local_only`. 11 apps actualizadas: `sqlite_api`, `dag_engine`, `call_monitor`, `kanban`, `deploy_server`, `registry_mcp`, `registry_api`, `footprint_geo_stack`, `element_matrix_chat`, `agents_and_robots`, `services_api`.
-- **Migration `014_service_metadata.sql`** — anade 8 columnas (`service_port`, `service_health_endpoint`, `service_health_timeout_s`, `service_systemd_unit`, `service_systemd_scope`, `service_restart_policy`, `service_runtime`, `service_is_local_only`) a `apps` + tabla nueva `service_targets (app_id, pc_id, role)` con indices por `app_id` y `pc_id`.
-- **`registry.App.Service *ServiceSpec`** + parser `rawService` + escritura/lectura en `InsertApp`/`scanApps`/`Purge` (preserva `service_targets`). API publica `db.GetServicePCTargets(appID) []string`.
-- **`audit_services_spec_go_infra`** (`functions/infra/audit_services_spec.{go,md}`) — audita apps `tag: service` y reporta drift del bloque `service:` (runtime allowlist, pc_targets >=1, systemd_unit obligatorio si `runtime` empieza con `systemd-`, restart_policy en `always|on-failure|none`).
-- **`fn doctor services-spec`** — subcomando nuevo en `cmd/fn/doctor.go`. Salida tabwriter + `--json`. Hoy: `11/11 services with complete service: block`.
-- **App `services_api`** (`apps/services_api/`, issue 0106) — Go HTTP daemon en `127.0.0.1:8485`. Loop paralelo cada 15s (max 8 in-flight, timeout 20s/probe) que reconcilia esperado vs real para cada `(app, pc)` cruzado de `service_targets`. Probes locales (`systemctl is-active` + TCP dial + `http.Client`) o remotos (`ssh_exec_go_infra`). Persiste en `operations.db`: `service_state` (snapshot actual) + `service_transition` (cambios de overall append-only). Endpoints `GET /api/health`, `GET /api/services`, `POST /api/check`, `GET /api/pcs`. systemd unit `~/.config/systemd/user/services_api.service` con `Restart=always`.
-- **App `services_monitor`** (`apps/services_monitor/`, issue 0106) — frontend C++ ImGui. Polling auto cada 5s configurable + boton "Force check" (POST `/api/check`). Tabla 9-col agrupada por app: overall pill, systemd state, port + listening flag (`TI_PLUG`/`TI_PLUG_CONNECTED`), HTTP status+latency, runtime, last change age, error/note. JSON via `vendor/nlohmann/json.hpp` (copiado de data_factory). HTTP socket TCP via `http_client.{cpp,h}` (copiado de data_factory). Build linux + windows con `add_imgui_app` + ws2_32 en Win. Deploy automatico via `redeploy_cpp_app_windows`.
-- **Issues 0105 + 0106** (`dev/issues/`) — estandarizacion del bloque `service:` y app `services_monitor`.
-
-### Fixed
-
-- **`sqlite_api.service` murio 20h sin alerta el 2026-05-17** — Raiz: el unit tenia `Restart=on-failure` y el ultimo exit fue por `SIGTERM` (limpio, no failure). systemd NO reinicia exit success. Fix: cambio a `Restart=always` + `RestartSec=5`. Reload + restart inmediato. Detectado mientras se debuggeaba `data_factory` cargando lento (raiz: data_factory llama a `sqlite_api:8484`, timeout 3s, no responde). Aplicado el mismo `Restart=always` al unit nuevo `services_api.service`.
-- **`sqlite_api/app.md` health_endpoint** — declaraba `/api/status` que devuelve 404. Cambiado a `/api/databases` (200, lista de bases registradas). Detectado por el primer ciclo del propio `services_api` que marcaba sqlite_api como `degraded`.
-
-### Changed
-
-- **`services_monitor` tags** — sin `service`/`services` en `tags` para evitar falso positivo en el matcher `tags LIKE '%service%'` del audit `services-spec`. La app es desktop client (frontend), no daemon.
-
-## 2026-05-16
-
-### Added
-
-- **Panel "Logs" en `dag_engine` RunDetail** — `apps/dag_engine/frontend/src/pages/RunDetail.tsx` anade `<Paper>` final con `<Code block>` scrollable + `CopyButton` de Mantine. Helper `buildLogText(run, steps)` compone texto plano (metadata del run + por-step status/exit/duration/stdout/stderr indentado) para pegar entero al LLM sin abrir los `Collapse` del `StepTimeline`.
-
-### Fixed
-
-- **`dag_engine` steps `function:` fallando con `error: function "<id>" not found (tried as ID and name)`** — tres DAGs nocturnos (`fn_backup` x2, `daily-registry-audit`) fallaron 2026-05-15/16 porque el binario `fn` resolvia una copia stale `apps/dag_engine/registry.db` (May 15, 262 KB) en vez del `registry.db` raiz. Raiz: el systemd unit `dag_engine.service` tiene `WorkingDirectory=apps/dag_engine/` y no exportaba `FN_REGISTRY_ROOT`; `cmd/fn/ops.go::tryOpenRegistryDB` cae al walk-up `go.mod` (devuelve `apps/dag_engine/`). Fix:
-  - Borrado `apps/dag_engine/registry.db` stale (violaba `.claude/rules/db_locations.md`).
-  - `~/.config/systemd/user/dag_engine.service`: anadido `Environment=FN_REGISTRY_ROOT`, `FN_BIN`, `PATH` (con `/usr/local/go/bin` para steps `function:` Go sin tests que invocan `go vet`), `HOME`.
-  - `apps/dag_engine/executor.go`: steps `function:` exportan `FN_REGISTRY_ROOT=<root>` en env y default `dir = fnRegistryRoot` si `step.Dir`/`dag.WorkingDir` vacios. Steps `command:`/`script:` sin cambio.
-
-### Added
-
-- **Iconos `.ico` Windows para apps C++** — 11 apps GUI (`chart_demo`, `dag_engine_ui`, `data_factory`, `graph_explorer`, `navegator_dashboard`, `odr_console`, `primitives_gallery`, `registry_dashboard`, `shaders_lab`, `text_editor_smoke`, `altsnap_jitter_test`) ahora tienen icono propio en el `.exe` y en `<exe_dir>` desplegado.
-  - Glyphs: **Phosphor Icons** (`fill` weight), clonado en `sources/phosphor-core/` (1512 SVGs disponibles). Cada app usa un `accent_hex` distinto (Tailwind 500-700) para distinguirse en taskbar/desktop.
-  - Mapping inicial en `dev/gen_app_icons.py` (script reproducible). Cada `.ico` multi-resolucion (16/24/32/48/64/128/256).
-  - Wiring CMake: `cpp/CMakeLists.txt:1-5` declara `LANGUAGES C CXX RC` en WIN32; `add_imgui_app` macro detecta `<app_dir>/appicon.ico` y genera `<target>_appicon.rc` enlazado via `windres` (toolchain `cpp/toolchains/mingw-w64.cmake`).
-  - Nueva funcion del registry: `generate_app_icon_py_infra` (`python/functions/infra/generate_app_icon.{py,md}`). Toma `phosphor_icon_name + accent_hex + out_ico_path` y exporta `.ico` multi-res. Tags: `cpp-windows`, `icon`, `phosphor`.
-  - Convencion documentada en `.claude/rules/cpp_apps.md §11`.
-
-- **C++ framework — Alt+RMB resize / Alt+LMB move anywhere** (`cpp/framework/app_base.cpp`). WndProc subclass detecta `WM_RBUTTONDOWN`/`WM_LBUTTONDOWN` con `GetAsyncKeyState(VK_MENU) & 0x8000`, `ReleaseCapture` + `PostMessage(WM_SYSCOMMAND, SC_SIZE|dir | SC_MOVE|HTCAPTION)`. Modal nativo, cero jitter automatico via gate sizemove existente. Aplica a main + cada viewport flotante (subclass per-frame).
-- **C++ framework — multi-HWND subclass** para anti-jitter. `g_subclassed` ahora `unordered_map<HWND, WNDPROC>`, scan per-frame en `pio.Viewports` instala subclass en cada HWND nuevo, `prune_dead_subclassed()` con `IsWindow`, `uninstall_sizemove_subclass_all()` al exit. Fix del temblor en paneles flotantes (no solo el main HWND).
-- **C++ framework — iconified survival** de paneles flotantes. Antes `glfwWaitEvents+continue` paraba el frame loop entero al minimizar el main → secondary viewports congelados/ocultos. Ahora detecta secondary viewports y fall-through al frame normal si existen; solo duerme cuando no hay flotantes.
-- **C++ framework — `fn::internal::*` test observability**. `sizemove_enter_count()`, `alt_rmb_resize_count()`, `alt_lmb_move_count()`, `rbuttondown_seen_count()`, `set_force_alt_for_test(bool)`. Counters monotonicos zero-cost, modo test salta `PostMessage SC_SIZE/SC_MOVE` para no atrapar al harness en modal.
-- **`apps/altsnap_jitter_test/`** — extendido a 6 phases (p1 sync, p2 main HWND modal, p3 secondary HWND modal, p4 iconify+restore preserva floating, p5 Alt+RMB consumed, p6 Alt+LMB consumed). Todas PASS en Windows.
-- **`redeploy_all_cpp_apps_bash_pipelines`** — pipeline nuevo `bash/functions/pipelines/redeploy_all_cpp_apps.sh` que cross-compila todo el arbol `cpp/` en un solo cmake pass + redeploy de cada `.exe` al Desktop. Filtro opcional por substring de nombre. Tolerante a fallos (build best-effort, summary OK/SKIPPED/FAILED). Tags: `cpp, windows, deploy, redeploy, bulk, cpp-windows`. Composicion: `build_cpp_windows_bash_infra` + loop `taskkill.exe` + `deploy_cpp_exe_to_windows_bash_infra`.
-
-### Changed
-
-- **`io.ConfigWindowsMoveFromTitleBarOnly = true`** en `fn::run_app`. Floating panels (viewport secundario = OS window borderless con UNA ventana ImGui rellenandolo) ahora respetan "solo header arrastra" como las decoradas. Fix del drag-anywhere-sin-alt en panel flotante. Alt+LMB anywhere sigue funcionando (subclass consume antes que ImGui).
-- **`resolve_cpp_app_dir_bash_infra` v1.1.0** — ahora busca apps tambien en `apps/<X>/` (canonical issue 0096) ademas de `cpp/apps/<X>/` (legacy) y `projects/*/apps/<X>/`. Fix retroactivo: `./fn run compile_cpp_app <name>` fallaba para apps en el layout canonical (ej. `dag_engine_ui`). Deduccion desde CWD tambien actualizada. Helper interno `_list_cpp_apps`.
-
-### Notes
-
-- Apps C++ redesplegadas via `redeploy_all_cpp_apps`: 12 OK / 1 SKIP (`data_factory` sin .exe target) / 0 FAILED. Todas tienen los fixes del framework activos.
-- ImGui_ImplGlfw subclassea el HWND DESPUES que nuestro framework. ImGui captura nuestro WndProc como `PrevWndProc` y chainea via `CallWindowProc`, asi que el subclass nuestro sigue recibiendo TODOS los mensajes en el orden correcto. NO re-subclassear despues de ImGui init (provoca recursion infinita por cycle: `our_proc -> orig=imgui_proc -> imgui_proc -> prev=our_proc -> ...`).
-- Pre-existing build break en `cpp/tests/test_llm_anthropic.cpp` + `cpp/tests/test_graph_icons.cpp` por uso de `setenv()` que no existe en mingw-w64. NO bloquea `redeploy_all_cpp_apps` (build best-effort). Candidato a guard `#ifdef _WIN32` con `_putenv_s` o skip cross-compile. No introducido por esta sesion.
-
-## 2026-05-14
-
-### Added
-
-- **Issue 0086 — Monitor tab del `registry_dashboard`** (sub-repo `dataforge/registry_dashboard`). Pestaña `Monitor` primera y por defecto del TabBar, landing del bucle reactivo construir->ejecutar->recopilar->analizar->mejorar.
-  - 7 KPIs (Calls / MCP / Reg % / Errors / Violations / Copies / Versions) filtradas por ventana temporal (1h/24h/7d/30d/All).
-  - Sub-tab `Recent Executions` con columnas When/Function/Tool/ms/OK/Error. Columna Function muestra `$ <snippet>` en gris cuando `function_id` vacio, hover tooltip con comando completo. Checkbox `Only registry functions` filtra por `function_id != ''`.
-  - Sub-tab `Failed Functions` (5a) — subset filtrado a registry-functions fallidas, columnas When/Function/Tool/Error class/Error snippet, function_id en rojo.
-  - Live scatter `duracion (ms)` vs `time`: eje X auto-scroll a `now`, ventana configurable (1m/5m/15m/1h/6h) independiente del filtro de KPIs, eje Y dinamico `0..max(visible)+500ms`. Hora local (`UseLocalTime`). Series ok/error en verde/rojo. Hover sobre punto = tooltip Function/Tool/Duration/Error.
-  - Indicador `live`/`offline` con timestamp del ultimo evento WS.
-- **WebSocket live stream sqlite_api -> registry_dashboard** (sub-repo `dataforge/sqlite_api`). Endpoint `GET /api/events/call_monitor`. Hub global con subscribers; ticker arranca solo con >=1 subscriber (cero overhead si nadie mira). Cliente recibe snapshot inicial (KPIs + 100 ultimas filas + watermark) y luego deltas `id > watermark`. Cliente puede mandar `{watermark: N}` para resumir tras reconexion.
-- **WS client C++** hand-rolled RFC6455 en `ws_client.{h,cpp}` (~330 LOC) en el dashboard. Localhost-only (no TLS). Thread propio, reconnect exponencial 0.5s->8s, FIN/text/ping/pong/close handling, queue thread-safe drenada cada frame.
-- **Migration 007 `command_snippet` en `calls`** (`projects/fn_monitoring/apps/call_monitor/migrations/007_calls_command_snippet.sql`). Aditiva, idempotente. Llena por hook `hook_call_monitor.sh` solo cuando `function_id == ''`. Redactado de `password=`/`token=`/`secret=`/`api_key=`/`bearer=`. Truncado 200 chars.
-- **Issue 0087 — Capability Discovery Acceleration**. Modelo 5 capas + 7 piezas (ver `dev/issues/0087-*.md`).
-  - **`fn match`** (`cmd/fn/match.go`) — subcommand fuzzy-FTS5 que dado un comando devuelve top-N funciones del registry candidates. Latencia 6-7ms. Output JSON con `score` (normalizado top=1.0) + `raw_score` (absoluto pre-normalizacion) + `high_confidence` gate (`raw_score >= 4.0 AND top1.raw/top2.raw > 1.5`).
-  - **`fn doctor capabilities --emit-claude-md`** (`cmd/fn/doctor.go` + `functions/infra/emit_capabilities_md.go`) — emite bloque markdown con secciones TOP 20 (por `calls_total`), Fresh 7d, Pipelines top 5. Fallback si `call_monitor.operations.db` ausente.
-  - **`call_monitor sequences --detect [--propose]`** (`projects/fn_monitoring/apps/call_monitor/sequences.go` + `migrations/006_function_sequences.sql`). Detecta secuencias A->B(->C) en `calls` (same session, gap < 30s, occ >= 5, sess >= 2, success_rate >= 0.9) y abre proposals `new_pipeline` automaticamente.
-  - **Hook `PreToolUse` `hook_fn_match.sh`** — denylist + `fn match` con timeout 0.2s. Inyecta `<system-reminder>FUZZY-MATCH: USE ./fn run <id>` cuando confidence alta. Latencia 113ms trigger / 32ms denylist. Registrado en `.claude/settings.local.json` (Bash matcher).
-  - **Hook `UserPromptSubmit` `hook_capabilities_inject.sh`** — cache 1h en `~/.cache/fn_registry/capabilities.txt`. Emite JSON `hookSpecificOutput.additionalContext` con linea compacta `CAPABILITIES: TOP / FRESH / PIPELINES`. Latencia cold 33ms / warm 18ms.
-  - **Timer systemd user** `call_monitor_sequences.timer` (OnCalendar 0/6h) + `.service` oneshot ejecutando `call_monitor sequences --detect --propose --report`. Versionado en `projects/fn_monitoring/apps/call_monitor/systemd/`.
-- **3 funciones nuevas grupo `cpp-windows`** + pagina madre `docs/capabilities/cpp-windows.md`:
-  - `launch_cpp_app_windows_bash_infra` — `cmd.exe`/`PowerShell Start-Process` para lanzar exe en Windows desde WSL2.
-  - `is_cpp_app_running_windows_bash_infra` — `tasklist.exe /FI` con exit code 0/1 + stdout `RUNNING: PID=N MEM=K` o `NOT_RUNNING`.
-  - `redeploy_cpp_app_windows_bash_pipelines` — pipeline build? + deploy + launch + verify en 1 invocacion. Reemplaza ~6 commands manuales.
-- **ADR 0004 `docs/adr/0004-telemetry-driven-capability-growth.md`** — formaliza el bucle telemetria -> proposal -> capability group -> discovery acceleration como motor de crecimiento del registry.
-- **Regla `.claude/rules/function_growth_and_self_docs.md`** (entry #30 en `INDEX.md`) — contrato `.md` autosuficiente (Ejemplo + Cuando usarla + Gotchas + Growth log) + crecimiento del registry por promocion de composiciones, NO por inflado de funciones individuales.
-
-### Changed
-
-- **`.claude/CLAUDE.md` Norte ampliado** — 4o objetivo `PROMOVER COMPOSICIONES A PIPELINES` (el registry crece por composicion, no por inflado). Linea sobre auto-discovery zero-second-lookup.
-- **`.claude/rules/registry_calls.md`** — clausula nueva: hooks e infraestructura de telemetria (`fn_match`, `fn doctor`, `call_monitor`) pueden leer `registry.db` directo con conexion read-only. NO sujeto a regla MCP-first (no son acciones del agente).
-- **`/fn_claude` command** mejorado con objetivos del Monitor + interpretacion de `FUZZY-MATCH` hint + `CAPABILITIES` line + threshold semantica.
-
-### Fixed
-
-- **`launch_cpp_app_windows` quoting bug** — `cmd.exe /c "cd /d \"$dir\" && start ..."` rompia con paths Windows (el `\"` final se interpretaba como escape de comilla -> string sin cerrar -> "Windows cannot find \\"). Fix: reescribir a `powershell.exe -Command "Start-Process -FilePath ... -WorkingDirectory ..."` (single-quote PowerShell es literal, sin procesar `\` ni `$`).
-- **`fn match high_confidence` siempre true** — debido a normalizacion `top=1.0`. Fix: añadir `raw_score` preservado pre-normalizacion + gate dual `raw_score >= 4.0 AND top1.raw/top2.raw > 1.5`. Threshold 4.0 tuneado contra 14 patrones del analysis `domain_coverage_gaps` (~93% precision).
-
-## 2026-05-07
-
-### Added
-
-- **`fn doctor` CLI** (`cmd/fn/doctor.go`) — entrypoint unico read-only para diagnostico del registry y artefactos. Subcomandos: `artefacts` (git/venv/app.md/upstream), `services` (apps tag service + systemctl + puerto), `sync` (drift `pc_locations` BD vs disco), `uses-functions` (imports reales vs declarados en `app.md`), `unused` (funciones sin consumidores). Flag `--json` para agentes/scripts. Cada subcomando es wrapper fino sobre una funcion del registry.
-- `.claude/rules/fn_doctor.md` — regla 23 en `INDEX.md`. Documenta cuando usar, mapeo subcomando → funcion del registry, y acciones derivadas (que hacer cuando reporta un drift).
-- `bash/functions/infra/backup_sqlite_db` (`backup_sqlite_db_bash_infra`, **impure**) — snapshot atomico de SQLite via `VACUUM INTO`. Mas seguro que `cp` con escrituras concurrentes.
-- `bash/functions/infra/rotate_backups` (`rotate_backups_bash_infra`, **impure**) — retention rsnapshot-style `daily.N/weekly.M/monthly.K`.
-- `bash/functions/infra/wait_for_http` (`wait_for_http_bash_infra`, **impure**) — poll URL hasta 2xx con timeout, util en deploys/smoke tests.
-- `bash/functions/infra/wait_for_port` (`wait_for_port_bash_infra`, **impure**) — poll TCP host:puerto. Usa `nc` o `/dev/tcp` builtin (sin deps).
-- `bash/functions/infra/port_kill` (`port_kill_bash_infra`, **impure**) — mata proceso(s) escuchando un puerto. Idempotente, fallback `KILL` tras `TERM`.
-- `bash/functions/infra/tail_journal` (`tail_journal_bash_infra`, **impure**) — wrapper `journalctl` con auto-deteccion `--user` vs sistema, prioridad y `--since`.
-- `bash/functions/infra/pre_commit_hook_install` (`pre_commit_hook_install_bash_infra`, **impure**) — instala hook que llama `scan_secrets_in_dirty_bash_cybersecurity` antes de cada commit. Idempotente con marca `fn_registry-pre-commit-v1`.
-- `functions/infra/notify_telegram` (`notify_telegram_go_infra`, **impure**) — envia mensaje a chat Telegram via Bot API. Trunca >4096 chars.
-- `functions/infra/artefact_doctor` (`artefact_doctor_go_infra`, **impure**) — audita salud de cada app/analysis: dir existe, `.git` presente, manifest parseable, `.venv` valido (analyses), upstream configurado.
-- `functions/infra/services_status` (`services_status_go_infra`, **impure**) — apps con tag `service` + `systemctl is-active` (user/system) + puerto declarado en notes/description + check TCP localhost.
-- `functions/infra/pc_locations_drift` (`pc_locations_drift_go_infra`, **impure**) — detecta drift `pc_locations` BD vs disco para el PC actual (`~/.fn_pc`). Tres tipos: `missing_on_disk`, `untracked_on_disk`, `status_should_be_active`.
-- `functions/infra/audit_uses_functions` (`audit_uses_functions_go_infra`, **impure**) — para cada app Go/Py compara imports reales contra `uses_functions` del `app.md`. Reporta `missing_in_app_md` y `unused_in_app_md`. Heuristica documentada (puede dar falsos positivos en `unused`).
-- `functions/infra/find_unused_functions` (`find_unused_functions_go_infra`, **impure**) — funciones del registry sin consumidores en otras funciones, apps o analyses. Pipelines sin tag `launcher` tambien aparecen.
-- `bash/functions/pipelines/backup_all` (`backup_all_bash_pipelines`, **impure**, tag `launcher`) — orquesta `backup_sqlite_db` + `rotate_backups` sobre `registry.db`, cada `apps/*/operations.db`, y rsync `--link-dest` para vaults declarados en `projects/*/vaults/vault.yaml`.
-
-### Changed
-
-- `.claude/CLAUDE.md` — seccion CLI ampliada con comandos `fn doctor [subcommand] [--json]` y enlace a la regla.
-- `.claude/rules/INDEX.md` — anadida fila 23 para `fn_doctor.md`.
-
-### Fixed
-
-- `functions/infra/pc_locations_drift.go` — `filepath.Join(absoluto, absoluto)` producia paths corruptos cuando `dir_path` ya era absoluto (caso comun: filas `pc_locations` traen path absoluto al disco del PC). Fix: chequear `filepath.IsAbs` antes de unir. Sintoma previo: todos los artefactos reportados como `missing_on_disk` aunque existieran.
-- `go.mod` — `golang.org/x/net` movido a deps directas (`go mod tidy` tras anadir `notify_telegram`).
-
-### Notes
-
-- Hallazgo de la primera ejecucion `fn doctor uses-functions`: 7/12 apps con drift real (`auto_metabase`, `dag_engine`, `deploy_server`, `docker_tui`, `kanban`, `metabase_registry`, `script_navegador`). Pendiente sincronizar sus `app.md` con los imports reales en sesion futura.
-- `fn doctor unused` muestra muchas funciones core sin consumidores aun (`compose2_go_core`, `curry2_go_core`, etc.). Esperado: el registry crece antes que las apps que las consuman.
-
-## 2026-05-04
-
-### Added
-
-- `cpp/functions/viz/graph_labels_select` (`graph_labels_select_cpp_viz`, **pure**) — TU separado de `graph_labels` con los helpers puros `graph_compute_degrees` y `graph_labels_select` (frustum cull + always_for_* + top-N por `size * (degree+1)`). Vive en su propio archivo para que los tests unitarios lo cubran sin abrir ImGui.
-- `cpp/functions/viz/graph_viewport_selection` (`graph_viewport_selection_cpp_viz`, **pure**) — TU separado de `graph_viewport` con `clear_selection`, `is_selected`, `add_to_selection`, `toggle_selection`. Mantienen sincronizados `state.selection` y `nodes[i].flags & NF_SELECTED`.
-- `cpp/functions/viz/graph_types` (`graph_types_cpp_viz`, **pure**) — TU de implementacion de `GraphData::update_bounds()` y `GraphData::find_node_by_user_data()`. Pareja obligatoria del header del tipo (`graph_types.h` indexado en `types/viz/`).
-- `cpp/apps/chart_demo/app.md` — la demo de primitivos viz (line/scatter/bar/heatmap) ahora aparece en el registry como `chart_demo_cpp_viz`.
-- `cpp/apps/shaders_lab/app.md` — el live GLSL playground con DAG ahora tiene `app.md` propio (antes solo existia entrada legacy en BD sin `.md` en disco).
-
-### Changed
-
-- `registry/indexer.go` — el indexer ahora escanea tambien `<lang>/apps/*/app.md` (mismo patron que ya usaba para `<lang>/functions/` y `<lang>/types/`). Antes solo veia `apps/` y `projects/*/apps/` — las apps en `cpp/apps/` quedaban invisibles. `./fn index` reporta 17 apps (antes 15).
-- `cpp/functions/viz/graph_labels.md` — `signature` reducida a `graph_labels_draw` y `graph_labels_draw_at` (los helpers puros pasan a entrada propia). `uses_functions` apunta a la nueva entrada `graph_labels_select_cpp_viz`.
-- `cpp/functions/viz/graph_viewport.md` — `uses_functions` añade `graph_viewport_selection_cpp_viz`.
-- `projects/osint_graph/apps/graph_explorer/app.md` — `uses_functions` sincronizado con `CMakeLists.txt`: ahora declara las 23 funciones del registry que enlaza (antes 15). Añadidas: `graph_viewport_selection`, `graph_labels_select`, `graph_types`, `graph_spatial_hash`, `button`, `icon_button`, `badge`, `empty_state`.
-- `projects/fn_monitoring/apps/registry_dashboard/app.md` — `uses_functions` sincronizado con `CMakeLists.txt` (21 deps, antes 9). Añadidas: `badge`, `button`, `empty_state`, `icon_button`, `modal_dialog`, `page_header`, `process_runner`, `process_state_machine`, `select`, `text_input`, `toast`, `toolbar`, `tree_view`. Removido: `fps_overlay` (vive en `fn_framework`, no se declara).
-
-### Decisions
-
-- ADR `0003-orphan-tu-as-separate-function-entry.md` — cuando una funcion del registry necesita partir su `.cpp` en varios TUs por testabilidad o separacion ImGui-vs-puro, cada TU adicional se registra como entrada propia con su `.md` en lugar de extender `file_path` para listar varios archivos. El parent declara la nueva entrada en `uses_functions`. Razon: el indexer asume `1 .cpp = 1 .md`; un `file_path` multi-archivo rompe la convencion y deja apps nuevas sin saber que TUs enlazar.
-
-### Added — sesion NER+RE para graph_explorer (tarde, 980 → 990 funciones)
-
-**18 funciones nuevas** sobre el ecosistema NER+RE, en dos rondas de `fn-constructor`:
-
-Ronda 1 — extraccion de relaciones (mREBEL/REBEL/MarianMT):
-- `python/functions/datascience/parse_rebel_output.py` (pure) — parser wire `<triplet>` REBEL/mREBEL.
-- `python/functions/datascience/align_relations_to_entities.py` (pure) — string-match aligner.
-- `python/functions/datascience/mrebel_load_model.py` (impure, **CC BY-NC-SA 4.0 — NO comercial**).
-- `python/functions/datascience/mrebel_base_load_model.py` (impure, misma licencia).
-- `python/functions/datascience/rebel_load_model.py` (impure, **Apache 2.0**, EN-only).
-- `python/functions/datascience/marianmt_es_en_load_model.py` (impure) — Helsinki-NLP/opus-mt-es-en.
-- `python/functions/datascience/translate_es_to_en.py` (impure) — wrapper traduccion frase a frase.
-- `python/functions/datascience/extract_relations_mrebel.py` (impure) — pipeline mREBEL frase-a-frase + alineamiento.
-- 21 tests pytest verdes.
-
-Ronda 2 — pipeline GLiNER2 + OpenIE schema-less + composicion (tarde):
-- `python/functions/core/clean_pdf_text.py` (pure) — limpia artefactos PyPDF2.
-- `python/functions/core/chunk_with_overlap.py` (pure) — sliding window con avance forzado.
-- `python/functions/core/merge_entity_aliases.py` (pure) — coreferencia normalize+substring.
-- `python/functions/core/filter_relations_by_entity_types.py` (pure) — post-filter typed.
-- `python/functions/core/aggregate_extraction_results.py` (pure) — dedupe + Counter sobre N chunks.
-- `python/functions/datascience/gliner2_load_model.py` (impure, **Apache 2.0**) — `fastino/gliner2-large-v1`.
-- `python/functions/datascience/extract_graph_gliner2.py` (impure) — wrapper schema + threshold + include_confidence.
-- `python/functions/datascience/spacy_es_load_model.py` (impure) — `es_core_news_md` cacheado.
-- `python/functions/datascience/extract_triples_spacy_es.py` (impure) — OpenIE schema-less ES por reglas de dependencia (verbo del texto = predicado).
-- `python/functions/pipelines/extract_graph_from_text.py` (impure pipeline) — composicion E2E: chunk → extract_graph_gliner2 (×N) → aggregate → filter typed → merge aliases → grafo final.
-- 39 tests pytest verdes.
-
-### Added — analysis `gliner_glirel_tuning`
-
-`projects/osint_graph/analysis/gliner_glirel_tuning/` — investigacion empirica de modelos NER/RE. **9 notebooks** ejecutados:
-
-| # | Notebook | Hallazgo clave |
-|---|---|---|
-| 01 | `01_gliner_glirel_tuning.ipynb` | Calibracion de thresholds GLiNER+GLiREL |
-| 02 | `02_e2e_spanish_graph.ipynb` | E2E texto ES — descubrimiento del fail de GLiREL en castellano |
-| 03 | `03_mrebel_vs_glirel.ipynb` | mREBEL gana a GLiREL pero CC BY-NC-SA |
-| 04 | `04_gliner2_winner.ipynb` ⭐ | **GLiNER2 (Apache 2.0, NER+RE joint, 340M)** elegido como motor principal |
-| 05 | `05_long_text_and_pdf.ipynb` | Pipeline PDF E2E sobre `politica_proteccion_datos.pdf` (BBVA, 89.882 chars) |
-| 06 | `06_improvements.ipynb` | Threshold 0.3 (vs default 0.5) → +187% relaciones; coref reduce 18% aislados |
-| 07 | `07_nuextract_vs_gliner2.ipynb` | NuExtract GPU 2.6× mas lento, calidad similar — descartado por defecto |
-| 08 | `08_improving_gliner2.ipynb` | snake_case verbal labels + post-filter typed = mejor combo |
-| 09 | `09_spacy_es_openie.ipynb` | spaCy ES dep-rules: schema-less, predicado = verbo del texto |
-
-### Added — vault `osint_nlp_models`
-
-`projects/osint_graph/vaults/osint_nlp_models` (symlink a `~/vaults/osint_nlp_models/`):
-- `models/` — fichas de gliner, glirel, mrebel, gliner2, candidates a probar.
-- `decisions/` — 3 ADRs cortos del 2026-05-04 (mrebel-over-glirel mañana, gliner2-over-mrebel tarde, license-constraint).
-- `benchmarks/corpus_v1.md` + `results_log.csv` (15 filas de experimentos).
-- `test_documents/politica_proteccion_datos.pdf` (PDF de BBVA copiado para reproducibilidad).
-
-### Added — playground HTML
-
-`projects/osint_graph/analysis/gliner_glirel_tuning/playground/`:
-- `server.py` — FastAPI con GLiNER2 cacheado, endpoints `GET /` (HTML) y `POST /extract` (texto → grafo).
-- `index.html` — UI: textarea, KPIs (nodos/aristas/tiempo), grafo Sigma.js, JSON exportable.
-- `static/sigma.min.js` + `graphology.umd.min.js` (servidos localmente para evitar bloqueo CDN por extensiones tipo MetaMask/SES).
-
-Stack aplicado por el server:
-1. snake_case verbal labels (`works_at`, `ceo_of`, `headquartered_in`, `agreement_with`...)
-2. threshold 0.3 (configurable)
-3. chunking automatico > 1500 chars
-4. post-filter typed (`(person, organization)` validos por relacion)
-5. coreferencia normalize+substring
-6. layout server-side via `networkx.spring_layout`
-7. render Sigma.js (sin fisica → sin loops de ResizeObserver)
-
-### Added — issues
-
-- `dev/issues/0050-jupyter-exec-collab-client-failure.md` — bug `jupyter_exec` con cliente colaborativo + workaround documentado.
-- `projects/osint_graph/apps/graph_explorer/issues/0041-split-confidence-thresholds.md` — split `confidence_threshold` en `entity_threshold` + `relation_threshold`.
-- `projects/osint_graph/apps/graph_explorer/issues/0042-gliner2-unified-extractor.md` ⭐ — sustituir GLiREL por GLiNER2 en `extract_graph_hybrid`. Reemplaza 0042-mrebel.
-- `projects/osint_graph/apps/graph_explorer/issues/0042-mrebel-relation-extractor.md.superseded` — version mREBEL del 0042 archivada al ganar GLiNER2.
-
-### Changed
-
-- `cpp/CMakeLists.txt` — `_GE_DIR` y `_DASH_DIR` sobreescribibles via `-D<...>=<path>` para builds en worktrees (commit `e72d6364`). Habilita `parallel-fix-issues` sobre apps C++.
-- `python/functions/datascience/glirel_load_model.py` — workaround compat `huggingface_hub` 1.x: classmethod monkey-patch idempotente para inyectar `proxies`/`resume_download` que el HF nuevo dejo de pasar (commit `3b3378cf`).
-- Sub-repo `dataforge/graph_explorer` master local: merges `--no-ff` de `issue/0035e-polish-and-tests` (commit `f614a51`) + `issue/0013-paste-extract-panel` (commit `2a49c2b`). 125/125 tests pytest verdes. **Sin push aun** — pendiente confirmacion + validacion Windows.
-
-### Fixed (bugs encontrados + raiz + fix)
-
-| Bug | Raiz | Fix |
-|---|---|---|
-| `chunk_with_overlap` bucle infinito | Frase mas larga que `max_chars`, no avanzaba `i`, OOM-killed por overlap acumulado | Avance forzado: meter al menos UNA frase aunque exceda `max_chars` |
-| NuExtract degenera en texto largo | Sin `repetition_penalty`, decoder entra en bucle de tokens repetidos hasta agotar 2048 max_new_tokens | `repetition_penalty=1.15` + chunking obligatorio (179/179 chunks parsed OK tras fix) |
-| NuExtract `AutoProcessor.from_pretrained` rota en transformers 5.x | Sub-processor de video tira `TypeError: argument of type 'NoneType' is not iterable` (Qwen2-VL) | Bypass: `AutoTokenizer` + `AutoModelForImageTextToText` directamente |
-| Vis-network ResizeObserver loop spam (en SES/MetaMask) | Vis-network usa physics simulation → ResizeObserver dispara warnings amplificados por SES | Migrar a Sigma.js + layout server-side via `networkx.spring_layout` (sin fisica frontend) |
-| `jupyter_exec append` HTTP 405 | `jupyter_nbmodel_client` espera collab WebSocket Y.js, no soportado al 100% por jupyter-collaboration nuevo | Documentado en issue 0050; workaround actual: build_notebook scripts con `nbformat` + `nbconvert --execute` |
-| Kernel startup shadows pip packages | `00_fn_registry.py` añade cada subdir de `python/functions/` a sys.path top-level → `bigquery/datasets.py` shadows HF `datasets` package needed by transformers | Workaround per-notebook: `sys.path = [p for p in sys.path if not p.startswith(_pf+'/')]` + añadir solo el padre. Issue futuro pendiente. |
-
-### Decisions — vault ADRs
-
-| Decision | Razon |
-|---|---|
-| **GLiNER2 (Apache 2.0)** sustituye a GLiREL en `extract_graph_hybrid` | 6/8 relaciones correctas vs 0/1 de GLiREL en es_corporate_short, 1.18s vs 22s de mREBEL, NER+RE en una pasada |
-| mREBEL queda como fallback (no comercial) | 4/5 correctas pero CC BY-NC-SA 4.0 + 25× mas lento |
-| spaCy ES dep-rules para OpenIE schema-less | Predicado = verbo del texto (`querer`, `abrazar`), 5ms/frase, sin alucinaciones |
-| Threshold `0.3` (vs default `0.5`) sweet spot | +187% relaciones manteniendo precision; 0.2 mete +22% entidades dudosas |
-| Coreferencia normalize+substring + post-filter typed = **gratis y decisivos** | Coref −18% aislados; post-filter elimina `Madrid president_of Persona` |
-| Translate ES→EN + triplet-extract EN **NO** vale la pena | Pierdes verbos del texto (`querer` → `loves`), +500ms-1s, +300MB MarianMT, riesgo nombres propios |
-
-## 2026-04-28
-
-### Added
-
-- `cpp/functions/core/app_about` (`app_about_cpp_core`) — ventana flotante About con `about_window_set_info(project, version, description)`, `about_window_menu_item("About...")` y `about_window_render()`. Render automatico via `fn::run_app` (cableado en `cpp/framework/app_base.cpp`).
-- `bash/functions/infra/ensure_repo_synced` (`ensure_repo_synced_bash_infra`) — pipeline idempotente que compone `gitea_create_repo` + `gitea_push_directory`: crea repo Gitea si falta, inicializa `.git` local si falta, commitea cambios pendientes y pushea. Defaults: owner `dataforge`, branch `master`.
-- `analysis.md` para 6 analyses que estaban en disco pero sin indexar: `agent_coding_eval`, `estudio_embeddings`, `estudio_mercados`, `ontology_graph`, `pruebas_jupyter`, `retrieving_graphs`. Ahora `./fn index` reporta 8 analyses (antes 2).
-- Repos `dataforge/<name>` creados en Gitea para apps y analyses que no estaban subidos: `agents_and_robots`, `element_matrix_chat`, `deploy_server`, `shaders_lab`, `voice_guide`, `agent_coding_eval`, `ontology_graph`, `turismo_spain`. Cada uno con `.gitignore` apropiado para excluir binarios, `.venv/`, `node_modules/`, `.jupyter*`, `operations.db*`.
-
-### Changed
-
-- `cpp/functions/core/app_menubar`: el item top-level `Settings...` pasa a ser un `BeginMenu("Settings")` con dos subitems: `Settings...` (ventana de `app_settings`) y `About...` (nuevo, ventana de `app_about`). Las apps que usan `fn_ui::app_menubar(nullptr, 0, nullptr)` heredan el cambio sin tocar nada.
-- `projects/fn_monitoring/apps/registry_dashboard/main.cpp`: cablea `fn_ui::about_window_set_info("fn_registry Dashboard", "0.2.0", "...")` antes de `fn::run_app`. Tabla `Apps` gana columna `Git` con valores `remote` (repo_url poblado), `local` (.git/ presente) o `-`.
-- `data.h`/`data.cpp`/`data_http.cpp` del dashboard: `AppRow` extendido con `repo_url` y `dir_path`.
-- 10 repos migrados de branch `main` a `master` para unificar convencion: `apps/{docker_tui,fuzzygraph,metabase_registry,pipeline_launcher,rapid_dashboards,script_navegador}`, `analysis/{estudio_embeddings,estudio_mercados,pruebas_jupyter,retrieving_graphs}`. Default branch en Gitea actualizado via API (`PATCH /repos/{owner}/{repo}` con `{"default_branch":"master"}`), branch `main` remota borrada.
-- `git config --global init.defaultBranch master` para que los proximos `git init` sean consistentes.
-- `/full-git-push`: descubre apps/analyses sin `.git` y ofrece inicializarlos con `ensure_repo_synced` automaticamente. Excluye `subrepos/` para evitar duplicacion (mirrors upstream).
-- `/full-git-pull`: tras `fn sync`, segunda pasada que clona los `dataforge/<name>` registrados en `apps`/`analysis` que no existan localmente — soluciona el "no pude recuperar la app en el otro PC".
-- `bash/functions/infra/ensure_repo_synced.sh`: localiza dependencias via `FN_REGISTRY_INFRA_DIR` o `FN_REGISTRY_ROOT`, robusto a sourcing desde zsh/bash.
-
-### Fixed
-
-- `projects/fn_monitoring/apps/sqlite_api/handlers.go|main.go|handlers_test.go` + nuevos `handlers_mutations.go` y `handlers_projects.go`: cableados endpoints `POST /add_app|add_analysis|add_vault|reindex` y `GET /projects` para que el dashboard pueda crear artefactos y navegar projects desde la actions bar (estado pendiente de varios dias en uncommitted, ahora versionado en `dataforge/sqlite_api`).
-- Bug operativo en `sqlite_api` (Windows): `SO_RCVTIMEO` se pasaba como `struct timeval` cuando Windows espera `DWORD ms` → timeout efectivo de 5 ms. Ya documentado en `app.md` del dashboard.
-
-## 2026-04-24
-
-### Added
-
-- 6 funciones `bash/infra/systemd_local_*` (install_unit, enable, start, restart, status, uninstall) para gestionar servicios systemd del sistema desde el registry (complementa las versiones remotas SSH ya existentes).
-- Pipeline `install_systemd_service_bash_pipelines` que compone las anteriores: genera unit file + install + enable + start + status.
-- Servicio systemd `sqlite_api.service` instalado y habilitado en aurgi-pc — arranque automático al iniciar WSL en `127.0.0.1:8484`.
-- `projects/fn_monitoring/launcher.sh` — launcher del dashboard (arranca API si no está + lanza ventana + cleanup).
-- Regla [`.claude/rules/kiss.md`](.claude/rules/kiss.md) — filosofía KISS para proyectos y apps.
-- Documentación ADR en `docs/adr/` con plantilla y ADR 0001 (experimento GitButler).
-- Diario en `docs/diary/` + slash command `/entrada_diario` para añadir entradas.
-- `CHANGELOG.md` (este archivo).
-- Submódulo `cpp/vendor/glfw` re-registrado con path limpio (antes heredado con path absoluto `/home/lucas/...`).
-- aurgi-pc registrado en el server centralizado (`registry.organic-machine.com`) con 18 pc_locations.
-
-### Changed
-
-- `registry.db` ahora está gitignorada. Es regenerable con `fn index` + completable con `fn sync`. Evita conflictos entre ramas y PCs.
-- `sqlite_api` ahora se distribuye como binario compilado (`projects/fn_monitoring/apps/sqlite_api/sqlite_api`) en lugar de `go run` al vuelo.
-
-### Fixed
-
-- `http_client.cpp` del dashboard: añadido `#include <cstdint>` requerido por mingw-w64 para cross-compile Windows (g++ Linux lo incluía transitivamente).
-- `registry_dashboard.exe` (Windows) ya no abre ventana de consola al lanzarse — enlazado como GUI app (`WIN32_EXECUTABLE TRUE` / `-mwindows`).
-
-### Added (design system C++)
-
-- `cpp/functions/core/tokens` — design tokens para dashboards ImGui (colors, spacing, radius, font_size) inspirados en `@fn_library` (Mantine v9). Paleta dark + indigo primary. `apply_dark_theme()` aplica los tokens al `ImGuiStyle` global.
-- `cpp/functions/core/badge` — etiqueta inline con 6 variantes (Default/Success/Warning/Error/Info/Outline). Equivalente a `<Badge>` de `@fn_library`.
-- `cpp/functions/core/empty_state` — placeholder centrado para tablas/listas vacías.
-- `cpp/functions/core/page_header` — header de página con título/subtítulo + hueco para acciones + separator.
-- `registry_dashboard` migrado a los nuevos componentes: `page_header_begin/end` en el header, `empty_state` en las 4 tablas cuando están vacías, `apply_dark_theme()` al primer frame. Sin hardcode de colores disperso.
-- `systemd_local_{enable,start,restart}`: stdout de `systemctl` redirigido a stderr para no contaminar el JSON capturado por el pipeline.
-- `.gitmodules`: entry fantasma `cpp/vendor/glfw` con path absoluto `/home/lucas/...` que bloqueaba `git submodule status` y el cross-compile Windows.
-
-### Removed
-
-- Integración de GitButler de Claude Code — binario `~/.local/bin/but`, plugin `gitbutler-tools`, skill `.claude/skills/gitbutler/`, hooks en `settings.json`, ramas `gitbutler/*` + `e-branch-*`, estado interno `.git/gitbutler/`. Ver [ADR 0001](docs/adr/0001-gitbutler-experiment.md) para motivos.

agents_dashboard.log

@@ -1,22 +0,0 @@
-[2026-05-22 23:18:14.872] [INFO] app start: Agents Dashboard
-[2026-05-22 23:24:12.811] [INFO] app start: Agents Dashboard
-[2026-05-22 23:24:14.628] [INFO] [connect] testing https://agents.organic-machine.com...
-[2026-05-22 23:24:14.758] [INFO] [connect] OK
-[2026-05-22 23:24:14.765] [INFO] [db] base_url saved
-[2026-05-22 23:24:14.765] [INFO] [fetch_agents] starting
-[2026-05-22 23:24:14.766] [INFO] [fetch_agents] requesting https://agents.organic-machine.com/agents
-[2026-05-22 23:24:14.903] [INFO] [fetch_agents] response status=200 err= body_len=3146
-[2026-05-22 23:24:14.904] [INFO] [fetch_agents] parsed 11 rows
-[2026-05-22 23:24:14.904] [INFO] [fetch_agents] done
-[2026-05-22 23:24:14.910] [INFO] [agents_panel] render n_rows=11 cells=121 specs=11
-[2026-05-22 23:27:07.469] [INFO] app start: Agents Dashboard
-[2026-05-22 23:27:08.242] [INFO] [agents_panel] render n_rows=11 cells=121 specs=11
-[2026-05-22 23:27:36.670] [INFO] app start: Agents Dashboard
-[2026-05-22 23:27:37.446] [INFO] [agents_panel] render n_rows=11 cells=121 specs=11
-[2026-05-22 23:28:07.068] [INFO] app start: Agents Dashboard
-[2026-05-22 23:30:03.025] [INFO] app start: Agents Dashboard
-[2026-05-22 23:30:38.605] [INFO] app start: Agents Dashboard
-[2026-05-22 23:30:48.267] [INFO] app start: Agents Dashboard
-[2026-05-22 23:40:58.931] [INFO] app start: Agents Dashboard
-[2026-05-22 23:41:16.455] [INFO] app start: Agents Dashboard
-[2026-05-22 23:42:35.646] [INFO] app start: Agents Dashboard

altsnap_jitter_test.log

@@ -1,4 +0,0 @@
-[2026-05-15 23:51:43.764] [INFO] app start: altsnap_jitter_test
-[2026-05-15 23:51:44.017] [INFO] app exit
-[2026-05-15 23:52:47.933] [INFO] app start: altsnap_jitter_test
-[2026-05-15 23:52:48.135] [INFO] app exit

bash/functions/browser/apply_chromium_cdp_flag.md

@@ -1,71 +0,0 @@
----
-name: apply_chromium_cdp_flag
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "apply_chromium_cdp_flag [--port N] [--network] [--fragment-path <path>] [--remove] [--dry-run]"
-description: "Gestiona de forma idempotente el fragmento /etc/chromium.d/cdp que activa Chrome DevTools Protocol global en todo chromium que el usuario lance en el equipo. Escribe, actualiza o borra el fragmento con backup automático."
-tags: [navegator, chromium, cdp, devtools, browser, automation, infra]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-params:
-  - name: "--port N"
-    desc: "Puerto TCP donde Chromium escuchará conexiones CDP. Default 9222."
-  - name: "--network"
-    desc: "Si se pasa, añade --remote-debugging-address=0.0.0.0 (accesible desde la red local). Por defecto solo loopback (127.0.0.1). Imprime advertencia de seguridad."
-  - name: "--fragment-path <path>"
-    desc: "Ruta del fragmento a escribir/borrar. Default /etc/chromium.d/cdp."
-  - name: "--remove"
-    desc: "Borra el fragmento (desactiva CDP global). Idempotente: si no existe, no-op."
-  - name: "--dry-run"
-    desc: "Imprime el fragmento que se escribiría sin tocar nada. No requiere sudo."
-output: "Sale 0 en éxito (aplicado, ya-aplicado, o eliminado). Sale != 0 en error con mensaje a stderr. En caso de actualización imprime ruta del backup creado."
-file_path: "bash/functions/browser/apply_chromium_cdp_flag.sh"
----
-
-## Ejemplo
-
-```bash
-# Activar CDP global en loopback puerto 9222 (proyecto web_scraping, regla 8)
-source bash/functions/browser/apply_chromium_cdp_flag.sh
-apply_chromium_cdp_flag
-
-# Previsualizar el fragmento sin escribir nada (no requiere sudo)
-apply_chromium_cdp_flag --port 9222 --dry-run
-
-# Puerto alternativo (para correr en paralelo al navegador del usuario)
-apply_chromium_cdp_flag --port 9333
-
-# Activar expuesto a la red local (RIESGO: cualquier host de la LAN puede controlar el navegador)
-apply_chromium_cdp_flag --port 9222 --network
-
-# Desactivar CDP global
-apply_chromium_cdp_flag --remove
-
-# Ruta personalizada (útil en pruebas o entornos chroot)
-apply_chromium_cdp_flag --port 9222 --fragment-path /tmp/test_cdp_fragment --dry-run
-```
-
-## Cuando usarla
-
-Al preparar un PC nuevo para controlar el chromium diario del usuario vía CDP (primer setup del proyecto `web_scraping`, regla 8). Al cambiar el puerto CDP del sistema. Al desactivar esa capacidad antes de prestar o formatear el equipo. Sustituye el paso manual "crear `/etc/chromium.d/cdp` con sudo" documentado en `CHROMIUM_SYSTEM.md`.
-
-## Gotchas
-
-- **Requiere sudo** para escribir bajo `/etc/`. En este equipo usar `pass show claude/sudo | sudo -S apply_chromium_cdp_flag` o ejecutar como root.
-- **`--network` (0.0.0.0) es un riesgo de seguridad serio**: cualquier máquina en la red local puede conectarse al puerto CDP y controlar Chromium completamente (leer cookies, sesiones, inyectar JavaScript). Solo usar en entornos de red aislados o laboratorios.
-- **El chromium ya abierto antes del cambio no hereda el flag** hasta que se reinicie. El fragmento solo se aplica en el próximo arranque de `/usr/bin/chromium`.
-- **Dos procesos chromium no pueden compartir el mismo puerto**. Si el usuario ya tiene un chromium con CDP en 9222, la automatización dedicada debe arrancar con `chrome_launch_go_browser` en otro puerto (ej. 9333) o usar `--port 9333` en esta función.
-- **Idempotente**: si el fragmento ya existe con contenido idéntico, la función sale 0 sin tocar nada ni crear backup.
-- **Backup automático**: al sobreescribir, crea `<path>.bak.YYYYMMDD`. Si ya existe un backup del mismo día, no lo sobreescribe (el primero del día se preserva).
-- **Validación post-escritura**: tras escribir, verifica con `grep` que la línea `export CHROMIUM_FLAGS` con el puerto correcto quedó en el archivo. Si falla, restaura el backup y sale con error.
-- Ver `projects/web_scraping/CHROMIUM_SYSTEM.md` para el contexto completo del sistema CDP de este equipo.

bash/functions/browser/apply_chromium_cdp_flag.sh

@@ -1,205 +0,0 @@
-#!/usr/bin/env bash
-# apply_chromium_cdp_flag — gestiona el fragmento /etc/chromium.d/cdp que activa CDP global.
-#
-# Uso:
-#   apply_chromium_cdp_flag [--port N] [--network] [--fragment-path <path>] [--remove] [--dry-run]
-
-apply_chromium_cdp_flag() {
-    local port=9222
-    local network=0
-    local fragment_path="/etc/chromium.d/cdp"
-    local remove=0
-    local dry_run=0
-
-    # Parseo de argumentos
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --port)
-                port="$2"
-                shift 2
-                ;;
-            --network)
-                network=1
-                shift
-                ;;
-            --fragment-path)
-                fragment_path="$2"
-                shift 2
-                ;;
-            --remove)
-                remove=1
-                shift
-                ;;
-            --dry-run)
-                dry_run=1
-                shift
-                ;;
-            *)
-                echo "apply_chromium_cdp_flag: argumento desconocido: $1" >&2
-                return 1
-                ;;
-        esac
-    done
-
-    # Validación del puerto
-    if ! [[ "$port" =~ ^[0-9]+$ ]] || (( port < 1 || port > 65535 )); then
-        echo "apply_chromium_cdp_flag: puerto inválido: $port (debe ser 1-65535)" >&2
-        return 1
-    fi
-
-    # Construcción del contenido del fragmento
-    local flags_line
-    if (( network )); then
-        echo "ADVERTENCIA DE SEGURIDAD: --network activa --remote-debugging-address=0.0.0.0." >&2
-        echo "El navegador quedará expuesto a toda la red local. Cualquier host en la red" >&2
-        echo "podrá controlar Chromium remotamente y leer todas las sesiones abiertas." >&2
-        flags_line='export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --remote-debugging-port='"${port}"' --remote-allow-origins=* --remote-debugging-address=0.0.0.0"'
-    else
-        flags_line='export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --remote-debugging-port='"${port}"' --remote-allow-origins=*"'
-    fi
-
-    local mode_label
-    if (( network )); then
-        mode_label="network (0.0.0.0)"
-    else
-        mode_label="loopback (127.0.0.1)"
-    fi
-
-    local fragment_content
-    fragment_content="# CDP global para automatizacion del navegador del usuario (proyecto web_scraping, regla 8).
-# Bind ${mode_label} por defecto: el puerto solo
-# es accesible desde 127.0.0.1, no desde la red.
-${flags_line}"
-
-    # Modo --dry-run: solo mostrar y salir
-    if (( dry_run )); then
-        echo "--- dry-run: fragmento que se escribiría en ${fragment_path} ---"
-        echo "${fragment_content}"
-        echo "--- fin dry-run ---"
-        return 0
-    fi
-
-    # Modo --remove
-    if (( remove )); then
-        if [[ ! -e "$fragment_path" ]]; then
-            echo "apply_chromium_cdp_flag: ${fragment_path} no existe, nada que borrar."
-            return 0
-        fi
-
-        local backup_path="${fragment_path}.bak.$(date +%Y%m%d)"
-        if [[ ! -e "$backup_path" ]]; then
-            if [[ $EUID -eq 0 ]]; then
-                cp "$fragment_path" "$backup_path"
-            else
-                sudo cp "$fragment_path" "$backup_path" || {
-                    echo "apply_chromium_cdp_flag: no se pudo crear backup en ${backup_path}" >&2
-                    return 1
-                }
-            fi
-        fi
-
-        if [[ $EUID -eq 0 ]]; then
-            rm "$fragment_path"
-        else
-            sudo rm "$fragment_path" || {
-                echo "apply_chromium_cdp_flag: no se pudo borrar ${fragment_path}" >&2
-                return 1
-            }
-        fi
-
-        echo "apply_chromium_cdp_flag: fragmento eliminado (backup: ${backup_path})"
-        echo "Nota: el chromium ya abierto antes de este cambio no lo hereda hasta reiniciarlo."
-        return 0
-    fi
-
-    # Idempotencia: comparar con contenido actual
-    if [[ -f "$fragment_path" ]]; then
-        local current_content
-        current_content=$(cat "$fragment_path" 2>/dev/null)
-        if [[ "$current_content" == "$fragment_content" ]]; then
-            echo "apply_chromium_cdp_flag: ya aplicado, sin cambios (${fragment_path})."
-            return 0
-        fi
-    fi
-
-    # Crear directorio si falta
-    local fragment_dir
-    fragment_dir=$(dirname "$fragment_path")
-    if [[ ! -d "$fragment_dir" ]]; then
-        if [[ $EUID -eq 0 ]]; then
-            mkdir -p "$fragment_dir"
-        else
-            sudo mkdir -p "$fragment_dir" || {
-                echo "apply_chromium_cdp_flag: no se pudo crear ${fragment_dir}" >&2
-                return 1
-            }
-        fi
-    fi
-
-    # Backup si ya existe y difiere
-    if [[ -e "$fragment_path" ]]; then
-        local backup_path="${fragment_path}.bak.$(date +%Y%m%d)"
-        if [[ ! -e "$backup_path" ]]; then
-            if [[ $EUID -eq 0 ]]; then
-                cp "$fragment_path" "$backup_path"
-            else
-                sudo cp "$fragment_path" "$backup_path" || {
-                    echo "apply_chromium_cdp_flag: no se pudo crear backup en ${backup_path}" >&2
-                    return 1
-                }
-            fi
-            echo "apply_chromium_cdp_flag: backup creado en ${backup_path}"
-        fi
-    fi
-
-    # Escribir fragmento
-    local tmpfile
-    tmpfile=$(mktemp)
-    printf '%s\n' "$fragment_content" > "$tmpfile"
-
-    if [[ $EUID -eq 0 ]]; then
-        cp "$tmpfile" "$fragment_path"
-        chmod 644 "$fragment_path"
-    else
-        sudo cp "$tmpfile" "$fragment_path" || {
-            rm -f "$tmpfile"
-            echo "apply_chromium_cdp_flag: no se pudo escribir ${fragment_path}" >&2
-            return 1
-        }
-        sudo chmod 644 "$fragment_path" 2>/dev/null || true
-    fi
-    rm -f "$tmpfile"
-
-    # Validación post-escritura
-    local expected_line="--remote-debugging-port=${port}"
-    if ! grep -qF "$expected_line" "$fragment_path" 2>/dev/null; then
-        echo "apply_chromium_cdp_flag: validación fallida — la línea export no apareció en ${fragment_path}." >&2
-        # Restaurar backup si existe
-        local backup_path="${fragment_path}.bak.$(date +%Y%m%d)"
-        if [[ -f "$backup_path" ]]; then
-            if [[ $EUID -eq 0 ]]; then
-                cp "$backup_path" "$fragment_path"
-            else
-                sudo cp "$backup_path" "$fragment_path" 2>/dev/null || true
-            fi
-            echo "apply_chromium_cdp_flag: backup restaurado desde ${backup_path}" >&2
-        fi
-        return 1
-    fi
-
-    # Resumen final
-    echo "apply_chromium_cdp_flag: CDP global activado correctamente."
-    echo "  Fragmento : ${fragment_path}"
-    echo "  Puerto    : ${port}"
-    echo "  Modo      : ${mode_label}"
-    echo ""
-    echo "Nota: el chromium ya abierto antes de este cambio no hereda el flag hasta reiniciarlo."
-    echo "Nota: dos procesos chromium no pueden compartir el mismo puerto; usa --port <otro> para"
-    echo "      automatización dedicada que corra en paralelo al navegador del usuario."
-}
-
-# Auto-ejecución al correr el archivo directo (bash file.sh / fn run). Si se hace `source`,
-# solo se define la función y no se ejecuta nada.
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    apply_chromium_cdp_flag "$@"
-fi

bash/functions/browser/apply_chromium_extension_policy.md

@@ -1,90 +0,0 @@
----
-name: apply_chromium_extension_policy
-kind: function
-lang: bash
-domain: browser
-version: "1.1.0"
-purity: impure
-signature: "apply_chromium_extension_policy [--keep <ext_id[=update_url]>]... [--block <ext_id>]... [--policy-path <path>] [--update-url <url>] [--dry-run]"
-description: "Escribe de forma idempotente la política managed de Chromium combinando ExtensionInstallForcelist (force-instala la whitelist --keep) y ExtensionInstallBlocklist (bloquea y desinstala la blocklist --block). No usa el comodín \"*\" blocked, por lo que NO afecta a las extensiones unpacked cargadas con --load-extension. Guarda backup fuera del directorio managed/ (que Chromium lee entero). Requiere sudo para escribir en /etc; en --dry-run no toca el sistema."
-tags: [chromium, extensions, policy, browser, navegator, managed-policy, idempotent]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-params:
-  - name: "--keep <ext_id[=update_url]>"
-    desc: "ID de extensión a force-instalar (repetible). Va a ExtensionInstallForcelist. Forma simple '<id>' usa el update_url por defecto (Web Store). Forma '<id>=<update_url>' fuerza una extensión self-hosted: por ejemplo '<id>=file:///home/u/.web_proxy/update.xml' instala un .crx local empaquetado bajo managed policy (necesario porque --load-extension queda desactivado cuando hay managed policy). Ejemplo Web Store: ddkjiahejlhfcafbddmgiahcphecmpfh (uBlock Origin Lite)."
-  - name: "--block <ext_id>"
-    desc: "ID de extensión a bloquear y desinstalar en cualquier perfil (repetible). Va a ExtensionInstallBlocklist. Solo afecta a los IDs listados; el resto de extensiones no se toca."
-  - name: "--policy-path <path>"
-    desc: "Ruta del JSON de managed policy. Default: /etc/chromium/policies/managed/extensions.json."
-  - name: "--update-url <url>"
-    desc: "URL del servicio de actualización de extensiones. Default: https://clients2.google.com/service/update2/crx."
-  - name: "--dry-run"
-    desc: "Imprime el JSON que se escribiría sin tocar el sistema (no requiere sudo)."
-output: "Escribe el JSON de política en policy-path y emite a stdout un resumen: extensiones forzadas, bloqueadas, ruta, backup creado y recordatorio de reinicio de Chromium. Sale 0 si la política se aplicó o ya estaba vigente. Sale != 0 en error. Requiere al menos un --keep o --block."
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/apply_chromium_extension_policy.sh"
----
-
-## Ejemplo
-
-```bash
-# Dejar el perfil con solo uBlock Origin Lite: forzar uBlock + bloquear las 3 que estorban
-# al scraping (Dark Reader, NoScript, OneTab). Proyecto web_scraping, regla 9.
-source bash/functions/browser/apply_chromium_extension_policy.sh
-apply_chromium_extension_policy \
-    --keep  ddkjiahejlhfcafbddmgiahcphecmpfh \
-    --block eimadpbcbfnmbkopoojfekhnkhdbieeh \
-    --block doojmbjmlfjjnbmnoijecmcbfeoakpjm \
-    --block chphlpgkkbolifaimnlloiipkdnihall
-
-# Previsualizar sin tocar el sistema (sin sudo)
-apply_chromium_extension_policy --keep ddkjiahejlhfcafbddmgiahcphecmpfh --dry-run
-
-# Ejecutar como root para el sudo no interactivo de este equipo
-pass show claude/sudo | sudo -S bash bash/functions/browser/apply_chromium_extension_policy.sh \
-    --keep ddkjiahejlhfcafbddmgiahcphecmpfh --block eimadpbcbfnmbkopoojfekhnkhdbieeh
-```
-
-La policy por sí sola evita la reinstalación pero NO desinstala lo ya presente en un perfil concreto:
-combínala con `clean_chrome_profile_extensions_bash_browser` (con Chromium cerrado) para purgar del
-disco las extensiones ya instaladas.
-
-## Cuando usarla
-
-Al preparar un PC nuevo o cambiar qué extensiones de Chrome Web Store deben estar (o no estar) en
-cualquier perfil de Chromium del equipo. Reemplaza el paso manual de editar el JSON de policy con
-sudo. `--keep` fuerza y fija las imprescindibles; `--block` elimina las molestas sin tocar el resto.
-
-## Gotchas
-
-- **El backup NUNCA va dentro de `managed/`** (lo gestiona la función, pero es la lección clave): Chromium
-  lee **todos** los archivos del directorio `policies/managed/` sin filtrar por extensión de nombre. Un
-  `extensions.json.bak.YYYYMMDD` dentro de `managed/` se mergea con la policy efectiva y **reinyecta** las
-  extensiones del backup (se ven como `location=7` external_policy_download y vuelven aunque las borres).
-  Por eso la función guarda los backups en `policies/policy-backups/`, fuera de `managed/`. Si encuentras
-  backups antiguos dentro de `managed/`, muévelos fuera.
-- **No usa el comodín `"*": blocked`**: ese modo desinstala todo lo no-whitelist pero también **bloquea las
-  extensiones unpacked** (`--load-extension`), rompiendo cosas como la extensión de captura de `web_proxy`
-  con el error "Loading of unpacked extensions is disabled by the administrator". Esta función bloquea solo
-  los IDs de `--block`.
-- **`--load-extension` y managed policy son incompatibles en Chromium 137+**: con CUALQUIER managed policy
-  presente, Chromium desactiva `--load-extension` ("disabled by the administrator"). Para cargar una
-  extensión local junto a una managed policy hay que empaquetarla (.crx + update_url) o usar `--proxy-server`
-  directo en el caso de `web_proxy`.
-- **Requiere sudo** para escribir en `/etc/chromium/policies/managed/`. En este equipo: `pass show claude/sudo | sudo -S <cmd>`.
-- **Chrome cachea la política en memoria**: cerrar TODOS los Chromium (`pkill -9 chromium`) y relanzar, o `chrome://policy` → "Reload policies".
-- **Idempotente**: si el archivo ya tiene el mismo contenido, no-op y sale 0.
-- Referencia del sistema completo: `projects/web_scraping/CHROMIUM_SYSTEM.md`.
-
-## Capability growth log
-
-- v1.2.0 (2026-06-05) — `--keep` acepta `<id>=<update_url>` para force-instalar extensiones self-hosted (p.ej. un `.crx` local vía `file://` a un `update.xml`), que es la forma de cargar una extensión propia cuando hay managed policy y `--load-extension` está desactivado.
-- v1.1.0 (2026-06-05) — añade `--block` (ExtensionInstallBlocklist); reemplaza el modo `ExtensionSettings "*": blocked` (rompía extensiones unpacked) por blocklist específica; mueve los backups fuera de `managed/` (Chromium lee todo el directorio y un `.bak` ahí reinyectaba extensiones).
-- v1.0.0 (2026-06-05) — baseline: ExtensionInstallForcelist con whitelist `--keep`.

bash/functions/browser/apply_chromium_extension_policy.sh

@@ -1,257 +0,0 @@
-#!/usr/bin/env bash
-# apply_chromium_extension_policy — Escribe de forma idempotente la política managed de Chromium
-# que fuerza la instalación de una whitelist de extensiones y bloquea (desinstala) una blocklist
-# concreta, sin tocar el resto. Usa ExtensionInstallForcelist + ExtensionInstallBlocklist.
-
-apply_chromium_extension_policy() {
-    local policy_path="/etc/chromium/policies/managed/extensions.json"
-    local update_url="https://clients2.google.com/service/update2/crx"
-    local dry_run=0
-    local -a keep_ids=()
-    local -a block_ids=()
-
-    # --- Parseo de argumentos ---
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --keep)
-                if [[ -z "${2:-}" ]]; then
-                    echo "apply_chromium_extension_policy: --keep requiere un ID de extensión" >&2
-                    return 1
-                fi
-                keep_ids+=("$2")
-                shift 2
-                ;;
-            --block)
-                if [[ -z "${2:-}" ]]; then
-                    echo "apply_chromium_extension_policy: --block requiere un ID de extensión" >&2
-                    return 1
-                fi
-                block_ids+=("$2")
-                shift 2
-                ;;
-            --policy-path)
-                if [[ -z "${2:-}" ]]; then
-                    echo "apply_chromium_extension_policy: --policy-path requiere un valor" >&2
-                    return 1
-                fi
-                policy_path="$2"
-                shift 2
-                ;;
-            --update-url)
-                if [[ -z "${2:-}" ]]; then
-                    echo "apply_chromium_extension_policy: --update-url requiere un valor" >&2
-                    return 1
-                fi
-                update_url="$2"
-                shift 2
-                ;;
-            --dry-run)
-                dry_run=1
-                shift
-                ;;
-            *)
-                echo "apply_chromium_extension_policy: argumento desconocido: $1" >&2
-                echo "Uso: apply_chromium_extension_policy [--keep <ext_id>]... [--block <ext_id>]... [--policy-path <path>] [--update-url <url>] [--dry-run]" >&2
-                return 1
-                ;;
-        esac
-    done
-
-    # --- Validar que hay al menos una extensión a forzar o bloquear ---
-    if [[ ${#keep_ids[@]} -eq 0 && ${#block_ids[@]} -eq 0 ]]; then
-        echo "apply_chromium_extension_policy: se requiere al menos un --keep o un --block <ext_id>" >&2
-        return 1
-    fi
-
-    # --- Construir el JSON ---
-    # Dos claves complementarias, ninguna bloquea las extensiones unpacked (--load-extension),
-    # de modo que extensiones locales como la de captura de web_proxy siguen cargando:
-    #   1. ExtensionInstallForcelist: fuerza la instalación de la whitelist (--keep), que además
-    #      no se puede desinstalar desde la UI.
-    #   2. ExtensionInstallBlocklist: bloquea Y desinstala las extensiones de la blocklist
-    #      (--block) en cualquier perfil. Solo afecta a los IDs listados; el resto no se toca.
-    local forcelist_json="[]" blocklist_json="[]"
-    if [[ ${#keep_ids[@]} -gt 0 ]]; then
-        local entries="" first=1
-        for kid in "${keep_ids[@]}"; do
-            # Cada --keep puede ser "<id>" (usa el update_url por defecto, Web Store) o
-            # "<id>=<update_url>" para una extensión self-hosted (p.ej. file:// a un update.xml local).
-            local id="${kid%%=*}" url="$update_url"
-            [[ "$kid" == *=* ]] && url="${kid#*=}"
-            [[ $first -eq 0 ]] && entries+=","$'\n'
-            entries+="    \"${id};${url}\""
-            first=0
-        done
-        forcelist_json=$(printf '[\n%s\n  ]' "$entries")
-    fi
-    if [[ ${#block_ids[@]} -gt 0 ]]; then
-        local entries="" first=1
-        for id in "${block_ids[@]}"; do
-            [[ $first -eq 0 ]] && entries+=","$'\n'
-            entries+="    \"${id}\""
-            first=0
-        done
-        blocklist_json=$(printf '[\n%s\n  ]' "$entries")
-    fi
-
-    local new_json
-    new_json=$(cat <<JSONEOF
-{
-  "ExtensionInstallForcelist": ${forcelist_json},
-  "ExtensionInstallBlocklist": ${blocklist_json}
-}
-JSONEOF
-)
-
-    # --- Modo dry-run ---
-    if [[ $dry_run -eq 1 ]]; then
-        echo "[dry-run] JSON que se escribiría en: ${policy_path}"
-        echo "---"
-        echo "$new_json"
-        echo "---"
-        echo "[dry-run] No se ha modificado el sistema."
-        return 0
-    fi
-
-    # --- Idempotencia: comparar con contenido actual ---
-    if [[ -f "$policy_path" ]]; then
-        local current_content
-        current_content=$(cat "$policy_path" 2>/dev/null || true)
-        if [[ "$current_content" == "$new_json" ]]; then
-            echo "apply_chromium_extension_policy: política ya aplicada (sin cambios). Nada que hacer."
-            return 0
-        fi
-    fi
-
-    # --- Backup del archivo existente ---
-    # CRÍTICO: el backup NUNCA puede vivir dentro del directorio de la policy. Chromium lee TODOS
-    # los archivos del directorio managed/ (sin filtrar por extensión de nombre), así que un
-    # "extensions.json.bak.YYYYMMDD" dentro de managed/ se mergea con la policy efectiva y reinyecta
-    # las extensiones del backup. Por eso el backup se guarda en un directorio hermano (policy-backups)
-    # que chromium no lee.
-    local backup_path=""
-    if [[ -f "$policy_path" ]]; then
-        local date_suffix policy_dir backup_dir
-        date_suffix=$(date +%Y%m%d)
-        policy_dir="$(dirname "$policy_path")"
-        case "$(basename "$policy_dir")" in
-            managed|recommended) backup_dir="$(dirname "$policy_dir")/policy-backups" ;;
-            *)                   backup_dir="$policy_dir" ;;
-        esac
-        backup_path="${backup_dir}/$(basename "$policy_path").bak.${date_suffix}"
-        if [[ ! -d "$backup_dir" ]]; then
-            if [[ $EUID -ne 0 ]]; then sudo mkdir -p "$backup_dir" 2>/dev/null; else mkdir -p "$backup_dir"; fi
-        fi
-        if [[ ! -f "$backup_path" ]]; then
-            echo "apply_chromium_extension_policy: creando backup → ${backup_path}"
-            if [[ $EUID -ne 0 ]]; then
-                sudo cp "$policy_path" "$backup_path" || {
-                    echo "apply_chromium_extension_policy: no se pudo crear el backup en ${backup_path}" >&2
-                    return 1
-                }
-            else
-                cp "$policy_path" "$backup_path" || {
-                    echo "apply_chromium_extension_policy: no se pudo crear el backup en ${backup_path}" >&2
-                    return 1
-                }
-            fi
-        else
-            echo "apply_chromium_extension_policy: backup del día ya existe (${backup_path}), se omite."
-        fi
-    fi
-
-    # --- Crear directorio padre si no existe ---
-    local policy_dir
-    policy_dir=$(dirname "$policy_path")
-    if [[ ! -d "$policy_dir" ]]; then
-        echo "apply_chromium_extension_policy: creando directorio ${policy_dir}"
-        if [[ $EUID -ne 0 ]]; then
-            sudo mkdir -p "$policy_dir" || {
-                echo "apply_chromium_extension_policy: no se pudo crear el directorio ${policy_dir}" >&2
-                return 1
-            }
-        else
-            mkdir -p "$policy_dir" || {
-                echo "apply_chromium_extension_policy: no se pudo crear el directorio ${policy_dir}" >&2
-                return 1
-            }
-        fi
-    fi
-
-    # --- Escribir el JSON vía tmpfile + sudo cp ---
-    local tmpfile
-    tmpfile=$(mktemp /tmp/chromium_policy_XXXXXX.json)
-    echo "$new_json" > "$tmpfile"
-
-    if [[ $EUID -ne 0 ]]; then
-        sudo cp "$tmpfile" "$policy_path" || {
-            echo "apply_chromium_extension_policy: no se pudo escribir ${policy_path}" >&2
-            rm -f "$tmpfile"
-            if [[ -n "$backup_path" && -f "$backup_path" ]]; then
-                echo "apply_chromium_extension_policy: restaurando backup tras error..."
-                sudo cp "$backup_path" "$policy_path" 2>/dev/null || true
-            fi
-            return 1
-        }
-    else
-        cp "$tmpfile" "$policy_path" || {
-            echo "apply_chromium_extension_policy: no se pudo escribir ${policy_path}" >&2
-            rm -f "$tmpfile"
-            if [[ -n "$backup_path" && -f "$backup_path" ]]; then
-                echo "apply_chromium_extension_policy: restaurando backup tras error..."
-                cp "$backup_path" "$policy_path" 2>/dev/null || true
-            fi
-            return 1
-        }
-    fi
-    rm -f "$tmpfile"
-
-    # --- Validar el JSON escrito ---
-    local validation_ok=0
-    if command -v python3 &>/dev/null; then
-        python3 -c "import json,sys; json.load(open(sys.argv[1]))" "$policy_path" 2>/dev/null && validation_ok=1
-    elif command -v jq &>/dev/null; then
-        jq . "$policy_path" &>/dev/null && validation_ok=1
-    else
-        validation_ok=1
-    fi
-
-    if [[ $validation_ok -eq 0 ]]; then
-        echo "apply_chromium_extension_policy: el JSON escrito no es válido — restaurando backup" >&2
-        if [[ -n "$backup_path" && -f "$backup_path" ]]; then
-            if [[ $EUID -ne 0 ]]; then
-                sudo cp "$backup_path" "$policy_path" 2>/dev/null || true
-            else
-                cp "$backup_path" "$policy_path" 2>/dev/null || true
-            fi
-        fi
-        return 1
-    fi
-
-    # --- Resumen final ---
-    echo "apply_chromium_extension_policy: política aplicada correctamente."
-    echo "  Ruta     : ${policy_path}"
-    if [[ ${#keep_ids[@]} -gt 0 ]]; then
-        echo "  Forzadas (${#keep_ids[@]}):"
-        for id in "${keep_ids[@]}"; do echo "    - ${id}"; done
-    fi
-    if [[ ${#block_ids[@]} -gt 0 ]]; then
-        echo "  Bloqueadas/desinstaladas (${#block_ids[@]}):"
-        for id in "${block_ids[@]}"; do echo "    - ${id}"; done
-    fi
-    echo "  Extensiones unpacked (--load-extension, p.ej. web_proxy): NO afectadas."
-    if [[ -n "$backup_path" && -f "$backup_path" ]]; then
-        echo "  Backup   : ${backup_path}"
-    fi
-    echo ""
-    echo "  AVISO: Chromium cachea la politica en memoria. Para que surta efecto:"
-    echo "    pkill -9 chromium   (cierra TODOS los procesos)"
-    echo "    # Luego relanza Chromium. O desde un Chromium abierto:"
-    echo "    # chrome://policy → 'Reload policies'"
-}
-
-# Auto-ejecución al correr el archivo directo (bash file.sh / fn run). Si se hace `source`,
-# solo se define la función y no se ejecuta nada.
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    apply_chromium_extension_policy "$@"
-fi

bash/functions/browser/backup_chrome_bookmarks.md

@@ -1,79 +0,0 @@
----
-name: backup_chrome_bookmarks
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "backup_chrome_bookmarks --user-data-dir <dir> [--profile <name>]... [--backup-dir <dir>] [--dry-run]"
-description: "Copia byte a byte los archivos Bookmarks de perfiles Chrome/Chromium a un directorio de backup con timestamp ISO. Descubre automáticamente todos los perfiles con Bookmarks si no se especifica ninguno. Preserva el checksum interno del archivo sin parsear ni reserializar el JSON. No requiere que Chromium esté cerrado."
-tags: [navegator, chromium, bookmarks, backup, browser, scraping]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/backup_chrome_bookmarks.sh"
-params:
-  - name: --user-data-dir
-    desc: "(obligatorio) Ruta raíz del user-data-dir de Chrome/Chromium. Ej: ~/.config/chromium-cdp"
-  - name: --profile
-    desc: "Nombre de carpeta de perfil a respaldar (repetible). Si no se pasa ninguno se descubren todos los perfiles que contengan un archivo Bookmarks, excluyendo System Profile."
-  - name: --backup-dir
-    desc: "Directorio raíz donde se crearán los backups. Default: ~/.local/share/web_scraping/bookmarks-backups"
-  - name: --dry-run
-    desc: "Muestra a stderr qué archivos se copiarían y sus tamaños sin escribir nada en disco. El JSON de salida se emite igualmente."
-output: "JSON en stdout: {backup_dir: \"<dir>\", ts: \"<YYYYMMDDTHHmmss>\", profiles: [{profile: \"<name>\", src: \"<path>\", dst: \"<path>\", bytes: N}, ...]}. Perfiles sin Bookmarks se omiten silenciosamente. Exit 0 en éxito o dry-run. Errores a stderr con exit != 0."
----
-
-## Ejemplo
-
-```bash
-# Backup de todos los perfiles del chromium-cdp (descubrimiento automático)
-source $HOME/fn_registry/bash/functions/browser/backup_chrome_bookmarks.sh
-backup_chrome_bookmarks --user-data-dir "$HOME/.config/chromium-cdp"
-
-# Previsualizar sin tocar nada
-backup_chrome_bookmarks \
-    --user-data-dir "$HOME/.config/chromium-cdp" \
-    --dry-run
-
-# Backup de perfiles específicos
-backup_chrome_bookmarks \
-    --user-data-dir "$HOME/.config/chromium-cdp" \
-    --profile Default \
-    --profile Personal \
-    --profile "Profile 1"
-
-# Backup a directorio personalizado
-backup_chrome_bookmarks \
-    --user-data-dir "$HOME/.config/chromium-cdp" \
-    --backup-dir "$HOME/vaults/backups/bookmarks"
-
-# Salida esperada (ejemplo):
-# {"backup_dir":"/home/enmanuel/.local/share/web_scraping/bookmarks-backups","ts":"20260605T143022","profiles":[{"profile":"Default","src":"/home/enmanuel/.config/chromium-cdp/Default/Bookmarks","dst":"/home/enmanuel/.local/share/web_scraping/bookmarks-backups/20260605T143022/Default/Bookmarks","bytes":4218}]}
-```
-
-También ejecutable directamente con `fn run`:
-
-```bash
-cd $HOME/fn_registry
-./fn run backup_chrome_bookmarks_bash_browser -- \
-    --user-data-dir "$HOME/.config/chromium-cdp" --dry-run
-```
-
-## Cuando usarla
-
-Úsala antes de cualquier sesión de scraping o automatización que modifique bookmarks de Chromium, para tener un snapshot recuperable. También útil como paso previo en pipelines que reorganizan o importan marcadores masivamente. Combínala con `rotate_backups_bash_infra` para aplicar política de retención sobre el directorio de backups.
-
-## Gotchas
-
-- **Copia verbatim para preservar checksum**: el archivo `Bookmarks` de Chromium incluye un campo `checksum` calculado sobre el contenido. Esta función usa `cp -p` sin tocar el contenido — si parseases y reserializases el JSON (con `jq`, `python3 json.dump`, etc.) el checksum quedaría inválido y Chromium podría resetear o ignorar los marcadores al arrancar.
-- **No requiere Chromium cerrado**: a diferencia de `clean_chrome_profile_extensions`, esta función solo lee el archivo `Bookmarks`. Chromium no mantiene un lock exclusivo sobre él — la copia es segura con el navegador abierto. El archivo refleja el estado en disco en ese instante; cambios en vuelo en memoria no estarán en el backup hasta que Chromium los persista.
-- **Perfiles sin Bookmarks se omiten silenciosamente**: si un perfil existe pero no tiene el archivo `Bookmarks` (perfil recién creado sin haber abierto el navegador), se salta sin error. Solo aparece en el JSON de salida si fue respaldado.
-- **System Profile excluido siempre**: el perfil `System Profile` es un perfil interno de Chromium sin datos de usuario y se excluye del descubrimiento automático.
-- **Sin jq ni python3**: la emisión del JSON de salida se construye con printf de bash puro, sin dependencias externas.

bash/functions/browser/backup_chrome_bookmarks.sh

@@ -1,139 +0,0 @@
-#!/usr/bin/env bash
-# backup_chrome_bookmarks — copia byte a byte los archivos Bookmarks de perfiles
-# Chrome/Chromium a un directorio de backup con timestamp. Preserva el checksum
-# interno del archivo sin parsear ni reserializar el JSON.
-
-set -euo pipefail
-
-backup_chrome_bookmarks() {
-    # ── defaults ──────────────────────────────────────────────────────────────
-    local _user_data_dir=""
-    local _profiles=()
-    local _backup_dir="${HOME}/.local/share/web_scraping/bookmarks-backups"
-    local _dry_run=0
-
-    # ── parse args ─────────────────────────────────────────────────────────────
-    _usage() {
-        cat >&2 <<'EOF'
-Usage: backup_chrome_bookmarks --user-data-dir <dir> [--profile <name>]...
-           [--backup-dir <dir>] [--dry-run]
-
-  --user-data-dir   (obligatorio) Raíz de perfiles de Chrome/Chromium.
-                    Ej: ~/.config/chromium-cdp
-  --profile <name>  Nombre de carpeta de perfil a respaldar (repetible).
-                    Si no se pasa ninguno → respalda TODOS los perfiles con
-                    un archivo Bookmarks (excluye System Profile).
-  --backup-dir <dir> Directorio raíz para backups.
-                    Default: ~/.local/share/web_scraping/bookmarks-backups
-  --dry-run         Muestra qué copiaría sin tocar nada.
-
-Exit codes:
-  0  éxito (o dry-run completado)
-  1  error de argumento o validación
-EOF
-        return 1
-    }
-
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --user-data-dir) _user_data_dir="$2"; shift 2 ;;
-            --profile)       _profiles+=("$2");   shift 2 ;;
-            --backup-dir)    _backup_dir="$2";    shift 2 ;;
-            --dry-run)       _dry_run=1;           shift   ;;
-            -h|--help)       _usage; return 0 ;;
-            *) echo "backup_chrome_bookmarks: argumento desconocido: $1" >&2; return 1 ;;
-        esac
-    done
-
-    # ── validaciones ──────────────────────────────────────────────────────────
-    if [[ -z "$_user_data_dir" ]]; then
-        echo "backup_chrome_bookmarks: --user-data-dir es obligatorio" >&2
-        return 1
-    fi
-
-    if [[ ! -d "$_user_data_dir" ]]; then
-        echo "backup_chrome_bookmarks: directorio no encontrado: ${_user_data_dir}" >&2
-        return 1
-    fi
-
-    # ── descubrir perfiles si no se pasó ninguno ───────────────────────────────
-    if [[ ${#_profiles[@]} -eq 0 ]]; then
-        local _candidate
-        while IFS= read -r -d '' _candidate; do
-            local _pname
-            _pname="$(basename "$_candidate")"
-            # Excluir System Profile (perfil interno de Chromium sin datos de usuario)
-            if [[ "$_pname" == "System Profile" ]]; then
-                continue
-            fi
-            if [[ -f "${_candidate}/Bookmarks" ]]; then
-                _profiles+=("$_pname")
-            fi
-        done < <(find "$_user_data_dir" -mindepth 1 -maxdepth 1 -type d -print0 | sort -z)
-    fi
-
-    if [[ ${#_profiles[@]} -eq 0 ]]; then
-        echo "backup_chrome_bookmarks: no se encontraron perfiles con archivo Bookmarks en: ${_user_data_dir}" >&2
-        return 1
-    fi
-
-    # ── timestamp único para este backup ──────────────────────────────────────
-    local _ts
-    _ts="$(date +%Y%m%dT%H%M%S)"
-
-    # ── procesar perfiles ─────────────────────────────────────────────────────
-    # Construir el array de resultados JSON manualmente (sin jq ni python3)
-    local _results="["
-    local _first=1
-    local _profile
-
-    for _profile in "${_profiles[@]}"; do
-        local _src="${_user_data_dir}/${_profile}/Bookmarks"
-
-        # Si el perfil no tiene Bookmarks, se omite sin error
-        if [[ ! -f "$_src" ]]; then
-            continue
-        fi
-
-        local _dst="${_backup_dir}/${_ts}/${_profile}/Bookmarks"
-        local _bytes
-        _bytes="$(wc -c < "$_src")"
-
-        if [[ $_dry_run -eq 1 ]]; then
-            echo "backup_chrome_bookmarks: [dry-run] cp -p \"${_src}\" -> \"${_dst}\" (${_bytes} bytes)" >&2
-        else
-            local _dst_dir
-            _dst_dir="$(dirname "$_dst")"
-            mkdir -p "$_dst_dir"
-            cp -p "$_src" "$_dst"
-        fi
-
-        # Escapar comillas dobles en el path por si acaso
-        local _src_esc="${_src//\"/\\\"}"
-        local _dst_esc="${_dst//\"/\\\"}"
-        local _profile_esc="${_profile//\"/\\\"}"
-
-        local _entry
-        _entry="$(printf '{"profile":"%s","src":"%s","dst":"%s","bytes":%s}' \
-            "$_profile_esc" "$_src_esc" "$_dst_esc" "$_bytes")"
-
-        if [[ $_first -eq 1 ]]; then
-            _results+="$_entry"
-            _first=0
-        else
-            _results+=",${_entry}"
-        fi
-    done
-
-    _results+="]"
-
-    # ── emitir resultado JSON ──────────────────────────────────────────────────
-    local _backup_dir_esc="${_backup_dir//\"/\\\"}"
-    printf '{"backup_dir":"%s","ts":"%s","profiles":%s}\n' \
-        "$_backup_dir_esc" "$_ts" "$_results"
-}
-
-# ── auto-ejecución ────────────────────────────────────────────────────────────
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    backup_chrome_bookmarks "$@"
-fi

bash/functions/browser/chrome_load_extensions.md

@@ -1,80 +0,0 @@
----
-name: chrome_load_extensions
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "chrome_load_extensions [--port N] [--profile DIR] --ext PATH [--ext PATH ...] [--proxy URL] [--url URL]"
-description: "Lanza Chrome con extensiones unpacked via --load-extension (WSL2→Windows chrome.exe, paths traducidos, join sin echo, setsid anti-exit-144). OJO: --load-extension SOLO funciona en Chrome for Testing/Chromium/Dev. En Chrome STABLE 138+ esta DESACTIVADO (feature DisableLoadExtensionCommandLineSwitch + bloqueo duro en 148) y carga 0 extensiones aunque el cmdline sea correcto. Para Chrome stable usar install via Web Store (1-clic, persiste en perfil) o enterprise policy ExtensionInstallForcelist (requiere HKLM/HKCU Policies escribible — denegado en maquinas gestionadas)."
-tags: [chrome, cdp, browser, extensions, wsl2, navegator]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-params:
-  - name: "--port N"
-    desc: "Puerto de remote debugging CDP. Default: 9222."
-  - name: "--profile DIR"
-    desc: "Chrome user-data-dir. Acepta ruta Windows (C:\\...) o ruta WSL/Linux (se traduce via wslpath -w). Default: C:\\Users\\<USERNAME>\\AppData\\Local\\fn-chrome-cdp-profile (WSL2) o /tmp/fn-chrome-cdp-profile (Linux nativo)."
-  - name: "--ext PATH"
-    desc: "Ruta a un directorio de extensión unpacked. Repetible. Acepta ruta Windows (se pasa intacta) o ruta WSL/Linux (se traduce via wslpath -w). Obligatorio al menos uno."
-  - name: "--proxy URL"
-    desc: "Proxy opcional, ej. http://127.0.0.1:8889. Agrega --proxy-server=URL a Chrome."
-  - name: "--url URL"
-    desc: "URL inicial opcional para abrir con --new-window."
-output: "PID del proceso Chrome lanzado (stdout). Mensajes de estado en stderr. CDP listo en 127.0.0.1:<port>."
-file_path: "bash/functions/browser/chrome_load_extensions.sh"
----
-
-## Ejemplo
-
-```bash
-source bash/functions/browser/chrome_load_extensions.sh
-
-chrome_load_extensions \
-  --port 9222 \
-  --profile 'C:\Users\lucas\AppData\Local\fn-chrome-cdp-profile' \
-  --ext 'C:\Users\lucas\hls-dl-ext' \
-  --ext 'C:\Users\lucas\ubol' \
-  --proxy http://127.0.0.1:8889 \
-  --url https://www.gnularetro.cc/
-```
-
-Sin proxy ni URL, sólo extensiones:
-
-```bash
-source bash/functions/browser/chrome_load_extensions.sh
-
-pid=$(chrome_load_extensions \
-  --ext '/home/lucas/dev/hls-dl-ext' \
-  --ext '/home/lucas/dev/ubol')
-# Paths WSL traducidos automáticamente a Windows.
-# CDP listo en 127.0.0.1:9222.
-echo "Chrome PID: $pid"
-```
-
-## Cuando usarla
-
-Cuando necesites Chrome CDP con extensiones unpacked cargadas (HLS downloader, uBlock Origin, extensiones en desarrollo) y `chrome_launch_go_browser` no sirve porque hardcodea `--disable-extensions`. WSL2→Windows. Ideal para sesiones de navegator con proxy + extensión activa.
-
-## Gotchas
-
-- **MUERTO en Chrome STABLE 138+ (validado 2026-05-30, Chrome 148)**: `--load-extension` NO carga nada en el canal stable, ni con `--disable-extensions-except` ni con `--disable-features=DisableLoadExtensionCommandLineSwitch`. `chrome://version` muestra el flag correcto pero `chrome://extensions` sale vacío. Google lo bloqueó duro en stable. La función SOLO sirve en **Chrome for Testing / Chromium / Dev/Canary**, donde el switch sigue activo. Para stable: ver opciones abajo.
-- **Instalar en Chrome STABLE (las que SÍ funcionan)**:
-  1. **Web Store 1-clic** — abre la página del store en el perfil CDP, el humano da "Añadir a Chrome". Persiste en el perfil para siempre (futuros lanzamientos ya con la extensión, sin flags). El popup de confirmación es UI del navegador (no DOM) → NO es CDP-clickable, requiere gesto humano. Único método no-admin que persiste por-perfil.
-  2. **Enterprise policy** `ExtensionInstallForcelist` (HKCU/HKLM `\Software\Policies\Google\Chrome`) — force-install sin clic desde el store, browser-wide. El key `Policies\Google\Chrome` puede dar "Access denied" al escribir (visto 2026-05-30 incluso en máquina personal vía reg.exe/PowerShell desde WSL — Chrome/Windows protege el subárbol Policies). Si funciona, requiere relanzar Chrome para que descargue del store. Método global (afecta todos los perfiles).
-  3. Extensiones **unpacked custom** (no en store, ej. un HLS downloader propio) en stable: no hay vía no-admin. Empaquetar a CRX + self-host `update_url` + policy, o usar Chrome for Testing. A menudo innecesario si la lógica vive fuera (ej. `grab_stream.py` descarga sin extensión).
-- **Combo flags (solo Chrome for Testing/dev)**: requiere AMBOS `--load-extension=p1,p2` Y `--disable-extensions-except=p1,p2` juntos + `--disable-features=DisableLoadExtensionCommandLineSwitch`. **NUNCA `--disable-extensions`** (desactiva todo).
-- **join sin `echo`**: rutas Windows `C:\Users\...` tienen `\U`; el `echo` de zsh (o sh con xpg_echo) lo interpreta como escape unicode y trunca la ruta a `C:`. La función usa acumulador `+=`, no `echo`. Verificable en `chrome://version` (debe verse el path completo, no `--load-extension=C:`).
-- **exit 144 en Bash tool**: si el proceso Chrome retiene el pipe stdout, la herramienta devuelve exit 144. Esta función lanza con `setsid ... </dev/null >log 2>&1 &` + `disown` para desacoplar completamente. El log queda en `/tmp/chrome_ext_<port>.log`.
-- **WSL2: traducir paths con `wslpath -w`**: los paths de `--ext` y `--profile` que sean rutas Linux se traducen automáticamente. Las rutas Windows (`C:\...`) se pasan intactas. `wslpath` debe estar disponible (estándar en WSL2 desde Windows 10 1903+).
-- **Perfil ya abierto**: si Chrome ya tiene ese perfil abierto, relanzar añade una ventana extra a la misma instancia. La función detecta si CDP ya responde en el puerto y avisa por stderr, pero procede igualmente.
-- **Web Store vs unpacked**: instalar extensiones desde la Web Store (un clic) persiste en el perfil sin necesidad de flags y sobrevive reinicios. Esta función es para extensiones unpacked en desarrollo o que no están en la Web Store. Si usas ambas, los flags no interfieren con las instaladas del store.
-- **zsh globbing**: `--remote-allow-origins=*` está dentro de comillas en la función, no se expande. Si lo pasas desde la línea de comandos, entrecomillarlo.
-- **Proxy + extensión**: si usas proxy para captura de tráfico (Burp, mitmproxy, gost), el proxy se aplica a toda la sesión Chrome, incluyendo el tráfico de las extensiones.

bash/functions/browser/chrome_load_extensions.sh

@@ -1,161 +0,0 @@
-#!/usr/bin/env bash
-# chrome_load_extensions — lanza Chrome (WSL2→Windows chrome.exe) con extensiones unpacked cargadas en un perfil CDP.
-# Chrome 148+: requiere --load-extension=<paths> Y --disable-extensions-except=<same paths> juntos.
-# NUNCA pasar --disable-extensions (desactiva todo, incluyendo las que quieres cargar).
-
-chrome_load_extensions() {
-    local port=9222
-    local profile=""
-    local proxy=""
-    local url=""
-    local -a ext_paths=()
-
-    # --- Parse args ---
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --port)
-                port="$2"; shift 2 ;;
-            --profile)
-                profile="$2"; shift 2 ;;
-            --ext)
-                ext_paths+=("$2"); shift 2 ;;
-            --proxy)
-                proxy="$2"; shift 2 ;;
-            --url)
-                url="$2"; shift 2 ;;
-            --*)
-                echo "chrome_load_extensions: flag desconocido: $1" >&2; return 1 ;;
-            *)
-                # Positional = extra ext path
-                ext_paths+=("$1"); shift ;;
-        esac
-    done
-
-    if [[ ${#ext_paths[@]} -eq 0 ]]; then
-        echo "chrome_load_extensions: se requiere al menos un --ext PATH de extension unpacked" >&2
-        return 1
-    fi
-
-    # --- Detectar chrome.exe ---
-    local chrome_bin=""
-    if command -v chrome.exe &>/dev/null; then
-        chrome_bin="chrome.exe"
-    elif [[ -f "/mnt/c/Program Files/Google/Chrome/Application/chrome.exe" ]]; then
-        chrome_bin="/mnt/c/Program Files/Google/Chrome/Application/chrome.exe"
-    elif [[ -f "/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe" ]]; then
-        chrome_bin="/mnt/c/Program Files (x86)/Google/Chrome/Application/chrome.exe"
-    else
-        echo "chrome_load_extensions: chrome.exe no encontrado en PATH ni en rutas conocidas" >&2
-        return 1
-    fi
-
-    # --- Detectar WSL2 ---
-    local wsl2=0
-    if grep -qi 'microsoft\|wsl' /proc/version 2>/dev/null; then
-        wsl2=1
-    fi
-
-    # --- Traducir paths de extensiones a Windows si hace falta ---
-    local -a win_ext_paths=()
-    for p in "${ext_paths[@]}"; do
-        if [[ $wsl2 -eq 1 ]] && [[ "$p" != [A-Za-z]:\\* ]]; then
-            # Path Linux → traducir a Windows
-            local win_p
-            win_p=$(wslpath -w "$p" 2>/dev/null) || {
-                echo "chrome_load_extensions: wslpath -w '$p' falló" >&2
-                return 1
-            }
-            win_ext_paths+=("$win_p")
-        else
-            win_ext_paths+=("$p")
-        fi
-    done
-
-    # --- Resolver perfil ---
-    if [[ -z "$profile" ]]; then
-        # Default: perfil canónico fn-chrome-cdp-profile en Windows
-        local win_user="${USERNAME:-${USER:-lucas}}"
-        if [[ $wsl2 -eq 1 ]]; then
-            profile="C:\\Users\\${win_user}\\AppData\\Local\\fn-chrome-cdp-profile"
-        else
-            profile="/tmp/fn-chrome-cdp-profile"
-        fi
-    elif [[ $wsl2 -eq 1 ]] && [[ "$profile" != [A-Za-z]:\\* ]]; then
-        # Path Linux del perfil → traducir a Windows
-        profile=$(wslpath -w "$profile" 2>/dev/null) || {
-            echo "chrome_load_extensions: wslpath -w '$profile' falló" >&2
-            return 1
-        }
-    fi
-
-    # --- Construir lista de paths separada por coma (para Chrome) ---
-    # Chrome usa coma como separador en --load-extension y --disable-extensions-except.
-    # NO usar `echo` para el join: rutas Windows como C:\Users tienen \U, y el echo de
-    # zsh (o sh con xpg_echo) interpreta \U como escape unicode y trunca la ruta a "C:".
-    # Acumulador con += y printf-safe, sin interpretacion de backslashes.
-    local ext_list=""
-    local p
-    for p in "${win_ext_paths[@]}"; do
-        ext_list+="${ext_list:+,}${p}"
-    done
-
-    # --- Construir args de Chrome ---
-    local -a args=(
-        "--remote-debugging-port=${port}"
-        "--user-data-dir=${profile}"
-        "--no-first-run"
-        "--no-default-browser-check"
-        "--remote-allow-origins=*"
-        "--load-extension=${ext_list}"
-        "--disable-extensions-except=${ext_list}"
-        # Chrome 137+ activa por defecto el feature DisableLoadExtensionCommandLineSwitch,
-        # que IGNORA silenciosamente --load-extension. Hay que desactivarlo o las
-        # extensiones unpacked no cargan (chrome://extensions sale vacio).
-        "--disable-features=DisableLoadExtensionCommandLineSwitch"
-    )
-
-    # WSL2: bind en 0.0.0.0 para que sea accesible desde la red WSL
-    if [[ $wsl2 -eq 1 ]]; then
-        args+=("--remote-debugging-address=0.0.0.0")
-    fi
-
-    if [[ -n "$proxy" ]]; then
-        args+=("--proxy-server=${proxy}")
-    fi
-
-    if [[ -n "$url" ]]; then
-        args+=("--new-window" "$url")
-    fi
-
-    # --- Revisar si CDP ya responde en el puerto ---
-    if curl -sf --max-time 1 "http://127.0.0.1:${port}/json/version" &>/dev/null; then
-        echo "chrome_load_extensions: CDP ya activo en puerto ${port}; lanzando ventana extra" >&2
-    fi
-
-    # --- Lanzar Chrome desacoplado del proceso padre ---
-    # setsid + redirección evita el exit 144 en el Bash tool (el pipe no queda retenido).
-    setsid "$chrome_bin" "${args[@]}" </dev/null >"/tmp/chrome_ext_${port}.log" 2>&1 &
-    local chrome_pid=$!
-    disown "$chrome_pid"
-
-    echo "chrome_load_extensions: Chrome lanzado PID=${chrome_pid} puerto=${port}" >&2
-
-    # --- Esperar a que CDP esté listo (hasta 15 segundos) ---
-    local deadline=$(( $(date +%s) + 15 ))
-    local ready=0
-    while [[ $(date +%s) -lt $deadline ]]; do
-        if curl -sf --max-time 1 "http://127.0.0.1:${port}/json/version" &>/dev/null; then
-            ready=1
-            break
-        fi
-        sleep 0.5
-    done
-
-    if [[ $ready -eq 1 ]]; then
-        echo "chrome_load_extensions: CDP listo en 127.0.0.1:${port}"
-    else
-        echo "chrome_load_extensions: advertencia — CDP no respondió en 15s en puerto ${port}; Chrome puede estar iniciando lentamente" >&2
-    fi
-
-    echo "$chrome_pid"
-}

bash/functions/browser/clean_chrome_profile_extensions.md

@@ -1,84 +0,0 @@
----
-name: clean_chrome_profile_extensions
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "clean_chrome_profile_extensions [--user-data-dir <dir>] [--profile-directory <name>] [--keep <ext_id>]... [--dry-run]"
-description: "Purga in-place las extensiones de un perfil Chrome/Chromium existente que no estén en la whitelist --keep: borra sus carpetas de disco y elimina sus referencias de Preferences y Secure Preferences para que Chromium no las reinstale. Complementaria a apply_chromium_extension_policy_bash_browser que evita reinstalación pero no desinstala lo ya instalado en Chromium 148."
-tags: [navegator, chromium, extensions, profile, cleanup, browser, scraping]
-uses_functions: [apply_chromium_extension_policy_bash_browser]
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/clean_chrome_profile_extensions.sh"
-params:
-  - name: --user-data-dir
-    desc: "Ruta raíz del user-data-dir de Chrome/Chromium. Default: ~/.config/chromium"
-  - name: --profile-directory
-    desc: "Nombre del subperfil dentro de user-data-dir. Default: Default"
-  - name: --keep
-    desc: "ID de extensión Chrome a conservar (repetible, 32 chars minúsculas). Si no se pasa ninguno el default es ddkjiahejlhfcafbddmgiahcphecmpfh (uBlock Origin Lite)"
-  - name: --dry-run
-    desc: "Muestra qué IDs se conservarían y cuáles se borrarían sin tocar disco ni archivos de preferencias"
-output: "JSON en stdout: {profile: \"<path>\", kept: [id...], removed: [id...]}. Exit 0 en éxito o dry-run. Errores a stderr con exit != 0."
----
-
-## Ejemplo
-
-```bash
-# Cerrar Chromium primero (OBLIGATORIO en modo real)
-pkill -TERM chromium
-
-# Purgar perfil Default dejando solo uBlock Origin Lite
-source $HOME/fn_registry/bash/functions/browser/clean_chrome_profile_extensions.sh
-clean_chrome_profile_extensions --keep ddkjiahejlhfcafbddmgiahcphecmpfh
-
-# Previsualizar antes de tocar nada
-clean_chrome_profile_extensions --keep ddkjiahejlhfcafbddmgiahcphecmpfh --dry-run
-
-# Perfil no-default con whitelist de dos extensiones
-clean_chrome_profile_extensions \
-    --user-data-dir "$HOME/.config/chromium" \
-    --profile-directory "Profile 1" \
-    --keep ddkjiahejlhfcafbddmgiahcphecmpfh \
-    --keep cjpalhdlnbpafiamejdnhcphjbkeiagm
-
-# Salida esperada (ejemplo):
-# {"profile":"/home/enmanuel/.config/chromium/Default","kept":["ddkjiahejlhfcafbddmgiahcphecmpfh"],"removed":["dark-reader-id","another-ext-id"]}
-```
-
-También ejecutable directamente con `fn run`:
-
-```bash
-cd $HOME/fn_registry
-./fn run clean_chrome_profile_extensions_bash_browser -- --dry-run
-```
-
-## Cuando usarla
-
-Úsala después de reducir la whitelist de extensiones con `apply_chromium_extension_policy_bash_browser` (modo `blocked`), para quitar del disco las que ya estaban instaladas en el perfil: la policy evita que Chromium reinstale extensiones nuevas, pero en Chromium 148 no desinstala las que ya estaban force-instaladas. Esta función hace la purga determinista del estado existente. También útil antes de una sesión de scraping para dejar el perfil con solo las extensiones necesarias.
-
-## Gotchas
-
-- **Chromium DEBE estar cerrado** antes de ejecutar en modo real. Chromium reescribe `Preferences` desde memoria al cerrar y desharía toda la purga. La función lo comprueba con `pgrep -x chromium` y aborta con exit 2 si hay procesos vivos. En `--dry-run` no se hace este check.
-- **Combínala con `apply_chromium_extension_policy_bash_browser` (blocked)** para que las extensiones no vuelvan a instalarse la próxima vez que arranques Chromium. Esta función purga el estado actual; la policy evita la reinstalación futura.
-- **Backup automático de prefs**: antes de editar `Preferences` y `Secure Preferences` la función crea `<archivo>.bak.YYYYMMDD`. Si ya existe un backup del día no lo sobreescribe. En caso de problemas: `cp Preferences.bak.YYYYMMDD Preferences`.
-- **Opera por perfil**: actúa sobre `--user-data-dir`/`--profile-directory`/Extensions. Si tienes varios perfiles (`Default`, `Profile 1`, etc.) debes invocarla una vez por cada uno.
-- **python3 > jq > warn**: para editar el JSON de Preferences usa python3 si está disponible, jq como fallback, y emite un warning a stderr (sin abortar) si ninguno está. En ese caso las carpetas sí se borran pero las referencias en Preferences quedan — Chromium podría intentar reinstalar desde Web Store.
-- **Secure Preferences HMAC**: la tabla `protection.macs.extensions.settings` también se limpia para evitar que Chromium detecte inconsistencia entre el HMAC y la entrada eliminada y resetee configuraciones. Si la HMAC falla de todas formas, Chromium lo trata como perfil potencialmente corrupto y puede resetear algunas prefs — comportamiento esperado de Chromium, no un bug de esta función.
-
-## Exit codes
-
-| Código | Significado |
-|--------|------------|
-| 0 | Éxito o dry-run completado |
-| 1 | Argumento inválido o perfil no encontrado |
-| 2 | Chromium está corriendo (solo en modo real) |
-| 3 | Directorio Extensions no encontrado |

bash/functions/browser/clean_chrome_profile_extensions.sh

@@ -1,245 +0,0 @@
-#!/usr/bin/env bash
-# clean_chrome_profile_extensions — purga in-place extensiones fuera de la whitelist
-# de un perfil Chrome/Chromium existente. Borra las carpetas de disco y limpia las
-# referencias en Preferences y Secure Preferences para que Chromium no las reinstale.
-
-set -euo pipefail
-
-clean_chrome_profile_extensions() {
-    # ── defaults ──────────────────────────────────────────────────────────────
-    local _user_data_dir="${HOME}/.config/chromium"
-    local _profile_dir="Default"
-    local _keep=()
-    local _default_ext="ddkjiahejlhfcafbddmgiahcphecmpfh"
-    local _dry_run=0
-
-    # ── parse args ─────────────────────────────────────────────────────────────
-    _usage() {
-        cat >&2 <<'EOF'
-Usage: clean_chrome_profile_extensions [--user-data-dir <dir>] [--profile-directory <name>]
-           [--keep <ext_id>]... [--dry-run]
-
-  --user-data-dir      Raíz del perfil. Default: ~/.config/chromium
-  --profile-directory  Subperfil. Default: Default
-  --keep <ext_id>      ID de extensión a conservar (repetible).
-                       Default si no se pasa ninguno: ddkjiahejlhfcafbddmgiahcphecmpfh (uBlock Origin Lite)
-  --dry-run            Lista qué se borraría sin tocar nada.
-
-Exit codes:
-  0  éxito (o dry-run completado)
-  1  error de argumento o validación
-  2  chromium está corriendo (solo en modo real)
-  3  directorio de extensiones no encontrado
-EOF
-        return 1
-    }
-
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --user-data-dir)     _user_data_dir="$2"; shift 2 ;;
-            --profile-directory) _profile_dir="$2";   shift 2 ;;
-            --keep)              _keep+=("$2");        shift 2 ;;
-            --dry-run)           _dry_run=1;           shift   ;;
-            -h|--help)           _usage; return 0 ;;
-            *) echo "clean_chrome_profile_extensions: argumento desconocido: $1" >&2; return 1 ;;
-        esac
-    done
-
-    # ── whitelist por defecto ──────────────────────────────────────────────────
-    if [[ ${#_keep[@]} -eq 0 ]]; then
-        _keep=("$_default_ext")
-    fi
-
-    # ── construir paths base ───────────────────────────────────────────────────
-    local _profile_path
-    _profile_path="${_user_data_dir}/${_profile_dir}"
-    local _ext_dir="${_profile_path}/Extensions"
-
-    # ── validaciones ──────────────────────────────────────────────────────────
-    if [[ ! -d "$_profile_path" ]]; then
-        echo "clean_chrome_profile_extensions: perfil no encontrado: ${_profile_path}" >&2
-        return 1
-    fi
-
-    if [[ ! -d "$_ext_dir" ]]; then
-        echo "clean_chrome_profile_extensions: directorio de extensiones no encontrado: ${_ext_dir}" >&2
-        return 3
-    fi
-
-    # ── guard: chromium NO debe estar corriendo (excepto en dry-run) ──────────
-    if [[ $_dry_run -eq 0 ]]; then
-        if pgrep -x chromium >/dev/null 2>&1; then
-            echo "clean_chrome_profile_extensions: chromium está corriendo — ciérralo antes de limpiar:" >&2
-            echo "  pkill -TERM chromium" >&2
-            echo "(Chromium reescribe Preferences desde memoria al cerrar y desharía la purga)" >&2
-            return 2
-        fi
-    fi
-
-    # ── enumerar extensiones instaladas ───────────────────────────────────────
-    local _to_remove=()
-    local _to_keep=()
-
-    while IFS= read -r -d '' _ext_path; do
-        local _ext_id
-        _ext_id="$(basename "$_ext_path")"
-
-        # Siempre ignorar la carpeta Temp (usada durante installs en curso)
-        if [[ "$_ext_id" == "Temp" ]]; then
-            continue
-        fi
-
-        # Comprobar si está en la whitelist
-        local _in_keep=0
-        local _k
-        for _k in "${_keep[@]}"; do
-            if [[ "$_ext_id" == "$_k" ]]; then
-                _in_keep=1
-                break
-            fi
-        done
-
-        if [[ $_in_keep -eq 1 ]]; then
-            _to_keep+=("$_ext_id")
-        else
-            _to_remove+=("$_ext_id")
-        fi
-    done < <(find "$_ext_dir" -mindepth 1 -maxdepth 1 -type d -print0 | sort -z)
-
-    # ── modo dry-run: solo informar ────────────────────────────────────────────
-    if [[ $_dry_run -eq 1 ]]; then
-        echo "=== clean_chrome_profile_extensions DRY-RUN ===" >&2
-        echo "  Perfil : ${_profile_path}" >&2
-        echo "  Conservar (${#_to_keep[@]}): ${_to_keep[*]+"${_to_keep[*]}"}" >&2
-        echo "  Borrar  (${#_to_remove[@]}): ${_to_remove[*]+"${_to_remove[*]}"}" >&2
-        _emit_json "$_profile_path" _to_keep _to_remove
-        return 0
-    fi
-
-    # ── borrar extensiones fuera de la whitelist ───────────────────────────────
-    if [[ ${#_to_remove[@]} -gt 0 ]]; then
-        local _id
-        for _id in "${_to_remove[@]}"; do
-            rm -rf "${_ext_dir}/${_id}"
-        done
-
-        # ── purgar referencias en Preferences y Secure Preferences ────────────
-        # Construir lista Python de IDs eliminados
-        local _py_ids_list=""
-        for _id in "${_to_remove[@]}"; do
-            _py_ids_list+="\"${_id}\","
-        done
-        _py_ids_list="[${_py_ids_list%,}]"
-
-        local _today
-        _today="$(date +%Y%m%d)"
-
-        local _prefs_file
-        for _prefs_file in "${_profile_path}/Preferences" "${_profile_path}/Secure Preferences"; do
-            if [[ ! -f "$_prefs_file" ]]; then
-                continue
-            fi
-
-            # Backup (no sobreescribir backup del mismo día)
-            local _backup="${_prefs_file}.bak.${_today}"
-            if [[ ! -f "$_backup" ]]; then
-                cp "$_prefs_file" "$_backup"
-            fi
-
-            # Editar con python3 si está disponible
-            if command -v python3 >/dev/null 2>&1; then
-                python3 - "$_prefs_file" "$_py_ids_list" <<'PY' || \
-                    echo "clean_chrome_profile_extensions: advertencia — no se pudo purgar ${_prefs_file} con python3" >&2
-import sys, json
-
-prefs_path = sys.argv[1]
-removed_ids = json.loads(sys.argv[2])
-
-with open(prefs_path, "r", encoding="utf-8") as f:
-    data = json.load(f)
-
-# 1. extensions.settings.<id>
-ext_settings = data.get("extensions", {}).get("settings", {})
-for ext_id in removed_ids:
-    ext_settings.pop(ext_id, None)
-
-# 2. extensions.pinned_extensions (lista de IDs)
-pinned = data.get("extensions", {}).get("pinned_extensions", None)
-if isinstance(pinned, list):
-    data["extensions"]["pinned_extensions"] = [
-        pid for pid in pinned if pid not in removed_ids
-    ]
-
-# 3. protection.macs.extensions.settings.<id> (Secure Preferences HMAC table)
-try:
-    mac_ext = data["protection"]["macs"]["extensions"]["settings"]
-    for ext_id in removed_ids:
-        mac_ext.pop(ext_id, None)
-except (KeyError, TypeError):
-    pass
-
-with open(prefs_path, "w", encoding="utf-8") as f:
-    json.dump(data, f, separators=(",", ":"))
-PY
-
-            # Fallback con jq si python3 no está disponible
-            elif command -v jq >/dev/null 2>&1; then
-                local _tmp_prefs
-                _tmp_prefs="$(mktemp)"
-                local _jq_del=""
-                for _id in "${_to_remove[@]}"; do
-                    _jq_del+=" | del(.extensions.settings[\"${_id}\"])"
-                    _jq_del+=" | del(.protection.macs.extensions.settings[\"${_id}\"])"
-                done
-                # pinned_extensions como lista
-                _jq_del+=" | if .extensions.pinned_extensions then .extensions.pinned_extensions -= [$(printf '"%s",' "${_to_remove[@]}" | sed 's/,$//')]  else . end"
-                jq "${_jq_del:1}" "$_prefs_file" > "$_tmp_prefs" && mv "$_tmp_prefs" "$_prefs_file" || {
-                    echo "clean_chrome_profile_extensions: advertencia — jq falló procesando ${_prefs_file}" >&2
-                    rm -f "$_tmp_prefs"
-                }
-            else
-                echo "clean_chrome_profile_extensions: advertencia — ni python3 ni jq disponibles; se borraron las carpetas pero no las referencias en $(basename "$_prefs_file")" >&2
-            fi
-        done
-    fi
-
-    # ── emitir resultado JSON ──────────────────────────────────────────────────
-    _emit_json "$_profile_path" _to_keep _to_remove
-}
-
-# ── helpers ────────────────────────────────────────────────────────────────────
-
-# _json_array_from_nameref <nameref>
-# Convierte un array bash (pasado por nombre de variable) en JSON array de strings.
-_json_array_from_nameref() {
-    local -n _arr_ref="$1"
-    local _out="["
-    local _first=1
-    local _item
-    for _item in "${_arr_ref[@]+"${_arr_ref[@]}"}"; do
-        if [[ $_first -eq 1 ]]; then
-            _out+="\"${_item}\""
-            _first=0
-        else
-            _out+=",\"${_item}\""
-        fi
-    done
-    _out+="]"
-    echo "$_out"
-}
-
-# _emit_json <profile_path> <kept_nameref> <removed_nameref>
-_emit_json() {
-    local _p="$1"
-    local _kept_json
-    _kept_json="$(_json_array_from_nameref "$2")"
-    local _removed_json
-    _removed_json="$(_json_array_from_nameref "$3")"
-    printf '{"profile":"%s","kept":%s,"removed":%s}\n' \
-        "$_p" "$_kept_json" "$_removed_json"
-}
-
-# ── auto-ejecución ────────────────────────────────────────────────────────────
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    clean_chrome_profile_extensions "$@"
-fi

bash/functions/browser/create_chrome_profile.md

@@ -1,93 +0,0 @@
----
-name: create_chrome_profile
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "create_chrome_profile --user-data-dir <dir> --profile <dir-name> --name <legible> [--port N] [--chrome-path <path>] [--no-launch] [--timeout-sec N] [--dry-run]"
-description: "Crea un perfil Chrome/Chromium nuevo en un user-data-dir: opcionalmente lanza chromium headless vía systemd-run para que la managed policy instale las extensiones forzadas (uBlock, web_proxy) y luego edita Local State para asignar el nombre legible al perfil. Con --no-launch crea solo la estructura de carpetas y la entrada en Local State sin arrancar Chrome."
-tags: [navegator, chromium, profile, browser, cdp, headless, scraping]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/create_chrome_profile.sh"
-params:
-  - name: --user-data-dir
-    desc: "Raíz del user-data-dir de Chrome/Chromium. Puede no existir; la función lo crea. Obligatorio."
-  - name: --profile
-    desc: "Nombre de la carpeta del perfil dentro de user-data-dir, por ejemplo: Default, \"Profile 1\", Automation. Obligatorio."
-  - name: --name
-    desc: "Nombre legible visible en el selector de perfil de Chrome, por ejemplo: Work, Aurgi, Bot. Obligatorio."
-  - name: --port
-    desc: "Puerto CDP para el lanzamiento headless. Default: 9250. Usar un valor distinto al 9222 global para no colisionar."
-  - name: --chrome-path
-    desc: "Ruta absoluta al binario chromium/chrome. Si se omite, auto-detecta: chromium, chromium-browser, google-chrome, brave-browser."
-  - name: --no-launch
-    desc: "No lanza chromium. Solo crea la carpeta del perfil y edita Local State con el nombre legible. El perfil no tendrá extensiones instaladas. Útil para tests y CRUD offline."
-  - name: --timeout-sec
-    desc: "Segundos máximos esperando a que Preferences aparezca tras el lanzamiento headless. Default: 25."
-  - name: --dry-run
-    desc: "Describe las acciones que se ejecutarían sin lanzar ni escribir nada. Emite el JSON de resultado con dry_run:true."
-output: "JSON en stdout: {\"profile\":\"<dir-name>\",\"name\":\"<legible>\",\"launched\":true|false,\"preferences_created\":true|false}. En dry-run añade \"dry_run\":true. Exit 0 en éxito."
----
-
-## Ejemplo
-
-```bash
-source $HOME/fn_registry/bash/functions/browser/create_chrome_profile.sh
-
-# Modo offline (no lanza Chrome, solo CRUD de Local State — seguro para tests)
-create_chrome_profile \
-  --user-data-dir /tmp/test_udd \
-  --profile "Automation" \
-  --name "Aurgi Bot" \
-  --no-launch
-# Salida: {"profile":"Automation","name":"Aurgi Bot","launched":false,"preferences_created":false}
-
-# Modo normal: lanza headless para que la policy instale uBlock y web_proxy,
-# luego asigna nombre en Local State
-create_chrome_profile \
-  --user-data-dir "$HOME/.local/share/web_scraping/profiles" \
-  --profile "Profile 1" \
-  --name "Work" \
-  --port 9250
-# Salida: {"profile":"Profile 1","name":"Work","launched":true,"preferences_created":true}
-
-# Dry-run: describe acciones sin ejecutar nada
-create_chrome_profile \
-  --user-data-dir "$HOME/.local/share/web_scraping/profiles" \
-  --profile "Default" \
-  --name "Scraping" \
-  --dry-run
-```
-
-## Cuando usarla
-
-Úsala para aprovisionar perfiles nuevos en un user-data-dir de automatización antes de lanzar sesiones CDP con `script-navegador` o funciones del grupo `navegator`. En modo normal (sin `--no-launch`) la managed policy instala automáticamente uBlock y la extensión web_proxy en el perfil nuevo; en `--no-launch` sirve para tests unitarios o para crear la entrada de Local State sin depender de Chrome.
-
-## Gotchas
-
-- **Lanzar chromium desde Bash tool de Claude da exit-144**: la función usa `systemd-run --user --collect` para aislar el proceso en su propio cgroup, evitando que el harness del agente lo mate. Esto es obligatorio; lanzar con `&` / `setsid` daría exit-144 en el contexto del agente.
-- **La managed policy instala las extensiones al arrancar el perfil**: NO pasar `--disable-extensions` — rompería la forcelist. Las extensiones force-listed (`ExtensionInstallForcelist` en `/etc/chromium/policies/managed/extensions.json`) se instalan en el perfil durante el primer arranque; en el headless inicial puede no completar la descarga si no hay red o si el timeout es corto.
-- **Dos chromium NO pueden compartir el mismo user-data-dir**: si ya hay un chromium corriendo sobre `--user-data-dir`, la función detecta `SingletonLock` y sale con exit 2 antes de lanzar. Para perfiles de automatización paralela, usa un `--user-data-dir` dedicado por perfil.
-- **Local State debe editarse con Chrome muerto**: la función para el unit de systemd y espera la desaparición de `SingletonLock` antes de editar `Local State`. Si se edita mientras Chrome está vivo, Chrome sobreescribe el archivo desde memoria al salir y los cambios de nombre se pierden.
-- **`--remote-allow-origins=*` necesita comillas en zsh**: el glob `*` se expande si no va entre comillas. La función pasa el flag correctamente internamente, pero si lo pasas tú en otros scripts acuérdate de las comillas.
-- **Perfil diario en `~/.config/chromium-cdp`**: en este equipo el fragmento `/etc/chromium.d/cdp` redirige el user-data-dir global a `~/.config/chromium-cdp`. Para automatización usar siempre un `--user-data-dir` dedicado fuera de `~/.config/`.
-- **Timeout corto puede dar `preferences_created: false`**: el perfil headless tarda entre 2-8 segundos en crear `Preferences` según la carga del sistema. Si se aumenta `--timeout-sec` a 45-60 en máquinas lentas se evitan falsos timeouts.
-
-## Exit codes
-
-| Código | Significado |
-|--------|------------|
-| 0 | Éxito |
-| 1 | Argumento obligatorio faltante o binario no encontrado |
-| 2 | Lock: ya hay un chromium usando el mismo user-data-dir |
-| 3 | Timeout esperando a que Preferences se cree |
-| 4 | Error editando Local State (JSON inválido tras escritura) |

bash/functions/browser/create_chrome_profile.sh

@@ -1,309 +0,0 @@
-#!/usr/bin/env bash
-# create_chrome_profile — crea un perfil Chrome/Chromium nuevo en un user-data-dir,
-# opcionalmente lanzando chromium headless para que la managed policy instale las
-# extensiones forzadas (uBlock, web_proxy). Edita Local State para asignar el nombre
-# legible al perfil.
-
-set -euo pipefail
-
-create_chrome_profile() {
-    # ── defaults ──────────────────────────────────────────────────────────────
-    local _udd=""
-    local _profile_dir=""
-    local _name=""
-    local _port=9250
-    local _chrome_path=""
-    local _no_launch=0
-    local _timeout_sec=25
-    local _dry_run=0
-
-    # ── parse args ─────────────────────────────────────────────────────────────
-    _usage() {
-        cat >&2 <<'EOF'
-Usage: create_chrome_profile --user-data-dir <dir> --profile <dir-name> --name <legible>
-           [--port N] [--chrome-path <path>] [--no-launch] [--timeout-sec N] [--dry-run]
-
-  --user-data-dir    Raíz del user-data-dir de Chrome/Chromium (obligatorio).
-  --profile          Nombre de la carpeta del perfil dentro de user-data-dir, ej: Default,
-                     "Profile 1", Automation (obligatorio).
-  --name             Nombre legible que aparece en el selector de perfil, ej: Work, Aurgi
-                     (obligatorio).
-  --port             Puerto CDP para el lanzamiento headless. Default: 9250.
-                     Usar un puerto distinto al 9222 global para no chocar.
-  --chrome-path      Ruta explícita al binario chromium/chrome. Auto-detecta si se omite.
-  --no-launch        No lanza chromium. Crea la carpeta y edita Local State offline.
-                     El perfil no tendrá extensiones instaladas; útil para tests/CRUD.
-  --timeout-sec      Segundos esperando a que Preferences aparezca tras el lanzamiento.
-                     Default: 25.
-  --dry-run          Describe las acciones sin lanzar ni escribir nada.
-
-Exit codes:
-  0  éxito
-  1  error de argumento o validación
-  2  lock: ya hay un chromium usando este user-data-dir
-  3  timeout esperando a que Preferences se cree
-  4  error editando Local State (JSON inválido tras escritura)
-EOF
-        return 1
-    }
-
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --user-data-dir)  _udd="$2";         shift 2 ;;
-            --profile)        _profile_dir="$2"; shift 2 ;;
-            --name)           _name="$2";         shift 2 ;;
-            --port)           _port="$2";         shift 2 ;;
-            --chrome-path)    _chrome_path="$2";  shift 2 ;;
-            --no-launch)      _no_launch=1;        shift   ;;
-            --timeout-sec)    _timeout_sec="$2";  shift 2 ;;
-            --dry-run)        _dry_run=1;          shift   ;;
-            -h|--help)        _usage; return 0 ;;
-            *) echo "create_chrome_profile: argumento desconocido: $1" >&2; return 1 ;;
-        esac
-    done
-
-    # ── validaciones obligatorias ──────────────────────────────────────────────
-    if [[ -z "$_udd" ]]; then
-        echo "create_chrome_profile: --user-data-dir es obligatorio" >&2
-        return 1
-    fi
-    if [[ -z "$_profile_dir" ]]; then
-        echo "create_chrome_profile: --profile es obligatorio" >&2
-        return 1
-    fi
-    if [[ -z "$_name" ]]; then
-        echo "create_chrome_profile: --name es obligatorio" >&2
-        return 1
-    fi
-
-    local _profile_path="${_udd}/${_profile_dir}"
-    local _local_state="${_udd}/Local State"
-    local _prefs_file="${_profile_path}/Preferences"
-
-    # ── guard: lock por user-data-dir ─────────────────────────────────────────
-    # Dos procesos chromium no pueden compartir el mismo user-data-dir.
-    if [[ $_dry_run -eq 0 && $_no_launch -eq 0 ]]; then
-        local _singleton="${_udd}/SingletonLock"
-        if [[ -e "$_singleton" ]]; then
-            echo "create_chrome_profile: ya hay un chromium corriendo con --user-data-dir=${_udd}" >&2
-            echo "  (encontrado: ${_singleton})" >&2
-            echo "  Ciérralo o usa un user-data-dir distinto." >&2
-            return 2
-        fi
-    fi
-
-    # ── detección del binario chromium ────────────────────────────────────────
-    local _bin=""
-    if [[ -n "$_chrome_path" ]]; then
-        if [[ ! -x "$_chrome_path" ]]; then
-            echo "create_chrome_profile: binario no encontrado o no ejecutable: ${_chrome_path}" >&2
-            return 1
-        fi
-        _bin="$_chrome_path"
-    elif [[ $_no_launch -eq 0 ]]; then
-        for _candidate in chromium chromium-browser google-chrome brave-browser; do
-            if command -v "$_candidate" &>/dev/null; then
-                _bin="$_candidate"
-                break
-            fi
-        done
-        if [[ -z "$_bin" ]]; then
-            echo "create_chrome_profile: no se encontró binario chromium en PATH" >&2
-            echo "  Probados: chromium, chromium-browser, google-chrome, brave-browser" >&2
-            echo "  Usa --chrome-path o --no-launch." >&2
-            return 1
-        fi
-    fi
-
-    # ── modo dry-run ──────────────────────────────────────────────────────────
-    if [[ $_dry_run -eq 1 ]]; then
-        echo "=== create_chrome_profile DRY-RUN ===" >&2
-        echo "  user-data-dir : ${_udd}" >&2
-        echo "  profile       : ${_profile_dir}" >&2
-        echo "  name          : ${_name}" >&2
-        if [[ $_no_launch -eq 1 ]]; then
-            echo "  modo          : --no-launch (sin chromium)" >&2
-            echo "  acciones      : mkdir -p ${_profile_path}" >&2
-            echo "                  editar ${_local_state} → info_cache + profiles_order" >&2
-        else
-            echo "  binario       : ${_bin}" >&2
-            echo "  puerto CDP    : ${_port}" >&2
-            echo "  timeout       : ${_timeout_sec}s" >&2
-            echo "  acciones      : systemd-run unit=create-prof-<rand> chromium headless" >&2
-            echo "                  poll Preferences hasta ${_timeout_sec}s" >&2
-            echo "                  systemctl --user stop unit" >&2
-            echo "                  editar ${_local_state} → info_cache + profiles_order" >&2
-        fi
-        printf '{"profile":"%s","name":"%s","launched":false,"preferences_created":false,"dry_run":true}\n' \
-            "$_profile_dir" "$_name"
-        return 0
-    fi
-
-    # ── crear directorio del perfil ───────────────────────────────────────────
-    mkdir -p "$_profile_path"
-
-    # ── también asegurar que user-data-dir existe ──────────────────────────────
-    mkdir -p "$_udd"
-
-    # ── modo --no-launch: solo estructura + Local State ────────────────────────
-    local _launched=false
-    local _prefs_created=false
-
-    if [[ $_no_launch -eq 1 ]]; then
-        _update_local_state "$_udd" "$_local_state" "$_profile_dir" "$_name"
-        if [[ -f "$_prefs_file" ]]; then
-            _prefs_created=true
-        fi
-        printf '{"profile":"%s","name":"%s","launched":false,"preferences_created":%s}\n' \
-            "$_profile_dir" "$_name" "$_prefs_created"
-        return 0
-    fi
-
-    # ── lanzar chromium headless vía systemd-run ──────────────────────────────
-    # systemd-run --user aísla el proceso del cgroup del agente (evita exit-144).
-    # NO se pasa --disable-extensions para que la managed policy instale las
-    # extensiones force-listed (uBlock, web_proxy).
-    local _rand
-    _rand="$(tr -dc 'a-z0-9' </dev/urandom | head -c 8 2>/dev/null || echo "$$")"
-    local _unit="create-prof-${_rand}"
-
-    systemd-run \
-        --user \
-        --collect \
-        --unit="$_unit" \
-        --setenv=DISPLAY=:0 \
-        --setenv=XAUTHORITY="${HOME}/.Xauthority" \
-        "$_bin" \
-        "--user-data-dir=${_udd}" \
-        "--profile-directory=${_profile_dir}" \
-        "--headless=new" \
-        "--no-first-run" \
-        "--remote-debugging-port=${_port}" \
-        "--remote-allow-origins=*" \
-        "about:blank" 2>/dev/null || true
-
-    _launched=true
-
-    # ── poll: esperar a que Preferences exista ────────────────────────────────
-    local _elapsed=0
-    while [[ $_elapsed -lt $_timeout_sec ]]; do
-        if [[ -f "$_prefs_file" ]]; then
-            _prefs_created=true
-            break
-        fi
-        sleep 1
-        (( _elapsed++ )) || true
-    done
-
-    # ── detener el unit Y matar TODO el árbol de chromium de este udd ───────────
-    # Necesario para poder editar Local State sin que Chrome lo sobreescriba. Ni el
-    # `systemctl stop` ni un `pkill -f --user-data-dir=` bastan: los procesos hijos
-    # (zygote/gpu/renderer) no repiten el flag --user-data-dir pero sí referencian la
-    # ruta del user-data-dir en otros argumentos. Los matamos por PID seleccionando
-    # los procesos chromium cuyo cmdline contiene la ruta del udd (seguro: no mata
-    # este propio script porque filtramos por '[c]hromium').
-    systemctl --user kill -s SIGKILL "$_unit" 2>/dev/null || true
-    systemctl --user stop "$_unit" 2>/dev/null || true
-    # Matar por PID los procesos cuyo comm es exactamente "chromium" (pgrep -x) y cuyo cmdline
-    # contiene la ruta del udd. Usamos pgrep -x para NO auto-matchear grep/pgrep: el path del udd
-    # contiene la cadena "chromium" (~/.config/chromium-cdp).
-    local _wait=0 _p _pids
-    while :; do
-        _pids=""
-        for _p in $(pgrep -x chromium 2>/dev/null); do
-            tr '\0' ' ' < "/proc/$_p/cmdline" 2>/dev/null | grep -qF -- "$_udd" && _pids="$_pids $_p"
-        done
-        [[ -z "${_pids// }" ]] && break
-        # shellcheck disable=SC2086
-        kill -TERM $_pids 2>/dev/null || true
-        sleep 0.5
-        (( _wait++ )) || true
-        if [[ $_wait -ge 20 ]]; then
-            # shellcheck disable=SC2086
-            kill -9 $_pids 2>/dev/null || true
-            break
-        fi
-    done
-    rm -f "${_udd}/SingletonLock" 2>/dev/null || true
-
-    if [[ "$_prefs_created" == false ]]; then
-        echo "create_chrome_profile: timeout (${_timeout_sec}s) esperando a que se cree: ${_prefs_file}" >&2
-        echo "  El directorio del perfil puede existir pero está vacío." >&2
-        printf '{"profile":"%s","name":"%s","launched":true,"preferences_created":false,"error":"timeout"}\n' \
-            "$_profile_dir" "$_name"
-        return 3
-    fi
-
-    # ── editar Local State para asignar nombre legible ────────────────────────
-    _update_local_state "$_udd" "$_local_state" "$_profile_dir" "$_name"
-
-    printf '{"profile":"%s","name":"%s","launched":true,"preferences_created":true}\n' \
-        "$_profile_dir" "$_name"
-}
-
-# ── helper: editar Local State con python3 ────────────────────────────────────
-# Crea/actualiza info_cache.<profile_dir> con name + is_using_default_name=false
-# y añade profile_dir a profiles_order si no está.
-_update_local_state() {
-    local _udd="$1"
-    local _local_state="$2"
-    local _profile_dir="$3"
-    local _name="$4"
-    local _today
-    _today="$(date +%Y%m%d)"
-
-    # Si Local State no existe, crear una estructura mínima
-    if [[ ! -f "$_local_state" ]]; then
-        printf '{"profile":{"info_cache":{},"profiles_order":[]}}\n' > "$_local_state"
-    fi
-
-    # Backup antes de modificar (no sobreescribir el del mismo día)
-    local _backup="${_local_state}.bak.${_today}"
-    if [[ ! -f "$_backup" ]]; then
-        cp "$_local_state" "$_backup"
-    fi
-
-    # Editar con python3
-    if ! python3 - "$_local_state" "$_profile_dir" "$_name" <<'PY'; then
-import sys, json
-
-ls_path    = sys.argv[1]
-prof_dir   = sys.argv[2]
-prof_name  = sys.argv[3]
-
-with open(ls_path, "r", encoding="utf-8") as f:
-    data = json.load(f)
-
-# Asegurar estructura profile
-profile_section = data.setdefault("profile", {})
-info_cache = profile_section.setdefault("info_cache", {})
-
-# Crear o actualizar la entrada del perfil en info_cache
-entry = info_cache.setdefault(prof_dir, {})
-entry["name"] = prof_name
-entry["is_using_default_name"] = False
-
-# Añadir a profiles_order si no está
-order = profile_section.setdefault("profiles_order", [])
-if prof_dir not in order:
-    order.append(prof_dir)
-
-with open(ls_path, "w", encoding="utf-8") as f:
-    json.dump(data, f, separators=(",", ":"))
-PY
-        echo "create_chrome_profile: error editando Local State con python3" >&2
-        return 4
-    fi
-
-    # Validar JSON tras escritura
-    if ! python3 -c "import json,sys; json.load(open(sys.argv[1]))" "$_local_state" 2>/dev/null; then
-        echo "create_chrome_profile: JSON inválido tras escribir Local State; restaurando backup" >&2
-        cp "$_backup" "$_local_state"
-        return 4
-    fi
-}
-
-# ── auto-ejecución ────────────────────────────────────────────────────────────
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    create_chrome_profile "$@"
-fi

bash/functions/browser/delete_chrome_profile.md

@@ -1,93 +0,0 @@
----
-name: delete_chrome_profile
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "delete_chrome_profile --user-data-dir <dir> --profile <name> [--profile <name>]... [--dry-run]"
-description: "Borra por completo uno o varios perfiles Chrome/Chromium: elimina la carpeta del perfil del disco y limpia todas sus referencias en Local State (info_cache, profiles_order, last_active_profiles, last_used, variations_google_groups). Requiere que Chromium esté cerrado. Hace backup automático de Local State antes de editar y valida el JSON resultante restaurando el backup si es inválido."
-tags: [navegator, chromium, profile, cleanup, browser, scraping]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/delete_chrome_profile.sh"
-params:
-  - name: --user-data-dir
-    desc: "Ruta raíz del user-data-dir de Chrome/Chromium (obligatorio). Ej: ~/.config/chromium"
-  - name: --profile
-    desc: "Nombre de la carpeta del perfil a borrar (repetible, mínimo uno obligatorio). Ej: 'Default', 'Profile 1'"
-  - name: --dry-run
-    desc: "Muestra qué carpetas borraría y qué claves de Local State quitaría sin tocar nada. No activa el guard de chromium cerrado."
-output: "JSON en stdout. Modo real: {deleted:[{profile, dir_removed, local_state_cleaned}...], last_used:'<nuevo>', backup:'Local State.bak.YYYYMMDD'}. Modo dry-run: {dry_run:true, would_delete:[{profile, dir_exists, would_remove, local_state_would_clean}...]}. Errores a stderr con exit != 0."
----
-
-## Ejemplo
-
-```bash
-# Cerrar Chromium primero (OBLIGATORIO en modo real)
-pkill -TERM chromium
-
-# Borrar un perfil
-source $HOME/fn_registry/bash/functions/browser/delete_chrome_profile.sh
-delete_chrome_profile \
-    --user-data-dir "$HOME/.config/chromium" \
-    --profile "Profile 1"
-# Salida: {"deleted":[{"profile":"Profile 1","dir_removed":true,"local_state_cleaned":true}],"last_used":"Default","backup":"Local State.bak.20260606"}
-
-# Borrar varios perfiles a la vez
-delete_chrome_profile \
-    --user-data-dir "$HOME/.config/chromium" \
-    --profile "Profile 1" \
-    --profile "Profile 2"
-
-# Previsualizar sin tocar nada (no requiere Chromium cerrado)
-delete_chrome_profile \
-    --user-data-dir "$HOME/.config/chromium" \
-    --profile "Profile 1" \
-    --dry-run
-# Salida: {"dry_run":true,"would_delete":[{"profile":"Profile 1","dir_exists":true,"would_remove":true,"local_state_would_clean":true}]}
-
-# Con un user-data-dir sintético para pruebas
-mkdir -p /tmp/test_udd/Default /tmp/test_udd/"Profile 1"
-echo '{"profile":{"info_cache":{"Default":{},"Profile 1":{}},"profiles_order":["Default","Profile 1"],"last_active_profiles":["Profile 1"],"last_used":"Profile 1"},"variations_google_groups":{}}' \
-    > "/tmp/test_udd/Local State"
-delete_chrome_profile --user-data-dir /tmp/test_udd --profile "Profile 1" --dry-run
-```
-
-También ejecutable directamente con `fn run`:
-
-```bash
-cd $HOME/fn_registry
-./fn run delete_chrome_profile_bash_browser -- \
-    --user-data-dir "$HOME/.config/chromium" --profile "Profile 1" --dry-run
-```
-
-## Cuando usarla
-
-Úsala cuando necesites limpiar completamente un perfil de Chromium: antes de crear un perfil de scraping fresco, para depurar problemas de perfiles corruptos, o para liberar espacio eliminando perfiles de sesión temporales. A diferencia de borrar solo la carpeta, esta función también retira las referencias de `Local State` para que Chromium no muestre el perfil fantasma ni intente acceder a él al arrancar.
-
-## Gotchas
-
-- **Chromium DEBE estar cerrado antes de ejecutar en modo real**. Chromium reescribe `Local State` desde memoria al cerrar y desharía todos los cambios. La función comprueba `pgrep -x chromium` y aborta con exit 2 si detecta procesos vivos. En `--dry-run` este check no se activa.
-- **Operación destructiva e irreversible**: todos los datos del perfil (cookies, logins guardados, historial, caché, contraseñas) se pierden permanentemente al borrar la carpeta. No hay papelera.
-- **Backup automático de Local State**: antes de editar, la función crea `<udd>/Local State.bak.YYYYMMDD`. Si ya existe un backup del día no lo sobreescribe. Restaurar manualmente: `cp "Local State.bak.YYYYMMDD" "Local State"`.
-- **Validación JSON tras edición**: si el JSON de Local State queda inválido (raro pero posible con perfiles con nombres muy especiales), la función restaura el backup automáticamente y sale con exit != 0.
-- **Nombres de perfil con espacios**: los nombres como `"Profile 1"` se pasan entre comillas al script Python. El parsing usa `json.loads` por lo que los espacios no dan problemas, pero deben pasarse correctamente en el shell: `--profile "Profile 1"`.
-- **python3 > jq > warning**: usa python3 para editar Local State, jq como fallback. Si ninguno está disponible, las carpetas se borran pero Local State queda sin modificar (Chromium podría mostrar perfiles fantasma al arrancar).
-- **last_used reasignado automáticamente**: si el perfil borrado era el `last_used`, la función asigna el primer perfil restante en `info_cache`. Si no queda ningún perfil, `last_used` queda como cadena vacía.
-- **No afecta a `--profile Default` si es el único perfil**: lo borrará igualmente — Chromium puede quedar sin ningún perfil configurado y recreará Default al arrancar.
-
-## Exit codes
-
-| Código | Significado |
-|--------|-------------|
-| 0 | Éxito o dry-run completado |
-| 1 | Argumento inválido, directorio o Local State no encontrado, JSON inválido tras edición |
-| 2 | Chromium está corriendo (solo en modo real) |

bash/functions/browser/delete_chrome_profile.sh

@@ -1,264 +0,0 @@
-#!/usr/bin/env bash
-# delete_chrome_profile — borra por completo uno o varios perfiles Chrome/Chromium:
-# elimina la carpeta del perfil y limpia todas las referencias en Local State
-# (info_cache, profiles_order, last_active_profiles, last_used, variations_google_groups).
-
-set -euo pipefail
-
-delete_chrome_profile() {
-    # ── defaults ──────────────────────────────────────────────────────────────
-    local _user_data_dir=""
-    local _profiles=()
-    local _dry_run=0
-
-    # ── parse args ─────────────────────────────────────────────────────────────
-    _usage() {
-        cat >&2 <<'EOF'
-Usage: delete_chrome_profile --user-data-dir <dir> --profile <name> [--profile <name>]... [--dry-run]
-
-  --user-data-dir <dir>   Ruta raíz del user-data-dir de Chrome/Chromium (obligatorio).
-  --profile <name>        Nombre de la carpeta del perfil, ej. "Default" o "Profile 1"
-                          (repetible, al menos uno obligatorio).
-  --dry-run               Muestra qué borraría y qué claves de Local State quitaría
-                          sin tocar nada.
-
-Exit codes:
-  0  éxito (o dry-run completado)
-  1  error de argumento o validación
-  2  chromium está corriendo (solo en modo real)
-EOF
-        return 1
-    }
-
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --user-data-dir) _user_data_dir="$2"; shift 2 ;;
-            --profile)       _profiles+=("$2");   shift 2 ;;
-            --dry-run)       _dry_run=1;           shift   ;;
-            -h|--help)       _usage; return 0 ;;
-            *) echo "delete_chrome_profile: argumento desconocido: $1" >&2; return 1 ;;
-        esac
-    done
-
-    # ── validaciones de argumentos ────────────────────────────────────────────
-    if [[ -z "$_user_data_dir" ]]; then
-        echo "delete_chrome_profile: --user-data-dir es obligatorio" >&2
-        return 1
-    fi
-
-    if [[ ${#_profiles[@]} -eq 0 ]]; then
-        echo "delete_chrome_profile: se requiere al menos un --profile" >&2
-        return 1
-    fi
-
-    if [[ ! -d "$_user_data_dir" ]]; then
-        echo "delete_chrome_profile: user-data-dir no encontrado: ${_user_data_dir}" >&2
-        return 1
-    fi
-
-    local _local_state="${_user_data_dir}/Local State"
-    if [[ ! -f "$_local_state" ]]; then
-        echo "delete_chrome_profile: Local State no encontrado: ${_local_state}" >&2
-        return 1
-    fi
-
-    # ── guard: ningún chromium debe tener ESTE user-data-dir abierto (excepto en dry-run) ──
-    # Por-udd, no global. Comprobamos por PID con comm=chromium (pgrep -x) y leemos su cmdline,
-    # para NO auto-matchear el propio `grep`/`pgrep` del pipe: como el path del udd contiene la
-    # cadena "chromium" (p.ej. ~/.config/chromium-cdp), un `pgrep -af '[c]hromium' | grep <udd>`
-    # se detecta a sí mismo. pgrep -x chromium solo lista procesos cuyo nombre es exactamente
-    # "chromium" (el navegador), nunca grep/pgrep/bash.
-    if [[ $_dry_run -eq 0 ]]; then
-        local _p _busy=0
-        for _p in $(pgrep -x chromium 2>/dev/null); do
-            if tr '\0' ' ' < "/proc/$_p/cmdline" 2>/dev/null | grep -qF -- "$_user_data_dir"; then
-                _busy=1; break
-            fi
-        done
-        if [[ $_busy -eq 1 ]]; then
-            echo "delete_chrome_profile: hay un chromium con este user-data-dir abierto — ciérralo antes de borrar perfiles:" >&2
-            echo "  pkill -TERM chromium" >&2
-            echo "(Chromium reescribe Local State desde memoria al cerrar y desharía el borrado)" >&2
-            return 2
-        fi
-    fi
-
-    local _today
-    _today="$(date +%Y%m%d)"
-
-    # ── modo dry-run ──────────────────────────────────────────────────────────
-    if [[ $_dry_run -eq 1 ]]; then
-        echo "=== delete_chrome_profile DRY-RUN ===" >&2
-        local _p
-        for _p in "${_profiles[@]}"; do
-            local _pdir="${_user_data_dir}/${_p}"
-            if [[ -d "$_pdir" ]]; then
-                echo "  [borraría] rm -rf ${_pdir}" >&2
-            else
-                echo "  [no existe] ${_pdir}" >&2
-            fi
-            echo "  [Local State] quitaría claves para perfil: '${_p}'" >&2
-            echo "    profile.info_cache.${_p}" >&2
-            echo "    profile.profiles_order (entrada '${_p}')" >&2
-            echo "    profile.last_active_profiles (entrada '${_p}')" >&2
-            echo "    profile.last_used (si == '${_p}', reasignar)" >&2
-            echo "    variations_google_groups.${_p} (si existe)" >&2
-        done
-
-        # Construir JSON de dry-run inline
-        local _dry_items="" _dry_first=1
-        for _p in "${_profiles[@]}"; do
-            local _pdir="${_user_data_dir}/${_p}"
-            local _sep="" _exists="false"
-            [[ $_dry_first -eq 0 ]] && _sep=","
-            _dry_first=0
-            [[ -d "$_pdir" ]] && _exists="true"
-            _dry_items+="${_sep}{\"profile\":\"${_p}\",\"dir_exists\":${_exists},\"would_remove\":${_exists},\"local_state_would_clean\":true}"
-        done
-        printf '{"dry_run":true,"would_delete":[%s]}\n' "$_dry_items"
-        return 0
-    fi
-
-    # ── backup de Local State (no sobreescribir el del día) ───────────────────
-    local _backup="${_local_state}.bak.${_today}"
-    if [[ ! -f "$_backup" ]]; then
-        cp "$_local_state" "$_backup"
-    fi
-
-    # ── borrar carpetas de perfil ──────────────────────────────────────────────
-    local _deleted_results=()   # "profile|dir_removed|ls_cleaned"
-    local _p
-    for _p in "${_profiles[@]}"; do
-        local _pdir="${_user_data_dir}/${_p}"
-        local _dir_removed=false
-        if [[ -d "$_pdir" ]]; then
-            rm -rf "$_pdir"
-            _dir_removed=true
-        fi
-        _deleted_results+=("${_p}|${_dir_removed}|false")
-    done
-
-    # ── construir lista Python de perfiles a eliminar ─────────────────────────
-    local _py_profiles_list=""
-    for _p in "${_profiles[@]}"; do
-        _py_profiles_list+="\"${_p}\","
-    done
-    _py_profiles_list="[${_py_profiles_list%,}]"
-
-    # ── editar Local State con python3 ────────────────────────────────────────
-    local _ls_cleaned=false
-    if command -v python3 >/dev/null 2>&1; then
-        python3 - "$_local_state" "$_py_profiles_list" <<'PY'
-import sys, json
-
-ls_path = sys.argv[1]
-profiles_to_delete = json.loads(sys.argv[2])
-
-with open(ls_path, "r", encoding="utf-8") as f:
-    data = json.load(f)
-
-profile_section = data.get("profile", {})
-
-# 1. profile.info_cache — eliminar cada perfil
-info_cache = profile_section.get("info_cache", {})
-for p in profiles_to_delete:
-    info_cache.pop(p, None)
-
-# 2. profile.profiles_order — quitar entradas del perfil
-if "profiles_order" in profile_section and isinstance(profile_section["profiles_order"], list):
-    profile_section["profiles_order"] = [
-        x for x in profile_section["profiles_order"] if x not in profiles_to_delete
-    ]
-
-# 3. profile.last_active_profiles — quitar entradas del perfil
-if "last_active_profiles" in profile_section and isinstance(profile_section["last_active_profiles"], list):
-    profile_section["last_active_profiles"] = [
-        x for x in profile_section["last_active_profiles"] if x not in profiles_to_delete
-    ]
-
-# 4. profile.last_used — reasignar si apunta a un perfil borrado
-last_used = profile_section.get("last_used", "")
-if last_used in profiles_to_delete:
-    remaining = [k for k in info_cache.keys() if k not in profiles_to_delete]
-    profile_section["last_used"] = remaining[0] if remaining else ""
-
-# 5. variations_google_groups — limpiar entradas del perfil (si existe)
-vgg = data.get("variations_google_groups", {})
-for p in profiles_to_delete:
-    vgg.pop(p, None)
-
-with open(ls_path, "w", encoding="utf-8") as f:
-    json.dump(data, f, separators=(",", ":"))
-PY
-        _ls_cleaned=true
-
-    # ── fallback con jq ───────────────────────────────────────────────────────
-    elif command -v jq >/dev/null 2>&1; then
-        local _tmp_ls
-        _tmp_ls="$(mktemp)"
-        local _jq_expr="."
-        for _p in "${_profiles[@]}"; do
-            _jq_expr+=" | del(.profile.info_cache[\"${_p}\"])"
-            _jq_expr+=" | del(.variations_google_groups[\"${_p}\"])"
-            _jq_expr+=" | if .profile.profiles_order then .profile.profiles_order -= [\"${_p}\"] else . end"
-            _jq_expr+=" | if .profile.last_active_profiles then .profile.last_active_profiles -= [\"${_p}\"] else . end"
-        done
-        if jq "${_jq_expr}" "$_local_state" > "$_tmp_ls" 2>/dev/null; then
-            mv "$_tmp_ls" "$_local_state"
-            _ls_cleaned=true
-        else
-            echo "delete_chrome_profile: advertencia — jq falló editando Local State" >&2
-            rm -f "$_tmp_ls"
-        fi
-
-    else
-        echo "delete_chrome_profile: advertencia — ni python3 ni jq disponibles; carpetas borradas pero Local State no modificado" >&2
-    fi
-
-    # ── validar que el JSON resultante sigue siendo parseable ─────────────────
-    if [[ "$_ls_cleaned" == "true" ]]; then
-        if command -v python3 >/dev/null 2>&1; then
-            if ! python3 -c "import sys, json; json.load(open(sys.argv[1]))" "$_local_state" 2>/dev/null; then
-                echo "delete_chrome_profile: JSON de Local State inválido tras edición — restaurando backup" >&2
-                cp "$_backup" "$_local_state"
-                return 1
-            fi
-        fi
-    fi
-
-    # ── actualizar _deleted_results con ls_cleaned ────────────────────────────
-    local _updated_results=()
-    for _entry in "${_deleted_results[@]}"; do
-        local _ep _edr _els
-        IFS='|' read -r _ep _edr _els <<< "$_entry"
-        _updated_results+=("${_ep}|${_edr}|${_ls_cleaned}")
-    done
-
-    # ── leer last_used resultante ──────────────────────────────────────────────
-    local _new_last_used=""
-    if command -v python3 >/dev/null 2>&1; then
-        _new_last_used="$(python3 -c "
-import sys, json
-data = json.load(open(sys.argv[1]))
-print(data.get('profile', {}).get('last_used', ''))
-" "$_local_state" 2>/dev/null || echo "")"
-    fi
-
-    # ── construir JSON de resultado inline ────────────────────────────────────
-    local _result_items="" _res_first=1
-    for _entry in "${_updated_results[@]+"${_updated_results[@]}"}"; do
-        local _pn _dr _lc
-        IFS='|' read -r _pn _dr _lc <<< "$_entry"
-        local _rsep=""
-        [[ $_res_first -eq 0 ]] && _rsep=","
-        _res_first=0
-        _result_items+="${_rsep}{\"profile\":\"${_pn}\",\"dir_removed\":${_dr},\"local_state_cleaned\":${_lc}}"
-    done
-    printf '{"deleted":[%s],"last_used":"%s","backup":"Local State.bak.%s"}\n' \
-        "$_result_items" "$_new_last_used" "$_today"
-}
-
-# ── auto-ejecución ────────────────────────────────────────────────────────────
-if [[ "${BASH_SOURCE[0]:-}" == "${0}" ]]; then
-    delete_chrome_profile "$@"
-fi

bash/functions/browser/install_chromium_proxy_extension.md

@@ -1,81 +0,0 @@
----
-name: install_chromium_proxy_extension
-kind: function
-lang: bash
-domain: browser
-version: 1.0.0
-purity: impure
-signature: install_chromium_proxy_extension --ext-dir DIR [--name NAME] [--stable-dir DIR] [--uninstall]
-description: "Instala una extension desempaquetada de Chromium en todos los perfiles del usuario de forma persistente, escribiendo un fragmento en /etc/chromium.d/ que el wrapper de Chromium carga en cada arranque. Pensado para distribuir la extension de toggle de proxy de web_proxy sin Web Store, pero sirve para cualquier extension desempaquetada."
-tags: [web-proxy, chromium, extension, browser, proxy, install]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-params:
-  - name: --ext-dir
-    desc: "Directorio de la extension desempaquetada de origen (debe contener manifest.json). Obligatorio salvo en --uninstall."
-  - name: --name
-    desc: "Nombre del fragmento en /etc/chromium.d/ (default web_proxy_ext). Identifica esta instalacion para poder desinstalarla."
-  - name: --stable-dir
-    desc: "Ruta estable donde se copia la extension, independiente del repo (default ~/.web_proxy/extension). --load-extension apunta aqui."
-  - name: --uninstall
-    desc: "Elimina el fragmento de /etc/chromium.d/ y la copia estable. No requiere --ext-dir."
-output: "JSON en stdout: {installed|uninstalled, name, stable_dir, chromiumd, ext_id}. Requiere sudo para escribir en /etc/chromium.d/."
-file_path: bash/functions/browser/install_chromium_proxy_extension.sh
----
-
-# install_chromium_proxy_extension
-
-Instala una extension desempaquetada de Chromium en **todos los perfiles** del
-usuario, de forma persistente, sin pasar por la Chrome Web Store.
-
-## Ejemplo
-
-```bash
-# Instalar la extension de toggle de proxy de web_proxy en todos los perfiles
-install_chromium_proxy_extension --ext-dir /home/enmanuel/fn_registry/apps/web_proxy/extension
-
-# Desinstalarla
-install_chromium_proxy_extension --uninstall
-
-# Otra extension, con nombre y ruta estable propios
-install_chromium_proxy_extension --ext-dir ~/mis-extensiones/foo --name foo_ext --stable-dir ~/.local/share/foo_ext
-```
-
-Tras instalar, cierra y vuelve a abrir Chromium: la extension aparece en todos
-los perfiles, incluidos los que se creen despues.
-
-## Cuando usarla
-
-Cuando necesitas que una extension desempaquetada este presente en todos los
-perfiles de Chromium de una maquina (por ejemplo, un toggle de proxy de captura
-preconfigurado) y no quieres publicarla en la Web Store ni cargarla a mano en
-cada perfil. Es la pieza que hace que `web_proxy` quede "a un clic" en cualquier
-ventana de Chromium.
-
-## Gotchas
-
-- **Requiere sudo** para escribir en `/etc/chromium.d/`. Ten las credenciales
-  cacheadas (`sudo -v`) antes de invocarla de forma no interactiva.
-- **Solo para el wrapper de Chromium de Debian/Ubuntu** (paquete `chromium`,
-  no snap ni Google Chrome). El wrapper hace `source /etc/chromium.d/*` en cada
-  arranque. Comprueba con `head -1 $(command -v chromium)` que es un script.
-- **`--enable-remote-extensions` es imprescindible** en estos builds: sin el,
-  el wrapper anade `--disable-extensions-except` y `--disable-background-networking`,
-  que deshabilitan toda extension que no venga por `--load-extension`. El
-  fragmento generado lo incluye; por eso las demas extensiones del usuario
-  siguen funcionando.
-- La extension se carga **desempaquetada** (`--load-extension`), no como `.crx`
-  firmado. Chromium puede mostrar un aviso de "extensiones en modo desarrollador".
-  El force-install via managed policy con `.crx` local + `update_url file://`
-  no funciona con este wrapper (lo bloquea `--disable-extensions-except`).
-- El ID de la extension depende de `--stable-dir` (se deriva del path). Si
-  cambias la ruta estable, el ID cambia.
-- No reinicia Chromium: los cambios aplican en el siguiente arranque del
-  navegador.
-
-## Capability growth log
-
-- v1.0.0 (2026-06-02) — version inicial. Instala/desinstala extension global via /etc/chromium.d con --enable-remote-extensions + --load-extension.

bash/functions/browser/install_chromium_proxy_extension.sh

@@ -1,103 +0,0 @@
-#!/usr/bin/env bash
-# install_chromium_proxy_extension — instala una extension desempaquetada de
-# Chromium en TODOS los perfiles del usuario, de forma persistente, escribiendo
-# un fragmento en /etc/chromium.d/ que el wrapper de Chromium carga en cada
-# arranque.
-#
-# Por que /etc/chromium.d en vez de managed policy con .crx force_installed:
-# el wrapper de Chromium de Debian/Ubuntu (xtradeb y derivados), cuando NO se
-# pasa --enable-remote-extensions, anade --disable-extensions-except=<solo las
-# de --load-extension> y --disable-background-networking. Eso deshabilita
-# cualquier extension force_installed por policy y bloquea su update check. La
-# via fiable es habilitar --enable-remote-extensions y cargar la extension
-# desempaquetada con --load-extension, ambos inyectados de forma global desde
-# /etc/chromium.d/, que el wrapper hace `source` en cada lanzamiento.
-
-install_chromium_proxy_extension() {
-    local ext_dir=""
-    local name="web_proxy_ext"
-    local stable_dir="$HOME/.web_proxy/extension"
-    local chromiumd="/etc/chromium.d"
-    local uninstall="no"
-
-    # Permite sudo no interactivo via SUDO_ASKPASS (sudo -A) cuando se ejecuta
-    # sin terminal (agentes, CI). Con terminal interactivo usa sudo normal.
-    local SUDO="sudo"
-    [[ -n "${SUDO_ASKPASS:-}" ]] && SUDO="sudo -A"
-
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --ext-dir)    ext_dir="$2"; shift 2 ;;
-            --name)       name="$2"; shift 2 ;;
-            --stable-dir) stable_dir="$2"; shift 2 ;;
-            --uninstall)  uninstall="yes"; shift ;;
-            *) echo "ERROR: argumento desconocido: $1" >&2; return 1 ;;
-        esac
-    done
-
-    if [[ ! -d "$chromiumd" ]]; then
-        echo "ERROR: $chromiumd no existe. Este Chromium no usa el wrapper con /etc/chromium.d." >&2
-        echo "       Comprueba 'head -1 \$(command -v chromium)'; si no es un wrapper shell, usa otra via." >&2
-        return 1
-    fi
-
-    # Desinstalacion: quitar el fragmento global y la copia estable.
-    if [[ "$uninstall" == "yes" ]]; then
-        $SUDO rm -f "${chromiumd}/${name}" || {
-            echo "ERROR: no se pudo eliminar ${chromiumd}/${name} (requiere sudo)." >&2
-            return 1
-        }
-        rm -rf "$stable_dir"
-        printf '{"uninstalled": true, "name": "%s"}\n' "$name"
-        return 0
-    fi
-
-    # Instalacion: validar la extension de origen.
-    if [[ -z "$ext_dir" || ! -f "${ext_dir}/manifest.json" ]]; then
-        echo "ERROR: --ext-dir debe apuntar a un directorio con manifest.json." >&2
-        return 1
-    fi
-
-    # Copiar la extension a una ubicacion estable, independiente del repo, para
-    # que --load-extension no se rompa si el repo se mueve o se limpia.
-    mkdir -p "$stable_dir" || {
-        echo "ERROR: no se pudo crear $stable_dir." >&2
-        return 1
-    }
-    # Vaciar destino y copiar el contenido del origen.
-    rm -rf "${stable_dir:?}/"* 2>/dev/null
-    cp -r "${ext_dir}/." "$stable_dir/" || {
-        echo "ERROR: no se pudo copiar la extension a $stable_dir." >&2
-        return 1
-    }
-
-    # Escribir el fragmento que el wrapper carga en cada arranque. Se hace via
-    # archivo temporal + sudo cp para no exponer el contenido por una tuberia.
-    local tmp
-    tmp="$(mktemp)"
-    printf 'export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --enable-remote-extensions --load-extension=%s"\n' "$stable_dir" > "$tmp"
-    if ! $SUDO cp "$tmp" "${chromiumd}/${name}"; then
-        rm -f "$tmp"
-        echo "ERROR: no se pudo escribir ${chromiumd}/${name} (requiere sudo)." >&2
-        return 1
-    fi
-    $SUDO chmod 0644 "${chromiumd}/${name}" 2>/dev/null
-    rm -f "$tmp"
-
-    # ID de extension desempaquetada (deterministico: sha256 del path estable).
-    local ext_id
-    ext_id="$(python3 - "$stable_dir" <<'PY' 2>/dev/null
-import hashlib, sys
-h = hashlib.sha256(sys.argv[1].encode()).hexdigest()[:32]
-print(''.join(chr(ord('a') + int(c, 16)) for c in h))
-PY
-)"
-
-    printf '{"installed": true, "name": "%s", "stable_dir": "%s", "chromiumd": "%s/%s", "ext_id": "%s"}\n' \
-        "$name" "$stable_dir" "$chromiumd" "$name" "$ext_id"
-}
-
-# Ejecutar si se llama directamente (fn run / bash <file>)
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    install_chromium_proxy_extension "$@"
-fi

bash/functions/browser/launch_chromium_proxy.md

@@ -1,74 +0,0 @@
----
-name: launch_chromium_proxy
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "launch_chromium_proxy [--proxy URL] [--profile DIR] [--url URL] [--ca-cert PATH] [--extra \"ARGS\"]"
-description: "Lanza Chromium (o Chrome) apuntando a un proxy HTTP/HTTPS local con un perfil completamente aislado del perfil real del usuario. Pensado para capturar trafico con un proxy de interceptacion (mitmproxy, Burp Suite) sin contaminar la sesion normal de navegacion. Emite un JSON con el PID del proceso lanzado."
-tags: [chromium, chrome, proxy, mitmproxy, burp, browser, web-proxy, intercept, tls]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-params:
-  - name: "--proxy URL"
-    desc: "URL del proxy HTTP/HTTPS local, ej. http://127.0.0.1:8080. Se pasa a Chromium como --proxy-server=URL. Default: http://127.0.0.1:8080."
-  - name: "--profile DIR"
-    desc: "Directorio de perfil aislado para Chromium (--user-data-dir). Se crea automaticamente si no existe. Default: /tmp/chromium-proxy. Usar un path distinto por sesion si se quiere aislamiento total entre corridas."
-  - name: "--url URL"
-    desc: "URL inicial a abrir al arrancar el navegador. Opcional. Si se omite, Chromium abre su pagina de nueva pestana."
-  - name: "--ca-cert PATH"
-    desc: "Ruta a un CA cert PEM del proxy (ej. ~/.mitmproxy/mitmproxy-ca-cert.pem). Si se pasa, la funcion NO agrega --ignore-certificate-errors y asume que el usuario ya importo el CA en el perfil o en el sistema. Si se omite, se agrega --ignore-certificate-errors automaticamente para que el proxy MITM no rompa HTTPS (menos seguro)."
-  - name: "--extra \"ARGS\""
-    desc: "Flags extra que se pasan directamente a chromium, ej. --extra \"--disable-gpu --window-size=1280,800\". El valor completo debe ir entre comillas."
-output: "JSON en stdout: {\"pid\": <pid>, \"browser\": \"<binario>\", \"proxy\": \"<url>\", \"profile\": \"<dir>\", \"log\": \"<ruta_log>\"}. Mensajes de estado e informacion de CA en stderr. El navegador corre en background desacoplado de la sesion. Exit codes: 0=lanzado correctamente, 1=binario no encontrado o argumento invalido o error al crear el directorio de perfil."
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/launch_chromium_proxy.sh"
----
-
-## Ejemplo
-
-```bash
-source bash/functions/browser/launch_chromium_proxy.sh
-
-# Caso mas comun: interceptar trafico con mitmproxy corriendo en 8080
-# (sin CA instalado: --ignore-certificate-errors se aplica automaticamente)
-result=$(launch_chromium_proxy --proxy http://127.0.0.1:8080 --url https://httpbin.org/get)
-echo "$result"
-# {"pid":12345,"browser":"chromium","proxy":"http://127.0.0.1:8080","profile":"/tmp/chromium-proxy","log":"/tmp/chromium-proxy-12345.log"}
-
-# Con CA cert instalado (mitmproxy): sin --ignore-certificate-errors
-launch_chromium_proxy \
-  --proxy http://127.0.0.1:8080 \
-  --ca-cert ~/.mitmproxy/mitmproxy-ca-cert.pem \
-  --profile /tmp/mitm-session \
-  --url https://api.ejemplo.com/v1/test
-
-# Con Burp Suite en puerto 8081, perfil aislado y ventana de tamano fijo
-launch_chromium_proxy \
-  --proxy http://127.0.0.1:8081 \
-  --profile /tmp/burp-session \
-  --extra "--window-size=1440,900" \
-  --url https://app.objetivo.com
-```
-
-## Cuando usarla
-
-Cuando necesitas capturar y analizar trafico HTTPS de un navegador con mitmproxy, Burp Suite u otro proxy de interceptacion, sin tocar el perfil real del usuario ni sus cookies/credenciales guardadas. Ideal antes de hacer analisis de trafico de una app web o API, o al reproducir un flujo autenticado desde una sesion limpia.
-
-## Gotchas
-
-- **Deteccion de binario en orden**: la funcion prueba `chromium`, `chromium-browser`, `google-chrome-stable`, `google-chrome`. En sistemas donde solo existe `google-chrome`, ese sera el binario usado. Si ninguno esta en el PATH, retorna exit 1. Instalar con `sudo apt install chromium` o `chromium-browser`.
-- **`--ignore-certificate-errors` sin `--ca-cert`**: este flag desactiva toda la validacion TLS del navegador. Es conveniente para empezar rapido, pero reduce la seguridad de la sesion. Para produccion o analisis de seguridad serio, instalar el CA del proxy en el sistema (`sudo cp mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy.crt && sudo update-ca-certificates`) o en el perfil de Chromium (chrome://settings/certificates), y pasar `--ca-cert` para que la funcion omita el flag inseguro.
-- **`--proxy-bypass-list="<-loopback>"`**: fuerza que el trafico loopback (127.0.0.1, localhost) TAMBIEN pase por el proxy. Sin esto, Chromium excluye loopback del proxy por defecto y no veras esas peticiones en mitmproxy. Si quieres el comportamiento estandar (excluir loopback), elimina este flag via `--extra`.
-- **Perfil persistente entre sesiones**: el perfil en `/tmp/chromium-proxy` (o el directorio que elijas) persiste entre ejecuciones. Si quieres una sesion 100% limpia cada vez, pasa `--profile /tmp/chromium-proxy-$$` (usa el PID del shell como sufijo) o borra el directorio antes de llamar a la funcion.
-- **`setsid` + `disown`**: el navegador se lanza desacoplado de la sesion del agente. Si la shell/sesion que llamo a la funcion termina, el proceso Chromium sigue vivo. Para matarlo, usar `kill <pid>` con el PID del JSON de salida.
-- **Log del navegador**: stdout y stderr de Chromium se redirigen a `/tmp/chromium-proxy-<pid>.log`. Si el navegador no arranca, revisar ese archivo para ver el error.
-- **Chrome STABLE 138+**: al igual que `chrome_load_extensions`, algunos flags de automatizacion estan bloqueados en Chrome STABLE. Para interceptacion de trafico `--proxy-server` y `--user-data-dir` siguen funcionando en todas las versiones. Esta funcion es compatible con Chrome/Chromium en cualquier canal.
-- **Multiples instancias**: si ya hay una instancia de Chromium corriendo con el mismo `--user-data-dir`, Chromium puede reusar esa instancia en lugar de abrir una nueva. Usar un directorio de perfil distinto por sesion concurrente.

bash/functions/browser/launch_chromium_proxy.sh

@@ -1,118 +0,0 @@
-#!/usr/bin/env bash
-# launch_chromium_proxy — Lanza Chromium apuntando a un proxy HTTP/HTTPS local con perfil aislado.
-
-launch_chromium_proxy() {
-    local proxy_url="http://127.0.0.1:8080"
-    local profile_dir="/tmp/chromium-proxy"
-    local start_url=""
-    local ca_cert=""
-    local extra_args=""
-    local ext_dir=""
-
-    # Parsear argumentos
-    while [[ $# -gt 0 ]]; do
-        case "$1" in
-            --proxy)
-                proxy_url="$2"; shift 2 ;;
-            --profile)
-                profile_dir="$2"; shift 2 ;;
-            --url)
-                start_url="$2"; shift 2 ;;
-            --ca-cert)
-                ca_cert="$2"; shift 2 ;;
-            --ext)
-                ext_dir="$2"; shift 2 ;;
-            --extra)
-                extra_args="$2"; shift 2 ;;
-            *)
-                echo "ERROR: argumento desconocido: $1" >&2
-                return 1 ;;
-        esac
-    done
-
-    # Detectar binario del navegador
-    local browser_bin=""
-    for candidate in chromium chromium-browser google-chrome-stable google-chrome; do
-        if command -v "$candidate" &>/dev/null; then
-            browser_bin="$candidate"
-            break
-        fi
-    done
-
-    if [[ -z "$browser_bin" ]]; then
-        echo "ERROR: no se encontro ningun binario Chromium/Chrome en el PATH." >&2
-        echo "       Probados: chromium, chromium-browser, google-chrome-stable, google-chrome." >&2
-        return 1
-    fi
-
-    # Crear directorio de perfil si no existe
-    if [[ ! -d "$profile_dir" ]]; then
-        mkdir -p "$profile_dir" || {
-            echo "ERROR: no se pudo crear el directorio de perfil: $profile_dir" >&2
-            return 1
-        }
-    fi
-
-    # Construir argumentos del navegador
-    local args=(
-        "--user-data-dir=${profile_dir}"
-        "--no-first-run"
-        "--no-default-browser-check"
-    )
-
-    # Proxy fijo opcional. Con "--proxy none" (o vacio) no se fija proxy en el
-    # cmdline: util cuando una extension de proxy gestiona la conexion (toggle).
-    if [[ -n "$proxy_url" && "$proxy_url" != "none" ]]; then
-        args+=("--proxy-server=${proxy_url}" "--proxy-bypass-list=<-loopback>")
-    fi
-
-    # Cargar una extension desempaquetada (--load-extension). Funciona en
-    # Chromium (no en Chrome stable 138+). Para persistencia en todos los
-    # perfiles se usa managed policy en su lugar.
-    if [[ -n "$ext_dir" ]]; then
-        args+=("--load-extension=${ext_dir}")
-    fi
-
-    # Manejo de certificados TLS
-    if [[ -n "$ca_cert" ]]; then
-        # El usuario instalo el CA en el perfil; no ignorar errores de certificado.
-        # (El CA se instala en el sistema o en el perfil antes de lanzar.)
-        echo "INFO: CA cert declarado: $ca_cert" >&2
-        echo "INFO: Asegurate de haber importado el CA en el perfil o en el sistema antes de navegar HTTPS." >&2
-    else
-        # Sin CA cert: ignorar errores de certificado para que mitmproxy/Burp funcionen sin configuracion extra.
-        # ADVERTENCIA: esto desactiva la validacion TLS completa del navegador.
-        args+=("--ignore-certificate-errors")
-        echo "WARN: --ignore-certificate-errors activo. Usa --ca-cert si instalaste el CA del proxy." >&2
-    fi
-
-    # URL inicial opcional
-    if [[ -n "$start_url" ]]; then
-        args+=("$start_url")
-    fi
-
-    # Argumentos extra pasados por el usuario
-    # shellcheck disable=SC2206
-    local extra_arr=()
-    if [[ -n "$extra_args" ]]; then
-        read -r -a extra_arr <<< "$extra_args"
-        args+=("${extra_arr[@]}")
-    fi
-
-    # Log temporal para stderr/stdout del navegador
-    local log_file="/tmp/chromium-proxy-$$.log"
-
-    # Lanzar en background desacoplado de la sesion del agente
-    setsid "$browser_bin" "${args[@]}" </dev/null >"$log_file" 2>&1 &
-    local browser_pid=$!
-    disown "$browser_pid"
-
-    # Emitir JSON con informacion del proceso lanzado
-    printf '{"pid":%d,"browser":"%s","proxy":"%s","profile":"%s","log":"%s"}\n' \
-        "$browser_pid" "$browser_bin" "$proxy_url" "$profile_dir" "$log_file"
-}
-
-# Ejecutar si se llama directamente (fn run / bash <file>)
-if [[ "${BASH_SOURCE[0]}" == "${0}" ]]; then
-    launch_chromium_proxy "$@"
-fi

bash/functions/browser/prepare_chrome_profile.md

@@ -1,74 +0,0 @@
----
-name: prepare_chrome_profile
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "prepare_chrome_profile --src <user-data-dir> --dst <user-data-dir> [--keep <ext_id>]... [--force]"
-description: "Clona un user-data-dir de Chrome/Chromium creando un perfil de scraping limpio: conserva solo las extensiones de una lista blanca (por defecto uBlock Origin Lite) y excluye caché, locks y sesiones antiguas."
-tags: [chrome, browser, profile, scraping, extensions, navegator]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/prepare_chrome_profile.sh"
-params:
-  - name: --src
-    desc: "user-data-dir origen con un perfil Chrome/Chromium ya configurado (debe existir --src/Default)"
-  - name: --dst
-    desc: "Ruta de destino del nuevo perfil; no debe existir salvo que se pase --force"
-  - name: --keep
-    desc: "ID de extensión Chrome a conservar (repetible). Si no se pasa ninguno el default es ddkjiahejlhfcafbddmgiahcphecmpfh (uBlock Origin Lite)"
-  - name: --force
-    desc: "Borra --dst si existe antes de recrearlo. Sin este flag la función aborta si --dst ya existe"
-output: "JSON en stdout: {dst, kept: [id...], removed: [id...]}. Exit 0 en éxito."
----
-
-## Ejemplo
-
-```bash
-source $HOME/fn_registry/bash/functions/browser/prepare_chrome_profile.sh
-
-prepare_chrome_profile \
-  --src "$HOME/.config/chromium" \
-  --dst "$HOME/.local/share/web_scraping/chrome-profile"
-
-# Con extensión adicional conservada
-prepare_chrome_profile \
-  --src "$HOME/.config/chromium" \
-  --dst "$HOME/.local/share/web_scraping/chrome-profile" \
-  --keep "ddkjiahejlhfcafbddmgiahcphecmpfh" \
-  --keep "cjpalhdlnbpafiamejdnhcphjbkeiagm" \
-  --force
-
-# Salida esperada (ejemplo):
-# {"dst":"/home/enmanuel/.local/share/web_scraping/chrome-profile","kept":["ddkjiahejlhfcafbddmgiahcphecmpfh"],"removed":["abcdefghijklmnopabcdefghijklmnop","dark-reader-id"]}
-```
-
-## Cuando usarla
-
-Úsala antes de lanzar una sesión de scraping/automatización para partir de un perfil aislado: con uBlock Origin Lite activo (menos anuncios/trackers = DOM más limpio, respuestas más rápidas) pero sin extensiones que interfieren (Dark Reader muta colores del DOM, NoScript bloquea JS, OneTab modifica tabs). También sirve para aislar sesiones de diferentes proyectos de scraping sin contaminar el perfil personal.
-
-## Gotchas
-
-- **Chrome debe estar CERRADO sobre `--src`** antes de ejecutar. Los archivos SQLite (`Cookies`, `History`, `Login Data`, etc.) estarán bloqueados si Chrome está abierto, y `rsync` copiará versiones inconsistentes. Verificar con `pgrep -x chromium` o `pgrep -x chrome`.
-- **HMAC de Secure Preferences**: el archivo `Local State` contiene la semilla HMAC que Chrome usa para verificar `Preferences` y `Secure Preferences`. Si no se copia (o se copia entre máquinas distintas con distinto binding), Chrome puede invalidar las extensiones al arrancar y resetear configuraciones. La función copia `Local State` automáticamente, pero la copia entre máquinas puede seguir produciendo resets de extensiones — esto es comportamiento esperado de Chrome, no un bug de esta función.
-- **Purga de referencias en Preferences**: tras borrar las carpetas de extensiones fuera de la whitelist, la función también elimina con `python3` las entradas `extensions.settings.<id>` de `Default/Preferences` y `Default/Secure Preferences`, los IDs de `extensions.pinned_extensions` y las claves `protection.macs.extensions.settings.<id>`. Sin esta limpieza Chrome detecta las entradas en Preferences (con `from_webstore`/install_source) y **vuelve a descargar la extensión del Web Store al arrancar**, deshaciendo el filtrado (caso real: Dark Reader reaparece y oscurece páginas rompiendo screenshots). Si `python3` falla al procesar un Preferences concreto se emite un warning a stderr pero la función no aborta — el borrado de carpetas ya es el efecto principal.
-- **`--force` borra `--dst` completamente**: si `--dst` es un perfil con datos que quieres conservar, no uses `--force` sin antes hacer backup.
-- **Extensiones instaladas desde Web Store vs unpacked**: esta función opera sobre la carpeta `Extensions/` física. Las extensiones instaladas desde la Web Store tienen IDs de 32 caracteres en minúsculas. Las extensiones unpacked (`--load-extension`) no viven en `Extensions/` y no se ven afectadas.
-
-## Exit codes
-
-| Código | Significado |
-|--------|------------|
-| 0 | Éxito |
-| 1 | Argumento inválido o `--src/Default` no existe |
-| 2 | `--dst` ya existe y no se pasó `--force` |
-| 3 | `--src` y `--dst` resuelven al mismo path real |
-| 4 | Error durante `rsync` |

bash/functions/browser/prepare_chrome_profile.sh

@@ -1,223 +0,0 @@
-#!/usr/bin/env bash
-# prepare_chrome_profile — clona un user-data-dir de Chrome/Chromium conservando solo
-# las extensiones de una lista blanca. Sirve para perfiles de scraping limpios.
-
-set -euo pipefail
-
-# ── defaults ──────────────────────────────────────────────────────────────────
-_SRC=""
-_DST=""
-_FORCE=0
-# uBlock Origin Lite por defecto
-_KEEP=()
-_DEFAULT_EXT="ddkjiahejlhfcafbddmgiahcphecmpfh"
-
-# ── parse args ────────────────────────────────────────────────────────────────
-_usage() {
-    cat >&2 <<'EOF'
-Usage: prepare_chrome_profile --src <user-data-dir> --dst <user-data-dir> \
-           [--keep <ext_id>]... [--force]
-
-  --src   user-data-dir origen (ej. $HOME/.config/chromium)
-  --dst   user-data-dir destino a crear
-  --keep  ID de extensión a conservar (repetible). Default: uBlock Origin Lite
-  --force si --dst existe, lo borra y recrea; sin flag aborta si existe
-
-Exit codes:
-  0  éxito
-  1  error de argumento o validación
-  2  --dst ya existe y no se pasó --force
-  3  --src igual a --dst (mismo path real)
-  4  error de copia/rsync
-EOF
-    exit 1
-}
-
-while [[ $# -gt 0 ]]; do
-    case "$1" in
-        --src)   _SRC="$2";  shift 2 ;;
-        --dst)   _DST="$2";  shift 2 ;;
-        --keep)  _KEEP+=("$2"); shift 2 ;;
-        --force) _FORCE=1;   shift ;;
-        -h|--help) _usage ;;
-        *) echo "prepare_chrome_profile: argumento desconocido: $1" >&2; _usage ;;
-    esac
-done
-
-# ── validaciones básicas ──────────────────────────────────────────────────────
-if [[ -z "$_SRC" || -z "$_DST" ]]; then
-    echo "prepare_chrome_profile: --src y --dst son obligatorios" >&2
-    exit 1
-fi
-
-if [[ ! -d "$_SRC/Default" ]]; then
-    echo "prepare_chrome_profile: $_SRC/Default no existe; ¿es un user-data-dir válido?" >&2
-    exit 1
-fi
-
-# Resolver paths reales para comparar (evitar borrar src cuando src==dst)
-_SRC_REAL="$(realpath "$_SRC")"
-_DST_REAL="$(realpath -m "$_DST")"   # -m: no requiere que exista
-
-if [[ "$_SRC_REAL" == "$_DST_REAL" ]]; then
-    echo "prepare_chrome_profile: --src y --dst resuelven al mismo path: $_SRC_REAL" >&2
-    exit 3
-fi
-
-# También rechazar si --dst es prefijo de --src (evitar borrar el origen)
-if [[ "$_SRC_REAL" == "$_DST_REAL"/* ]]; then
-    echo "prepare_chrome_profile: --src está dentro de --dst; operación peligrosa, abortando" >&2
-    exit 3
-fi
-
-# ── lista blanca de extensiones ───────────────────────────────────────────────
-if [[ ${#_KEEP[@]} -eq 0 ]]; then
-    _KEEP=("$_DEFAULT_EXT")
-fi
-
-# ── gestionar destino ─────────────────────────────────────────────────────────
-if [[ -d "$_DST" ]]; then
-    if [[ $_FORCE -eq 1 ]]; then
-        rm -rf "$_DST"
-    else
-        echo "prepare_chrome_profile: $_DST ya existe; usa --force para sobreescribir" >&2
-        exit 2
-    fi
-fi
-
-mkdir -p "$_DST/Default"
-
-# ── copiar Local State (HMAC seed para Secure Preferences) ────────────────────
-if [[ -f "$_SRC/Local State" ]]; then
-    cp "$_SRC/Local State" "$_DST/Local State"
-fi
-
-# ── rsync del perfil Default excluyendo caché y locks ─────────────────────────
-rsync -a \
-    --exclude='Cache/' \
-    --exclude='Code Cache/' \
-    --exclude='GPUCache/' \
-    --exclude='Dawn Cache/' \
-    --exclude='DawnGraphiteCache/' \
-    --exclude='DawnWebGPUCache/' \
-    --exclude='Service Worker/CacheStorage/' \
-    --exclude='Service Worker/ScriptCache/' \
-    --exclude='Singleton*' \
-    --exclude='*.lock' \
-    --exclude='lockfile' \
-    --exclude='Sessions/' \
-    --exclude='Session Storage/' \
-    --exclude='Current Session' \
-    --exclude='Current Tabs' \
-    --exclude='Last Session' \
-    --exclude='Last Tabs' \
-    "$_SRC/Default/" "$_DST/Default/" || {
-        echo "prepare_chrome_profile: rsync falló (exit $?)" >&2
-        exit 4
-    }
-
-# ── eliminar extensiones fuera de la lista blanca ────────────────────────────
-_EXT_DIR="$_DST/Default/Extensions"
-_removed=()
-_kept=()
-
-if [[ -d "$_EXT_DIR" ]]; then
-    while IFS= read -r -d '' ext_path; do
-        ext_id="$(basename "$ext_path")"
-        # Conservar siempre la carpeta Temp (usada por Chrome durante installs)
-        if [[ "$ext_id" == "Temp" ]]; then
-            continue
-        fi
-        # Comprobar si está en la lista blanca
-        _in_keep=0
-        for keep_id in "${_KEEP[@]}"; do
-            if [[ "$ext_id" == "$keep_id" ]]; then
-                _in_keep=1
-                break
-            fi
-        done
-        if [[ $_in_keep -eq 1 ]]; then
-            _kept+=("$ext_id")
-        else
-            rm -rf "$ext_path"
-            _removed+=("$ext_id")
-        fi
-    done < <(find "$_EXT_DIR" -mindepth 1 -maxdepth 1 -type d -print0)
-fi
-
-# ── purgar referencias a extensiones eliminadas en Preferences ───────────────
-# Chrome re-descarga del Web Store cualquier extensión que aparezca en
-# extensions.settings aunque su carpeta haya sido borrada. Editamos el JSON
-# con python3 para evitar ese comportamiento.
-if [[ ${#_removed[@]} -gt 0 ]]; then
-    # Construir lista Python de IDs eliminados
-    _py_ids_list=""
-    for _id in "${_removed[@]}"; do
-        _py_ids_list+="\"${_id}\","
-    done
-    _py_ids_list="[${_py_ids_list%,}]"
-
-    for _prefs_file in "$_DST/Default/Preferences" "$_DST/Default/Secure Preferences"; do
-        if [[ -f "$_prefs_file" ]]; then
-            python3 - "$_prefs_file" "$_py_ids_list" <<'PY' || \
-                echo "prepare_chrome_profile: advertencia — no se pudieron purgar refs en $(basename "$_prefs_file")" >&2
-import sys, json
-
-prefs_path = sys.argv[1]
-removed_ids = json.loads(sys.argv[2])
-
-with open(prefs_path, "r", encoding="utf-8") as f:
-    data = json.load(f)
-
-# 1. extensions.settings.<id>
-ext_settings = data.get("extensions", {}).get("settings", {})
-for ext_id in removed_ids:
-    ext_settings.pop(ext_id, None)
-
-# 2. extensions.pinned_extensions (lista de IDs)
-pinned = data.get("extensions", {}).get("pinned_extensions", None)
-if isinstance(pinned, list):
-    data["extensions"]["pinned_extensions"] = [
-        pid for pid in pinned if pid not in removed_ids
-    ]
-
-# 3. protection.macs.extensions.settings.<id>  (Secure Preferences)
-try:
-    mac_ext = data["protection"]["macs"]["extensions"]["settings"]
-    for ext_id in removed_ids:
-        mac_ext.pop(ext_id, None)
-except (KeyError, TypeError):
-    pass
-
-with open(prefs_path, "w", encoding="utf-8") as f:
-    json.dump(data, f, separators=(",", ":"))
-PY
-        fi
-    done
-fi
-
-# ── emitir resultado JSON ─────────────────────────────────────────────────────
-_json_array() {
-    # Convierte array bash en JSON array de strings
-    local arr=("$@")
-    local out="["
-    local first=1
-    for item in "${arr[@]}"; do
-        if [[ $first -eq 1 ]]; then
-            out+="\"$item\""
-            first=0
-        else
-            out+=",\"$item\""
-        fi
-    done
-    out+="]"
-    echo "$out"
-}
-
-_kept_json="$(_json_array "${_kept[@]+"${_kept[@]}"}")"
-_removed_json="$(_json_array "${_removed[@]+"${_removed[@]}"}")"
-
-printf '{"dst":"%s","kept":%s,"removed":%s}\n' \
-    "$_DST_REAL" \
-    "$_kept_json" \
-    "$_removed_json"

bash/functions/browser/restore_chrome_bookmarks.md

@@ -1,93 +0,0 @@
----
-name: restore_chrome_bookmarks
-kind: function
-lang: bash
-domain: browser
-version: "1.0.0"
-purity: impure
-signature: "restore_chrome_bookmarks --backup-dir <ts-dir> [--user-data-dir <dir>] [--profile <name>]... [--dry-run]"
-description: "Restaura archivos Bookmarks de Chrome/Chromium desde un directorio de backup generado por backup_chrome_bookmarks hacia los perfiles destino en user-data-dir. Copia byte a byte con cp -p para preservar el checksum MD5 interno del archivo. Nunca parsea ni reserializa el JSON. Requiere que Chromium esté cerrado antes de ejecutar."
-tags: [navegator, chromium, bookmarks, restore, browser, scraping, profile]
-uses_functions: []
-uses_types: []
-returns: []
-returns_optional: false
-error_type: "error_go_core"
-imports: []
-tested: false
-tests: []
-test_file_path: ""
-file_path: "bash/functions/browser/restore_chrome_bookmarks.sh"
-params:
-  - name: --backup-dir
-    desc: "Directorio de backup con timestamp generado por backup_chrome_bookmarks. Debe contener subdirectorios <profile>/Bookmarks. OBLIGATORIO."
-  - name: --user-data-dir
-    desc: "Ruta raíz del user-data-dir de Chrome/Chromium destino. Default: ~/.config/chromium"
-  - name: --profile
-    desc: "Nombre del perfil a restaurar (repetible, ej. Default, Profile 1). Si no se pasa ninguno se restauran TODOS los perfiles presentes en el backup-dir."
-  - name: --dry-run
-    desc: "Muestra qué archivos se copiarían y cuáles Bookmarks.bak se borrarían, sin tocar nada en disco."
-output: "JSON en stdout: {\"restored\": [{\"profile\": \"Default\", \"dst\": \"<path>\", \"bytes\": N}, ...]}. Exit 0 en éxito o dry-run. Errores a stderr con exit != 0."
----
-
-## Ejemplo
-
-```bash
-# PASO 1 — cerrar Chromium (OBLIGATORIO en modo real)
-pkill -TERM chromium
-
-# PASO 2 — restaurar todos los perfiles desde el backup más reciente
-source $HOME/fn_registry/bash/functions/browser/restore_chrome_bookmarks.sh
-restore_chrome_bookmarks \
-    --user-data-dir "$HOME/.config/chromium" \
-    --backup-dir "$HOME/backups/chromium_bookmarks/2026-06-04T15:30:00"
-
-# Restaurar solo un perfil concreto
-restore_chrome_bookmarks \
-    --backup-dir "$HOME/backups/chromium_bookmarks/2026-06-04T15:30:00" \
-    --profile Default
-
-# Restaurar dos perfiles específicos
-restore_chrome_bookmarks \
-    --backup-dir "$HOME/backups/chromium_bookmarks/2026-06-04T15:30:00" \
-    --profile Default \
-    --profile "Profile 1"
-
-# Previsualizar sin tocar nada (no necesita Chromium cerrado)
-restore_chrome_bookmarks \
-    --backup-dir "$HOME/backups/chromium_bookmarks/2026-06-04T15:30:00" \
-    --dry-run
-
-# Salida esperada:
-# {"restored":[{"profile":"Default","dst":"/home/enmanuel/.config/chromium/Default/Bookmarks","bytes":12453}]}
-```
-
-También ejecutable directamente con `fn run`:
-
-```bash
-cd $HOME/fn_registry
-./fn run restore_chrome_bookmarks_bash_browser -- \
-    --backup-dir "$HOME/backups/chromium_bookmarks/2026-06-04T15:30:00" \
-    --dry-run
-```
-
-## Cuando usarla
-
-Úsala después de una sesión de scraping o automatización que haya alterado los bookmarks, o para recuperar bookmarks tras formatear/recrear un perfil de Chromium. Combínala con `backup_chrome_bookmarks` (que genera el `--backup-dir` con la estructura esperada) para tener un ciclo completo de backup/restore. También útil para propagar bookmarks de un perfil o PC a otro.
-
-## Gotchas
-
-- **Chromium DEBE estar cerrado** antes de ejecutar en modo real. Chromium mantiene los bookmarks en memoria y los reescribe al archivo `Bookmarks` al cerrar; si restauras con Chromium abierto, el proceso sobreescribirá tu restauración al cerrarse. La función lo comprueba con `pgrep -x chromium` y aborta con exit 2 si hay procesos vivos. En `--dry-run` este check se omite.
-- **Copia verbatim — nunca reserializar el JSON**. El archivo `Bookmarks` contiene un campo `checksum` con el MD5 del propio contenido JSON (calculado por Chromium internamente). Si se parsea y reserializa el JSON (aunque sea equivalente), el checksum queda inválido y Chromium descarta silenciosamente el archivo y regenera uno vacío. Esta función usa `cp -p` para garantizar que los bytes son idénticos al original.
-- **En Chromium 148 los bookmarks NO están bajo `super_mac` de Secure Preferences**. No es necesario tocar `Preferences` ni `Secure Preferences` al restaurar bookmarks (a diferencia de extensiones). La función solo opera sobre el archivo `Bookmarks`.
-- **`Bookmarks.bak` residual se borra**. Chromium crea `Bookmarks.bak` como copia de seguridad interna. Si existe antes de la restauración, esta función lo borra para que Chromium no lo use como fallback en lugar del archivo recién restaurado.
-- **El directorio destino del perfil se crea si no existe**. Si el perfil aún no tiene directorio en `user-data-dir`, se crea con `mkdir -p`. Chromium lo inicializará correctamente la primera vez que arranque con ese perfil.
-- **Opera por perfil**. Si no pasas `--profile`, restaura todos los perfiles presentes en el backup. Pasa `--profile` explícito para restaurar selectivamente y evitar sobreescribir perfiles sin querer.
-
-## Exit codes
-
-| Código | Significado |
-|--------|------------|
-| 0 | Éxito o dry-run completado |
-| 1 | Argumento inválido, backup-dir/user-data-dir no encontrado, o perfil no presente en backup |
-| 2 | Chromium está corriendo (solo en modo real) |