.claude/commands/app.md

@@ -20,6 +20,8 @@ Si no se proporciona nombre, preguntar al usuario que quiere construir.
 
 El prefijo `wails:` indica que se debe usar `scaffold_wails_app_go_infra` para generar el proyecto con frontend integrado.
 
+El prefijo `service:` indica que la app es un proceso de larga duracion (API, daemon, watcher). Añadir tag `service` automaticamente.
+
 ---
 
 ## PASO 0: Entender que se va a construir
@@ -97,15 +99,15 @@ mkdir -p /home/lucas/fn_registry/apps/{app_name}
 ```yaml
 ---
 name: {app_name}
-lang: {go|py|bash|ts}
+lang: {go|py|bash|ts|cpp}
 domain: {domain}
 description: "{descripcion}"
-tags: [{tags}]
+tags: [{tags}]  # Añadir "service" si es proceso de larga duracion
 uses_functions:
   - {id_funcion_1}
   - {id_funcion_2}
 uses_types: []
-framework: "{bubbletea|wails|httpx|...}"
+framework: "{bubbletea|wails|httpx|imgui|...}"
 entry_point: "{main.go|main.py|main.sh}"
 dir_path: "apps/{app_name}"
 repo_url: ""
@@ -120,6 +122,11 @@ repo_url: ""
 {Notas adicionales, dependencias externas, configuracion necesaria}
 ```
 
+**Si es un service** (tag `service`), documentar ademas en el app.md:
+- Puerto que usa (si expone HTTP/gRPC)
+- Como lanzarlo y pararlo
+- Health check (como comprobar que esta vivo)
+
 ### .gitignore (OBLIGATORIO)
 
 ```
@@ -217,9 +224,9 @@ Si el recopilador detecta problemas, corregirlos antes de continuar.
 
 ---
 
-## PASO 5: PUBLICAR en Gitea (@gitea)
+## PASO 5: PUBLICAR en Gitea (@gitea) — OBLIGATORIO
 
-Una vez la app esta funcionando y auditada, publicarla como repo independiente en Gitea.
+Toda app nueva DEBE publicarse en Gitea. Este paso NO es opcional.
 
 **Como invocar:**
 
@@ -315,17 +322,46 @@ Para ejecutar:
 2. Source pattern con REGISTRY_ROOT
 3. set -euo pipefail obligatorio
 
+### App C++ (ImGui)
+
+1. Codigo fuente va en `apps/{app_name}/` (no en `cpp/apps/`)
+2. `cpp/CMakeLists.txt` referencia la app con `add_subdirectory(../apps/{app_name} ...)`
+3. Funciones C++ del registry se incluyen como .cpp en el CMakeLists.txt de la app
+4. Para Windows: cross-compile con `cmake -DCMAKE_TOOLCHAIN_FILE=toolchains/mingw-w64.cmake`
+
+### Service (tag `service`)
+
+1. Detectar si el usuario pide un servicio (API, daemon, watcher, server) o usa prefijo `service:`
+2. Añadir tag `service` al array `tags` del app.md
+3. Documentar en app.md: puerto, como lanzar/parar, health check
+4. Estructura tipica para un HTTP service en Go:
+   ```
+   apps/{service_name}/
+   ├── app.md           # tags: [service, api, ...]
+   ├── main.go          # Bind port, listen, graceful shutdown
+   ├── handlers.go      # HTTP handlers que componen funciones del registry
+   ├── go.mod
+   ├── .gitignore
+   ```
+5. El service se ejecuta como: `go run . --port 8080`
+6. Para consultar services existentes: `sqlite3 registry.db "SELECT id, name, description FROM apps WHERE tags LIKE '%service%';"`
+
 ---
 
 ## Reglas
 
 - **Codigo reutilizable** va en `functions/`, NO en la app → usar fn-constructor
 - **Codigo especifico** de la app va en `apps/{app_name}/`
+- **Todas las apps van en `apps/`**, incluidas C++, TypeScript, etc. Nunca en `cpp/apps/` ni otros subdirectorios
 - **operations.db** SOLO dentro de la app, NUNCA en la raiz
 - **registry.db** SOLO en la raiz, NUNCA en apps
 - Toda app DEBE tener `app.md` con frontmatter completo
 - `uses_functions` en app.md DEBE listar TODAS las funciones del registry importadas
-- Siempre `./fn index` despues de crear/modificar la app
+- Siempre `./fn index` despues de crear/modificar la app — **verificar que aparece en registry.db**
 - Siempre auditar con fn-recopilador antes de publicar
+- **Siempre publicar en Gitea** (PASO 5) — toda app tiene repo en `dataforge/{app_name}`
+- **Siempre actualizar `repo_url`** en app.md despues de publicar y re-indexar
+- **Tag `service`**: añadir a apps que son procesos de larga duracion (APIs, daemons, watchers, schedulers)
+- **Tag `launcher`**: añadir a pipelines que deben aparecer en Pipeline Launcher TUI
 
 $ARGUMENTS

.claude/commands/create_functions.md

@@ -266,5 +266,8 @@ Para usar estas funciones:
 - **NO crear funciones especificas de una app** — solo codigo reutilizable y generico
 - Si el usuario pide algo que ya existe, informar y sugerir reutilizar en vez de duplicar
 - Si una funcion del batch falla, las demas del mismo batch pueden continuar independientemente
+- **Tags con significado especial** — ver `.claude/rules/function_tags.md`:
+  - `launcher`: pipelines que deben aparecer en Pipeline Launcher TUI. Añadir cuando se crea un pipeline ejecutable desde el launcher. NO añadir a pipelines interactivos/TUIs.
+  - `service`: para apps que son procesos de larga duracion (usado en /app, no en funciones)
 
 $ARGUMENTS