fn_registry/.claude/rules/apps_tbd.md at b4db4e4ef5aea5c3835db9fa11de7cd7e382bd73

Files

T

egutierrez 836ff02578 docs: ADR 0002 + CHANGELOG + reglas para dataforge/<name>+master

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

2026-04-28 22:41:55 +02:00

2.5 KiB

Raw Blame History

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

Nunca trabajar directo en master para una app. Crear issue/<NNNN>-<slug> o quick/<slug> primero.
Commits atomicos por bloque logico (no WIP, no mezclar tipos).
Tests obligatorios antes de mergear (los que aplique al stack: ctest/go test/pytest/...).
merge --no-ff preserva la historia paralela. git log --first-parent master da la vista limpia.
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.

2.5 KiB Raw Blame History

Trunk-based development (TBD) en apps generadas con fn