Was macht Persönliche Projekte?
Diese Regeln sind verbindlich in Projekten, die explizit personal@tj-agents übernehmen. Die Übernahme dokumentiert den persönlichen Rahmen des Projekts; ein Home-Verzeichnis, Autorenname oder eine Arbeitgeber-Zugehörigkeit begründen diesen niemals. Arbeitgeber-Projekte bleiben außerhalb dieses Profils, es sei denn, Tommy ändert diesen Rahmen explizit.
Behalte eine aktuell unterstützte Lösung. Wenn du Verhalten ersetzt, entferne die abgelösten Namen, Aliase, Fallback-Implementierungen, Adapter, Konfigurationsformate und Kompatibilitätszweige. Koordiniere und migriere alle bekannten Aufrufer, Projekterklärungen, installierten Registrierungen, generierten Artefakte und Live-Laufzeiteinstiegspunkte im selben Umstellungszeitraum. Behalte kein veraltetes Verhalten für hypothetische externe Benutzer zurück; stimme Upgrades mit den tatsächlich zusammenarbeitenden Entwicklern ab.
Überprüfe die Einstiegspunkte, die Personen tatsächlich nutzen, auf jeder unterstützten Plattform, einschließlich Windows- und Linux-Startpfaden, sofern unterstützt. Quellcode-Änderungen, erfolgreiche Generierung, bestandene Unit-Tests und Versionsbefehle allein beweisen nicht, dass eine Migration abgeschlossen ist. Prüfe installierte Bindungen und frisches Laufzeitverhalten. Zeichne jeden nicht verifizierten Einstiegspunkt als unvollständig auf, samt seinem Auflöser und beobachtbaren Akzeptanzkriterium.
Beispiel: Das Ersetzen von old-launch durch launch bedeutet, den registrierten Shell-Befehl, die Projektkonfiguration und die tatsächlichen Aufrufer zu migrieren, den alten Eintrag zu löschen, und dann launch in einer frischen Sitzung auf jedem unterstützten Betriebssystem aufzurufen. Die Ausführung von launch --version allein lässt die Umstellung unverifiziert.
Ersetze old-launch durch launch:
1. Migriere den registrierten Shell-Befehl, die Konfiguration und die tatsächlichen Aufrufer.
2. Lösche den alten Eintrag und generiere die installierten Einstellungen neu.
3. Rufe launch in einer frischen unterstützten Windows/Linux-Sitzung auf und prüfe das tatsächliche Verhalten.
Ergebnis: launch --version allein lässt diese Migration unvollständig.
Füge keine eigenständige Rückwärtskompatibilitäts-Ausnahme hinzu. Mache eine explizite entgegenstehende Benutzeranforderung als bewusste Richtungsentscheidung sichtbar, identifiziere das betroffene unterstützte Verhalten und kläre den Umfang dieses Profils, bevor du sie implementierst. Verbirg niemals eine Ausnahme in einem Fallback oder Adapter.
Löse das aufgezeigte Problem mit der kleinsten geeigneten Implementierung. Füge Abstraktionen, Abhängigkeiten, Konfigurationsschalter, doppelte Pfade oder Prozessmechanismen nur für einen konkreten aktuellen Bedarf hinzu. Bevorzuge die Fähigkeiten, die das Projekt bereits auswählt. Verifiziere das Verhalten und aussagekräftige Fehlerpfade im Verhältnis zur Änderung; füge keine Tests hinzu, die lediglich die Implementierung wiederholen oder eine Checkliste ohne konkreten Nutzen darstellen.
Diese Richtlinie ist hier einmal verfasst. Die persönliche Übernahme erzeugt den markierten nativen Anweisungsblock aus diesem Textkörper und prüft ihn auf Abweichungen. Ein ausgewähltes Plugin oder eine always-Stufe allein ist kein Nachweis der Ladung.