docs(rules): TBD obligatorio en apps generadas con fn (registry exento)

Aclara la politica:
- Registry (functions/, types/, .claude/, docs/, dev/issues/): push directo
  a master. Cambios atomicos por naturaleza, no hay deployment.
- Apps generadas (apps/, projects/*/apps/, services con tag service): TBD
  obligatorio — issue/<NNNN>-<slug> o quick/<slug>, merge --no-ff a master.

Tabla en apps_tbd.md de cuando aplica TBD por tipo de cambio. Indice de
reglas actualizado a 17 entradas.

.claude/rules/INDEX.md

@@ -20,3 +20,4 @@ Reglas operativas del proyecto. Cada archivo es una regla independiente.
 | 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) |

.claude/rules/apps_tbd.md

@@ -0,0 +1,43 @@
+## 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:
+
+```
+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`.
+
+### 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.