diodesign/diosix-agent-skills

Diosix prüfen

Jede Code- und Dokumentationsänderung in Diosix muss vor dem Commit oder Merge eine strenge, mehrperspektivische Prüfung durchlaufen. Änderungen niemals blind absegnen und niemals fehlerhaften, unvollständigen oder unverifizierten Code freigeben. Die nachfolgenden Prüfkriterien spiegeln developing-diosix und documenting-diosix 1:1 wider, sodass die Anwendung der Autorenfähigkeiten Nacharbeiten vor Commit und Merge vermeidet.

Verbindlicher 4-Schritte-Verifikationsworkflow

1. Build-, Vollständigkeits- und Testgate (Grundvoraussetzung):
   • Stellen Sie sicher, dass die Funktion zu 100 % wie entworfen implementiert ist, ohne TODO-Platzhalter, toten Code oder simulierte Produktionspfade.
   • Überschreiten refaktorierte Dateien die 500-Zeilen-Grenze, niemals Funktionalität oder Komponententests abschneiden; zu große Dateien stattdessen in zusammenhängende Unterverzeichnisse aufteilen (vm/run.zig, panes/modal.zig, tests/gui.zig), anstatt flache prefix_subname.zig-Dateien zu verwenden, und sicherstellen, dass jedes Untermodul im test-Block des übergeordneten Moduls referenziert wird (_ = @import("vm/run.zig");), damit zig build test seine Komponententests ausführt.
   • Stellen Sie sicher, dass Komponententests gemeinsam mit den zu testenden .zig-Quelldateien in denselben Dateien platziert sind und Integrationstests in separaten tests/-Verzeichnissen liegen.
   • Begrenzen Sie Dateiformat- und Zeilen-/Spaltenprüfungen auf die nachverfolgten Quellverzeichnisse (build.zig, hypervisor, tools, scripts), anstatt unbegrenzte rekursive Glob-Abfragen über .zig-cache/ oder zig-out/ auszuführen.
   • Führen Sie ./scripts/build.sh test --summary all und ./scripts/build.sh aus, bis 100 % der Kompilierungs- und Tests chritte ohne Warnungen oder Speicherlecks bestanden sind.
2. 4-Persona-Tiefenprüfung:
   • Prüfen Sie jede geänderte Datei und ihren umgebenden Kontext durch vier unterschiedliche Linsen:
     1. Skeptischer erfahrener Ingenieur (Vollständigkeit, Idiome, Unterverzeichnishierarchie statt flacher prefix_subname.zig-Dateien, hexadezimale Literale in Kleinbuchstaben 0xfff, benannte Konstanten/Hilfsfunktionen wie PAGE_OFFSET_MASK und crossesPageBoundary anstelle magischer Bitmasken, keine Kopier-Paste-Duplizierung von Spinlock/Ausrichtungs-/Pfadvalidierern, keine historischen Kandidatenlisten-Fallback-Arrays wie DEFAULT_GUEST_CANDIDATES für ko-versionierte interne Pfade, explizite u64-ABI-Typen mit fester Breite anstelle von usize, explizite usize-Typannotationen bei @min/@max mit Literalen, Aufteilung von Dateien >500 Zeilen ohne Abschneiden, <=80-Zeichen-Grenze, dynamische vs. statische Puffer, Externalisierung von Richtlinien in Build-/Laufzeitkonfiguration, keine On-the-Fly-Binär-/ELF-/Bildsynthese in Zig, keine generierten Dateien innerhalb von tools/overlay-common/)
     2. Paranoider Sicherheitsexperte (Hypervisor-Blast-Radius-Isolation, Einzelkopie-Doppelabruf/TOCTOU-Verhinderung bei Gastspeicher, IRQ-sichere Sperren über atomic.Spinlock, Krypto-/Seitennullstellung, geprüfte arithmetische Grenzen)
     3. Diosix-Maintainer (Modularität, Lesbarkeit, defer/errdefer, ABI comptime-Größen-/Offset-Assertions, Abwärtskompatibilität externer Verträge vs. atomare In-Tree-Migration, Testabdeckung von Untermodulen)
     4. Anfänger & erfahrener Benutzer (Nullaufwand-Benutzererfahrung, klare englische Fehler, Konfigurationsflexibilität, Leistung)
3. Rust-artiger Borrow-Checker- und Pointer-Lebensdauer-Audit:
   • Verfolgen Sie manuell jeden Zeiger, jedes Slice und jede Allokation über alle Kontrollflusspfade hinweg, um Null Use-After-Free (UAF), Double-Free, Pointer-Invalidierung bei Größenänderung/Neuzuordnung oder baumelnde Stack-Referenzen zu garantieren.
4. Dokumentations-, Rechtschreib- und Style-Gate:
   • Stellen Sie sicher, dass docs/ mit allen Codeänderungen übereinstimmt (einschließlich SBI-FIDs, C-Struct-Typen, CLI-Flags und modularisierten Dateipfaden), in klarem, grammatikalisch korrektem amerikanischem Englisch mit überprüfter Rechtschreibung verfasst ist und docs/style-guide.md und docs/development.md einhält.
   • Führen Sie nach allen Überprüfungs korrekturen zig fmt --check build.zig hypervisor tools scripts und ./scripts/build.sh test --summary all erneut aus.
5. Bei Unsicherheit: Anhalten und den Lead-Maintainer fragen: Wenn eine Überprüfung einen architektonischen Zielkonflikt oder eine fehlende Grundstruktur aufdeckt, halten Sie an und fragen Sie den Lead-Maintainer nach einer Richtung, bevor Sie Annahmen treffen.

Fokussierte Referenzleitfäden

Konsultieren Sie diese Referenzchecklisten bei jeder Überprüfung:

• Die 4 Prüfpersonas-Checkliste: Detaillierte Prüfkriterien für den skeptischen erfahrenen Ingenieur, den paranoiden Sicherheitsexperten, den Diosix-Maintainer und den Anfänger/erfahrenen Benutzer.
• Borrow-Checker-Audit: Schrittweise Methodik zur Verfolgung von Pointer-Herkunft, Lebensdauern, aliasing-bedingter Mutabilität und Cross-Privilege-Speichersicherheit in Zig.
• Pre-Commit-Gates: Konkrete Verifikationsbefehle und Freigabekriterien, die vor dem Commit oder Merge in devel oder stable erforderlich sind.