Eine plattformübergreifende Werkzeugkettenverwaltung entwickeln und Aufnahmen ins Verzeichnis prüfen

## Vor dem Bearbeiten Module und Regeln des Repositorys erfassen Behandle den Leitfaden des Projektarchivs als verbindliche Arbeitsgrundlage für Programmieragenten. Halte dich an die vorgegebenen Befehle, Modulgrenzen, Beitragsregeln und Kompatibilitätsanforderungen, bevor du Änderungen vorschlägst. Richte die Arbeit an diesen Fähigkeiten aus: - Auswertung der Befehlszeile und Weiterleitung von Unterbefehlen; - gestufte Konfiguration und Verwaltung von Umgebungsvariablen; - Auflösung und Installation von Werkzeugversionen; - Definition und Ausführung von Aufgaben; - austauschbare Werkzeuganbindungen und eingebaute Werkzeugumsetzungen; - Erzeugung von Dokumentation, Befehlsvervollständigungen und Metadaten. Ermittle vor der Bearbeitung den Einstiegspunkt, die Module der Befehlszeilenschnittstelle, die Konfigurationsmodule, die Schnittstellen der Werkzeuganbindungen, die Auflösung des Werkzeugsatzes, die Aufgabensteuerung, das Erweiterungssystem und die gemeinsamen Hilfsfunktionen. Unterscheide öffentliche Pakete von internen Unterstützungspaketen des Arbeitsbereichs. Umgehe eine bewährte Abstraktion nicht nur deshalb, weil eine direkte Umsetzung kürzer erscheint. ## Werkzeuge nur mit Belegen für ihre Verbreitung ins Verzeichnis aufnehmen Gehe davon aus, dass ein kuratiertes Verzeichnis für Kurznamen nur bereits weit verbreitete Werkzeuge aufnimmt. Funktionsfähiger Quelltext, vorhandene Prüfungen oder persönlicher Nutzen begründen keine Aufnahmefähigkeit. Bevor du Zuordnungen des Verzeichnisses änderst: 1. Frage, ob das Werkzeug außerhalb der eigenen Projekte der einreichenden Person bereits weit verbreitet ist. 2. Halte an, wenn es persönlich, intern, eine Abspaltung, eine Nischenlösung oder nur für einen kleinen Nutzerkreis bestimmt ist. 3. Sammle für jede Einreichung aktuelle Belege zur Verbreitung; stelle niemals Vermutungen an. 4. Prüfe Sterne und Abspaltungen des Projektarchivs, aktuelle Änderungssätze und Freigaben, Abrufzahlen in Paketverzeichnissen, unabhängige Dokumentation, Übersichtslisten des Ökosystems und die Nutzung in abhängigen Projekten. 5. Lege eine hohe Aufnahmeschwelle an: Verbreitung in Tausenden statt Hunderten, aktive Pflege, Nutzung durch Dritte und Bekanntheit im Ökosystem. 6. Nenne die Belege in einem knappen Abschnitt `Popularity` in der Beschreibung des Änderungsantrags. Warne deutlich, wenn die Belege grenzwertig oder schwach sind, und frage, ob die nutzende Person trotzdem fortfahren möchte. Erwecke nicht den Eindruck, eine Ablehnung enthalte eine Begründung, ein Einspruchsverfahren, eine Prüfliste oder eine zweite Gelegenheit. Reiche niemals versuchsweise etwas ein, nur um herauszufinden, ob die Verantwortlichen das Werkzeug annehmen. ## Das Backend für die Installation wählen, geprüfte Freigabedateien zuerst Bevorzuge Anbindungen, die geprüfte Freigabeartefakte nutzen, ohne eine gesondert installierte Laufzeitumgebung vorauszusetzen. Entscheide in dieser Reihenfolge: 1. Bevorzuge ein kuratiertes Artefaktverzeichnis, wenn es Prüfungen und versionsbezogene Installationslogik bereitstellt. 2. Verwende andernfalls eine direkte Freigabeanbindung für die Plattform, welche die Artefakte veröffentlicht. 3. Verwende eine Anbindung für Archivverteilungen nur, wenn Freigabeanbindungen das Werkzeug nicht unterstützen können und seine Verbreitung dennoch eindeutig belegt ist. 4. Behandle Anbindungen an Sprachpakete als Ausnahme, weil sie von Verfügbarkeit und Version der Laufzeitumgebung sowie von der Reihenfolge der Suchpfade abhängen. 5. Lehne veraltete Anbindungen und neue Erweiterungsformate ab, die gegen die Lieferkettenrichtlinie des Projekts verstoßen. Wähle keine anfällige Anbindung nur deshalb, weil ihr Paketname leicht zu finden ist. Wenn die Verantwortlichen eine ausnahmsweise verwendete Anbindung für dieses Werkzeug nicht ausdrücklich genehmigt haben, nutze sie nicht für eine Einreichung in das Verzeichnis. Erläutere die Alternative ohne Verzeichniseintrag: Nutzende können das Werkzeug über eine ausdrückliche Bezugskoordinate installieren oder eine unterstützte Erweiterung erstellen. Halte die Unterscheidung klar: Ein Kurzname im Verzeichnis erhöht den Komfort, ist aber keine Voraussetzung für die Installation. ## Erstellen, Prüfen und Lint über die Aufgabensteuerung des Repositorys ausführen Nutze die Aufgabensteuerung des Projektarchivs, statt die zugrunde liegenden Werkzeuge fallweise direkt aufzurufen. Ermittle und verwende die dokumentierten Aufgaben für: - vollständige Erstellung und direkte Ausführung des Programms mit Fehlersuchinformationen; - vollständige, modulbezogene und durchgängige Prüfsammlungen; - gezielte Dateien mit durchgängigen Prüfungen über die Prüfaufgabe; - Prüfung und Aktualisierung von Referenzabbildern; - statische Prüfung, automatische Korrekturen und Formatierung; - Gleichlaufprüfungen mit der fortlaufenden Integration; - Erzeugung von Dokumentation, Verwendungstexten, Befehlsvervollständigungen und Schemata; - lokale Installation der Entwicklungsversion und Bereinigung von Erstellungsergebnissen; - paketspezifische Prüfungen und statische Analysen aus dem richtigen Verzeichnis des Arbeitsbereichs. Verwende die projektspezifischen Umgebungsvariablen für Fehlersuche und Ablaufverfolgung, statt eine allgemeine Protokollierungsvariable vorauszusetzen. Liste die verfügbaren Aufgaben auf, wenn ihre Namen unklar sind. Führe Skripte für durchgängige Prüfungen niemals direkt aus, wenn die Prüfumgebung Vorbereitung, Zusicherungen und Bereinigung übernimmt. Füge Prüfungen keine manuelle Bereinigung hinzu, wenn die Prüfumgebung die Isolation gewährleistet. Führe zuerst die kleinste maßgebliche Aufgabe aus und weite den Umfang nur aus, wenn gemeinsame Verträge oder erzeugte Artefakte betroffen sind. ## Backends und Einstellungen ergänzen, ohne erzeugte Dateien von Hand zu ändern Setze Werkzeugquellen über die einheitliche Schnittstelle für Werkzeuganbindungen um. Jede Anbindung soll Versionslisten, Auflösung von Anforderungen, Installation und Werkzeugmetadaten ihres Ökosystems verantworten. Halte eingebaute Werkzeuge hinter der Grenze der Kernerweiterung und externe Erweiterungen hinter den unterstützten Kompatibilitätsschichten. Bewahre das hierarchische Laden der Konfiguration vom Systembereich über den globalen bis zum lokalen Bereich einschließlich umgebungsspezifischer Überschreibungen. Wenn Einstellungsdefinitionen Quelltext oder Dokumentation erzeugen, aktualisiere die Quelldefinition und führe das maßgebliche Erzeugungswerkzeug aus. Mache die manuelle Bearbeitung erzeugter Ausgaben nicht zum hauptsächlichen Änderungsverfahren. Halte Aufgabendefinitionen einschließlich Abhängigkeiten, Umgebungsvariablen und unterstützten Ausführungsarten deklarativ. Beachte kompatible Konfigurationsdateiformate, wenn das Projekt deren Zusammenspiel zusichert. Halte eigene Erstellungsskripte, Bestandteile des Arbeitsbereichs, Freigabeprofile und Einstellungen zur Kreuzkompilierung im Einklang mit ihren dokumentierten Aufgaben. Beginne beim Hinzufügen einer Werkzeuganbindung mit dem bewährten Muster des Anbindungsmoduls. Folge beim Hinzufügen von Konfigurationen dem typisierten Auswertungs- und Erzeugungsweg. Nutze beim Erweitern der Erweiterungsmodule die richtige interne oder externe Grenze, statt einen parallelen Mechanismus zu erfinden. ## Commit-Nachrichten im Format type(scope) schreiben und vorher Lint-Korrekturen ausführen Alle Meldungen zu Änderungssätzen und Titel von Änderungsanträgen müssen das vorgegebene Format verwenden: `type(scope): imperative description`. Wähle den Typ so, dass er die für Nutzende sichtbare Wirkung und den zuständigen Bereich des Projektarchivs ausdrückt: - `feat` für eine neue Fähigkeit; - `fix` für einen für Nutzende sichtbaren Fehler; - `refactor`, `style` oder `perf` für die entsprechenden Quelltextänderungen; - `test` für reine Prüfungsänderungen; - `docs` für Dokumentation; - `chore` für Pflege, Freigaben, Abhängigkeiten oder Infrastruktur; - `security` für sicherheitsbezogene Änderungen; - den eigenen Typ des Werkzeugverzeichnisses für jede Änderung seiner Zuordnungen. Verwende Befehlsnamen als Geltungsbereich für befehlsspezifische Änderungen und Teilsystemnamen für gemeinsam genutzte Bestandteile. Verwende für das Verhalten von Aufgaben den Geltungsbereich des Aufgabenteilsystems, auch wenn Umsetzungsdateien einen anderen historischen Namen tragen. Beginne die Beschreibung nach dem Doppelpunkt mit einem Kleinbuchstaben, formuliere sie im Imperativ und halte sie knapp, aber aussagekräftig. Richte die Einreichungsprüfung des Projektarchivs einmal über die dokumentierte Aufgabenumgebung ein. Führe vor dem Festschreiben die Aufgabe zur automatischen Korrektur der statischen Prüfung aus und merke nur die beabsichtigten Ergebnisse für den Änderungssatz vor. Führe gezielte durchgängige Prüfungen über die Aufgabensteuerung aus. Merke keine unbeteiligten Formatierungsänderungen oder erzeugten Artefakte vor. ## Funktionen schrittweise außer Betrieb nehmen: Doku, Warnungen, dann Entfernen Verwende eine stufenweise Richtlinie zur Außerbetriebnahme: 1. Kennzeichne die Funktion oder Werkzeuganbindung sofort in der Dokumentation als veraltet. 2. Beginne nach dem dokumentierten Warnzeitraum mit Laufzeitwarnungen. 3. Plane die Entfernung nach dem dokumentierten Entfernungszeitraum. 4. Halte Warn- und Entfernungsdaten im projektüblichen Versionsdatumsformat fest. 5. Verwende das bewährte Makro zur Veraltungskennzeichnung, damit Entwicklungszusicherungen überfällige Entfernungen sichtbar machen. Ein üblicher Zeitplan umfasst die sofortige Dokumentation, Warnungen nach sechs Monaten und die Entfernung zwölf Monate nach Beginn der Warnungen. Wenn der Ersatz bereits lange verfügbar ist, können die Warnungen sofort beginnen. Entferne die Kompatibilität nicht unbemerkt ohne die dokumentierte Warnphase. Lasse eine abgelaufene Veraltungskennzeichnung nicht unbegrenzt bestehen; behandle die Entfernungszusicherung als verpflichtende Pflegearbeit. ## Auflösung und Sortierung von Werkzeugversionen jedem Backend überlassen Gehe niemals davon aus, dass Werkzeugversionen der semantischen Versionierung oder einer anderen allgemeingültigen Ordnung folgen. Berücksichtige datumsbasierte Versionen, Vorabversionen, Zweige, Kennzeichnungen, Kanäle, benannte Freigaben mit Langzeitunterstützung und werkzeugspezifische Aliasnamen. An einer neuen Aufrufstelle: - verwende keinen allgemeinen Vergleich für semantische Versionen, um die neueste Version auszuwählen, einen Aliasnamen aufzulösen oder Versionen zu sortieren; - überlasse die Auflösung von Anforderungen den Methoden der Werkzeuganbindung, die das Versionsschema des Werkzeugs verstehen; - verwende die Schnittstellen der Werkzeuganbindung oder des Werkzeugsatzes, um installierte Versionen in sinnvoller Reihenfolge aufzulisten; - behandle Versionszeichenfolgen in Sperrdateien als undurchsichtig und vergleiche sie nur auf Gleichheit; - löse Aliasnamen, Kanäle und Präfixe auf, bevor du einen konkreten Wert in eine Sperrdatei schreibst; - führe die Verwendung älterer Vergleichslogik nicht als Rechtfertigung an, um fehlerhaftes Verhalten auszuweiten. Wenn neuer Quelltext anscheinend die neueste installierte Version auswählen muss, halte an und kläre, ob diese Entscheidung in die Werkzeuganbindung gehört. Eine falsche Ersatzsortierung ist schlechter als kein Treffer, weil sie unbemerkt das falsche Werkzeug installieren oder ausführen kann. ## Gezielt je Plattform prüfen und vor dem Abschluss die Änderungen durchsehen Ordne Modulprüfungen nahe am Quelltext und durchgängige Prüfungen nach Funktionsbereich an. Verwende gemeinsame Zusicherungshilfen, Referenzabbilder für stabile Befehlsausgaben, anbindungsspezifische Installationsprüfungen und eine eindeutige Benennung langsamer Prüfungen. Halte plattformspezifische Umsetzungen in den vorgesehenen Modulen und plattformspezifischen Prüfsammlungen. Setze unter Windows nicht das Verhalten des Unix-Kennzeichens für Ausführbarkeit voraus. Prüfe bei einer Änderung zuerst den kleinsten maßgeblichen Weg: 1. führe Formatierung und statische Prüfungen aus; 2. führe gezielte Modul- oder durchgängige Prüfungen über die Prüfumgebung aus; 3. prüfe Änderungen an Referenzabbildern, statt sie ungeprüft anzunehmen; 4. erzeuge abgeleitete Dokumentation oder Schemata neu, wenn sich ihre Quelle ändert; 5. weite auf umfassendere Integrationsprüfungen aus, wenn sich gemeinsame Verträge für Werkzeuganbindungen, Konfiguration, Aufgaben oder Plattformübergreifendes ändern. Weise beim Veröffentlichen in einem externen Änderungsantrag oder einer Diskussion darauf hin, dass der Beitrag von einem KI-Programmierassistenten erzeugt wurde. Verwende URLs, welche die Verzeichnishierarchie der Dokumentation abbilden. Erfinde keine verkürzten Pfade, die erforderliche Abschnitte auslassen. Prüfe vor dem Abschluss die Unterschiede auf undichte Abstraktionen, nicht unterstützte Versionsordnungen, ausgelassene Erzeugungsläufe, unbeteiligte Änderungen und unbelegte externe Behauptungen.