Aller au contenu

Développer une feature

Source de vérité : les issues GitHub

Les issues du projet #3 sont la seule source de vérité des specs backend. Lisez-les avec gh issue view <N>.

Chaque issue a un résumé fonctionnel (user story, critères d'acceptation, cross-module). Les critères d'acceptation sont le contrat : l'implémentation doit les satisfaire. Les formes d'endpoint / codenames de permission mentionnés sont des indications — adaptez-les aux conventions du codebase (workspace actif par en-tête, registre de codenames, routes REST plates).

Priorité

La priorité (Px) se règle via le champ Priority du projet #3 — ne créez jamais de labels P0/P1/P2.

TDD (obligatoire)

  1. Aligner sur quoi construire et comment — questions + plan d'abord.
  2. Rouge — écrire les tests qui échouent.
  3. Vert — implémenter jusqu'à faire passer les tests.
  4. Tous les tests passent avant de marquer la tâche terminée.

Voir Tests pour les conventions (factories, seeding FK, tiers d'intégration/e2e).

Ordre des couches (slice vertical)

Construisez une fonctionnalité couche par couche, dans cet ordre :

  1. Entité de domaine — domain/<entity>/ (données + fromRecord + interface d'attributs).
  2. Modèle DB — database/sequelize/models/, migration, accesseur typé, associations. Compétence ikloze-define-model.
  3. Service applicatif — app/<entity>/ (schéma Zod + service en 6 étapes). Compétence ikloze-define-service.
  4. Couche web — schéma Swagger, contrôleur NestJS, câblage du module. Compétence ikloze-define-web.

La compétence ikloze-new-feature orchestre ce slice complet.

Flux Git

  • Brancher depuis dev avec git switch -c <feature-code>/<short-description> (ex. users/allow-closer-assignment).
  • Ouvrir une PR draft tôt, rebaser avant de passer en « ready ».
  • Format de commit avec (#N), gabarit de PR, et règle « pas de Closes #N » dans les PR backend.

Cycle de vie de l'issue

Au démarrage d'une issue : la déplacer Ready → In progress sur le projet #3 avant d'écrire du code. À la fusion de la PR backend : déplacer l'issue en « QA », jamais la fermer. L'issue se ferme une fois que l'issue frontend appairée se ferme.

Les conventions tactiques complètes (création de branche, format de commit, gabarit de PR, rituel post-merge, mutation GraphQL du projet #3) sont dans Guidelines Git. Le modèle de branches, les milestones et le déploiement sont dans Workflow Git.