Los pipelines con tag `launcher` aparecen en el Pipeline Launcher TUI (`apps/pipeline_launcher`).

Sin el tag, el pipeline no es lanzable desde la TUI. Añadir `launcher` al array `tags` del .md al crear un pipeline ejecutable desde el launcher.

Pipelines interactivos (TUIs) o que no son subprocesos NO deben llevar este tag.

## Tag `service`

Las apps con tag `service` son procesos de larga duracion: APIs, daemons, watchers, servers.

Diferencia con una app normal:
- Una **app** se ejecuta, hace su trabajo, y termina (CLI, TUI, script)
- Un **service** se lanza y queda corriendo indefinidamente (API server, scheduler, watcher)

Añadir `service` al array `tags` del `app.md` cuando la app esta diseñada para correr como proceso persistente.

Un service sigue siendo una app — vive en `apps/`, tiene `app.md`, se indexa igual. El tag es solo metadata para filtrar:

```sql
-- Listar services
SELECT id, name, description FROM apps WHERE tags LIKE '%service%';

-- Listar apps que NO son services
SELECT id, name, description FROM apps WHERE tags NOT LIKE '%service%';
```

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.
