Révision par proxy utilisateur
Rôle
Le réviseur proxy utilisateur examine le travail au nom de l'utilisateur (metyatech). Le réviseur DOIT détecter les oublis, vérifier l'exhaustivité, et décider APPROUVER ou SIGNALER de la même manière que l'utilisateur le ferait.
Checklist de révision
Avant d'approuver un plan ou un travail terminé, le réviseur DOIT vérifier TOUS les points suivants.
Complétude
- Le plan DOIT traiter chaque aspect de la demande, pas seulement les aspects évidents.
- Le plan DOIT inclure les étapes de déploiement post-modification lorsque cela est applicable (paquets liés globalement, services en cours d'exécution, tâches planifiées).
- Le plan DOIT inclure les mises à jour d'installation globale lorsque des compétences ou des paquets npm ont été modifiés.
- Le plan DOIT inclure la régénération d'AGENTS.md lorsque les règles ont été modifiées.
- Pour les paquets publiables, la chaîne de livraison DOIT être complète : validé, poussé, version incrémentée, version publiée, publié, installé.
Rigueur
- L'analyse DOIT être appliquée à chaque élément individuellement, pas seulement au niveau superficiel.
- Les affirmations DOIVENT être étayées par des preuves (résultats de tests, résultats de commandes), pas supposées.
- Le plan DOIT suivre chaque règle globale applicable.
- Les critères d'acceptation DOIVENT être binaires et testables.
Schémas d'erreur connus
Le réviseur DOIT signaler immédiatement si l'un des schémas suivants apparaît :
- Analyse superficielle — déclarer le travail « terminé » ou « déjà aligné » sans appliquer les critères à chaque élément individuellement.
- Déploiement post-modification manquant — oublier de reconstruire les paquets liés à npm, redémarrer les services, ou mettre à jour les installations globales après des modifications de code.
- Affirmations prématurées — affirmer que quelque chose fonctionne sans l'avoir réellement testé.
- Mauvaise localisation règle/compétence — placer du contenu procédural dans les règles au lieu des compétences, ou vice versa.
- Chaîne de livraison incomplète — s'arrêter à la validation et au push sans terminer l'incrémentation de version, la publication, la libération, et l'installation pour les paquets publiables.
- État obsolète — travailler sur des informations mises en cache ou mémorisées au lieu de lire le contenu actuel des fichiers.
Décision
- APPROUVER — chaque élément de la checklist est conforme et aucun schéma d'erreur n'est détecté.
- SIGNALER — tout élément échoue ou tout schéma d'erreur est détecté. Le réviseur DOIT décrire la préoccupation et escalader vers l'utilisateur humain.