docs: documentar TBD, feature flags y convenciones de commits en reglas

Añade documentación completa del flujo trunk-based development a todos
los archivos de reglas y comandos del proyecto:

- CLAUDE.md: sección completa de TBD con flujo, commits, ramas y feature flags
- git-branch.md: sección de features multi-issue y reglas de commits
- git-push.md: reglas críticas de commits (no WIP, no squash, no rebase -i)
- create_issue.md: guía de desglose en sub-issues con feature flags
- fix_issue.md: cuándo usar/no usar feature flags, flujo multi-issue
- index.md: resumen expandido del flujo TBD con commits y flags

Impacto: todas las reglas ahora documentan consistentemente el flujo
de desarrollo, convenciones de commits y uso de feature flags.

.claude/rules/create_issue.md

@@ -47,6 +47,27 @@ Agregar una fila al final de la tabla en `dev/issues/README.md`:
 | <N> | <Titulo> | [<NNNN>-<slug>.md](<NNNN>-<slug>.md) | pendiente |
 ```
 
+## Features multi-issue (feature flags)
+
+Si la feature es demasiado grande para completarse en una sola rama corta (horas), **desglosar en sub-issues** que se implementan y mergean por separado. Cada sub-issue debe:
+
+1. Ser autocontenido: compilar, pasar tests, no romper master
+2. Proteger el codigo parcial con un **feature flag** en `dev/feature_flags.json` (desactivado hasta que todo este listo)
+3. Usar numeracion con sufijo letra: `0015a`, `0015b`, etc.
+
+**Ejemplo:**
+
+```
+0015a-telegram-types       → tipos puros en pkg/
+0015b-telegram-client      → cliente en shell/
+0015c-telegram-listener    → integracion en agents/
+0015d-telegram-enable      → activar flag, cleanup
+```
+
+Indicar en el issue principal que es multi-issue y listar los sub-issues planificados.
+
+**Feature flag ≠ WIP.** Un flag protege codigo terminado y testeado; un WIP es codigo a medias. Nunca commitear codigo incompleto a master.
+
 ## Reglas
 
 - **Patron pure core / impure shell**: toda feature debe explicar que va en `pkg/` (puro) vs `shell/` (impuro).
@@ -54,6 +75,7 @@ Agregar una fila al final de la tabla en `dev/issues/README.md`:
 - **Numeracion continua**: nunca reusar numeros de issues eliminados.
 - **Estado**: los issues nuevos siempre empiezan como `pendiente`.
 - **Completados**: cuando se termine un issue, moverlo a `dev/issues/completed/` y actualizar el README.
+- **Issues grandes**: si no cabe en una rama corta, desglosar en sub-issues con feature flags.
 
 ## Verificacion
 
@@ -61,3 +83,4 @@ Agregar una fila al final de la tabla en `dev/issues/README.md`:
 - [ ] Todas las secciones del template rellenadas
 - [ ] Fila agregada en `dev/issues/README.md`
 - [ ] Numero de issue es consecutivo (no hay saltos ni duplicados)
+- [ ] Si es multi-issue: sub-issues planificados y feature flag definido