Eine Webentwicklungs-CLI aus JavaScript und nativem Code in der zuständigen Ebene ändern

## Die für ein CLI-Verhalten zuständige Ebene finden und den globalen wie den lokalen Weg verfolgen Ordne die Anforderung vor der Bearbeitung der Komponente zu, die das Verhalten besitzt: - JavaScript- oder TypeScript-Einstiegspunkte besitzen das übergeordnete Verhalten der lokalen CLI und die Paketexporte. - Native Crates besitzen die eigenständige globale Binärdatei, die Laufzeitinitialisierung, die Einbindung der Paketverwaltung, Installationsprogramme, Migrationen und gemeinsam genutzte Prozesshilfen. - Die native Bindung besitzt die Brücke zwischen der lokalen JavaScript-CLI und nativen Befehlsimplementierungen. - Kernpakete stellen gebündelte Oberflächen für Build, Tests, Dokumentation und Paketierung bereit. - Repositoriumswerkzeuge besitzen lokale Register, Build-Hilfen, Testdaten und Veröffentlichungsunterstützung. - Dokumentation und erzeugte Projektanleitungen sind getrennte Produkte mit unterschiedlichen Quellen. Verfolge globale und lokale Befehlswege getrennt, wenn beide denselben Benutzerbefehl umsetzen können. Eine Korrektur in nur einem Weg ist unvollständig, solange der andere widersprüchlich bleibt. Bearbeite keine erzeugten Projektanleitungen, wenn die Aufgabe nur die Hinweise für Mitwirkende des Repositoriums betrifft. Bevorzuge maßgebliche Architektur- und Konfigurationsdokumente gegenüber kopierten Erklärungen. ## Eingebaute Befehle und Aufgaben des Task-Runners getrennt halten Unterscheide eingebaute Werkzeugkettenbefehle von der Aufgabensteuerung. Ein eingebauter Test-, Build-, Prüf- oder Formatierungsbefehl kann eine mitgelieferte Implementierung aufrufen, während ein Ausführungsbefehl ein Paketskript oder eine konfigurierte Aufgabe gleichen Namens startet. Behandle Paketskripte als vollwertige Ausführungsziele. Verwende eine ausdrückliche Aufgabenkonfiguration nur, wenn eine Aufgabe Abhängigkeiten, Zwischenspeicherung, Befehlseinstellungen, Eingabeverfolgung oder Umgebungsverfolgung benötigt. Ein Aufgabenname darf nur einen Besitzer haben. Definiere denselben Namen nicht sowohl in Paketskripten als auch in der Werkzeugkonfiguration. Bewahre die Aufgabenkonfiguration in der aktuellen maßgeblichen Konfigurationsdatei auf und führe außer Betrieb genommene eigenständige Konfigurationsformate nicht wieder ein. Halte öffentliche Testimporte auf der unterstützten Paketoberfläche und erzeuge Kompatibilitätsadapter mit dem zuständigen Build-Skript. Erstelle entfernte Pakete nicht neu und behandle externe Abhängigkeiten nicht als Mitglieder des lokalen Arbeitsbereichs. Prüfe vor einer Änderung der Weiterleitung die Befehlshilfe, die Versionen mitgelieferter Werkzeuge, Paketexporte und die nächstgelegene Aufgabendokumentation. ## Die kleinsten Tests wählen, die zur Art der Änderung passen Nutze die kleinste Prüfmenge, die das geänderte Verhalten abdeckt: - Dokumentation oder Agentenanleitung: Prüfe referenzierte Pfade, Befehle, Verweise und Leerraum. - Verhalten der JavaScript-CLI: Führe die Repositoriumsprüfung, Komponententests und gezielte Pakettests aus. - Verhalten der nativen CLI oder eines Crates: Führe native Prüfungen, Tests und statische Analysen aus. - Befehlsdarstellung oder Interaktionsgestaltung: Führe gezielte Pseudoterminal-Momentaufnahmetests aus und prüfe die Differenz. - Verhalten der globalen CLI: Erstelle und installiere die lokale globale Binärdatei neu und prüfe anschließend Version und betroffene Befehle. - Veröffentlichungs- oder Paketierungsverhalten: Führe den Veröffentlichungs-Build aus. - Integration vor dem Zusammenführen: Initialisiere die CLI, führe alle Tests aus und prüfe den Repositoriumsstatus. Verwende den Korrekturmodus nur, wenn Änderungen durch Formatierung oder statische Prüfung ausdrücklich zum Umfang gehören. Suche bei Verhaltensänderungen vor der Bearbeitung den nächstgelegenen vorhandenen Test und ergänze die Abdeckung im selben Bereich. Führe bei reinen Dokumentationsänderungen keine breiten, sachfremden Testsammlungen aus. Behaupte bei beteiligter Weiterleitung mitgelieferter Werkzeuge auch nicht allein anhand von Komponententests, dass die CLI-Weiterleitung korrekt ist. ## Pseudoterminal-Snapshot-Tests hinzufügen, die unter Unix und Windows laufen Lege neue Befehlszeilenfälle und interaktive Abläufe im Pseudoterminal-Momentaufnahmetestgerüst des Repositoriums ab. Definiere jeden Fall mit einer ausdrücklichen Argumentliste statt mit einer Shell-Zeichenkette. Verwende Hilfsbefehle des Testgerüsts statt plattformspezifischer Systemwerkzeuge, damit dieselben Testdaten unter Unix und Windows gleich funktionieren. Gib an, ob ein Fall die lokale CLI, die globale CLI oder beide betrifft; lokale Fälle benötigen eine frisch erstellte lokale Distribution. Abweichende Momentaufnahmen müssen mit einer prüfbaren Differenz fehlschlagen und eine Kandidatendatei erzeugen. Aktualisiere Momentaufnahmen ausschließlich im ausdrücklichen Aufzeichnungsmodus und prüfe das aufgezeichnete Ergebnis wie Code, bevor du es committest. Teste bei Änderungen der Befehlserfahrung sowohl das konkrete Verhalten als auch dessen Mitschrift. Stelle bei Installations- oder Migrationsverhalten den verpackten Checkout über die lokale Registerschnittstelle des Repositoriums bereit, statt das tatsächliche Verhalten der Paketverwaltung zu umgehen. Halte interaktive Meilensteine und Tastenschritte ausdrücklich fest, damit ein Fehlschlag die abweichende Phase erkennen lässt. ## Lint-Regeln jeder Sprache befolgen und erzeugte Dateien nur über ihren Generator ändern Befolge bei nativem Code die Einschränkungen der statischen Analyse, gemeinsam genutzte Ausgabefunktionen, Umgebungskonfiguration, Pfadbehandlung und den Stil benachbarter Befehle. Verwende bei TypeScript den maßgeblichen Compiler, Terminalausgabefunktionen und die Aufgabenkonfiguration des Repositoriums. Dupliziere keine Sprachregeln in Mitwirkendenanleitungen, wenn Analysewerkzeug, Compilereinstellung oder Quellreferenz maßgeblich sind. Behandle erzeugte Bindungen, Adapter, Agentendateien, Distributionen und Momentaufnahmeausgaben als Artefakte mit klarer Zuständigkeit. Ändere sie nur über ihren Generator oder den ausdrücklichen Freigabeablauf für Momentaufnahmen. Begrenze die Differenz auf die angeforderte Zuständigkeitsebene und lasse sachfremde versionierte oder nicht versionierte Dateien unberührt. Ändert sich eine erzeugte Datei unerwartet, untersuche Quelle oder Generator, statt das abgeleitete Ergebnis zu patchen. Nutze bei der Prüfung einer installierten globalen CLI den dokumentierten Initialisierungspfad und bestätige die aufgelöste Version. Schließe nicht daraus, dass ein Paket-Build auch die installierte Binärdatei aktualisiert hat. ## Fehler suchen, indem man den globalen nativen mit dem lokalen JavaScript-Weg vergleicht Erfasse zuerst die Versionen der mitgelieferten Komponenten und prüfe die allgemeine sowie die befehlsspezifische Hilfe. Vergleiche bei Weiterleitungsfehlern den globalen nativen Pfad mit dem lokalen JavaScript- und Bindungspfad. Vergleiche bei Konfigurationsfehlern die statische Extraktion mit der JavaScript-Ersatzauflösung. Prüfe bei Fehlern der Paketverwaltung sowohl Befehlsoberfläche als auch Installationsebene und die zugehörigen Terminalmomentaufnahmen. Prüfe bei Fehlern in Kontrolle, statischer Analyse, Formatierung, Typprüfung oder Tests den Ende-zu-Ende-Befehl. Die Weiterleitung mitgelieferter Werkzeuge kann einzelne Pakettests bestehen lassen, während die Benutzerkonfiguration unbemerkt ignoriert wird. Wenn ein Fehler von der lokalen oder globalen Variante abhängt, reproduziere beide ausdrücklich. Wenn er von erzeugten Ausgaben abhängt, erstelle das genaue abgeleitete Ergebnis neu, bevor du die Quellkorrektur als wirkungslos bewertest. Nutze Navigationshinweise, um maßgebliche Dateien zu finden. Eine knappe Agentenanleitung darf ausführliche Architektur-, Migrations-, Aufgaben- oder Momentaufnahmedokumentation nicht ersetzen.