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](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 stream-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 !