egutierrez
836ff02578
- docs/adr/0002-apps-analyses-as-dataforge-master.md: decision arquitectural con contexto, alternativas descartadas y cambios concretos del 2026-04-28. - CHANGELOG.md: entrada 2026-04-28 con Added/Changed/Fixed. - .claude/CLAUDE.md: nota sobre /full-git-push y dataforge/<name>+master. - .claude/rules/apps_tbd.md: tronco unico master + init.defaultBranch. - cpp/functions/core/app_menubar.md: notas del submenu Settings con About. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
46 lines
2.5 KiB
Markdown
46 lines
2.5 KiB
Markdown
## Trunk-based development (TBD) en apps generadas con `fn`
|
|
|
|
**El registry NO usa TBD** (push directo a master OK). Pero **toda app generada con `fn`** que viva en `apps/`, `projects/<name>/apps/` o que se despliegue a un VPS via `deploy_server` **DEBE seguir TBD** mientras se desarrolla.
|
|
|
|
**Tronco unico: `master`** en todos los repos `dataforge/<name>` del ecosistema (apps + analyses). Ver ADR 0002. El default de `git init` debe estar en `master` (`git config --global init.defaultBranch master`) — los pipelines de scaffolding y `ensure_repo_synced_bash_infra` ya pasan `master` explicitamente.
|
|
|
|
```
|
|
master ← siempre deployable
|
|
↑
|
|
└── issue/<NNNN>-<slug> ← rama efimera (horas)
|
|
└── quick/<slug> ← cambios rapidos sin issue
|
|
commits atomicos (feat:, fix:, test:, docs:, refactor:, chore:)
|
|
merge --no-ff → master → push → delete branch
|
|
```
|
|
|
|
### Reglas
|
|
|
|
1. **Nunca trabajar directo en master para una app**. Crear `issue/<NNNN>-<slug>` o `quick/<slug>` primero.
|
|
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`.
|
|
|
|
### Por que el registry esta exento
|
|
|
|
El registry es un repo de funciones reutilizables, no un servicio en produccion. Los cambios son atomicos por su propia naturaleza (una funcion = uno o dos archivos). Imponer TBD a cada `fn add` añadiria fricion sin ganancia: la BD se regenera con `fn index`, no hay deployment, no hay usuarios consumiendo master en directo.
|
|
|
|
### Cuando aplica TBD
|
|
|
|
| Cambio | TBD obligatorio |
|
|
|---|---|
|
|
| Funcion nueva en `cpp/functions/`, `python/functions/`, etc. | NO — push directo a master |
|
|
| Tipo nuevo en `types/` | NO |
|
|
| Doc/regla en `.claude/`, `docs/` | NO |
|
|
| Issue del registry mismo (`dev/issues/`) | NO — issue cerrado y push directo |
|
|
| App nueva o modificacion de app en `apps/` o `projects/*/apps/` | **SI** |
|
|
| Service desplegable (`tag: service`) | **SI** |
|
|
| Analysis en `analysis/` o `projects/*/analysis/` | NO — son exploraciones efimeras |
|
|
|
|
### Comandos
|
|
|
|
- `/git-branch` — crea rama desde master actualizado (para apps).
|
|
- `/git-push` — tests → merge `--no-ff` → push → eliminar rama (para apps).
|
|
|
|
Para el registry, push directo a master con commits atomicos.
|