Déclencheurs
- phase de durcissement
- quality gate
- production readiness
- integration testing
- load testing
- compliance audit
- performance certification
- reality check
- security validation
- final QA
- cross-device testing
- regression testing
- stress testing
- pre-production
- hardening sprint
- quality assurance final
Instructions
La Phase 4 est l'épreuve finale de qualité. Le Reality Checker par défaut affiche "NEEDS WORK" — vous devez prouver la production readiness avec des preuves accablantes. Les premières implémentations nécessitent généralement 2-3 cycles de révision, et c'est sain. Durée : 3-7 jours.
Pré-conditions
Vérifier avant de commencer :
- Phase 3 Quality Gate passée (toutes les tâches QA'd)
- Phase 3 Handoff Package reçu
- Toutes les fonctionnalités implémentées et vérifiées individuellement
État d'esprit critique
Le verdict par défaut du Reality Checker est NEEDS WORK. La production readiness nécessite :
- Parcours utilisateur complets fonctionnant de bout en bout
- Cohérence cross-device (desktop, tablet, mobile)
- Performance en charge (pas seulement le chemin heureux)
- Validation de sécurité (pas juste « on a ajouté l'auth »)
- Conformité aux spécifications (chaque exigence, pas juste la plupart)
Étape 1 : Collecte de preuves (Jour 1-2, Tous en parallèle)
Utilisez organization_spawn ou swarm_spawn pour activer en parallèle :
Evidence Collector — Preuves visuelles complètes :
- Suite de screenshots complète : Desktop (1920x1080), Tablet (768x1024), Mobile (375x667) pour chaque page/vue
- Preuves d'interaction : flux de navigation, interactions de formulaires, modals, accordéons
- Preuves de thème : mode clair, mode sombre, détection de préférence système
- Preuves d'états d'erreur : pages 404, validation de formulaire, erreurs réseau, états vides
- Timeline : 2 jours.
API Tester — Régression API complète :
- Tous les endpoints testés (GET, POST, PUT, DELETE) avec vérification d'authentification
- Validation des entrées, vérification des réponses d'erreur
- Integration testing (cross-service, base de données, APIs externes)
- Edge cases : rate limiting, gros payloads, requêtes concurrentes, entrée malformée
- Timeline : 2 jours.
Performance Benchmarker — Load Testing :
- Load test à 10x le trafic attendu (P50, P95, P99 temps de réponse, débit, taux d'erreur, utilisation des ressources)
- Core Web Vitals : LCP < 2,5s, FID < 100ms, CLS < 0,1
- Performance base de données : temps de requête, connection pool, efficacité des index
- Stress test : point de rupture, dégradation gracieuse, temps de récupération
- Timeline : 2 jours.
Legal Compliance Checker — Audit de conformité final :
- Conformité vie privée : politique de confidentialité, gestion du consentement, droits des personnes, cookies
- Conformité sécurité : chiffrement, authentification, sanitization des entrées, OWASP Top 10
- Conformité réglementaire : GDPR, CCPA, exigences spécifiques au secteur
- Conformité accessibilité : WCAG 2.1 AA, lecteur d'écran, navigation au clavier
- Timeline : 2 jours.
Étape 2 : Analyse (Jour 3-4, Parallèle, après l'Étape 1)
Test Results Analyzer — Agrégation des métriques de qualité :
- Dashboard de qualité agrégé (score global, répartition par catégorie, distribution de la sévérité des problèmes)
- Priorisation des problèmes : Critique (doit être corrigé), Élevé (devrait être corrigé), Moyen (sprint suivant), Faible (backlog)
- Évaluation des risques : probabilité de production readiness, zones de risque restantes
Workflow Optimizer — Examen de l'efficacité des processus :
- Efficacité de la boucle Dev-QA (taux première pass, nombre moyen de retries)
- Identification des goulots, temps-à-résolution
- Recommandations d'amélioration pour les opérations de Phase 6
Infrastructure Maintainer — Vérification de la production readiness :
- Tous les services sains, auto-scaling testé, load balancer vérifié, SSL/TLS valide
- Monitoring validé, règles d'alerte testées, dashboards accessibles, logs agrégés
- Disaster recovery : backups opérationnels, procédures de récupération testées, failover vérifié
- Sécurité : règles firewall, contrôles d'accès, secrets management, scan de vulnérabilités clean
Étape 3 : Jugement final (Jour 5-7, Séquentiel)
Reality Checker — LE VERDICT FINAL :
Utilisez organization_delegate pour le Reality Checker :
- Reality Check Commands — vérifier ce qui a réellement été construit (ls, grep pour les fonctionnalités revendiquées)
- QA Cross-Validation — cross-référencer tous les résultats QA précédents
- Validation end-to-end — tester les parcours utilisateur COMPLETS (pas juste les fonctionnalités individuelles)
- Specification Reality Check — citer le texte EXACT des spécifications vs. l'implémentation réelle, documenter CHAQUE écart
Options de verdict :
- READY : Preuves accablantes de production readiness (rare première pass) -> Phase 5
- NEEDS WORK : Problèmes spécifiques avec liste de corrections (attendu) -> retour à la boucle Dev-QA de Phase 3
- NOT READY : Problèmes architecturaux majeurs -> retour à Phase 1/2
Attendu : 2-3 cycles de révision sont normaux. Une note B/B+ à la première pass est attendue.
Utilisez knowledge_write pour persister tous les rapports de certification et le verdict du Reality Checker.
Livrables
- [ ] Suite de preuves screenshot complète (desktop, tablet, mobile, toutes les pages)
- [ ] Rapport de régression API (pass/fail par endpoint)
- [ ] Rapport de Performance Certification (load test, Core Web Vitals, stress test)
- [ ] Rapport de Compliance Certification (vie privée, sécurité, réglementaire, accessibilité)
- [ ] Dashboard de qualité (scores agrégés, priorisation des problèmes)
- [ ] Rapport de Infrastructure Readiness (environnement de production validé)
- [ ] Rapport d'intégration Reality Checker avec verdict
Métriques de succès
- Tous les parcours utilisateur critiques fonctionnant de bout en bout
- Cohérence cross-device (desktop + tablet + mobile)
- P95 < 200ms, LCP < 2,5s, uptime > 99,9%
- Zéro vulnérabilités de sécurité critiques
- Tous les exigences réglementaires satisfaits
- Conformité 100% aux spécifications
- Environnement de production validé et prêt
- Reality Checker émet le verdict READY
Vérifier
- Le livrable pour cette phase existe en tant qu'artefact concret (doc, ticket, board, repo) et son emplacement est partagé, non décrit
- Chaque engagement a un propriétaire nommé, une date limite et une definition-of-done qu'une personne autre que l'auteur pourrait vérifier
- Les risques sont listés avec probabilité/impact et une mitigation nommée, pas en tant que balle générique 'risques : TBD'
- Les dépendances envers d'autres équipes/vendeurs/agents sont explicites ; un ack de chaque dépendance est enregistré ou marqué 'pending'
- Les critères de succès pour la phase suivante sont numériques ou objectivement testables
- Un critère de rollback / kill-switch / 'nous nous arrêterons si X' est écrit avant le début du travail