Funktionen in eine mehrschichtige Desktop-App einbauen und jeden Build testen

## Festlegen, wofür Kern, Desktop-Host und Benutzeroberfläche zuständig sind Lege die ausgelieferten Plattformen, unterstützten Clients, die Prozesstopologie und Vertrauensgrenzen fest, bevor du Code änderst. - Halte Geschäftsregeln, Persistenz, Ausführung und Domänenverhalten in einem maßgeblichen Kern. - Weise dem Desktop-Host die Verantwortung für Lebenszyklus, native Funktionen, sichere Überbrückung und Paketierung zu. - Weise der webbasierten Benutzeroberfläche Darstellung, Navigation und Ablaufsteuerung zu; dupliziere keine Kernregeln im Darstellungsprozess. - Leite Aufrufe von der Benutzeroberfläche zum Kern über eine einzige authentifizierte Transportabstraktion statt über fallweise Direktzugriffe. - Behandle experimentelle Clients als getrennte Kompatibilitätsoberflächen mit ausdrücklich festgelegtem Transport, Verschlüsselungs- und Freigabestatus. - Pflege eine Architekturübersicht, die jede Schicht, ihren eigenen Zustand, ihre öffentlichen Schnittstellen und ihre verbotenen Zuständigkeiten benennt. ## Befehle nach Risiko einstufen und Werkzeuge auf den Ordner des Nutzers beschränken Zentralisiere die Konfiguration und wende auf jedes ausführende Werkzeug eine einheitliche, standardmäßig ablehnende Richtlinie an. - Lies Umgebungswerte über typisierte Konfigurationsmodule; Funktionscode darf weder direkt auf Prozessumgebungsvariablen noch auf Variablen der Erstellungszeit zugreifen. - Modelliere Autonomie als ausdrückliche Stufen in Verbindung mit Arbeitsbereichsgrenzen, vertrauenswürdigen Stammverzeichnissen und Installationsberechtigungen. - Ordne Befehle den Klassen Lesen, Schreiben, Netzwerk, Installation oder destruktiv zu; behandle nicht erkannte Befehle als Schreibvorgänge. - Leite für jede Klasse aus der aktiven Stufe ab, ob sie erlaubt, nach Bestätigung ausgeführt oder blockiert wird. Blockiere System- und Zugangsdatenverzeichnisse immer. - Trenne den Aktionsstamm des Benutzers vom internen Anwendungszustand. Werkzeuge dürfen nur innerhalb des Aktionsstamms handeln und niemals direkt in den internen Zustand schreiben. - Lasse Bestätigungsschranken für interaktive Änderungen standardmäßig aktiviert, setze unbeantwortete Anfragen nach Ablauf außer Kraft und verweigere dann die Aktion. - Verbinde die Pfadprüfung auf Anwendungsebene mit einer Betriebssystem- oder Container-Sandbox; eine Sandbox dient der gestaffelten Verteidigung und ersetzt keine Richtlinienprüfungen. ## Jeder Domäne im Kern ein eigenes Modul geben Gib jeder Domäne ein eigenes Modul mit klarer Verantwortung und kleinen, kombinierbaren Dateien. ### Eine einheitliche Modulstruktur verwenden - Beschränke die Modulfassade auf Exporte und halte sie frei von Geschäftslogik. - Lege serialisierbare Domänentypen, Persistenz, Vorgänge, Controller-Schemata, Agentenwerkzeuge, Ereignisabonnenten und Tests in getrennten Dateien ab, sofern diese Zuständigkeiten vorhanden sind. - Ordne domäneneigene Werkzeuge der jeweiligen Domäne zu und nutze gemeinsame Werkzeuginfrastruktur nur für tatsächlich domänenübergreifendes Verhalten. - Beschränke Transportmodule auf Authentifizierung, Weiterleitung, Protokollierung, Beobachtbarkeit und Protokollbelange. Stelle Controller über ein Verzeichnis aus Schema-Handler-Paaren bereit. Neues Verhalten soll einen Domänencontroller hinzufügen und ihn an einem einzigen Zusammensetzungspunkt registrieren, statt Verzweigungen nach Befehlsnamen im gesamten Transportcode anwachsen zu lassen. ## Laufzeit-Schalter getrennt von Kompilierzeitfunktionen halten Modelliere zwei unabhängige Achsen: - Eine Dienstmenge wählt laufende Hintergrunddienste und Transporte aus. - Eine Domänenmenge wählt die zur Laufzeit verfügbaren Domänenfamilien aus. - Kompilierzeitfunktionen entfernen Code und Abhängigkeiten für Produktvarianten. Die Laufzeitfilterung muss Controller, Werkzeuge, Speicher und Abonnenten einer deaktivierten Domäne von der aktiven Oberfläche entfernen. Kompilierzeitschranken müssen mit diesem Verhalten zusammenspielen, ohne den Standard-Build zu verändern. Halte die Registrierungsstelle maßgeblich, damit Schemata, Weiterleitung, Werkzeuge und Startdienste nicht auseinanderlaufen können. ## Anhand echter Abhängigkeiten wählen, wie optionale Funktionen abgeschaltet werden Wähle die kleinste Schranke, die ständig verfügbares Verhalten bewahrt. 1. Verwende eine Blattschranke, wenn jede externe Referenz eine Registrierungsstelle ist; Oberflächen deaktivierter Funktionen sollen fehlen und nicht als fehlschlagende Platzhalter registriert werden. 2. Verwende eine Fassade mit Verhaltensplatzhaltern nur dann, wenn stets kompilierte Aufrufer aufrufbare Symbole benötigen. 3. Lagere gemeinsame, von Abhängigkeiten freie Typen in stets kompilierte Module aus und ersetze nur Verhalten durch Platzhalter. Dupliziere Typdefinitionen niemals zwischen aktivierten und deaktivierten Builds. 4. Teile ein Verzeichnis, wenn einige Hilfsfunktionen ständig verfügbaren Domänen dienen; sichere tatsächliche Abhängigkeitskanten ab, nicht Verzeichnisnamen. 5. Bewahre tragende Hilfsfunktionen selbst dann, wenn sie unter einer optionalen Domäne liegen. Ersetze eine notwendige Implementierung nicht durch einen Platzhalter, der Erfolg vortäuscht. Wenn ein Befehl sichtbar bleibt, obwohl seine Funktion nicht mitkompiliert wurde, gib einen ausdrücklichen Fehler für einen deaktivierten Build zurück statt eines irreführenden Fehlers wegen eines unbekannten Befehls. Bei Daten, die während der Kompilierung wirkungslos sind, aber dennoch deaktivierte Komponenten benennen, muss die Auflösung fehlende Bezeichner tolerieren; prüfe diesen Vertrag mit Tests. Behaupte niemals allein aufgrund einer erfolgreichen Kompilierung, dass eine Funktionsschranke Abhängigkeiten entfernt. Belege jede behauptete Entfernung mit einer umgekehrten Abhängigkeitsbaumabfrage in der deaktivierten Konfiguration. ## Builds mit ein- und ausgeschalteten optionalen Funktionen testen Behandle Tests als Teil der Architektur und decke Verhalten, Integration und Paketierung ab. - Ordne gezielte Modultests dem betreffenden Code zu und bevorzuge beobachtbares Verhalten gegenüber Implementierungsdetails. - Nutze einen gemeinsamen simulierten Dienst für deterministische Integrationstests; verbiete in Modultests echte Netzwerkzugriffe und zeitabhängige Wartepausen. - Definiere durchgängige Szenarien vor der Implementierung, einschließlich Erfolgsabläufen, Fehlern, Autorisierungsschranken und Wiederherstellung. - Teste optionale Funktionen in beide Richtungen: Belege ihre Registrierung im aktivierten und ihr Fehlen im deaktivierten Zustand. - Führe die Testsammlung für den deaktivierten Build ausdrücklich aus. Eine Spur, die nur eine Probekompilierung ausführt, kompiliert keinen Testcode und kann nicht belegen, dass abgesicherte Tests gültig bleiben. - Erzwinge einen Abdeckungsgrenzwert für geänderte Zeilen und greife auf die vollständige Testsammlung zurück, wenn gemeinsame Konfiguration oder grundlegende Verträge geändert werden. - Erstelle teure Plattformartefakte einmal und verteile die Tests von diesem Artefakt aus, sofern das Erstellungssystem dies zulässt. ## Diagnoseprotokolle ergänzen, die keine Geheimnisse oder persönlichen Daten speichern Neue und geänderte Abläufe benötigen Diagnoseangaben bei Eintritt, Austritt, Verzweigungen, externen Aufrufen, Wiederholungsversuchen, Zeitüberschreitungen, Zustandsübergängen und Fehlern. - Verwende stabile, leicht durchsuchbare Domänenpräfixe und Korrelationsfelder wie Anfragekennungen und Methodennamen. - Halte normale Protokolle knapp, während Debug- und Trace-Stufen für gezielte Untersuchungen ausreichend aussagekräftig bleiben. - Schreibe niemals Geheimnisse, rohe Zugangsdaten, vollständige personenbezogene Daten, benutzerverfasste Inhalte, Entitätskennungen, Dateinamen oder rohe Fehlermeldungen in Analysedaten. - Leite Analysedaten über eine einzige, einwilligungsbewusste Funktions-API und verwende stabile Ereignisnamen ohne Inhaltsdaten. - Betrachte fehlende Diagnoseangaben als unvollständige Implementierung, wenn die Änderung einen neuen Ausführungspfad einführt. ## Alle Texte der Benutzeroberfläche übersetzen und erzeugte Dokumente nicht von Hand ändern Nutze zentralisierten Zustand, Transport und Lokalisierung statt lokaler Abkürzungen. - Bevorzuge die vorgesehene Zustandsverwaltung der Anwendung gegenüber verstreutem Browserspeicher. - Nutze den gemeinsamen Kern-Client für alle Kernaufrufe und halte parallele Transporte im Verhalten deckungsgleich. - Schütze ausschließlich nativen Umgebungen vorbehaltene APIs mit der unterstützten Laufzeiterkennung und Fehlergrenze. - Führe jede sichtbare Zeichenfolge durch die Lokalisierung, füge echte Übersetzungen für jedes unterstützte Gebietsschema hinzu und bewahre Interpolationsplatzhalter exakt. - Führe vor Abschluss Prüfungen auf Lokalisierungssyntax, verbliebene englische Texte und Abdeckung aus. - Bearbeite erzeugte Dokumentationsblöcke niemals von Hand. Aktualisiere ihre Quellmarkierung, erzeuge sie neu und lasse Abweichungsprüfungen bei veralteter Ausgabe fehlschlagen. - Füge eingebetteten Ansichten von Drittanbietern keine Skripteinschleusung hinzu; implementiere neues Verhalten über native Handler, Protokollwerkzeuge oder kontrollierte IPC-Einhängepunkte. ## Funktionen vom Kern bis zur Benutzeroberfläche bauen und jede Schicht zuerst testen Halte einen festen vertikalen Ablauf ein: 1. Lege das Verhalten anhand vorhandener Domänenverträge, Benennungskonventionen, Sicherheitsrichtlinien und durchgängiger Szenarien fest. 2. Implementiere die maßgebliche Domänenlogik mit Modultests. 3. Belege die Controller- oder RPC-Grenze mit einem Integrationstest. 4. Stelle das Verhalten in der Benutzeroberfläche über den gemeinsamen Client bereit und belasse die Regeln im Kern. 5. Ergänze Modultests für die Benutzeroberfläche und plattformbezogene durchgängige Abdeckung. 6. Aktualisiere benutzerseitige Funktionsmetadaten und die Architekturdokumentation, wenn eine Funktion hinzugefügt, entfernt oder umbenannt wird. Gehe nicht zur nächsten Schicht über, solange die aktuelle Schicht ungetestet ist. Halte Module klein und auf einen Zweck beschränkt, und aktualisiere die Dokumentation zusammen mit dem von ihr geregelten Verhalten. ## Pflichtprüfungen nicht überspringen und vor dem Abschluss ihre Ergebnisse zeigen Nimm Änderungen auf einem eigenen Zweig vor, richte sie auf den vorgesehenen Integrationszweig des Repositorys und binde Produktionsfreigaben an die festgelegte Freigabequelle. - Verwende vom Stammverzeichnis des Repositorys aus die vorgeschriebene Paketverwaltung, festgeschriebene Werkzeugkette, Formatierung, statische Prüfung, Typprüfung und Testprogramme. - Halte gleichwertige Einstellungen von Build-Profilen über getrennt erstellte native Komponenten hinweg synchron. - Umgehe niemals erforderliche Einhängepunkte oder Prüfungen, um Fehler zu verbergen. Wenn ein Einhängepunkt Dateien erzeugt, prüfe und übernimm die Ergebnisse und führe ihn anschließend erneut aus. - Behebe Fehler, die durch die Änderung verursacht wurden; dokumentiere nicht damit zusammenhängende, bereits bestehende Hindernisse, statt Schutzvorkehrungen stillschweigend abzuschwächen. - Prüfe den abschließenden Unterschied auf Konsistenz von Implementierung, Tests, Schemata, erzeugten Artefakten, Lokalisierung und Dokumentation. - Erkläre die Arbeit nicht für abgeschlossen, solange keine direkten Ergebnisse der Prüfungen vorliegen, die für jede geänderte Schicht und unterstützte Build-Konfiguration relevant sind.