Ein Tool zur Geräteautomatisierung ändern und auf echten Geräten prüfen

## Die Anfrage einordnen und nur den betroffenen Code lesen Ordne zuerst die Anfrage ein. Eine rein informative Überprüfung, Sichtung oder Frage bleibt schreibgeschützt, sofern nicht ausdrücklich Änderungen oder eine Ausführung verlangt werden. Eine Anfrage zur Codeänderung erlaubt eine minimale Umsetzung und die für diesen Bereich erforderlichen Prüfungen. Nenne vor der Bearbeitung die Annahmen und definiere einen beobachtbaren Erfolg. Lies das dauerhafte Fachvokabular, die einschlägigen Architekturentscheidungen und die zuständige Konfiguration oder den maßgeblichen Vertrag. Lies nicht standardmäßig das gesamte Repository. Beginne mit einer begrenzten Suche: - Finde das Symbol, den Befehl, die Option oder den Fehler mit einer schnellen Textsuche. - Lies das zuständige Modul, genau eine gemeinsame Hilfsfunktion und genau einen nachgelagerten Aufrufer oder Adapter. - Suche in einer großen Datei zuerst den relevanten Typ oder die relevante Funktion, bevor du einen begrenzten Abschnitt öffnest. - Verfolge Importe und Tests nur dann weiter nach außen, wenn die Nachweise es erfordern. Halte die Änderung innerhalb einer Befehlsfamilie, einer Plattformgrenze oder einer Modulgruppe, sofern die Aufgabe nicht ausdrücklich Grenzen überschreitet. Untersuche nicht allein deshalb zwei Plattformimplementierungen, weil beide vorhanden sind. Falls der Umfang erweitert werden muss, halte an und bestätige die neue Grenze. Bestimme vor dem Programmieren die Auswirkungen auf Dokumentation, Hilfe, Schema und Fertigkeitsdefinitionen. Bevorzuge dauerhafte Verweise auf die verbindliche Wahrheitsquelle gegenüber Dateilisten, die veralten können. ## Name und Optionen jedes Befehls in einem Register bündeln Gib jedem Befehl genau einen kanonischen Deskriptor, der seine Identität, Fähigkeiten, Zeitüberschreitungsrichtlinie, Stapelrichtlinie und öffentlichen Darstellungen verwaltet. Halte die Weiterleitung von Hintergrunddienst oder Dienst in einem Routenregister, Garantien für Interaktionspfade in einer typisierten Matrix und Befehlsnamen in genau einem Katalog. Erstelle Zeichenfolgenmengen nicht erneut innerhalb von Verarbeitungsroutinen. Halte Router der obersten Ebene schlank und beschränke sie auf die Ablaufsteuerung. Leite an die zuständige Familie von Verarbeitungsroutinen weiter; häufe keine Befehlslogik am Einstiegspunkt an. Entscheidungen über Fähigkeiten gehören in deren verbindliche Wahrheitsquelle, nicht in verstreute Bedingungen. Lass jede öffentliche Option nur durch Ebenen fließen, die sie verstehen: 1. Definiere die öffentliche Option und ihre Grammatik. 2. Füge sie den Metadaten und dem Schema des zuständigen Befehls hinzu. 3. Analysiere sie als Befehlseingabe. 4. Übertrage sie nur dann in eine Dienstanfrage, wenn die Ausführung zur Laufzeit sie benötigt. 5. Erweitere typisierte Clients und Normalisierer nur dann, wenn diese Schnittstellen die Option bereitstellen. 6. Führe sie erst dann durch die Weiterleitung und Plattformmodule, wenn der öffentliche Vertrag belegt, dass sie dorthin gehört. 7. Ordne jede öffentliche Option im Modell für Architekturfortschritt oder Abdeckung ein. Zentralisiere Analyse, Abgleich, Auflösung und Prädikatsauswertung von Selektoren. Eine auf ein Element gerichtete Aktion soll stabile Selektoren oder aufgezeichnete Referenzen akzeptieren, ihre Selektorkette bewahren und Abweichungen bei der Wiedergabe als Vorschlag anzeigen, statt den Benutzerzustand stillschweigend umzuschreiben. ## Prüfen, dass schnelle Pfade und Cache-Pfade wie der Hauptpfad arbeiten Gehe davon aus, dass Garantien an Pfadgrenzen erodieren. Wenn du einen Schnellpfad, einen delegierten Pfad, einen Zwischenspeicherpfad oder einen plattformspezifischen Pfad hinzufügst, ordne jede betroffene Zelle aus Befehl und Pfad ein, bevor du Gleichwertigkeit behauptest. Ein Registereintrag ist kein semantischer Beleg. Lies die Implementierung und überprüfe, ob sie die Definition der Garantie erfüllt. Ein Rückfallpfad, der erst nach einem Fehler delegiert, belegt keine Gleichwertigkeit des Erfolgspfads; der Schnellpfad könnte eine Eingabe akzeptieren, die der gemeinsame Pfad ablehnen würde. Belege vor der Messung eines Experiments, dass jeder Versuchsarm ausgeführt werden kann. Zwei erfolgreiche Durchläufe sind bedeutungslos, wenn der geänderte Zweig nie aktiviert wurde. Erfasse Pfad, Backend, Ursachencode und weitere erforderliche typisierte Nachweise, um zu zeigen, welche Implementierung die Anfrage verarbeitet hat. Verwende strukturierte Signale, statt für Menschen bestimmte Meldungen auszuwerten. Verzweige anhand von Ursachencodes, typisierten Details und ausdrücklichen Zeitüberschreitungswerten; kopiere keine Erkennung anhand von Fehlertexten. Behandle jeden unvermeidbaren Meldungsabgleich als dokumentierte Schuld an der Entscheidungsstelle. Setze Warnungen mit dem gemeinsamen Antwortgenerator zusammen, statt frühere Warnungen zu überschreiben. Speichere Metadaten für die gesamte Antwort genau einmal, statt Bytes für jeden Knoten oder Eintrag zu wiederholen. Stelle vor dem Beibehalten eines Kompatibilitätsfelds fest, ob es veröffentlicht wurde. Eine unveröffentlichte Oberfläche kann sauber entfernt werden; eine veröffentlichte Oberfläche benötigt Migration und Kompatibilitätsbehandlung. ## Dateien klein halten und Tests wie den Quellcode gliedern Verwende `unknown` nur an Vertrauensgrenzen wie analysierten Eingaben, Laufzeitnutzlasten, abgefangenen Fehlern und allgemeiner Ein-/Ausgabe. Validiere einmal und grenze anschließend auf einen Domänentyp oder einen gezielten Parser ein, statt die Unsicherheit durch interne Hilfsfunktionen und Formatierer weiterzutragen. Bevorzuge Vollständigkeitsprüfungen auf Typebene, wenn die Sprache fehlende Fälle unmöglich machen kann. Platziere maschinenlesbare Aussagen neben dem Code, den sie beschreiben: Registerzellen neben Verweisen auf ihre Durchsetzung, Abdeckungsmanifeste neben Vertragstests und Entscheidungskommentare an dem Zweig, den sie begründen. Lass jedes Modul genau eine Frage beantworten. Strebe als praktische Warnschwelle für Implementierungsdateien ungefähr 300 Zeilen an; verbessere nach 500 Zeilen die Lokalität, bevor du Verhalten hinzufügst; behandle die Datei jenseits von 1,000 Zeilen als Architekturschuld, sofern sie keine generierten Daten oder eine Prüfdatenmomentaufnahme enthält. Benenne Dateien nach dem Domänenkonzept, das sie beantworten. Verwende Sammelmodule nur an Paketgrenzen; interne Sammelmodule fügen Navigationssprünge hinzu. Lagere ein tief verschachteltes Modul aus, wenn dies die begriffliche Zuständigkeit verbessert, nicht nur um die Zeilenzahl zu verringern. Spiegle die Quellstruktur in den Tests. Wenn ein Quellmodul aufgeteilt wird, teile seine Tests in derselben Änderung auf. Lege wiederverwendbare Prüfdaten in einem benannten, gleichgeordneten Prüfdatenmodul ab, statt große eingebettete Objekte zu duplizieren. Füge keine Exporte im Produktivcode ausschließlich deshalb hinzu, um ein privates Detail leichter testen zu können. Bereinige vor dem Abschluss den geänderten und direkt angrenzenden Code: Entferne veraltete Zweige, redundante Tests, ungenutzte Importe, überholte Prüfdaten und durch die Änderung unnötig gewordene Duplikate. Vermeide unbeteiligte Bereinigungen. ## Gerätesitzungen schließen und Protokolle von Diagnosen trennen Führe Prozesse über die gemeinsame Prozessabstraktion aus. Erweitere diese Abstraktion, wenn eine Fähigkeit fehlt, statt im gesamten Codebestand primitive Prozessfunktionen niedriger Ebene zu importieren. Behandle jede manuell geöffnete Gerätesitzung als Ressource. Erfasse Sitzungsname, Plattform, Gerätekennung und Zustandsverzeichnis und schließe sie vor dem Abschluss mit denselben Werten, selbst nach einem fehlgeschlagenen Experiment. Beende ausschließlich genau identifizierte veraltete Prozesse, die zum Verifikationslauf gehören; beende niemals auf Verdacht ganze Prozessgruppen. Halte Anwendungsprotokolle, Ausgabe des Ausführungsprogramms und Anfragediagnosen getrennt. Genau ein Backend soll für die Erfassung von Anwendungsprotokollen zuständig sein. Speichere Anfragediagnosen unter der aufgelösten Sitzung und Anfragekennung; reserviere Protokolle des Hintergrunddienstes auf oberster Ebene für den Lebenszyklus und für Fehler, die vor der Sitzungsauflösung auftreten. Zentralisiere Diagnosebereiche, Zeitgeber, Ereignisausgabe, Schwärzung und die Erstellung von Artefaktpfaden. Erstelle Protokollpfade nicht von Hand und füge keine Behelfsdateien hinzu, wenn der Diagnosedienst diese Daten verwaltet. Normalisiere benutzerseitig sichtbare Fehler in eine stabile Nutzlast mit Code, knapper Meldung, Wiederherstellungshinweis, Diagnosekennung, Protokollpfad und typisierten Details. Bewahre diese Felder beim Umschließen von Fehlern. Nenne, was fehlgeschlagen ist, warum, sofern bekannt, und die nächste Wiederherstellungsmaßnahme. Behandle optionale Sondierungen, Zwischenspeicherprüfungen und Vorabprüfungen als bestmögliche, aber nicht garantierte Prüfungen, sofern der Funktionsvertrag sie nicht verbindlich vorschreibt. Gib ihnen eine kürzere Zeitüberschreitung als dem erforderlichen Vorgang und weiche auf den etablierten Pfad aus, wenn sie fehlschlagen oder eine unbrauchbare Form zurückgeben. ## Tests passend zum geänderten Bereich auswählen Beginne mit dem Planer für betroffene Prüfungen des Repositorys, sofern er verfügbar ist. Er soll gezielte Tests und verbleibende Prüfstellen aus kanonischen Metadaten ableiten, nicht aus einer handgeschriebenen Liste. Ordne Prüfungen dem geänderten Bereich zu: - Jede Änderung an typisiertem Quellcode erfordert Typprüfung und Formatierung. - Änderungen an Werkzeugkette oder Compilerkonfiguration erfordern die Werkzeugprüfstelle und das Erstellen von Deklarationen. - Änderungen an gemeinsamen Diensten oder Verarbeitungsroutinen erfordern das gezielte Paket von Einheitstests. - Änderungen an Antwortform oder Anbietergrenze erfordern Anbieterintegrations- und Abdeckungsprüfungen. - Änderungen am nativen Ausführungsprogramm erfordern die Neuerstellung des nativen Testartefakts. - Plattformübergreifendes Verhalten erfordert die plattformübergreifende Integrationstestsammlung. - Reine Dokumentationsarbeit benötigt Laufzeittests nur dann, wenn ein genauerer Vertrag dies vorschreibt. Führe nicht standardmäßig breite Integrationstests aus, wenn gezielte Nachweise ausreichen. Umgekehrt darf eine gerätebezogene Änderung nicht allein aufgrund von Einheitstests als bereit gelten. Halte Tests verhaltensorientiert. Prüfe nicht erneut, was statische Typen bereits belegen. Einheitstests dürfen keine reale Zeit abwarten; injiziere ein Zeitbudget, leite daraus den Takt ab oder prüfe, dass das Budget korrekt weitergegeben wurde. Wenn eine Durchsetzungsprüfstelle ein nicht eingeordnetes Kennzeichen, eine fehlende Garantiezelle, ein nicht abgedecktes Szenario, eine Umgehung der Antworterstellung oder eine Lücke in der Regelgleichwertigkeit findet, ordne das neue Verhalten ein oder decke es ab. Unterdrücke niemals die Prüfstelle und füge keinen unerklärten Positivlisteneintrag hinzu. ## Neu bauen, bevor auf echten Geräten oder Simulatoren geprüft wird Erstelle vor der manuellen Überprüfung jedes Artefakt neu, das die Laufzeit tatsächlich verwendet, starte Dienste ohne dynamisches Nachladen neu und entwerte oder ersetze jedes übernommene Ausführungsprogramm, das weiterhin eine ältere native Binärdatei bereitstellen könnte. Ein Test gegen veraltete Ausgabe ist ein falsch negatives Ergebnis und kein Produktnachweis. Belege, welches Backend den Durchlauf verarbeitet hat. Erfasse eine maschinenlesbare Momentaufnahme oder Statusantwort und gleiche Backendkennung und Version der Hilfsfunktion mit dem aktuellen Paket ab. Ein stiller Rückfallpfad ist nur dann ein gültiger Nachweis, wenn das Verhalten des Rückfallpfads die geprüfte Funktion ist. Verwende für gleichzeitige Arbeitsbäume unterschiedliche Geräte, Simulatoren oder Emulatoren, da ein isolierter Zustand des Hintergrunddienstes physische Ziele nicht isoliert. Befolge die eigene Einrichtungsanleitung der Testanwendung; eine installierte Anwendung genügt nicht, sofern nicht Erstellungs-, Entwicklungsserver- und Oberflächenprüfungen belegen, dass die beabsichtigte Version ausgeführt wird. Ordne Umgebungsrauschen ein, bevor du Fehler im Produktcode untersuchst. Reproduziere Konfliktfehler isoliert und auf der unveränderten Basis unter derselben Last. Eine wechselnde Fehlermenge, die isoliert erfolgreich ist, deutet wahrscheinlich auf Ressourcenkonflikte hin; ein stabiler Fehler im geänderten Pfad ist ein stärkerer Regressionsnachweis. Wenn eine Sandbox einen erforderlichen lokalen Listener, eine Gerätebrücke oder ein natives Werkzeug verhindert, führe den Vorgang über den genehmigten Pfad mit erhöhten Rechten erneut aus, statt die Sandbox-Verweigerung als Produktfehler zu diagnostizieren. Bleibt die Überprüfung am realen System blockiert, nenne das genaue erforderliche Gerät, die Berechtigung, den Befehl oder Dienst und halte das verbleibende Risiko fest. ## Den echten Befehlsweg prüfen und mit Ergebnissen vom Gerät berichten Prüfe anhand des auslösenden Problems und der akzeptierten Architekturentscheidungen, nicht nur anhand des Änderungsvergleichs. Verfolge den Produktionspfad von der Befehlsoberfläche über die Anfrageweiterleitung bis zum Plattform-Backend. Ein Test, der den Router umgeht oder die kritische Schnittstelle nur nachbildet, belegt nicht das ausgelieferte Verhalten. Bestimme für jeden wichtigen Regressionstest die alte Implementierung, Entfernung oder Rücknahme, die ihn fehlschlagen lassen sollte. Bleibt der Test nach der Rückkehr des Fehlers erfolgreich, ist er aussagelos und muss verstärkt werden. Trenne die beabsichtigte Umstrukturierung von verborgenen Verhaltensänderungen an Ausgabeform, Warnungsweitergabe, Fehlerdetails, Artefaktpfaden, Wiederholungsstufen und Rückfallpfaden. Überprüfe verwandte Änderungen und die Zweigreihenfolge, wenn die Implementierung von einer anderen Änderung abhängt. Stelle externe Veröffentlichung oder Git-Push hinter eine einzige Erfolgskette, sodass sie nach einem fehlgeschlagenen Formatierungs-, Typprüfungs-, Stilprüfungs- oder Testbefehl nicht ausgeführt werden können. Halte Commits und Zusammenführungsanfragen eng begrenzt, verwende den üblichen Titelstil des Projekts und öffne standardmäßig nur dann eine prüfbereite Anfrage, wenn die Arbeit abgeschlossen ist. Fasse benutzersichtbares Verhalten, aussagekräftige Validierung, Nachweise vom realen Gerät und tatsächliche Abwägungen zusammen. Bezeichne die kontinuierliche Integration nicht aufgrund eines lokalen Einheitstestlaufs als erfolgreich und eine Plattformänderung nicht ohne aktuelle Nachweise vom realen System als zusammenführungsbereit. Nenne Auswirkungen auf Dokumentation oder Hilfe, den geänderten Umfang, jeden ungeprüften Pfad und die genaue Blockade. Schließe vor der Übergabe jede Sitzung und erfasse jede während der Überprüfung geöffnete Ressource. Melde jede Sitzung, jeden Prozess, jedes Zustandsverzeichnis oder Artefakt, das nicht bereinigt werden konnte.