egutierrez
a92213853d
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>
2.0 KiB
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
-
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.
- ¿Lo hace
-
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?
-
Sin abstracciones ni features especulativas. No generalizar "por si acaso". Tres líneas similares son mejores que una abstracción prematura.
-
Ser consciente del flujo de trabajo actual. Si algo funciona bien con
git/ submódulos /fnCLI, no lo sustituyas por una herramienta que prometa "mejorarlo" sin evidencia de mejora concreta en tu contexto. -
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 commitdirecto 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.