senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
veza/veza-docs/ORIGIN/ORIGIN_FEATURE_VALIDATION_STRATEGY.md
okinrev b7955a680c P0: stabilisation backend/chat/stream + nouvelle base migrations v1 
Backend Go:
- Remplacement complet des anciennes migrations par la base V1 alignée sur ORIGIN.
- Durcissement global du parsing JSON (BindAndValidateJSON + RespondWithAppError).
- Sécurisation de config.go, CORS, statuts de santé et monitoring.
- Implémentation des transactions P0 (RBAC, duplication de playlists, social toggles).
- Ajout d’un job worker structuré (emails, analytics, thumbnails) + tests associés.
- Nouvelle doc backend : AUDIT_CONFIG, BACKEND_CONFIG, AUTH_PASSWORD_RESET, JOB_WORKER_*.

Chat server (Rust):
- Refonte du pipeline JWT + sécurité, audit et rate limiting avancé.
- Implémentation complète du cycle de message (read receipts, delivered, edit/delete, typing).
- Nettoyage des panics, gestion d’erreurs robuste, logs structurés.
- Migrations chat alignées sur le schéma UUID et nouvelles features.

Stream server (Rust):
- Refonte du moteur de streaming (encoding pipeline + HLS) et des modules core.
- Transactions P0 pour les jobs et segments, garanties d’atomicité.
- Documentation détaillée de la pipeline (AUDIT_STREAM_*, DESIGN_STREAM_PIPELINE, TRANSACTIONS_P0_IMPLEMENTATION).

Documentation & audits:
- TRIAGE.md et AUDIT_STABILITY.md à jour avec l’état réel des 3 services.
- Cartographie complète des migrations et des transactions (DB_MIGRATIONS_*, DB_TRANSACTION_PLAN, AUDIT_DB_TRANSACTIONS, TRANSACTION_TESTS_PHASE3).
- Scripts de reset et de cleanup pour la lab DB et la V1.

Ce commit fige l’ensemble du travail de stabilisation P0 (UUID, backend, chat et stream) avant les phases suivantes (Coherence Guardian, WS hardening, etc.).
2025-12-06 11:14:38 +01:00

10 KiB
Raw Blame History

ORIGIN_FEATURE_VALIDATION_STRATEGY.md

📋 RÉSUMÉ EXÉCUTIF

Ce document définit la stratégie de validation stricte pour garantir que chaque feature soit 100% fonctionnelle avant d'être marquée comme complétée. Cette stratégie élimine le problème des features "complétées" mais non fonctionnelles.

🎯 OBJECTIFS

Objectif Principal

Garantir que chaque feature implémentée est 100% fonctionnelle dès le début, peu importe sa complexité, en suivant un processus de validation rigoureux conforme aux standards ORIGIN.

Objectifs Secondaires

  • Éliminer les features "complétées" mais non fonctionnelles
  • Réduire le temps de debugging post-implémentation à zéro
  • Assurer la cohérence entre le code et le comportement attendu
  • Maintenir la confiance dans le statut "complété" des tâches

🔒 RÈGLES IMMUABLES

  1. Aucune tâche ne peut être marquée "complétée" sans validation manuelle complète
  2. Chaque feature DOIT être testée dans le navigateur/app avant validation
  3. Tous les chemins d'utilisation DOIVENT être testés (happy path + edge cases + error cases)
  4. Les erreurs console DOIVENT être résolues avant validation
  5. Les tests automatisés DOIVENT passer avant validation
  6. La documentation DOIT être à jour avant validation
  7. Les dépendances backend/frontend DOIVENT être vérifiées
  8. Les intégrations (API, WebSocket, etc.) DOIVENT être fonctionnelles
  9. L'UX DOIT être cohérente et intuitive
  10. Les performances DOIVENT être acceptables (< 100ms pour actions utilisateur)

📋 CHECKLIST DE VALIDATION OBLIGATOIRE

Phase 1: Validation Technique (Backend)

✅ Backend API

  • Routes configurées : Routes définies dans routes.go et accessibles
  • Handlers implémentés : Tous les handlers nécessaires existent et fonctionnent
  • Services implémentés : Services métier complets avec logique correcte
  • Repositories implémentés : Accès données fonctionnel
  • Validation des données : Validation des inputs (binding, required, format)
  • Gestion d'erreurs : Erreurs gérées proprement avec codes HTTP appropriés
  • Authentification : Middleware auth appliqué si nécessaire
  • Logging : Logs appropriés pour debugging
  • Tests unitaires : Tests passent avec coverage ≥ 80%
  • Tests d'intégration : Tests API passent (curl/Postman)

✅ Base de données

  • Migrations : Migrations SQL créées et appliquées
  • Schéma : Tables/colonnes créées correctement
  • Indexes : Indexes créés pour performance
  • Contraintes : Foreign keys, unique constraints, etc.
  • Données de test : Données de test créées si nécessaire

Phase 2: Validation Technique (Frontend)

✅ Composants React

  • Composants créés : Tous les composants nécessaires existent
  • Props typées : TypeScript types corrects
  • État géré : State management (Zustand/Context) fonctionnel
  • Handlers d'événements : onClick, onSubmit, etc. implémentés
  • Validation formulaire : Validation côté client si nécessaire
  • Gestion d'erreurs : Erreurs affichées à l'utilisateur
  • Loading states : États de chargement affichés
  • Accessibilité : ARIA labels, keyboard navigation
  • Responsive : Design responsive fonctionnel

✅ Intégrations

  • API calls : Appels API fonctionnels (GET, POST, PUT, DELETE)
  • WebSocket : Connexions WebSocket fonctionnelles si nécessaire
  • Token management : Gestion des tokens JWT correcte
  • Error handling : Gestion des erreurs API (401, 404, 500, etc.)
  • Retry logic : Logique de retry si nécessaire

Phase 3: Validation Fonctionnelle (Manuelle)

✅ Test dans le navigateur

  • Feature accessible : Feature accessible via navigation/URL
  • UI visible : Interface utilisateur s'affiche correctement
  • Interactions fonctionnelles : Clics, saisies, soumissions fonctionnent
  • Flux complet : Flux utilisateur complet testé de bout en bout
  • Edge cases : Cas limites testés (champs vides, valeurs invalides, etc.)
  • Error cases : Cas d'erreur testés (API down, timeout, etc.)
  • Navigation : Navigation entre pages fonctionnelle
  • Redirections : Redirections après actions fonctionnent

✅ Console du navigateur

  • Aucune erreur console : Pas d'erreurs JavaScript/TypeScript
  • Aucun warning critique : Warnings non bloquants acceptables
  • Network requests : Requêtes réseau réussies (200, 201, etc.)
  • WebSocket connections : Connexions WebSocket établies si nécessaire

✅ UX/UI

  • Design cohérent : Design conforme au système de design
  • Feedback utilisateur : Messages de succès/erreur affichés
  • Loading indicators : Indicateurs de chargement visibles
  • Animations : Animations fluides (si applicable)
  • Performance : Temps de réponse < 100ms pour actions utilisateur

Phase 4: Validation des Intégrations

✅ Backend ↔ Frontend

  • Endpoints accessibles : Endpoints backend accessibles depuis frontend
  • Format de données : Format de données cohérent (JSON, types)
  • Authentification : Tokens JWT transmis correctement
  • CORS : CORS configuré si nécessaire
  • Rate limiting : Rate limiting respecté

✅ Services externes

  • WebSocket server : Serveur WebSocket accessible et fonctionnel
  • Database : Base de données accessible et fonctionnelle
  • Redis : Redis accessible si utilisé
  • Email service : Service email fonctionnel si utilisé

Phase 5: Validation des Tests Automatisés

✅ Tests unitaires

  • Tests passent : Tous les tests unitaires passent
  • Coverage ≥ 80% : Couverture de code ≥ 80%
  • Tests pertinents : Tests couvrent les cas critiques

✅ Tests d'intégration

  • Tests API passent : Tests d'intégration API passent
  • Tests E2E passent : Tests end-to-end passent (si applicable)

Phase 6: Documentation

✅ Documentation code

  • Commentaires : Commentaires pour logique complexe
  • JSDoc/GoDoc : Documentation pour fonctions publiques
  • README : README mis à jour si nécessaire

✅ Documentation utilisateur

  • Documentation feature : Feature documentée si nécessaire
  • Changelog : Changelog mis à jour

🔄 PROCESSUS DE VALIDATION

Étape 1: Implémentation

  1. Implémenter la feature (backend + frontend)
  2. Écrire les tests automatisés
  3. Vérifier que le code compile sans erreurs

Étape 2: Validation Technique

  1. Exécuter les tests automatisés
  2. Vérifier la compilation (Go, TypeScript)
  3. Vérifier les linters (golangci-lint, ESLint)
  4. Vérifier la couverture de code

Étape 3: Validation Fonctionnelle

  1. Démarrer tous les services (backend, frontend, database, Redis, etc.)
  2. Ouvrir le navigateur et naviguer vers la feature
  3. Tester le flux complet :
    • Happy path (cas normal)
    • Edge cases (champs vides, valeurs limites)
    • Error cases (erreurs API, timeout)
  4. Vérifier la console : Aucune erreur
  5. Vérifier le réseau : Requêtes réussies
  6. Vérifier l'UX : Feedback utilisateur, loading states

Étape 4: Validation des Intégrations

  1. Vérifier que backend et frontend communiquent correctement
  2. Vérifier que les services externes sont accessibles
  3. Vérifier que les WebSockets fonctionnent (si applicable)

Étape 5: Marquage "Complété"

  1. Toutes les cases de la checklist doivent être cochées
  2. Aucune erreur console
  3. Tous les tests passent
  4. Feature fonctionnelle dans le navigateur
  5. Documentation à jour

📝 TEMPLATE DE VALIDATION

Pour chaque feature, créer un fichier de validation :

# Validation: [Nom de la Feature]

## Informations
- **Tâche**: [ID de la tâche]
- **Date**: [Date]
- **Validateur**: [Nom]

## Checklist

### Phase 1: Backend
- [ ] Routes configurées
- [ ] Handlers implémentés
- [ ] Services implémentés
- [ ] Repositories implémentés
- [ ] Validation des données
- [ ] Gestion d'erreurs
- [ ] Tests unitaires (coverage ≥ 80%)
- [ ] Tests d'intégration

### Phase 2: Frontend
- [ ] Composants créés
- [ ] Props typées
- [ ] État géré
- [ ] Handlers d'événements
- [ ] Validation formulaire
- [ ] Gestion d'erreurs
- [ ] Loading states
- [ ] Accessibilité

### Phase 3: Test Manuel
- [ ] Feature accessible
- [ ] UI visible
- [ ] Interactions fonctionnelles
- [ ] Flux complet testé
- [ ] Edge cases testés
- [ ] Error cases testés
- [ ] Aucune erreur console
- [ ] Network requests réussies

### Phase 4: Intégrations
- [ ] Backend ↔ Frontend
- [ ] Services externes

### Phase 5: Tests Automatisés
- [ ] Tests unitaires passent
- [ ] Tests d'intégration passent
- [ ] Coverage ≥ 80%

### Phase 6: Documentation
- [ ] Commentaires code
- [ ] Documentation fonctions
- [ ] README mis à jour

## Résultat
- [ ] ✅ Feature 100% fonctionnelle
- [ ] ❌ Feature non fonctionnelle (détails ci-dessous)

## Notes
[Notes sur les problèmes rencontrés, solutions, etc.]

🚨 PROCÉDURE EN CAS D'ÉCHEC

Si une validation échoue :

  1. Ne PAS marquer la tâche comme "complétée"
  2. Documenter le problème dans le fichier de validation
  3. Corriger le problème immédiatement
  4. Re-valider en suivant la checklist complète
  5. Marquer comme "complétée" uniquement après validation réussie

📊 MÉTRIQUES DE SUCCÈS

  • Taux de validation réussie : 100% (toutes les features validées doivent être fonctionnelles)
  • Temps de debugging post-validation : 0 (aucun bug découvert après validation)
  • Confiance dans le statut "complété" : 100% (toutes les tâches "complétées" sont fonctionnelles)

🔄 AMÉLIORATION CONTINUE

  • Revue trimestrielle : Analyser les échecs de validation et améliorer la checklist
  • Feedback équipe : Collecter le feedback des développeurs sur le processus
  • Mise à jour : Mettre à jour la checklist selon les leçons apprises