Ein Rust-Datenfluss-Framework für Robotik und KI entwickeln und Tests passend zur Änderung wählen

## Den Rust-Arbeitsbereich aufbauen und die Laufzeit in vier Rollen aufteilen Organisiere das System als Rust-Arbeitsbereich mit Sprachbindungen für Python, C und C++. Halte die Mindestversion der Werkzeugkette und die gemeinsamen Paketmetadaten im Stammverzeichnis des Arbeitsbereichs fest. Ausdrücklich dokumentierte Crates oder Beispiele dürfen eigene Versionen festlegen. Verwende vier Laufzeitrollen mit klarer Verantwortung: - Ein Befehlszeilenprogramm erstellt, startet, stoppt und untersucht Datenflüsse. - Eine Koordinationskomponente verwaltet den verteilten Lebenszyklus über mehrere Rechner hinweg. - Ein Hintergrunddienst pro Rechner startet Knoten und verwaltet die lokale sowie entfernte Kommunikation. - Knoten führen Benutzercode als Prozesse aus; Operatoren laufen innerhalb eines Prozesses, wenn geringerer Verwaltungsaufwand erforderlich ist. Lege Nachrichten- und Protokolldefinitionen in einer gemeinsamen Bibliothek, die Deskriptorauswertung und Erstellungswerkzeuge in einer Kernbibliothek und die Sprachschnittstellen in getrennten Paketen ab. Anforderungen der Sprachbindungen dürfen gewöhnliche reine Rust-Erstellungen nicht beeinträchtigen. ## Sprachbindungen getrennt vom Rust-Arbeitsbereich bauen Erstelle den Rust-Arbeitsbereich ohne Sprachbindungspakete, die ein eigenes Paketierungswerkzeug benötigen. Erstelle diese Pakete mit ihrer jeweiligen Werkzeugkette, anstatt sie durch den gewöhnlichen Arbeitsbereichsbefehl zu zwingen. Unterstütze drei Bearbeitungsebenen: den gesamten Arbeitsbereich, ein Paket und ein einzelnes Testziel. Führe Prüfungen, Tests, statische Analyse und Formatierung mit den verbindlichen Arbeitsbereichsbefehlen aus und installiere lokale Befehlszeilenwerkzeuge mit gesperrten Abhängigkeiten. Erstelle das Projekt vor statischer Analyse, Tests, Integrationsmomentaufnahmen oder Dokumentationsprüfungen. Beispielziele benötigen eine eigene Prüfung, weil eine allgemeine Arbeitsbereichsprüfung sie möglicherweise nicht übersetzt. Nutze schnelle Pakettests während der Bearbeitung, kehre aber vor einer Veröffentlichung zum vollständigen betroffenen Arbeitsbereich zurück. Wird ein neuer Beispieldatenfluss hinzugefügt, führe die Beispiel-Anlauftests im unterstützten Sprachmodus aus. ## Die drei Kommunikationsmuster und die Regel für gemeinsamen Speicher klar halten Definiere Datenflüsse deklarativ. Knoten abonnieren benannte Ausgaben und deklarieren ihre eigenen Ausgaben. Stelle Zeitgeberquellen bereit und gib deren Frequenz oder Intervall im Deskriptor ausdrücklich an. Erhalte drei unterschiedliche benutzerseitige Kommunikationsmuster: - Der Themenkanal ist der voreingestellte Veröffentlichungs- und Abonnementfluss. - Der Dienst arbeitet nach dem Anfrage-Antwort-Muster und ordnet Nachrichten über `request_id` zu. - Die Aktion bildet Ziel, Rückmeldung, Ergebnis und Abbruch über `goal_id` und `goal_status` ab. Verwende begrenzte Mehrproduzentenkanäle für die interne Ereignisweiterleitung und eine asynchrone Laufzeitumgebung für die Ablaufsteuerung. Nutze rechnerübergreifend eine verteilte Veröffentlichungs- und Abonnementübertragung sowie eine hybride logische Uhr für die kausale Reihenfolge. Übertrage im lokalen Knotenverkehr Nachrichten über 4 KB durch kopierfreien gemeinsam genutzten Speicher und kleinere Nachrichten über TCP. Mache Schwellenwert, Eigentümerschaft und Ausweichverhalten ausdrücklich sichtbar; führe die Semantik des lokalen gemeinsamen Speichers und des entfernten Netzes niemals in einem undokumentierten Pfad zusammen. ## Jeden Commit erst prüfen und vereinfachen, dann testen Jeder Commit muss vor der Veröffentlichung diese Prüfungen bestehen: 1. Untersuche die Änderungen auf strukturelle, sicherheitsbezogene und logische Fehler. 2. Vereinfache unnötige Komplexität, Doppelungen und Ineffizienz. 3. Prüfe die Formatierung, behandle Warnungen bei der statischen Analyse als Fehler, führe mindestens die Tests des betroffenen Pakets und vor der Veröffentlichung die Tests des gesamten Arbeitsbereichs aus. 4. Übersetze die Beispielziele, damit Brüche von API-Signaturen nicht außerhalb des gewöhnlichen Arbeitsbereichsgraphen verborgen bleiben. Nutze vor jedem Commit eine schnelle lokale Prüfung mit Formatierung, statischer Analyse, Abhängigkeitsprüfung, Budget für unsichere Abkürzungen und Rechtschreibprüfung. Führe danach vor der Veröffentlichung den vollständigen vorgeschriebenen Testbefehl aus. Überspringe keine fehlgeschlagene Prüfung und verlasse dich nicht darauf, dass die langsamere entfernte CI den Fehler findet. Behebe den Fehler und wiederhole die betroffene Prüfung. Halte die Reihenfolge ein: Prüfung und Vereinfachung machen Entwurfsfehler vor breiten Tests kostengünstiger korrigierbar. ## Tiefe Tests nach Risiko wählen, statt sie bei jedem Commit auszuführen Führe nicht bei jedem Commit alle umfangreichen Prüfreihen aus und füge sie nicht vollständig der Pull-Request-CI hinzu. Wähle sie nach dem Änderungsumfang: - Nutze vor einer wichtigen Veröffentlichung die vollständige lokale Prüfreihe einschließlich Testabdeckung, wenn zusätzliche Sicherheit erforderlich ist. - Nutze für risikoreiche oder Tier-1-Änderungen eine Tiefenprüfung mit Mutationstests und Kompatibilitätsanalyse. - Nutze einen mehrstündigen Nachtlauf für plattformübergreifende, eigenschaftsbasierte, interpreterbezogene, formal bewiesene und durchgängige Abdeckung. - Nutze vor der Verteilung die Veröffentlichungsprüfung; halte eine unabhängige Sicherheitsprüfung, praktische Nutzungstests und Migrationsprüfungen als getrennte, von Menschen geleitete Prüfungen bei. - Nutze eine vollständige Mutationsprüfung nur für eine veröffentlichungsreife Testbewertung oder eine gezielte Untersuchung, da sie 10 bis 18 Stunden dauern kann. - Führe Beispieldatenflüsse nach Änderungen an Knoten-APIs, Befehlsverhalten oder Deskriptoren vollständig aus. - Führe formale Beweise bei Änderungen an beweisgeschützten Modulen aus und nimm die profilgesteuerte Optimierung auf dem Zielbetriebssystem und der Zielarchitektur vor, weil Profile nicht übertragbar sind. Behandle Testabdeckung, Mutationstests, Kompatibilität, Beispiele, formale Verifikation und Leistungsprofilierung als sich ergänzende Nachweise, nicht als austauschbare Ersatzmittel. ## Die Pull-Request-CI schnell halten und lange Jobs nachts laufen lassen Halte die Pull-Request-CI schlank genug für schnelle, blockierende Rückmeldungen. Sie sollte Formatierung, statische Analyse mit Warnungen als Fehler, Kerntests, durchgängige Fehlerpfade, semantische Verträge, Leistungsvergleichsregressionen, Rechtschreibung, Lieferkettenprüfungen, Budgets für unsichere Abkürzungen und Lizenzen abdecken. Erweitere die blockierende Prüfkette nicht um mehrstündige Aufgaben. Plane breite Prüfungen getrennt: - Führe Plattformtests unter Linux, macOS und Windows aus. - Prüfe Beispiele, Befehlszeilenvorlagen, Knoten in dynamischen Sprachen, Leistungsvergleiche und Kreuzkompilierung. - Decke verteilte Lebenszyklen, Aufzeichnung und Wiedergabe, Wiederverbindung, Zustandswiederherstellung, Prozessorbindung, Speicherhintergründe und Brückenadapter ab. - Prüfe den unterstützten Mindestcompiler und alle formalen Beweisharnische. Fehler im Nachtlauf sollten ein nachverfolgbares Regressionssignal erzeugen, müssen aber einen unbeteiligten Pull Request nicht blockieren. Führe vor dem Zusammenführen lokale Prüfungen für nicht voreingestellte Plattformen oder Beispiele aus, wenn die Änderung von diesen Pfaden abhängt. ## Zuerst einen fehlschlagenden Test schreiben, dann nur so viel Code, dass er besteht Alle neuen Funktionen und Fehlerbehebungen folgen RED-GREEN-IMPROVE: 1. RED: Schreibe den kleinsten Test, der das erwartete Verhalten festlegt, und prüfe, dass er aus dem beabsichtigten Grund fehlschlägt. 2. GREEN: Implementiere nur so viel Code, dass dieser Test besteht. 3. IMPROVE: Überarbeite den Code, während die gezielten Tests und die Tests des betroffenen Pakets erfolgreich bleiben. Wähle die erste Testebene nach dem Verhalten. Beginne Bibliotheksfunktionen mit Modultests, das Verhalten von Koordination oder Hintergrunddienst mit Integrationstests, Befehlsänderungen mit vernetzten Anlauftests, Datenflussfunktionen mit vernetzten und lokalen Anlauftests und Fehlerbehebungen mit dem engsten Regressionstest, der den Fehler reproduziert. Führe nach Bestehen des gezielten Tests die Tests des betroffenen Pakets, die statische Analyse mit Warnungen als Fehler und die Formatierungsprüfung aus. Betrifft die Änderung Befehlszeilenprogramm, Koordination oder Hintergrunddienst, führe Anlauftests dort nacheinander aus, wo gemeinsam genutzte Ports oder Prozesse getrennt werden müssen. ## Beispiel-Datenflüsse im vernetzten und im lokalen Smoke-Test-Modus ausführen Stelle zwei Anlauftestarten bereit: - Der Netzwerkmodus startet die verteilte Laufzeitumgebung, startet einen abgekoppelten Datenfluss, fragt bis zum Abschluss nach und stoppt sowie beendet danach die Laufzeitumgebung. - Der lokale Modus führt den Datenfluss in einem Prozess mit einer ausdrücklichen Beendigungsfrist aus. Neue Beispieldatenflüsse sollten beide Arten bestehen. Teile aufwendige Erstellungsvorbereitungen über eine einmalige Schutzvorrichtung, anstatt für jeden Test erneut zu erstellen. Halte durchgängige Tests für Befehlsübertragung und Fehlertoleranz von gewöhnlichen Modultests getrennt. Anlauftestreihen müssen Prozesse und Ports sowohl bei Erfolg als auch bei Fehlschlag bereinigen, damit spätere Tests nicht beeinträchtigt werden. Schließe Beispiele, die nicht verfügbare Hardware, interaktive Eingaben, eine Mehrrechnerumgebung oder nicht unterstützte native Werkzeugketten benötigen, aus der voreingestellten Anlauftestmenge aus. Dokumentiere jedoch die Ausschlussgrenze und stelle eine gezielte Ausführungsmöglichkeit bereit. ## Änderungen klein halten und genau melden, welche Prüfungen liefen Formatiere Änderungen vor der Einreichung mit dem voreingestellten Formatierer des Projektarchivs. Besprich nicht triviale Entwurfsänderungen vor der Umsetzung im Entscheidungskanal des Projekts. Behebe in derselben Änderung keine unbeteiligten Warnungen und überarbeite keinen unbeteiligten Code. Halte den Änderungssatz begrenzt, damit Fehler, Prüfung und Rücknahme zurechenbar bleiben. Behandle Sprachpakete und Befehlszeilenprogramme als getrennte Verteilungsflächen. Prüfe für jede Fläche die passenden Paket-, Bindungs-, Kompatibilitäts- und Veröffentlichungsanforderungen. Nutze ein optimiertes Veröffentlichungsprofil erst nach bestandenen Korrektheitsprüfungen. Leistungsarbeit muss die Zielplattform nennen und eine reproduzierbare Ausgangsbasis mit der optimierten Erstellung vergleichen. Berichte vor der Übergabe, welche schnellen, vollständigen, tiefen, nächtlichen, beispielbezogenen, formalen oder leistungsbezogenen Prüfungen tatsächlich ausgeführt wurden und welche ungeprüft bleiben. Behaupte niemals, eine erfolgreiche Ebene beweise den Erfolg einer anderen.