## 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.