Zuerst die Spezifikation schreiben, dann in kleinen testgeführten Schritten entwickeln

## Unklare Anforderungen als Fragen festhalten und vor der Planung auf Antworten warten Planen oder implementieren Sie nicht, solange eine wesentliche Anforderung unklar ist. Ermitteln Sie vor Änderungsvorschlägen alle offenen Anforderungen, nichtfunktionalen Erwartungen, Verhaltensweisen, Telemetriedaten, Richtlinien und Abnahmekriterien. Tragen Sie jede Klärung mit hoher Auswirkung und jede Unsicherheit mit mittlerer Auswirkung in das dafür vorgesehene Register offener Fragen des Projektbestands ein, bevor Sie um eine Entscheidung bitten. Geben Sie jeder Frage eine beständige Kennung und beschränken Sie die maßgebliche Spezifikation, den Plan und die Aufgabenliste bis zur Klärung auf diese Kennung. Speichern Sie bei der Vorstellung von Alternativen zunächst dieselben Auswahlmöglichkeiten und fassen Sie sie anschließend direkt für den Benutzer zusammen. Stellen Sie die empfohlene Möglichkeit an die erste Stelle, nennen Sie knapp ihre Vor- und Nachteile, verweisen Sie auf die Fragenkennung und halten Sie an, bis die erforderliche Antwort vorliegt. Übernehmen Sie die Antwort danach in die verbindlichen Abschnitte der Spezifikation und schließen Sie den Registereintrag. ## Vor der Planung Spezifikation und Architekturkarte lesen Arbeiten Sie vom Stammverzeichnis des Projektbestands aus und wenden Sie sowohl die für den gesamten Projektbestand geltenden Anweisungen als auch jede einschlägige untergeordnete Regel an. Lesen Sie vor der Planung den aktuellen Entwicklungsfahrplan, die maßgebliche Funktionsspezifikation, die Modul- oder Wissensübersicht, die Programmierkonventionen und die mit der betroffenen Funktion verknüpften Architekturentscheidungen. Erfassen Sie die Module, Verträge und Zuständigkeitsgrenzen, die von der Änderung betroffen sein können. Verwenden Sie die gepflegte Architekturaufnahme des Projektbestands, statt Beziehungen allein aus einer benachbarten Datei abzuleiten, und aktualisieren Sie diese Übersicht, wenn sich Module, Abhängigkeiten oder Verträge ändern. Verwenden Sie genehmigte Vorlagen für Spezifikationen, Pläne, Aufgaben und Architekturentscheidungen, damit Metadaten, Prüfvermerke und Querverweise einheitlich bleiben. ## Erst die Spezifikation, dann Plan und Aufgabenliste aktualisieren Erstellen oder aktualisieren Sie vor der Implementierung die Funktionsspezifikation. Legen Sie Anforderungen, nichtfunktionale Anforderungen, Einzelheiten zum Verhalten oder zur Schnittstelle, Telemetrie und Richtlinien, Abnahmefälle sowie bei Änderungen des sichtbaren Verhaltens eine Schnittstellenskizze fest. Klären Sie alle Fragen mit hoher oder mittlerer Auswirkung, bevor Sie den Umsetzungsplan erstellen. Halten Sie nach der Aktualisierung der Spezifikation architektonisch bedeutsame Ergebnisse in einem Architekturentscheidungsprotokoll fest und bewahren Sie geklärte Punkte in den verbindlichen Abschnitten auf, statt sie in einer gesonderten überholten Klärungsliste zu führen. Aktualisieren Sie erst danach den Plan und die Aufgabenprüfliste. Ordnen Sie die Tests vor der Implementierung an, teilen Sie die Arbeit in logische Schritte, die voraussichtlich innerhalb von 90 Minuten abgeschlossen werden können, und führen Sie die Analyseprüfung des Projektbestands aus, nachdem Spezifikation, Plan und Aufgaben übereinstimmen. Erfinden Sie kein Ausweich- oder Kompatibilitätsverhalten, sofern der Benutzer es nicht ausdrücklich verlangt. ## Die Sitzung aus einem gespeicherten Stand fortsetzen und ihn vor der Übergabe aktualisieren Befolgen Sie zu Beginn einer Sitzung ohne vorausgehenden Kontext die Anleitung des Projektbestands zum Zurücksetzen oder Übergeben. Fassen Sie den Stand des Entwicklungsfahrplans, den Fortschritt des aktiven Plans und offene Fragen zusammen, bevor Sie neue Umsetzungsarbeiten aufnehmen. Pflegen Sie genau eine dafür vorgesehene Momentaufnahme der aktuellen Sitzung als laufenden sitzungsübergreifenden Zustand. Aktualisieren Sie sie vor der Übergabe mit der aktiven Funktion, abgeschlossenen Arbeiten, offenen Fragen, dem Prüfstatus und der nächsten sicheren Handlung. Erstellen Sie keine konkurrierenden Fortschrittsaufzeichnungen. Halten Sie die Zuständigkeit für Funktionen und Module ausdrücklich fest, damit Dokumentation, Automatisierung, Sicherheit, dauerhafte Datenspeicherung und Schnittstellenarbeiten an ihren jeweils maßgeblichen Orten aktualisiert werden. ## Für jedes Verhalten zuerst einen fehlschlagenden Test schreiben Aktualisieren Sie die maßgebliche Spezifikation und den Plan, bevor Sie Code ändern. Schreiben oder erweitern Sie für jedes Verhalten zuerst einen ausführbaren Einheiten-, Verhaltens-, Vertrags- oder Szenariotest und bestätigen Sie, dass er aus dem beabsichtigten Grund fehlschlägt. Führen Sie bei der Planung die Erfolgs-, Prüf- und Fehlerverzweigungen auf und ergänzen Sie für jeden Pfad einen minimalen fehlschlagenden Test. Implementieren Sie nur so viel Code, wie zum Bestehen der Tests erforderlich ist, und strukturieren Sie ihn anschließend um, während alle Tests weiterhin bestehen. Halten Sie nach Abschluss des Zyklus Änderungen der Testabdeckung, Erkenntnisse und Folgearbeiten im Plan oder Entwicklungsfahrplan fest, damit die Begründungen prüfbar bleiben. ## Kleine, abgeschlossene Änderungen machen und Aufgaben sofort abhaken Gestalten Sie jeden Arbeitsschritt eigenständig und befolgen Sie die Konventionen des Projektbestands zu Sprache, Programmierumgebung, Dokumentation und Tests. Bevorzugen Sie eine geradlinige Ablaufsteuerung aus kleinen Hilfsfunktionen zur Prüfung und Normalisierung gegenüber tief verschachtelten Verzweigungen direkt im Code. Halten Sie Entwicklungsfahrplan, Spezifikation, Plan und Aufgabenprüfliste bei Verhaltensänderungen auf demselben Stand. Kennzeichnen Sie jede geprüfte Aufgabe sofort als abgeschlossen, statt Zustandsänderungen zu sammeln, und aktualisieren Sie die Architekturübersicht, sobald sich eine Modulbeziehung oder ein Vertrag ändert. Verwenden Sie Entscheidungsprotokolle nur für bestätigte Architekturentscheidungen. Vermeiden Sie nicht zugehörige Umstrukturierungen, flächendeckende Formatierung und spekulative Kompatibilitätsarbeit und richten Sie die Umsetzung weiter am genehmigten Arbeitsschritt aus. ## Prüfungen für die geänderten Dateitypen ausführen und Fehler untersuchen statt überspringen Führen Sie während der schrittweisen Bearbeitung das jeweils engste geeignete Formatierungswerkzeug, Stilprüfwerkzeug, die statische Analyse, Typprüfung und gezielte Tests aus. Führen Sie vor dem Abschluss alle vom Projektbestand verlangten Prüfungen für die geänderten Dateitypen und jede unmittelbar betroffene Integrationsgrenze aus. Behandeln Sie eine fehlgeschlagene lokale Prüfung oder Prüfung der kontinuierlichen Integration als zu untersuchenden Fehler, nicht als zu umgehende Schranke. Wenn die Richtlinie des Projektbestands ausdrücklich eine vorübergehende Testausnahme erlaubt, deaktivieren Sie nur den betroffenen Test, fügen Sie ein eindeutiges `TODO` mit Begründung hinzu und halten Sie die Folgearbeit im maßgeblichen Plan fest. Ergänzen oder aktualisieren Sie Tests für jedes geänderte Verhalten. Prüfen Sie den abschließenden Änderungsvergleich, bestätigen Sie, dass Dokumentation und Testabdeckung zur Implementierung passen, und erklären Sie den Arbeitsschritt nicht für abgeschlossen, solange vorgeschriebene Prüfungen fehlschlagen. ## Vor neuen Abhängigkeiten oder riskanten Git-Schritten eine Freigabe einholen Nehmen Sie nur Dateien in den Git-Index auf, die zum Arbeitsschritt gehören. Verwenden Sie keine pauschale Aufnahme, wenn erzeugte Ausgaben, Datenbankartefakte oder parallele Arbeiten vorhanden sein könnten. Bereiten Sie eine Beschreibung für einen atomaren Git-Commit nach den vereinbarten Konventionen vor und nennen Sie bei gemeinsamen Änderungen an Dokumentation und Code auch die Auswirkungen auf die Spezifikation. Lassen Sie den Commit jedoch von der dafür bestimmten Person ausführen, sofern die Ausführung nicht ausdrücklich übertragen wurde. Holen Sie vor dem Hinzufügen oder Aktualisieren von Abhängigkeiten, dem Löschen genau benannter Dateien oder Verzeichnisse, dem Umschreiben des Verlaufs, dem Übertragen von Änderungen oder dem Erstellen einer externen Begutachtung eine ausdrückliche Genehmigung ein. Halten Sie die Begründung für eine genehmigte Abhängigkeit im Funktionsplan fest und geben Sie verwalteten Auslösern und Qualitätsabläufen genügend Zeit. Übernehmen Sie niemals Geheimnisse in einen Commit und verwenden Sie zerstörerische Bereinigungen nicht als Abkürzung. Legen Sie unerwartete versionierte oder unversionierte Dateien zur Prüfung vor und lassen Sie nicht zugehörige Arbeiten unangetastet. ## Ohne Auftrag keine Kompatibilitätswege einbauen und riskante Änderungen vorher vorschlagen Befolgen Sie die erklärte Kompatibilitätshaltung des Projektbestands. Wenn Schnittstellen als Neuentwicklung behandelt werden, fügen Sie keine Ausweichlösungen, Anpassungsschichten oder Prüfungen für Altbestände hinzu, sofern der Benutzer sie nicht ausdrücklich für die aktuelle Aufgabe verlangt. Halten Sie Zusammenfassungen der Eingaben, wesentliche Befehlsfolgen und Begründungen im aktiven Plan oder einem verknüpften Anhang fest. Schlagen Sie riskante Umstrukturierungen, Änderungen der dauerhaften Datenspeicherung, Änderungen der Sicherheitsstrategie und wichtige nichtfunktionale Abwägungen vor der Bearbeitung vor und tragen Sie anschließend genehmigte Architekturentscheidungen in das richtige Entscheidungsprotokoll ein. Verfolgen Sie künftige Vertragstests, Mutationsanalysen und Sicherheitsübungen in den Plänen, bis automatisierte Prüfungen bestehen. Bewahren Sie Betriebshinweise nahe ihrem maßgeblichen Arbeitsablauf auf und vermeiden Sie, veränderliche Anweisungen in mehreren Dokumenten zu wiederholen. ## Tests nur gegen die Testdatenbank ausführen und vor einem Reset das Ziel prüfen Führen Sie niemals einen Befehl zum Zurücksetzen, vollständigen Leeren oder erstmaligen Migrieren einer Datenbank über eine ungeprüfte Verbindung aus. Bestätigen Sie vor jeder Migration oder jedem Zurücksetzen die aktive Umgebung, das Verbindungsziel und ob der Vorgang auf eine entbehrliche Testdatenbank beschränkt ist. Führen Sie Anwendungstests gegen die isolierte Testdatenbank des Projektbestands aus und nutzen Sie deren dokumentierte Transaktions- oder Migrationseinrichtung. Setzen Sie nur die ausdrücklich benannte Testdatenbank zurück, wenn dies erforderlich ist. Gehen Sie nicht davon aus, dass ein Testbefehl und ein interaktiver Anwendungsbefehl dieselbe Verbindung verwenden. Erstellen Sie neue Migrationen als Dateien und erproben Sie sie über den Testablauf. Wenn der Datenbankumfang unklar ist, halten Sie an und holen Sie eine Bestätigung ein, statt Entwicklungs- oder Produktionsdaten zu gefährden. ## Jeden Schritt mit einer Übergabe zu Änderungen und Prüfergebnissen abschließen Nachdem ein eigenständiger Arbeitsschritt seine einschlägigen Prüfungen bestanden hat, bestätigen Sie, dass abgeschlossene Aufgaben, der Stand des Entwicklungsfahrplans, Spezifikationsänderungen, Entscheidungsprotokolle und die Momentaufnahme der aktuellen Sitzung übereinstimmen. Erstellen Sie eine knappe Übergabe mit den geänderten Dateien, den ausgeführten Prüfungen und ihren Ergebnissen, offenen Hindernissen, Folgearbeiten und allen direkt kopierbaren Befehlen für die zuständige Person. Unterscheiden Sie umgesetzte Arbeiten von lediglich geplanten oder noch nicht genehmigten Arbeiten. Bereiten Sie den Git-Commit für die Funktion nach der Prüfung zügig vor, führen Sie ihn aber nur im Rahmen der Richtlinie zur Aufgabenübertragung des Projektbestands aus. Bewahren Sie genügend Belege auf, damit die nächste Sitzung ohne erneute Erkundung fortfahren kann.