286be8ba1d
- docs: SCOPE_CONTROL, CONTRIBUTING, README, .github templates - frontend: DeveloperDashboardView, Player components, MSW handlers, auth, reactQuerySync - backend: playback_analytics, playlist_service, testutils, integration README Excluded (artifacts): .auth, playwright-report, test-results, storybook_audit_detailed.json
2.7 KiB
2.7 KiB
🤝 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 :
- Cohérence — respecter la structure ORIGIN (docs/ORIGIN/).
- Lisibilité — code clair, typé, testé, documenté.
- É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 workerfix: correct JWT user_id mismatch between Go and Rustrefactor: isolate DM module in chat-server
5. Tests & Qualité
Avant toute PR :
- 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 !