veza/CONTRIBUTING.md

🤝 Contribuer à Veza

Merci de contribuer à Veza !
Ce guide formalise un workflow clair, reproductible et adapté à la complexité du projet.

---

1. Scope v0.101 (priorité absolue)

En cours jusqu'au tag v0.101 : freeze fonctionnel. Aucune nouvelle feature.

• Référence : docs/V0_101_RELEASE_SCOPE.md et docs/SCOPE_CONTROL.md
• Autorisé : fix, refactor, test, docs, nettoyage, stabilisation
• Interdit : nouvelles features, nouvelles routes, nouvelles pages, nouvelles dépendances (sauf correctif sécurité)
• Avant toute PR : cocher la vérification scope dans le template

---

2. Philosophie du projet

Veza suit trois principes :

1. Cohérence — respecter la structure ORIGIN (docs/ORIGIN/).
2. Lisibilité — code clair, typé, testé, documenté.
3. Évolutivité — préférer une architecture modulaire à un hack rapide.

---

3. Branching Model

• main : toujours stable, toujours déployable.
• develop (optionnel) : branche d’intégration continue.
• Branches par fonctionnalité :

feat/<nom-fonction>
fix/<bug>
chore/<tâche-technique>
refactor/<refacto>
docs/<documentation>

```

Exemples :

- `feat/auth-refresh-tokens`
- `fix/jwt-uuid-mismatch`
- `refactor/chat-room-architecture`

---

# 4. Convention de commits

Suivre le style **Conventional Commits** :

```

feat: ajout fonctionnalité
fix: correction de bug
chore: tâches automatiques, maj deps
docs: ajout ou mise à jour docs
refactor: restructuration sans changement de comportement
test: ajout/màj tests
ci: pipeline CI/CD

Exemples :

• feat: add adaptive HLS transcoding worker
• fix: correct JWT user_id mismatch between Go and Rust
• refactor: isolate DM module in stream-server

---

5. Tests & Qualité

Avant toute PR :

1. Lancer les tests Go :

   go test ./...
   

2. Lancer les tests Rust :

   ```bash
   cargo test
   ```

3. Lancer les tests du frontend :

   ```bash
   pnpm test
   ```

4. Vérifier lfmt / clippy :

   ```bash
   cargo fmt --all --check
   cargo clippy -- -D warnings
   ```

5. Vérifier go vet :

   ```bash
   go vet ./...
   ```

---

# 6. Pull Requests

1. Toujours ouvrir une PR, même si vous êtes seul.
2. Décrire :

   * Contexte
   * Changement
   * Impact sur l'architecture ORIGIN
   * Migrations nécessaires ?
   * Compatibilité ascendante ?
3. Ajouter des captures si c’est du frontend.
4. Pas de merge si CI échoue.

---

# 7. Documentation

* Tout changement significatif doit être reflété dans `docs/`.
* Si une décision touche à l’architecture : mettre à jour la section `ORIGIN`.

---

Merci de rendre Veza meilleur !