docs(rules): TBD con feature flags para WIP sin romper master

- apps_tbd.md: tabla de decision para WIP en working tree (incluir/flag/stash/issue separado)
- feature_flags.md (nuevo): doctrina TBD oficial, patrones Go/TS/Bash/Py, branch-by-abstraction, anti-patrones
- INDEX: entrada 24

Refs: trunkbaseddevelopment.com/feature-flags y branch-by-abstraction.

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

.claude/rules/apps_tbd.md

@@ -19,7 +19,20 @@ master ← siempre deployable
 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`.
+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