Saltar al contenido principal

Convenciones

Ramas​

RamaPara qué
devIntegración. Todo PR va aquí. Al hacer merge se despliega a test
mainProducción. Solo llega por promoción desde dev

Commits​

Conventional Commits, comprobado por el hook commit-msg antes de cada commit y otra vez por el CI sobre los commits del PR:

<tipo>(<ámbito>): <descripción en minúscula>

Tipos: feat, fix, docs, refactor, perf, test, build, ci, chore, revert.

El ámbito importa más de lo que parece: es lo que agrupa las notas de versión. Usa el módulo afectado (health, whatsapp, scheduling, crm, bots, docs).

feat(scheduling): permitir bloquear un rango desde el calendario
fix(whatsapp): conservar el contexto al elegir horario en una lista
docs(bots): documentar la tool de reserva

Si el commit rompe compatibilidad, ! antes de los dos puntos y un BREAKING CHANGE: en el cuerpo.

Código​

  • TypeScript en todo. Nada de any sin un comentario explicando por qué.
  • Backend: un módulo de Nest por dominio. Los controladores delegan, no implementan.
  • Frontend: page.tsx es un envoltorio; la interfaz va en sections/. Las rutas se referencian desde src/routes/paths.ts, nunca escritas a mano.
  • Textos de interfaz en los archivos de traducción desde el primer momento.
  • Comentarios: explica el porqué, no el qué. Si un comentario describe lo que hace la línea siguiente, sobra.

Antes de abrir un PR​

npm run test
cd frontend && yarn lint
cd docs && yarn gen && yarn build && yarn coverage

Y repasa la casilla de documentación de la plantilla del PR. Ver Mantener la documentación.

Secretos​

Nunca en el repositorio. Ni en el código, ni en la documentación, ni en un comentario de un PR. En la documentación se pone el nombre de la variable y dónde conseguir su valor, nunca el valor.

El archivo testaccounts.md de la raíz contiene credenciales de prueba y por eso se queda fuera del sitio de documentación: aunque el sitio interno esté protegido, no hay razón para multiplicar los sitios donde vive esa información.