egutierrez
28ff9c3f79
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>
31 lines
2.0 KiB
Markdown
31 lines
2.0 KiB
Markdown
## 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.
|