Super Review Council / 超级审查会

Que fait 超级审查会 ?

Lancer un pipeline lourd structuré de revue et correction multi-agent lorsque l'utilisateur demande explicitement ce workflow super-review-council. Il s'agit principalement de revue de code, mais des cibles explicites de bundles non-code gelés sont supportées ; ce n'est pas le routage d'approbation auto_review de Guardian ni la commande codex review intégrée.

Pour les exécutions explicites de haut niveau, la forme par défaut est un workflow à quatre agents pour chaque phase substantielle. Quatre agents inspectent le même bundle de changements gelés, quatre agents aident à trier les résultats, quatre agents participent à la planification/implémentation des correctifs où la propriété d'écriture peut être séparée, et quatre agents vérifient le résultat avant que la boucle ne se répète. L'agent principal coordonne, assigne les responsabilités, intègre les résultats et prend la décision finale sur les correctifs acceptés.

Utiliser lorsque :

• l'utilisateur dit explicitement super-review-council
• l'utilisateur dit explicitement Super Review Council
• l'utilisateur dit explicitement 超级审查会
• l'utilisateur demande explicitement ce workflow lourd de conseil de revue multi-agent
• un workflow coordinateur de haut niveau chargé invoque explicitement super-review-council comme un passage enfant en lecture seule et limité

Ne pas déclencher cette compétence pour une simple "revue", codex review intégré, auto_review de Guardian, l'auto-revue normale après édition, les réponses finales, les commits, la livraison, les vérifications CI, les anciennes mentions de nom de compétence, ou la maintenance ordinaire de ce fichier de compétence à moins que l'utilisateur n'ait demandé ce workflow super-review-council pour ce travail.

Lorsqu'elle est déclenchée, indiquer d'abord que la compétence super-review-council est active et identifier la cible de la revue avant de commencer le travail des réviseurs.

Attribution

Cette compétence est dérivée de la compétence skills/autoreview sous licence MIT de openclaw/agent-skills. Le nom hérité autoreview n'apparaît ici que pour l'attribution MIT, la compatibilité des chemins/sorties/environnement des aides, et les contextes d'interdiction de workflow imbriqué.

Workflow à quatre agents

Lorsque l'utilisateur dit super-review-council ou 超级审查会, utiliser quatre agents en parallèle pour chaque phase lorsque l'environnement supporte les sous-agents. Privilégier les agents de type explorer pour les phases en lecture seule et les agents de type worker pour les phases d'implémentation. Les agents de revue en lecture seule, de triage et de planification de correctifs ont par défaut un contexte minimal limité à la phase : identité de la cible gelée, rôle, outils autorisés, interdictions, et résultats/preuves pertinents uniquement. Les agents de vérification ont également par défaut un contexte minimal limité à la phase, plus toutes les commandes de vérification, chemins de sortie, limites d'écriture et exigences d'audit de dérive explicitement approuvées pour cette phase. Les anciennes approbations et instructions d'exécution peuvent être transmises uniquement comme preuves/provenance, doivent être explicitement étiquetées contexte historique uniquement et sans autorité, et ne peuvent pas accorder de permissions, approuver une exécution dégradée ou risquée, autoriser l'écriture, les tests, les correctifs, les workflows imbriqués, ou remplacer le contrat de phase en cours, les outils autorisés ou les interdictions. Les agents worker peuvent recevoir un contexte plus riche uniquement lorsque le correctif accepté l'exige, et ce contexte plus riche est soumis aux mêmes limites de preuve/provenance uniquement.

Phase 0 : pré-vol de la cible. Avant de geler le bundle ou de lancer des agents, identifier la cible de la revue :

• si l'utilisateur ou un workflow coordinateur fournit un fichier, un répertoire ou un bundle de revue gelé explicite, cette cible explicite prime sur la détection git du répertoire de travail courant ; canoniser la cible et utiliser l'identité de manifeste/hachage de contenu même lorsque le shell actuel se trouve dans un dépôt git
• si dans un dépôt git, enregistrer la racine du dépôt, la branche courante, l'état modifié/stagé/non-suivi, la base amont/base PR lorsqu'elle est disponible, et si la cible doit être en mode local, branche ou commit
• si pas dans un dépôt git, procéder uniquement lorsque l'utilisateur a fourni un fichier, répertoire ou bundle révisable explicite ; canoniser les chemins absolus, rejeter les cibles manquantes, énumérer les contenus du répertoire de manière déterministe, et s'arrêter pour demander un dépôt ou une cible explicite lorsqu'aucun n'a été fourni
• enregistrer l'identité immuable de la cible avant la Phase 1 : SHA de commit pour le mode commit ; références base/tête plus un hachage de diff pour le mode branche ; hachage de manifeste de diff local/non-suivi pour le mode local ; ou un hachage de manifeste de contenu pour les fichiers, répertoires et bundles non-git
• geler le bundle/source sélectionné avant la Phase 1 et signaler l'identité/hachage de la cible dans la première mise à jour destinée à l'utilisateur
• avant le triage, la planification des correctifs et l'implémentation, recalculer l'identité/hachage de la cible sélectionnée et la comparer à la ligne de base actuelle de la boucle de revue gelée ; initialement cette ligne de base est la valeur de la Phase 0 ; ce recalcul est uniquement un contrôle d'égalité et n'autorise pas le remplacement de la ligne de base, la régénération des manifestes, le regel ou le redémarrage
• après l'application des correctifs acceptés de la Phase 4, auditer l'identité de l'espace de travail/cible résultante par rapport à la ligne de base de la Phase 4, aux périmètres d'écriture acceptés, aux sorties approuvées et aux chemins interdits avant d'enregistrer l'identité/hachage de la cible résultante comme ligne de base de vérification de la Phase 5 et identité de départ pour la prochaine boucle de revue ; toute dérive inattendue, hors périmètre ou interdite doit être mise en quarantaine et divulguée, et bloque l'adoption de la ligne de base sauf approbation explicite
• si une comparaison d'identité de cible diffère en raison d'un changement externe non approuvé, arrêter cette phase, divulguer l'identité/hachage attendu et observé ainsi que les chemins modifiés lorsqu'ils sont connus, et exiger une approbation explicite de l'utilisateur ou du coordinateur avant de regeler, redémarrer ou adopter une nouvelle ligne de base ; en mode enfant en lecture seule, retourner ceci comme un bloqueur au coordinateur

Registre de sous-agents natifs : la gestion côté coordinateur est le contrôle principal, pas le verrouillage par système de fichiers. Avant que chaque sous-agent natif ne démarre, le coordinateur enregistre la phase et le rôle, les outils déclarés, les actions autorisées et interdites explicites, les chemins de lecture/écriture autorisés, les chemins interdits, le profil de sandbox et de permission lorsqu'il est disponible, l'identité/hachage de la cible de base, et le statut/les manifestes du dépôt/espace de travail, ou une ligne de base de mutation de l'espace de travail entier équivalente suffisante pour découvrir les écritures en dehors de la cible. Après le retour du sous-agent, comparer l'identité de la cible, les manifestes des chemins autorisés/interdits, le statut du dépôt/espace de travail, et les métadonnées d'outil/sandbox/permission par rapport à cet instantané. Mettre en quarantaine, ne pas utiliser et divulguer toute discordance de cible, écriture inattendue à l'intérieur ou à l'extérieur de la cible, dérive de chemin autorisé, touche de chemin interdit, dérive d'outil, expansion de permission ou de sandbox, mutation inexpliquée, dérive non autorisée ou écritures inattendues avant de continuer. Les modes lecture seule du système de fichiers, les répertoires immuables et les restrictions de sandbox sont des garde-fous ou preuves supplémentaires utiles lorsqu'ils sont disponibles, mais ils ne remplacent jamais le contrat de l'invite du coordinateur, le registre, l'audit d'instantané/dérive, la décision de quarantaine, la revue d'intégration et la décision finale.

Gestion des échecs de phase : si un agent, moteur d'aide ou worker requis génère une erreur, dépasse le temps imparti, enfreint le contrat de phase, retourne des champs obligatoires manquants ou produit une sortie inutilisable, cette phase est incomplète. Mettre en quarantaine ou ignorer la sortie suspecte, divulguer l'échec, et réessayer ou remplacer le participant uniquement dans les limites du même contrat de phase et des contraintes de moteur/modèle, ou s'arrêter pour une approbation explicite de mode dégradé ou un bloqueur. Ne jamais compter une sortie absente, obsolète ou inutilisable comme une couverture propre de quatre agents.

Phase 1 : revue par quatre agents. Donner à chaque réviseur le même diff/bundle gelé et un axe principal :

• correction et régressions
• sécurité et périmètres de confiance
• tests, cas limites et modes de défaillance
• maintenabilité, contrats d'intégration et comportement visible par l'utilisateur

Contraintes de revue :

• chaque moteur de réviseur doit être contraint par le coordinateur en tant que réviseur en lecture seule : le brief de lancement doit nommer les outils/actions en lecture seule autorisés, interdire les écritures et les commandes mutantes, interdire la création de revue/orchestration/agent imbriquée, et lier le réviseur à la cible gelée ; utiliser le sandbox, la politique d'outils, les indicateurs d'aide, les contrôles de lecture seule du système de fichiers ou les bundles immuables uniquement comme preuve supplémentaire facultative lorsqu'ils sont disponibles, mais ne jamais les exiger ; ne pas utiliser un moteur comme réviseur lorsque le coordinateur ne peut raisonnablement pas interdire, observer et auditer les écritures ou la dérive d'outils
• les réviseurs ne doivent pas modifier les fichiers, exécuter des formateurs, installer des paquets, muter l'état git, pousser, committer ou exécuter des commandes qui écrivent des fichiers
• les réviseurs peuvent inspecter les fichiers, types, docs, contrats de dépendance et docs publics actuels lorsque nécessaire
• pour les revues de diff, branche, commit ou patch, les réviseurs ne doivent signaler que les défauts actionnables introduits ou exposés par le changement examiné
• lorsque la cible gelée est un fichier entier, un bundle non-code, un plan, une spécification, des docs ou un bundle d'artefacts, les réviseurs signalent les défauts actionnables présents dans cet artefact par rapport à son objectif et ses contraintes déclarés, plutôt que des problèmes de code uniquement ou de provenance de diff
• les réviseurs ne doivent pas proposer de réécritures vastes, de préférences stylistiques ou de nettoyage non lié

Phase 2 : triage par quatre agents. D'abord passer la garde de cible obsolète de la Phase 0, puis demander à quatre agents de classifier indépendamment les résultats fusionnés comme acceptés, rejetés, doublons ou nécessitant plus de preuves. Les agents de triage doivent être contraints par le coordinateur avec le même contrat sans écriture, sans commande mutante, sans mutation git, sans installation, sans formateur, sans tests écrivant une sortie, sans création de revue/orchestration/agent imbriquée utilisé pour les phases de revue en lecture seule ; ils doivent inspecter uniquement la cible gelée, les résultats fusionnés, les preuves fournies et le contexte adjacent explicitement dans le périmètre. L'agent principal dédoublonne, rejette les résultats spéculatifs ou de faible valeur, résout les désaccords en lisant le chemin de code ou l'artefact examiné plus le contexte adjacent dans le périmètre, et enregistre l'ensemble de correctifs accepté.

Phase 3 : planification des correctifs par quatre agents. D'abord passer la garde de cible obsolète de la Phase 0, puis demander à quatre agents de planification en lecture seule de proposer des plans de correctifs minimaux et des limites de propriété. Les agents de planification des correctifs doivent être contraints par le coordinateur avec le même contrat sans écriture, sans commande mutante, sans mutation git, sans installation, sans formateur, sans création de revue/orchestration/agent imbriquée utilisé pour les phases de revue en lecture seule ; ils ne doivent pas modifier les fichiers, écrire des artefacts, appliquer des patches, exécuter des tests écrivant une sortie, ne doivent pas invoquer super-review-council, ne doivent pas invoquer autoreview hérité, ne doivent pas invoquer goal-orchestrator, ne doivent pas invoquer codex review intégré, ouvrir des panneaux de revue ou créer des agents supplémentaires. Ils peuvent inspecter la cible gelée et les résultats acceptés uniquement pour proposer des plans. Pour les cibles non-code, les plans doivent nommer les sections exactes d'artefact ou les modifications au niveau des lignes plutôt que des limites de propriété de code. Privilégier les petits correctifs à la bonne limite de propriété. Ne pas planifier de refontes importantes à moins qu'elles ne corrigent clairement la classe de bugs.

Phase 4 : implémentation par quatre agents. D'abord passer la garde de cible obsolète de la Phase 0, puis utiliser quatre agents worker uniquement lorsque les correctifs acceptés peuvent être divisés en périmètres d'écriture disjoints. Assigner une propriété explicite des fichiers/modules à chaque worker. Dire à chaque worker qu'il n'est pas seul dans la base de code, qu'il ne doit pas annuler les modifications apportées par les autres, et qu'il doit s'adapter aux changements parallèles. Les workers peuvent modifier uniquement les fichiers/modules locaux assignés au dépôt, doivent éviter les écritures qui se chevauchent, ne doivent pas formater des fichiers non liés, ne doivent pas installer de paquets ou dépendances, et ne doivent pas pousser, committer, réinitialiser, extraire/commuter/restaurer, annuler, nettoyer, stasher, rebaser, fusionner, supprimer des branches/tags, supprimer des fichiers non suivis, ou exécuter des commandes destructrices larges du système de fichiers comme rm -rf ou find -delete. Les workers ne doivent pas invoquer super-review-council, autoreview hérité, goal-orchestrator, codex review intégré, des panneaux de revue, des panneaux de planification ou des agents supplémentaires. Les workers doivent signaler les conflits plutôt que de les résoudre en annulant les modifications de l'utilisateur ou des pairs. L'agent principal examine les patches des workers avant de les accepter. S'il y a moins de quatre périmètres d'écriture indépendants, utiliser les agents restants pour la vérification en lecture seule, la planification de tests ou la revue d'implémentation plutôt que de forcer des modifications qui se chevauchent.

Phase 5 : vérification par quatre agents. D'abord passer la garde de cible obsolète par rapport à la ligne de base de vérification actuelle, puis exécuter quatre agents de vérification en parallèle lorsque possible :

• tests ciblés et sortie de commande
• audit de diff pour les modifications involontaires
• revérification de régression/sécurité des résultats acceptés
• artefacts générés, docs, instantanés ou cohérence de la sortie visible par l'utilisateur

Les agents de vérification doivent être lancés avec un rôle explicite, une identité/hachage de base, des commandes et outils autorisés, des chemins de lecture/écriture/sortie autorisés, des chemins et actions interdits, des délais d'attente finis, et une interdiction des installations, formateurs, mutation git, commandes destructrices du système de fichiers, revue/orchestration imbriquée et agents supplémentaires. Les tests ou commandes de vérification peuvent écrire uniquement sur des chemins approuvés par le coordinateur en dehors des racines de cible protégées, à moins que le correctif accepté ne possède explicitement ces sorties. La vérification qui peut modifier la cible examinée doit être sérialisée, ou tout résultat de vérificateur parallèle collecté par rapport à l'ancienne ligne de base doit être invalidé et réexécuté par rapport à la ligne de base post-écriture auditée. Après chaque vérificateur ou commande de test, le coordinateur compare l'identité/hachage de la cible, les manifestes des chemins autorisés et interdits, le statut du dépôt/espace de travail et les artefacts de commande par rapport à la ligne de base de la Phase 5. Toute dérive inattendue, écriture interdite ou sortie non déclarée doit être mise en quarantaine et divulguée avant de continuer. Si des écritures de vérification approuvées modifient légitimement la cible examinée, enregistrer l'identité/hachage de la cible post-vérification auditée comme identité de départ pour la prochaine boucle de revue avant que la Phase 6 ne relance la revue. Le mode enfant en lecture seule n'exécute pas les commandes de la Phase 5.

Phase 6 : répétition. Après que tout correctif accepté a modifié la cible examinée, y compris le code, les docs, le texte de compétence, la sortie générée ou tout autre contenu de bundle, relancer la phase de revue par quatre agents par rapport au diff ou à l'artefact mis à jour. Continuer jusqu'à ce que le processus de revue/triage par quatre agents ne laisse aucun résultat accepté/actionnable et que les tests requis ou les preuves spécifiques à l'artefact réussissent. Ne pas boucler indéfiniment : par défaut, s'arrêter après trois cycles complets de revue/correction à moins que l'utilisateur ne demande explicitement de continuer, et s'arrêter immédiatement si un cycle ne produit aucun changement ou n'accepte aucun résultat par rapport au cycle précédent. Chaque cycle doit démarrer à partir de la ligne de base de vérification auditée du cycle précédent.