docs(rules): añadir regla KISS para proyectos y apps

Formaliza la filosofía de mantener projects/ y apps/ simples:
- preferir herramientas del sistema o del registry antes que paquetes
  externos,
- cuestionar cada nueva dependencia (coste/beneficio, riesgo upstream),
- evitar abstracciones especulativas,
- ser consciente del flujo de trabajo actual.

Incluye el aprendizaje del experimento con GitButler (retirado en commit
correspondiente de repo_Claude) como caso concreto de una herramienta
externa que añadió complejidad sin beneficio en nuestro contexto.

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

.claude/rules/INDEX.md

@@ -19,3 +19,4 @@ Reglas operativas del proyecto. Cada archivo es una regla independiente.
 | 13 | [frontend_theming.md](frontend_theming.md) | Componentes propios y sistema de temas en frontends |
 | 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 |

.claude/rules/kiss.md

@@ -0,0 +1,30 @@
+## KISS en proyectos y apps
+
+**Mantener proyectos (`projects/`) y apps (`apps/`, `projects/*/apps/`) simples**. La complejidad no solicitada es deuda — cada línea, cada dependencia y cada herramienta externa se justifican o no entran.
+
+### Reglas
+
+1. **Preferir herramientas ya presentes en el sistema o en el registry** antes que paquetes/CLI externos.
+   - ¿Lo hace `git` / `bash` / una función del registry? Úsalo.
+   - Antes de añadir una dependencia nueva, buscar en `registry.db` (FTS5) si ya existe algo similar.
+
+2. **Cuestionar cada nueva herramienta externa**. Antes de instalarla preguntar:
+   - ¿Qué problema concreto resuelve que NO podemos resolver con lo que ya tenemos?
+   - ¿El coste (instalar, mantener, aprender, conflictos con nuestro flujo) compensa el beneficio real?
+   - ¿Qué pasa si el proyecto upstream se abandona / rompe compatibilidad?
+
+3. **Sin abstracciones ni features especulativas**. No generalizar "por si acaso". Tres líneas similares son mejores que una abstracción prematura.
+
+4. **Ser consciente del flujo de trabajo actual**. Si algo funciona bien con `git` / submódulos / `fn` CLI, no lo sustituyas por una herramienta que prometa "mejorarlo" sin evidencia de mejora concreta en tu contexto.
+
+5. **Escritura de apps**: una responsabilidad clara, layout mínimo (`main.*`, `app.md`, y lo estrictamente necesario), sin config ni estructuras que no se usen hoy.
+
+### Caso aprendido (GitButler)
+
+Se probó GitButler (virtual branches) pensando en paralelizar trabajo. Resultado:
+- Bugs con submódulos (git submodule add + gitlinks) — commits vacíos o contenido cruzado.
+- Auto-commits con el texto del chat como commit message.
+- Pre-commit hook que bloquea `git commit` directo y exige otro CLI (`but`).
+- Un binario externo de 37 MB + un plugin en Claude Code + skill propio + hooks en `settings.json`.
+
+Al volver a `git` + ramas normales + `fn` CLI: cero fricción, commits limpios, submódulos funcionan. **Lección**: antes de adoptar una capa nueva, medir la fricción real actual. Si no la hay, no vale la pena añadir complejidad.