# 🤝 Contribuer à Veza Merci de contribuer à Veza ! Ce guide formalise un workflow clair, reproductible et adapté à la complexité du projet. --- # 1. 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. --- # 2. Branching Model - `main` : toujours stable, toujours déployable. - `develop` (optionnel) : branche d’intégration continue. - Branches par fonctionnalité : ```` feat/ fix/ chore/ refactor/ docs/ ``` Exemples : - `feat/auth-refresh-tokens` - `fix/jwt-uuid-mismatch` - `refactor/chat-room-architecture` --- # 3. 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 chat-server` --- # 4. Tests & Qualité Avant toute PR : 1. Lancer les tests Go : ```bash 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 ./... ``` --- # 5. 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. --- # 6. 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 !