diodesign/diosix-agent-skills

Revue de Diosix

Chaque modification de code et de documentation dans Diosix doit passer un audit rigoureux et multi-perspective avant le commit ou la fusion. N'approuvez jamais les changements à la légère et ne signez jamais un code cassé, incomplet ou non vérifié. Les critères de revue ci-dessous reflètent 1:1 developing-diosix et documenting-diosix, de sorte que l'application des compétences d'écriture élimine les reprises avant le commit et avant la fusion.

Flux de travail de vérification obligatoire en 4 étapes

1. Porte de compilation, complétude et test (enjeux de base) :
   • Vérifiez que la fonctionnalité est 100 % implémentée comme conçue, sans stubs TODO, code mort ou chemins de production simulés.
   • Lors du refactoring de fichiers dépassant la limite de 500 lignes, ne tronquez jamais la fonctionnalité ou les tests unitaires ; toujours composantiser les fichiers surdimensionnés en sous-dossiers cohérents (vm/run.zig, panes/modal.zig, tests/gui.zig) plutôt que des fichiers plats prefix_subname.zig, et vérifiez que chaque sous-module est référencé dans le bloc test de son parent (_ = @import("vm/run.zig");) afin que zig build test exécute ses tests unitaires.
   • Vérifiez que les tests unitaires sont co-localisés dans les fichiers source .zig qu'ils testent et que les tests d'intégration résident dans des répertoires tests/ séparés.
   • Limitez les vérifications de format de fichier et de ligne/colonne aux répertoires sources suivis (build.zig, hypervisor, tools, scripts) plutôt que d'exécuter des globs récursifs sans portée sur .zig-cache/ ou zig-out/.
   • Exécutez ./scripts/build.sh test --summary all et ./scripts/build.sh jusqu'à ce que 100 % des étapes de compilation et de test réussissent sans aucun avertissement ni fuite.
2. Revue approfondie selon 4 personnages :
   • Auditez chaque fichier modifié et son contexte environnant à travers quatre lentilles distinctes :
     1. Ingénieur vétéran sceptique (complétude, idiomes, hiérarchie de sous-dossiers au lieu de fichiers plats prefix_subname.zig, littéraux hexadécimaux en minuscules 0xfff, constantes/utilitaires nommés comme PAGE_OFFSET_MASK et crossesPageBoundary au lieu de masques binaires magiques, zéro duplication par copier-coller des validateurs Spinlock/alignement/chemin, pas de tableaux de secours historiques de listes de candidats comme DEFAULT_GUEST_CANDIDATES pour les chemins internes co-versionnés, types ABI explicites à largeur fixe u64 au lieu de usize, annotations de type usize explicites sur @min/@max avec littéraux, composition de fichiers >500 lignes sans troncature, limite <=80 colonnes, tampons dynamiques vs. statiques, externalisation de la politique vers la configuration de construction/exécution, pas de synthèse binaire/ELF/image à la volée en Zig, pas de fichiers générés dans tools/overlay-common/)
     2. Expert en sécurité paranoïaque (isolation du rayon d'explosion de l'hyperviseur, prévention des double-lecture/TOCTOU en une seule copie sur la mémoire de l'invité, verrouillage sécurisé IRQ via atomic.Spinlock, remise à zéro crypto/page, limites arithmétiques vérifiées)
     3. Mainteneur Diosix (modularité, lisibilité, defer/errdefer, assertions de taille/décalage comptime ABI, compatibilité ascendante des contrats externes vs. migration atomique dans l'arbre, couverture des tests des sous-modules)
     4. Utilisateur débutant et expert (UX sans effort, erreurs claires en anglais, flexibilité de configuration, performances)
3. Audit de type 'borrow-checker' et de durée de vie des pointeurs :
   • Tracez manuellement chaque pointeur, tranche et allocation à travers tous les chemins de flux de contrôle pour garantir zéro utilisation après libération (UAF), double libération, invalidation de pointeur lors d'un redimensionnement/remappage, ou références de pile dangling.
4. Porte de documentation, d'orthographe et de style :
   • Vérifiez que docs/ correspond à toutes les modifications de code (y compris les FID SBI, les types de struct C, les indicateurs CLI et les chemins de fichiers modularisés), est rédigée en anglais américain clair et grammaticalement correct avec une orthographe vérifiée, et est conforme à docs/style-guide.md et docs/development.md.
   • Réexécutez zig fmt --check build.zig hypervisor tools scripts et ./scripts/build.sh test --summary all après toute correction de revue.
5. En cas de doute, arrêtez-vous et demandez au mainteneur principal : Si une revue révèle un compromis architectural ou une primitive manquante, arrêtez-vous et demandez au mainteneur principal la direction à suivre avant de faire des suppositions.

Guides de référence ciblés

Consultez ces listes de contrôle de référence lors de chaque revue :

• La liste de contrôle des 4 personnages de revue : Critères d'inspection détaillés pour l'ingénieur vétéran sceptique, l'expert en sécurité paranoïaque, le mainteneur Diosix et l'utilisateur débutant/expert.
• Audit de 'borrow-checker' : Méthodologie étape par étape pour tracer la provenance des pointeurs, les durées de vie, la mutabilité d'aliasing et la sécurité mémoire inter-privilèges en Zig.
• Portes avant commit : Commandes de vérification concrètes et critères d'approbation requis avant de committer ou de fusionner vers devel ou stable.