Vérification de l'état de préparation
Invoquez comme $check-readiness diff, $check-readiness pr <URL>, $check-readiness release ou $check-readiness full.
Lecture seule par défaut. Signalez les problèmes et les résolutions concrètes. Modifiez uniquement lorsque l'utilisateur demande explicitement de corriger ou d'appliquer les constatations ; puis vérifiez le comportement affecté.
1. Choisir la cible
| Mode | Cible | Critère d'achèvement |
|---|---|---|
diff | Modifications du dépôt courant en staging, unstaging et modifications non suivies pertinentes, plus les appelants et tests affectés. Par défaut lorsque les modifications sont la cible. | Chaque comportement modifié et chaque limite affectée sont pris en compte. |
pr <URL> | Diff de la PR liée, base, conversation, vérifications et contexte affecté. | Chaque comportement modifié est pris en compte ; les preuves locales ou distantes manquantes sont nommées. |
release | Dépôt courant et cible de déploiement nommée, ou cible trouvée dans la configuration du dépôt. | Chaque flux critique et chaque dépendance de release a un état. |
full | Dépôt courant sur l'ensemble des surfaces backend et frontend applicables. | Chaque route majeure, opération, frontière de confiance, magasin de données et chemin de cycle de vie est inventorié et évalué. |
Utilisez le mode nommé par l'utilisateur. Si aucun n'est nommé, déduisez-le d'une URL de PR, des modifications actuelles ou d'une release mentionnée ; sinon utilisez full. Enregistrez la cible exacte, la révision ou le diff, l'environnement et les chemins de validation disponibles avant de vérifier. Si une URL de PR est inaccessible, signalez ce qui est bloqué ; ne substituez pas un diff local non lié.
Sévérité
Chaque ÉCHEC est bloquant ou avis. Bloquant : sécurité, authn/authz, perte ou corruption de données, flux critique cassé, gestion non vérifiée des paiements ou webhooks, secrets divulgués, build ou tests en échec. Tout le reste est un avis et n'empêche pas à lui seul PRÊT. Chaque compétence de vérification liste ses propres zones bloquantes.
Profondeur par mode
diff et pr : vérifiez uniquement le comportement touché par la modification ; marquez le reste N/A (non touché) sur une seule ligne, pas par vérification. Les vérifications de passerelle de release (Lighthouse, tests de fumée sur l'environnement déployé, aperçus de partage) s'appliquent à release et full uniquement, sauf si la modification les affecte.
2. Rassembler les preuves
Pour diff, inspectez git status --short --branch, les diffs en staging et unstaging, et les fichiers non suivis pertinents. Pour pr, lisez la PR liée, son diff, ses vérifications et sa discussion ; utilisez un checkout local correspondant uniquement pour les tests lorsque sa révision est vérifiée. Pour release et full, cartographiez l'application dans le périmètre avant de tester. Tracez les appelants, les effets sur les données, la configuration, les tests et les dépendances de déploiement pour chaque zone affectée.
Exécutez backend-readiness lorsque du code ou comportement backend est dans le périmètre. Exécutez frontend-readiness lorsque du code ou comportement frontend est dans le périmètre. Transmettez le mode et la cible sélectionnés à chacune ; si les deux s'appliquent, combinez leurs constatations. Pour une revue de modifications, appliquez les vérifications au comportement affecté. Pour une release, appliquez les vérifications sur les flux critiques et l'environnement cible. Pour full, évaluez toutes les vérifications applicables dans le dépôt. Marquez chaque vérification applicable RÉUSSI, ÉCHEC, BLOQUÉ ou N/A ; attachez la preuve actuelle pour chaque RÉUSSI et une raison pour chaque N/A.
Utilisez le code source, les tests automatisés, l'exécution locale, le bac à sable du fournisseur et l'environnement déployé comme couches de preuves distinctes. Un build prouve un build. Enregistrez les informations d'identification, l'infrastructure ou les environnements indisponibles comme BLOQUÉ, avec la preuve exacte encore nécessaire. Exécutez des vérifications ciblées pouvant valider la cible ; ne revendiquez pas de comportement d'exécution ou de release à partir du seul code source.
Terminez lorsque les vérifications applicables ont des états, les échecs ont une cause et une résolution, et chaque affirmation de préparation correspond à sa couche de preuve.
3. Rapporter et agir
Rapportez le mode et la cible, puis les constatations classées par sécurité, perte de données, exactitude et impact utilisateur. Chaque constatation nomme l'emplacement ou le flux, la preuve, la conséquence et la plus petite résolution concrète. Incluez les vérifications effectuées avec les résultats exacts, ainsi que les éléments bloqués ou non vérifiés. Terminez par PRÊT, PAS PRÊT ou NON VÉRIFIÉ pour la cible choisie : PRÊT nécessite qu'aucun échec bloquant connu ne soit présent et que des preuves existent pour sa passerelle applicable ; NON VÉRIFIÉ signifie que des preuves manquantes empêchent cette affirmation.
Utilisez ce modèle :
Mode / cible : <mode, révision ou diff, environnement>
Constatations
| Sévérité | Emplacement ou flux | Preuve | Conséquence | Résolution |
Vérifications effectuées
| Commande ou test | Résultat |
Bloqué / non vérifié
- <élément> : <preuve encore nécessaire>
Verdict : PRÊT | PAS PRÊT | NON VÉRIFIÉ
Gardez les passages en revue en lecture seule. Si l'utilisateur demande de corriger des constatations, appliquez les correctifs demandés dans le code affecté, exécutez une vérification ciblée et rapportez les risques restants. N'inférez pas d'autorisation d'édition à partir d'une demande de vérification de préparation.
Terminez lorsque le rapport distingue le comportement vérifié des lacunes, ou que les correctifs demandés ont été appliqués et vérifiés.