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
137 lines
2.7 KiB
Markdown
137 lines
2.7 KiB
Markdown
# 🤝 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](docs/V0_101_RELEASE_SCOPE.md) et [docs/SCOPE_CONTROL.md](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 chat-server`
|
||
|
||
---
|
||
|
||
# 5. 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 ./...
|
||
```
|
||
|
||
---
|
||
|
||
# 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 !
|
||
|
||
|