zehuichan/vibe-harness

Revue d'un changement

Cette compétence est un guide, pas une checklist complète. Vérifiez et récupérez la base en direct et la tête exacte du changement, puis listez les chemins modifiés avec la commande change-scope du profil avant de lire le diff et suffisamment de code environnant pour comprendre la conception. Rétablissez la base après un reciblage ou une fusion. Priorisez l'exactitude, le cycle de vie, la sécurité et le comportement requis rompu sur le style ; une courte revue avec un seul blocage substantié est meilleure qu'une liste de nits.

Lisez les exigences avant de juger le diff. Mappez les chemins modifiés aux sources ci-dessous, ouvrez chaque page propriétaire, et lisez ensuite le diff par rapport à ces exigences. Juger un diff à partir de la mémoire des règles est ainsi qu'une violation passe la revue.

Sources de vérité

• AGENTS.md à la racine et dans chaque sous-arbre touché : ordres permanents.
• .agents/project-profile.md : commandes, surfaces activées, preuve par surface, et règles spécifiques au projet.
• docs/defensive-patterns/ : règles appliquées en revue, une page par famille d'artefact ; lisez chaque page que le diff touche.
• docs/AGENTS.md et standard-docs : placement et discipline de la documentation.
• standard-prose : couverture requise et jugement éditorial pour les commentaires, docs, prompts et chaînes visibles.
• gestion-erreurs : classification des échecs, propriété, confinement, garanties et rapports.
• revue-cycle-de-vie : état singleton, effets non annulés et ordre de nettoyage dans les plugins, services et composants.
• fiabilité-tests : isolation et preuve de régression pour les tests propriétaires de ressources, asynchrones ou instables.
• .agents/notes/ : justification de conception. Traitez un désaccord avec une Note d'Agent comme une discussion de conception, pas un veto automatique.
• Lorsque le profil active surfaces.ui, les compétences revue-ui-ux et ui-responsive.

Exigences bloquantes

1. Toute nouvelle prose reçoit une revue sémantique. Utilisez le standard prose sur chaque passage Markdown ajouté ou modifié, doc API, commentaire, prompt, description, diagnostic et chaîne visible. Les vérifications automatisées n'établissent ni l'exactitude, ni le placement, ni la couverture.
2. La documentation correspond au code. La configuration, les valeurs par défaut, les erreurs, les champs wire, les événements et le comportement public mettent à jour le README propriétaire et les docs API dans le même diff. Signalez la narration d'implémentation, les présentations de test, l'historique de revue et les justifications dupliquées.
3. Propriété et nettoyage. Pour le code de plugin, service ou composant avec un cycle de vie, appliquez la revue de cycle de vie au comportement modifié et aux consommateurs affectés. Chaque nouvel enregistrement prouve son élimination.
4. Preuve requise existe. Vérifiez que l'auteur a exécuté les vérifications pertinentes pour le diff (voir vérifications-pré-push) et que CI couvre le reste ; révisez les lacunes sémantiques qu'aucun des deux ne peut détecter.
5. Copie d'interface utilisateur localisée. Lorsque le profil active surfaces.localized-ui, rejetez le texte produit imbriqué dans le balisage, les templates, les retours de helper, les attributs d'accessibilité ou les valeurs par défaut des composants ; exigez le mécanisme de locale et la preuve dans chaque locale affectée. Les données utilisateur, modèle et wire restent textuelles.
6. Les changements cassants sont enregistrés. Lorsque le profil active surfaces.public-api, une rupture perceptible de l'extérieur comporte un guide de mise à niveau dans le même diff (voir guide-mise-niveau).

Vérifications manuelles

• Contrats d'intention et d'interface : tracez les deux côtés de chaque interface modifiée. Confirmez que l'implémentation correspond à la description et à toute Note d'Agent, y compris les erreurs, l'annulation, la propriété et l'élimination.
• Gestion des erreurs : rejetez le catch-and-continue sauf si le propriétaire de l'état établit que les préconditions du travail ultérieur sont remplies.
• Cycle de vie et concurrence : pour la configuration asynchrone, les callbacks, les processus ou le démontage, vérifiez les courses avant publication, l'annulation pendant les attentes, le rapport d'erreur indépendant, le confinement des callbacks, la propriété avant la réentrée, le nettoyage complet du détachement et l'élimination en état de quiescence.
• Adéquation consommateur et capacité : tracez chaque consommateur actuel, puis signalez un comportement spécifique au consommateur qui fuit dans une interface partagée. Signalez l'inverse aussi : une nouvelle méthode publique sur un service générique dont le seul appelant est un consommateur interne ; préférez une capacité privée remise à ce consommateur à la construction.
• Portée, propriété et nécessité : mappez chaque abstraction, machine d'état, option, copie défensive et chemin de compatibilité à son contrat actuel, son consommateur de production et son module propriétaire. Contestez les fonctionnalités non liées et la généralité spéculative.
• Configuration et choix publics : demandez quelle preuve du consommateur actuel ou quel art antérieur soutient chaque valeur par défaut, ensemble d'opérations publiques, format ou concept externe importé. Exigez un choix explicite ou un report lorsque cette preuve est absente.
• Perspective du modèle : lorsque le projet envoie des prompts, des schémas d'outils ou des résultats à un modèle, inspectez le texte exact que le modèle reçoit. Signalez les concepts en dehors de la tâche du modèle, et vérifiez le texte stable textuellement et le comportement dynamique via des tests ou des instantanés.
• Application : suivez chaque chemin de refus jusqu'à l'opération qui l'exécute ; exercez les appelants directs et alternatifs qui peuvent contourner les schémas, prompts, façades, wrappers ou l'ordre d'écoute.
• État emprunté et dérivé : déterminez si chaque valeur conservée est empruntée ou possédée, puis tracez les notifications et chaque cache, prompt, écho UI, rejeu et vue de requête jusqu'au point de succès documenté et à la source faisant autorité.
• Les limites couvrent l'opération finale : localisez le propriétaire du résultat complet émis ou conservé, y compris les wrappers et métadonnées. Sondez les limites petites et exactes, les gros morceaux uniques surdimensionnés et le texte multioctet pour les limites d'octets.
• Chemin d'entrée réel : les tests exercent le chargeur, binaire, worker ou sous-processus livré le cas échéant. Une configuration de test assemblée à la main ne détecte pas les exportations invalides.
• Robustesse des tests : les assertions échouent sur la régression prévue et vérifient l'état externe, les logs, les événements ou l'élimination plutôt que de reformuler l'implémentation. La couverture est nécessaire mais pas une preuve que le scénario est correct.
• Contrôles négatifs : vérifiez qu'un cas délibérément invalide échoue via le véritable exécuteur pour chaque règle d'acceptation modifiée.
• Les Notes d'Agent implémentées correspondent à la réalité livrée : lorsqu'un changement implémente une note proposée, déplacez-la et reformulez-la en état livré au présent dans le même diff.
• Traductions : comparez le sens et la terminologie des deux côtés ; une structure correspondante ne prouve pas la qualité de la traduction.

Rapport des résultats

Indiquez le défaut, l'emplacement, l'impact et la preuve. Placez un défaut localisé en ligne sur la plage de diff la plus pertinente ; utilisez un commentaire de premier niveau pour l'architecture transversale, la portée ou la synthèse. Séparez les blocages des suggestions, et omettez les problèmes déjà appliqués par une vérification réussie. Lorsque vous recevez une revue, vérifiez chaque affirmation et corrigez-la ou réfutez-la sur des bases techniques.