xxxx2l/design-to-implement

Workflow für Lösungsdesign und Implementierung

Kernkonzept

Erst klar diskutieren, dann Code schreiben. Dieser Workflow erzwingt eine strikte Trennung von "Denken" und "Handeln":

• Diskussionsphase: Nur Dialog, kein Code. Alle Schlussfolgerungen werden im Kommunikationsdokument festgehalten.
• Designphase: Konsens wird in einem Designdokument zusammengefasst – der einzigen Quelle der Wahrheit.
• Implementierungsphase: Basierend auf dem Designdokument wird ein Implementierungsdokument erstellt und Schritt für Schritt umgesetzt.

Solange die Diskussion nicht abgeschlossen ist oder der Benutzer nicht explizit "wir können mit der Umsetzung beginnen" sagt, wird kein Code angefasst. Bei Fragen wird so lange diskutiert, bis beide Seiten zufrieden sind.

Dokumentenverzeichnisstruktur

Fest im Projektstammverzeichnis unter docs/design/ abgelegt, jede Aufgabe in einem eigenen Unterordner:

Projektstamm/
└── docs/design/
    ├── README.md              ← Globale Aufgabenübersicht (Einstiegspunkt, zuerst lesen)
    ├── 01-Benutzerauthentifizierungsmodul/
    │   ├── 00-Aufgabenstatus.md      ← Kontextübergreifender Gedächtnisanker
    │   ├── 01-Kommunikation.md
    │   ├── 02-Design.md              ← Enthält Abnahmekriterien
    │   ├── 03-Implementierung.md
    │   └── 04-Tests.md               ← Testfälle (wird in der Implementierungsplanungsphase erstellt)
    └── 02-Zahlungsrefactoring/
        └── ...

Namensregeln:

• Aufgabenordner: Global inkrementelle zweistellige Nummer + Aufgabenname, z.B. 01-Benutzerauthentifizierungsmodul, 02-Zahlungsrefactoring. Die Nummern sind aufgabenübergreifend fortlaufend, um eine konsistente Sortierung nach Erstellungsreihenfolge zu gewährleisten.
• Dokumente innerhalb einer Aufgabe: Feste Phasennummer-Präfixe: 00-Aufgabenstatus / 01-Kommunikation / 02-Design / 03-Implementierung / 04-Tests. Dieses feste Präfix ermöglicht es Ihnen, in jeder Aufgabe sofort denselben Dokumenttyp zu identifizieren.

So bestimmen Sie die Nummer beim ersten Aufruf einer Aufgabe: Überprüfen Sie die höchste Nummer der vorhandenen Ordner unter docs/design/ und addieren Sie 1 für die neue Aufgabe. Wenn das Verzeichnis nicht existiert, beginnen Sie mit 01.

Erster Schritt in jedem neuen Dialog (Kontextübergreifender Gedächtnismechanismus)

Dieser Workflow kann sich über mehrere Dialogkontexte erstrecken. Um zu vermeiden, dass in jedem neuen Dialog umfangreicher Code gelesen oder der Verlust von Erinnerungen riskiert wird, wird die folgende Reihenfolge zur Wiederherstellung des Kontexts erzwungen:

1. Lesen Sie docs/design/README.md – die globale Aufgabenübersicht, um zu sehen, welche Aufgaben existieren und in welcher Phase sie sich befinden. Wenn der Benutzer eine bestimmte Aufgabe genannt hat, springen Sie direkt zu dieser Aufgabe.
2. Lesen Sie 00-Aufgabenstatus.md – den Gedächtnisanker der aktuellen Aufgabe, um zu bestätigen, was als Nächstes zu tun ist.
3. Lesen Sie das Dokument zur aktuellen Phase (in der Design-Phase lesen Sie 02-Design.md, in der Implementierungsphase 03-Implementierung.md).
4. Lesen Sie nur dann Code, wenn eine Überprüfung erforderlich ist, nicht als erste Maßnahme zur Kontextwiederherstellung.

00-Aufgabenstatus.md muss enthalten: Kurzbeschreibung der Aufgabe, aktuelle Phase, Zusammenfassung wichtiger Entscheidungen, offene Punkte und Fragen, Dokumentenindex, Kontextwechselprotokoll, Änderungshistorie (einschließlich Änderungen und Rücknahmen, siehe unten "Änderungen in der Implementierungsphase").

Die vier Phasen des Workflows und ihre Dokumente

Phase 1: Diskussion (Ausgabe → Kommunikationsdokument)

Auslöser: Der Benutzer stellt eine neue Anforderung, eine neue Funktion, ein neues Modul vor oder möchte eine bestehende Lösung diskutieren.

Verhaltensregeln:

• In dieser Phase wird nur diskutiert, es wird kein Geschäftslogik-Code geschrieben.
• Jeder bedeutungsvolle Austausch (wichtige Entscheidungspunkte, abgelehnte Alternativen, erreichter Konsens) wird im 01-Kommunikation.md dokumentiert.
• Verfolgung offener Fragen: Pflegen Sie oben in 01-Kommunikation.md eine Liste der "aktuell offenen Fragen". Aktualisieren Sie diese Liste vor dem Ende jeder Diskussion – welche Fragezeichen sind noch offen, welche sind neu aufgetaucht, welche wurden abgeschlossen. Das direkte Kriterium für den Übergang zur Design-Phase ist: Ist diese Liste leer? Dies visualisiert den Fortschritt der Diskussion, anstatt nur zu glauben, "wir haben genug diskutiert".
• Die Diskussion kann mehrere Runden umfassen und sich über mehrere Dialoge erstrecken.
• Wenn der Benutzer sagt "es reicht", "lassen Sie es uns so festlegen", "beginnen Sie mit dem Design" und die Liste der offenen Fragen leer ist, gehen Sie zu Phase 2 über.

Wann Sie die Diskussion fortsetzen statt voranzutreiben: Solange es noch ungeklärte Designfragen, Meinungsverschiedenheiten bei der Technologieauswahl oder unklare Grenzen gibt, bleiben Sie in Phase 1 und sammeln Sie mehr. Fragen Sie lieber eine Runde zu viel, als mit unbelegten Annahmen in das Design zu gehen.

Phase 2: Design (Ausgabe → Designdokument)

Auslöser: Die Diskussion hat einen Konsens erzielt, die Liste der offenen Fragen ist leer, der Benutzer stimmt zu, die Lösung zu fixieren.

Verhaltensregeln:

• Fassen Sie die Schlussfolgerungen aus der Kommunikation in einem strukturierten 02-Design.md zusammen. Das Designdokument ist die einzige Quelle der Wahrheit.
• Das Designdokument muss so vollständig wie möglich sein: Die ausgelieferte Lösung ist bestimmt und umsetzbar, es bleiben keine "offenen" Punkte oder "später in der Implementierung zu klären". Vollständigkeit wird durch zwei Dinge sichergestellt – erstens durch gründliche Diskussion, um alle Fragen zu klären, und zweitens durch Lesen des vorhandenen Codes, um alle Fakten zu bestätigen, die von der bestehenden Implementierung abhängen (Schnittstellenform, Tabellenstruktur, Aufrufmethoden usw.). Die Einschränkung "in der Designphase nur diskutieren, keinen Code schreiben" bezieht sich auf Geschäftslogik-Code; das Lesen von vorhandenem Code für das Design und die Bestätigung des Ist-Zustands gehört zur Designrecherche und verstößt nicht gegen die Einschränkung. Nehmen Sie sich in der Designphase lieber mehr Zeit für gründliche Überarbeitung, als mit Lücken in die Implementierung zu gehen – jede Lücke wird in der Implementierungsphase zu Nacharbeit oder Abweichung.
• Abnahmekriterien sind Teil des Designs: Das Designdokument enthält nicht nur "Was wird gemacht, warum", sondern auch "Bis zu welchem Grad ist die Anforderung erfüllt" – d.h. abstrakte Abnahmekriterien (auf Regel-Ebene, z.B. "Hochrisikowörter müssen blockiert werden, der Artikel wird nicht gespeichert"). Die Abnahmekriterien definieren die Grenzen der Anforderung und sind das letzte Glied für die Vollständigkeit des Designs; ohne Abnahmekriterien im Designdokument gibt es keine objektive Definition von "fertig". Die spezifischen Testfälle (auf Instanz-Ebene) werden nicht im Designdokument, sondern in 04-Tests.md geschrieben, wo die Implementierungsplanungsphase die Abnahmekriterien in Testfälle übersetzt.
• Designänderungshistorie: Pflegen Sie im Designdokument einen Abschnitt "Designänderungshistorie". Notieren Sie jede wichtige Änderung als eine Zeile (Zeitpunkt, was geändert wurde, warum). Dies ergänzt 01-Kommunikation.md – die Kommunikation ist ein fortlaufendes Protokoll, das Designdokument enthält die Schlussfolgerungen, und die Änderungshistorie ist die Entwicklungsgeschichte der Schlussfolgerungen. Dies macht die eiserne Regel "Lösungsänderungen aktualisieren das Designdokument, nicht das Implementierungsdokument" durchführbar, ohne die Historie zu verlieren.
• Nach Fertigstellung des Designdokuments aktualisieren Sie 00-Aufgabenstatus.md mit dem Vermerk "Design abgeschlossen, wartet auf Implementierung" und aktualisieren Sie gleichzeitig die Aufgabenphase in docs/design/README.md.

Phase 3: Implementierungsplanung (Ausgabe → Implementierungsdokument)

Auslöser: Das Designdokument ist finalisiert.

Verhaltensregeln:

• Erstellen Sie basierend auf dem Designdokument 03-Implementierung.md und zerlegen Sie die Lösung in ausführbare, abhakbare Schritte.
• Übersetzen Sie gleichzeitig die "Abnahmekriterien" des Designdokuments in konkrete Testfälle und erstellen Sie 04-Tests.md: Testfälle sind die Instanziierung der Abnahmekriterien (z.B. Abnahmekriterium "Hochrisikowörter müssen blockiert werden" → Testfall "Bei Eingabe von Text mit Hochrisikowörtern, erwartet Rückgabe 40901, Artikel wird nicht gespeichert"). Die Testfälle sind in vier Ebenen unterteilt: Funktion (T-F), Ausnahme (T-EX), Regression (T-R), Schnittstelle (T-API). Das Nummerierungsformat ist T-{Typ}-{zweistellige Nummer}, die Vorlage finden Sie in assets/test.md.
• Das Implementierungsdokument beschreibt "wie es gemacht wird", das Testdokument beschreibt "was getestet wird, was erwartet wird", und das Designdokument beschreibt "was gemacht wird, warum". Die drei haben unterschiedliche Verantwortlichkeiten. Kopieren Sie keine Designdetails in das Implementierungsdokument und fügen Sie keine Lösungsänderungen in das Implementierungsdokument ein.
• Das Implementierungsdokument ist eine reine Schritt-für-Schritt-Aufteilung. Jeder Schritt ist nur die "Umsetzung eines Teils des Designdokuments" und hat keine Verantwortung, das Design zu vervollständigen. Wenn Sie beim Aufteilen der Schritte feststellen, dass ein Schritt zuerst "die Schnittstellenform bestätigen", "das Design nachbessern" oder "Felder entscheiden" muss, bedeutet dies, dass die Designphase nicht abgeschlossen ist – in diesem Fall kehren Sie zu Phase 2 zurück, um das Design zu vervollständigen, anstatt einen Schritt zum "Nachbessern des Designs" in das Implementierungsdokument aufzunehmen. Kurz gesagt: Im Implementierungsdokument sollte es keine Aktionen vom Typ "Code lesen, um die Lösung zu bestimmen" geben, sondern nur Aktionen vom Typ "nach der festgelegten Lösung implementieren".
• Testaktionen im Implementierungsdokument referenzieren nur die Testfall-IDs, sie wiederholen nicht den Inhalt der Testfälle. Nach Abschluss eines Schrittes schreiben Sie "Überprüfen mit Testfall T-XX-XX", die Testfälle selbst sind in 04-Tests.md zentralisiert.
• Die Implementierungsschritte sind in große Schritte und kleine Schritte unterteilt, beide müssen unabhängige Abschlussmarkierungen haben.
• Nach Fertigstellung des Implementierungsdokuments aktualisieren Sie 00-Aufgabenstatus.md mit dem Vermerk "wartet auf Implementierung".

Phase 4: Implementierung (Ausführung der Schritte des Implementierungsdokuments)

Auslöser: Der Benutzer sagt "mit der Implementierung beginnen", "legen Sie los", "folgen Sie dem Dokument".

Verhaltensregeln:

• Folgen Sie strikt den Schritten in 03-Implementierung.md. Nach Abschluss jedes Schrittes aktualisieren Sie die Markierung im Dokument und notieren kurz das Ergebnis.
• Nach Abschluss jedes Schrittes überprüfen Sie mit den in 04-Tests.md referenzierten Testfällen für diesen Schritt; wenn ein Testfall fehlschlägt, gilt der Schritt nicht als abgeschlossen. Lokalisieren Sie das Problem (ist es ein Implementierungs-Bug oder ein Problem mit dem Design/den Testfällen – letzteres löst den Änderungs-/Rücknahmemechanismus aus). Nach Abschluss aller Schritte führen Sie die Regressionstests (T-R) aus.
• Wenn Sie auf eine Situation stoßen, die nicht mit dem Designdokument übereinstimmt, halten Sie an: Aktualisieren Sie zuerst 02-Design.md (einschließlich der Änderungshistorie), dann überarbeiten Sie synchron 03-Implementierung.md und 04-Tests.md (Testfälle folgen der Lösungsänderung), und fahren Sie dann fort. Weichen Sie niemals während der Implementierung stillschweigend vom Plan ab.
• Während der Implementierung entdeckte Designlücken, neue Einschränkungen oder API-Änderungen werden alle zurück in den Abschnitt "Designänderungshistorie" in 02-Design.md geschrieben, um das Designdokument auf dem neuesten Stand zu halten.
• Bei jedem Phasenwechsel und jedem wichtigen Meilenstein aktualisieren Sie 00-Aufgabenstatus.md und docs/design/README.md.

Änderungen in der Implementierungsphase: Änderungsmechanismus vs. Rücknahmemechanismus

Der Workflow heißt nominell Diskussion → Design → Implementierungsplanung → Implementierung, aber Abweichungen zwischen der Lösung und den Anforderungen/der Realität während der Implementierung sind erwartete Normalität, keine Ausnahme – selbst das vollständigste Design kann nicht 100% der Implementierungsdetails vorhersehen.

Es gibt zwei Arten von Abweichungen, die sich grundlegend unterscheiden und streng getrennt mit ihren eigenen Prozessen behandelt werden müssen:

	Änderung	Rücknahme
Wesen	Lösung im Großen und Ganzen richtig, es gibt Lücken/Fehler, die ergänzt werden müssen	Dieser Teil der Lösung ist grundlegend falsch und muss komplett neu gemacht werden
Hauptlösung	Wird beibehalten	Wird verworfen
Bereits erstellte Artefakte	Werden nicht ungültig	Teilweise ungültig
Häufigkeit	Normal	Selten
Typisches Szenario	Fehlendes Feld, fehlender Zweig, fehlender Dictionary-Wert, fehlender neuer Anforderungspunkt	Falsche Richtung, Kernannahme nicht haltbar, nicht mit der tatsächlichen Geschäftslogik vereinbar

Stellen Sie zuerst fest, zu welcher Kategorie die Abweichung gehört (die Verantwortung für die Feststellung ist in den jeweiligen Mechanismusbeschreibungen angegeben) und folgen Sie dann dem entsprechenden Prozess. Wenn Sie sich bei der Feststellung unsicher sind, neigen Sie dazu, sie zunächst als "Änderung" zu behandeln und mit dem Benutzer zu bestätigen; nur wenn es sich eindeutig um einen grundlegenden Fehler handelt, gehen Sie den Weg der "Rücknahme".

Änderungsmechanismus (Normal, Leichtgewichtig, Inkrementell)

Drei Bedingungen für die Feststellung (alle müssen erfüllt sein, um als Änderung zu gelten):

• Die Richtung der Hauptlösung ist in Ordnung
• Es müssen keine bereits erstellten Artefakte ungültig gemacht werden
• Es handelt sich nur um eine Ergänzung/Feinabstimmung (Feld ergänzen, Zweig ergänzen, Dictionary-Wert ergänzen, einen vergessenen neuen Anforderungspunkt ergänzen usw.)

Bearbeitungsablauf (strenge Reihenfolge, nicht umkehrbar):

1. Stoppen Sie die aktuelle Implementierung
2. Aktualisieren Sie zuerst das Designdokument: Fügen Sie den Inhalt im entsprechenden Abschnitt des Designdokuments hinzu und fügen Sie eine Zeile in der Designänderungshistorie hinzu
3. Warten Sie auf die Bestätigung des Benutzers für diese Änderung (Sie dürfen nicht selbstständig entscheiden und umsetzen)
4. Nach Bestätigung durch den Benutzer überarbeiten Sie synchron das Implementierungsdokument
5. Fahren Sie dann mit der Implementierung fort

Schlüsselprinzip: Zuerst das Design aktualisieren, dann implementieren – die Reihenfolge ist nicht umkehrbar. Es ist verboten, "erst zu implementieren und dann das Designdokument nachzutragen", da dies das Designdokument von einer Quelle der Wahrheit zu einem nachträglichen Protokoll degradieren würde. Selbst wenn nur ein Feld hinzugefügt wird, muss dieser Ablauf durchlaufen werden.

Rücknahmemechanismus (Selten, Schwergewichtig, Neuaufbau)

Drei Bedingungen für die Feststellung (alle müssen erfüllt sein, um als Rücknahme zu gelten):

• Die Richtung der Hauptlösung ist problematisch
• Bereits erstellte Artefakte müssen ungültig gemacht werden
• Eine erneute Diskussion/Design ist erforderlich

Verantwortung für die Feststellung: Die endgültige Entscheidung über eine Rücknahme liegt beim Benutzer. Wenn die KI ein vermutlich grundlegendes Problem entdeckt, kann sie nur eine vermutete Rücknahme vorschlagen und die Gründe dafür nennen; der Benutzer entscheidet endgültig, ob eine Rücknahme durchgeführt wird. Die KI kann nicht selbstständig eine Rücknahme feststellen.

Bearbeitungsablauf:

1. Stoppen Sie die aktuelle Implementierung
2. Die KI schlägt eine vermutete Rücknahme vor und erläutert die Gründe (welcher Teil der Richtung ist falsch, warum ist er nicht haltbar)
3. Warten Sie auf die endgültige Entscheidung des Benutzers, ob eine Rücknahme durchgeführt wird
4. Nach Bestätigung der Rücknahme durch den Benutzer notieren Sie in 00-Aufgabenstatus.md eine Zeile: Rückkehr von Phase X zu Phase Y, Grund, welche Artefakte ungültig sind
5. Kehren Sie zur Diskussions-/Designphase zurück, um sich neu auszurichten
6. Die neue Lösung wird gemäß dem ursprünglichen Workflow dokumentiert: Neue Fragen gehen in die Liste der offenen Fragen in 01-Kommunikation.md; Lösungsänderungen gehen in 02-Design.md mit einer Zeile in der Änderungshistorie
7. Überarbeiten Sie synchron 03-Implementierung.md

Gemeinsame eiserne Regeln der beiden Mechanismen

1. Lösungsänderungen werden immer im Designdokument geändert, nicht direkt im Implementierungsdokument
2. Zuerst das Design aktualisieren, dann implementieren – die Reihenfolge ist nicht umkehrbar (nicht erst handeln und dann nachtragen)
3. Jede Änderung muss im Aufgabenstatusdokument hinterlassen werden (Änderungen im Designdokument mit der Änderungshistorie, Rücknahmen zusätzlich mit einem Rücknahmevermerk)
4. Die Bestätigung durch den Benutzer ist ein obligatorischer Checkpoint für alle Änderungen (bei Änderungen muss die Ergänzung der Lösung bestätigt werden; bei Rücknahmen muss die Feststellung selbst bestätigt werden)

Denkweise: Abweichungen sind nicht schlimm, schlimm ist es, mit Abweichungen stur weiterzumachen oder stillschweigend vom Plan abzuweichen. Machen Sie "Änderungen" leichtgewichtig und reibungsarm (das ist der normale, reibungslose Ablauf), und "Rücknahmen" sorgfältig (Neuaufbau erfordert die Zustimmung des Benutzers). Beides wird standardisiert dokumentiert, was die Nacharbeitskosten minimiert.

Standard für Schrittmarkierungen im Implementierungsdokument

Die Implementierungsschritte sind in zwei Ebenen unterteilt: große und kleine Schritte. Beide müssen unabhängige Abschlussmarkierungen haben. Große Schritte werden mit Überschriften und Fortschrittszählern markiert, kleine Schritte mit einem Vier-Zustands-Checkbox.

Vier-Zustands-Markierungen:

- [ ]  Nicht begonnen
- [~] In Bearbeitung
- [x] Abgeschlossen
- [!] Blockiert (Grund dahinter angeben)

Organisationsbeispiel:

### 1. Datenbankebene ✅ 1/3
- [x] 1.1 Benutzertabelle erstellen (mit Migrationsskript)
- [~] 1.2 Indizes erstellen
- [ ] 1.3 Seed-Daten schreiben

### 2. API-Ebene ⬜ 0/2
- [ ] 2.1 POST /api/users implementieren
- [ ] 2.2 Authentifizierungsmiddleware anbinden

Statussymbole für große Schritte:

• ⬜ Nicht begonnen (0/N abgeschlossen)
• 🌗 In Bearbeitung (teilweise abgeschlossen)
• ✅ Vollständig abgeschlossen (N/N)

Das Fortschrittsformat ist einheitlich abgeschlossene Anzahl/Gesamtzahl, platziert am Ende der Überschrift des großen Schrittes. So sieht man sowohl den Gesamtfortschritt als auch, bei welchem kleinen Schritt genau es hakt.

Spezielle Handhabung für Backend-Projekte

Wenn das aktuelle Projekt ein reines Backend-Projekt ist (kein Frontend-Code, oder Backend und Frontend sind getrennte Repositories):

• Das Designdokument und das Implementierungsdokument enthalten nur Backend-Inhalte, keine Frontend-Implementierung.
• Jede neue Schnittstelle oder Änderung einer alten Schnittstelle (URL, Methode, Eingabeparameter, Ausgabeparameter, Fehlercodes, Authentifizierungsanforderungen usw.) muss in einem speziellen Abschnitt "Schnittstellenänderungsliste" in 02-Design.md zentral aufgeführt werden.
• Das Format der Schnittstellenliste sollte es Frontend-Entwicklern ermöglichen, sie direkt für die Integration zu verwenden. Empfohlene Felder: Schnittstellenpfad, Anforderungsmethode, Beispiel für Anforderungstext, Beispiel für erfolgreiche Antwort, Fehlercodetabelle, Authentifizierungsanforderungen, Anmerkungen.
• Diese Schnittstellenliste ist ein Liefergegenstand für das Frontend und sollte in sich schlüssig und unabhängig lesbar sein.
• Die Schnittstellenliste muss in der Designphase endgültige Ergebnisse liefern. Es ist verboten, Entscheidungen in die Implementierungsphase zu verschieben. Jede Tatsache, die vom vorhandenen Code abhängt, um festgestellt zu werden (z.B. "Ist diese Schnittstelle neu oder eine Änderung?", "Wird der Pfad übernommen oder geändert?", "An welcher bestehenden Struktur orientieren sich die Eingabefelder?") muss in der Designphase durch Lesen des vorhandenen Codes bestätigt und die Schlussfolgerung in die Schnittstellenliste aufgenommen werden. Die Einschränkung "in der Designphase nur diskutieren, keinen Code schreiben" bezieht sich auf Geschäftslogik-Code – das Lesen von vorhandenem Code zur Bestätigung der Schnittstellenform gehört zur Designrecherche, nicht zur Implementierung, und verstößt nicht gegen die Einschränkung. Im Designdokument sind vage Formulierungen wie "hängt vom vorhandenen Code ab" oder "in der Implementierungsphase zu bestätigen" verboten, ebenso wie Tags wie [Implementierungsphase bestätigen], die Unsicherheit legitimieren. Die Schnittstellenliste muss bei der Übergabe an das Frontend vollständig bestimmt sein, sonst kann das Frontend nicht integrieren.

Abnahmekriterien und Tests (Drei-Ebenen-Verantwortlichkeit)

Tests werden nicht erst in der Implementierungsphase ad hoc erstellt, sondern sind ein System, das sich vom Design bis zur Implementierung durchzieht. Die Verantwortlichkeiten der drei Ebenen sind streng getrennt:

Ebene	Träger	Inhalt	Art	Erstellungsphase
Regel	02-Design.md	Abstrakte Abnahmekriterien	"Bis zu welchem Grad ist die Anforderung erfüllt"	Design
Instanz	04-Tests.md	Konkrete Testfälle	"Welche Eingabe, welche Ausgabe erwartet"	Implementierungsplanung
Aktion	03-Implementierung.md	Schritte + Testfallreferenz	"Welche Aktion, mit welchem Testfall überprüfen"	Implementierungsplanung

Warum diese Aufteilung: Abnahmekriterien sind die Anforderungsgrenzen (gehören zum Design), Testfälle sind die Instanziierung dieser Grenzen, und die Implementierung ist die Umsetzung. Die drei Ebenen sind getrennt: Wenn sich eine Regel ändert, suchen Sie im Designdokument; wenn sich ein Testfall ändert, suchen Sie im Testdokument; wenn sich eine Aktion ändert, suchen Sie im Implementierungsdokument – jede hat ihre eigene Quelle der Wahrheit, ohne gegenseitige Verunreinigung.

Testfall-Ebenen und Nummerierung:

Präfix	Typ	Verwendung
T-F-	Funktionstestfall	Positiver Ablauf
T-EX-	Ausnahmetestfall	Negativer Ablauf, Grenzfälle, Fehlerzweige
T-R-	Regressionstestfall	Kritische Pfade, die nach Änderungen/Rücknahmen getestet werden müssen (aus F/EX ausgewählt, verhindert, dass Änderung an A B zerstört)
T-API-	Schnittstellentestfall	Entspricht jeder Schnittstelle in der "Schnittstellenänderungsliste" des Designdokuments

Für alle Aufgaben ist die Erstellung von 04-Tests.md obligatorisch: Dieser Skill richtet sich an mittlere bis große Aufgaben; bei kleinen Anforderungen wird der Skill vom Benutzer nicht ausgelöst, daher wird keine Komplexitätsprüfung durchgeführt – sobald eine Aufgabe die Implementierungsplanungsphase erreicht, ist das Testdokument ein Pflichtprodukt.

Verhältnis von Änderungen/Rücknahmen zu Tests: Nachdem der Änderungs- oder Rücknahmemechanismus durchlaufen wurde, ändert sich die Lösung → die Testfälle werden entsprechend aktualisiert (zuerst die Abnahmekriterien im Design ändern, dann die Testfälle ändern), und mindestens die Regressionstestsammlung (T-R) wird erneut durchlaufen, um zu verhindern, dass eine lokale Änderung eine globale Regression auslöst.

Erweiterungsmodus A: Aufgabenaufteilung (Große, modulare Aufgaben)

Wann aktivieren: Große Aufgaben bestehen natürlicherweise aus mehreren semi-unabhängigen Modulen (z.B. "Prüfsystem = Filterung sensibler Wörter + Bildprüfung + Manueller Prüfungsarbeitsplatz"), die in einen einzigen Kontext nicht passen. Wird aktiviert, wenn der Benutzer in der Diskussionsphase explizit sagt: "Dies ist eine große Aufgabe, teilen Sie sie in Module auf". Die Aufgabengröße wird nicht automatisch beurteilt; der Benutzer muss sie explizit auslösen.

Kernmechanismus: Die übergeordnete Aufgabe ist verantwortlich für Gesamtdesign + Modulaufteilung + Schnittstellenverträge zwischen Modulen + Orchestrierung, während die untergeordneten Aufgaben innerhalb der Grenzen der übergeordneten Aufgabe jeweils ihren eigenen vollständigen 4-Phasen-Workflow durchlaufen.

A.1 Dokumentenstruktur für übergeordnete und untergeordnete Aufgaben (verschachtelt)

Projektstamm/docs/design/
├── README.md                          ← Globale Aufgabenübersicht
├── 01-Prüfsystem/                     ← Übergeordnete Aufgabe
│   ├── 00-Aufgabenstatus.md                 ← Verwendet parent-task-status.md-Vorlage, enthält Liste der Unteraufgaben
│   ├── 01-Kommunikation.md                 ← Allgemeine Diskussion auf Ebene der übergeordneten Aufgabe
│   ├── 02-Design.md                     ← Gesamtarchitektur + Modulaufteilung + Schnittstellenverträge zwischen Modulen
│   ├── 03-Implementierung.md                     ← Nur Orchestrierung auf übergeordneter Ebene (Integrationstests, Abgleich), keine Modulinterna
│   ├── 04-Tests.md                     ← Nur modulübergreifende Integrationstests
│   └── Unteraufgaben/
│       ├── 01-1-Filterung sensibler Wörter/           ← Untergeordnete Aufgabe (vollständige 4-Phasen-Dokumente, normale Vorlage)
│       ├── 01-2-Bildprüfung/
│       └── 01-3-Manueller Prüfungsarbeitsplatz/
└── 02-Andere Aufgaben/

Untergeordnete Aufgaben verwenden die normale Vorlage (task-status / communication / design / implementation / test), völlig unverändert. Die übergeordnete Aufgabe verwendet die assets/parent-task-status.md-Vorlage, die einen zusätzlichen Abschnitt "Liste der Unteraufgaben" enthält; das Designdokument der übergeordneten Aufgabe muss zusätzlich zu den normalen Designvorlagen zwei Abschnitte enthalten:

• Modulaufteilung: Auflistung, in welche Unteraufgaben aufgeteilt wird, und deren jeweilige Verantwortungsbereiche
• Schnittstellenverträge zwischen Modulen: Schnittstellenvereinbarungen zwischen den Unteraufgaben (Schnittstellensignatur, Datenformat, Aufrufart usw.). Dies ist der Schlüssel für die parallele Arbeit der Unteraufgaben und muss in der Designphase klar festgelegt werden

A.2 Phasenfortschritt der übergeordneten Aufgabe (strikt sequentiell)

1. Die übergeordnete Aufgabe durchläuft zuerst "Diskussion + Design", muss die Modulaufteilung + die Schnittstellenverträge zwischen Modulen liefern
2. Das Design der übergeordneten Aufgabe muss vom Benutzer bestätigt werden, bevor die Unteraufgaben gestartet werden können
3. Beim Starten der Unteraufgaben bestimmen Sie die Startreihenfolge basierend auf den Abhängigkeiten: Die Designphase der übergeordneten Aufgabe muss die Abhängigkeiten zwischen den Unteraufgaben klar definieren (z.B. "Der manuelle Prüfungsarbeitsplatz ist abhängig von der Schnittstelle der Filterung sensibler Wörter"), die abhängige Unteraufgabe muss zuerst abgeschlossen sein, bevor die abhängige Aufgabe gestartet werden kann
4. Jede Unteraufgabe durchläuft ihren eigenen vollständigen 4-Phasen-Workflow (kann unter Erfüllung der Abhängigkeiten parallel erfolgen). Wie mehrere Unteraufgaben parallel gestartet werden, hängt vom verwendeten Agent-Framework ab (im Allgemeinen durch Hintergrund-/asynchrone Unteraufgaben-Fähigkeiten), siehe B.5 für die konkrete Umsetzung.
5. Nach Abschluss aller Unteraufgaben führt die übergeordnete Aufgabe einen "modulübergreifenden Integrationstest" als Abschluss durch

Warum die übergeordnete Aufgabe und die Unteraufgaben nicht parallel laufen können: Das Kernprodukt der übergeordneten Aufgabe sind die Schnittstellenverträge zwischen den Modulen, die Voraussetzung für die Unabhängigkeit der Unteraufgaben. Wenn die Unteraufgaben gestartet werden, bevor das Design der übergeordneten Aufgabe festgelegt ist, kommt es zwangsläufig zu Konflikten zwischen den Unteraufgaben.

A.3 Untergeordnete Aufgaben dürfen die von der übergeordneten Aufgabe definierten Schnittstellenverträge nicht eigenmächtig ändern

Die Schnittstellenverträge sind der Konsens mehrerer Module. Wenn eine Unteraufgabe sie eigenmächtig ändert, geraten die anderen Unteraufgaben außer Kontrolle. Wenn eine Unteraufgabe ein Problem mit den Schnittstellenverträgen der übergeordneten Aufgabe feststellt:

• Sie darf die Schnittstellenverträge nicht selbstständig ändern
• Sie muss zum Änderungsmechanismus auf Ebene der übergeordneten Aufgabe zurückkehren: Aktualisieren Sie 02-Design.md der übergeordneten Aufgabe (mit Änderungshistorie) → warten Sie auf die Bestätigung des Benutzers → informieren Sie alle Unteraufgaben, die von dieser Schnittstelle abhängen → die betroffenen Unteraufgaben überarbeiten synchron ihr eigenes Design/Implementierung/Tests

A.4 Beschränkung der Verschachtelungstiefe: Nur eine Ebene erlaubt

Übergeordnet → Untergeordnet, keine weitere Verschachtelung (Unteraufgaben können keine eigenen Unteraufgaben haben). Grund: Zu viele Verschachtelungsebenen machen die Aufgabenbeziehungen extrem komplex. Wenn eine Unteraufgabe noch weiter aufgeteilt werden müsste, deutet dies in der Regel auf eine falsche Aufteilungsgranularität hin – sie sollte stattdessen als eigenständige übergeordnete Aufgabe neu geplant werden, nicht in eine bestehende mehrschichtige Struktur gezwängt werden.

A.5 Verwendung der Vorlage für übergeordnete Aufgaben

• Aufgabenstatusdokument für übergeordnete Aufgaben: Verwenden Sie assets/parent-task-status.md (nicht die normale task-status-Vorlage)
• Andere Dokumente der übergeordneten Aufgabe (Kommunikation/Design/Implementierung/Tests): Verwenden Sie die normalen Vorlagen, aber das Designdokument muss zusätzlich die beiden in A.1 genannten Abschnitte enthalten
• Alle Dokumente der Unteraufgaben: Verwenden Sie die normalen Vorlagen, völlig unverändert

Erweiterungsmodus B: Dual-Agent-Implementierung (Implementierungsabschmitt)

Wann aktivieren: Innerhalb einer einzelnen Aufgabe führt die Stapelung von Implementierungs- und Testphase zu einem zu langen Kontext. Wird aktiviert, wenn der Benutzer zu Beginn der Implementierungsphase explizit sagt: "Implementierung im Dual-Agent-Modus". Wird nicht automatisch beurteilt; der Benutzer muss ihn explizit auslösen.

Kernmechanismus: Die Implementierungsphase wird intern in zwei serielle Abschnitte aufgeteilt – den Implementierungsagent (schreibt Code gemäß 03-Implementierung.md) und den Testagent (validiert gemäß 04-Tests.md). Beide sind physisch unabhängige Agenten (zwei unabhängige Kontexte), die über das Aufgabenstatusdokument kommunizieren. Der Kernwert von B ist die Kontextisolierung: Der Implementierungsagent trägt keinen Testkontext, der Testagent keine Implementierungsdetails.

B.1 Verantwortungsgrenzen von Implementierung und Tests

• Implementierungsagent: Führt nur die Schritte in 03-Implementierung.md aus (schreibt Code). Nach Abschluss führt er selbst keine Tests aus, sondern deklariert im Abschnitt "Implementierungsabschmitt-Status" in 00-Aufgabenstatus.md: "Implementierung abgeschlossen, Version X, bereit für Tests"
• Testagent: Validiert basierend auf der aktuellsten 03-Implementierung.md + 04-Tests.md. Seine Verantwortung ist streng auf "Testfälle ausführen, Fehler feststellen, berichten" beschränkt, er ist nicht für die Codeänderung zuständig (selbst wenn er einen Implementierungsfehler findet, behebt er ihn nicht selbst)

B.2 Behandlung, wenn der Testagent einen Fehler feststellt

Wenn der Testagent beim Ausführen eines Testfalls einen Fehler feststellt, beurteilt er vorläufig die Grundursache des Fehlers (der Testagent sieht das tatsächliche Verhalten und hat den besten Informationsvorteil für die vorläufige Beurteilung):

• Beurteilung als Implementierungsfehler (Code ist falsch geschrieben, Design ist richtig) → Melden an den Implementierungsagent, der die Änderung vornimmt. Nach der Änderung muss der Testagent den Fall erneut testen, und der Schritt gilt erst als abgeschlossen, wenn der Test bestanden ist (eine einseitige Erklärung des Implementierungsagents "ist behoben" reicht nicht aus)
• Beurteilung als Designfehler (Code wurde gemäß Design geschrieben, aber das Design selbst ist fehlerhaft) → Darf das Design nicht eigenmächtig ändern, löst den Änderungsmechanismus aus: Anhalten → Design aktualisieren → auf Benutzerbestätigung warten → Implementierung ändern → Tests ändern → zurück zum Testagent für erneuten Test

Wenn die Beurteilung falsch ist, korrigiert der Benutzer; aber "Design ändern" hat große Auswirkungen und erfordert die Zustimmung des Benutzers.

B.3 Abschnitt "Implementierungsabschmitt-Status"

00-Aufgabenstatus.md erhält einen optionalen Abschnitt (wird nur im B-Modus ausgefüllt, im Normalmodus leer gelassen):

## Implementierungsabschmitt-Status (nur für B-Modus, im Normalmodus leer lassen)

- Aktuelle Phase: Implementierung / Tests
- Implementierungsversion: (wird nach jedem Abschluss oder jeder Reparatur durch den Implementierungsagent erhöht)
- Implementierungsabschlusserklärung: JJJJ-MM-TT, Implementierungsagent hat erklärt, dass Tests beginnen können
- Testfortschritt:
  - Bestanden: T-F-01, T-F-02, ...
  - Fehlgeschlagen, wartet auf Reparatur: T-EX-03 (Implementierungsfehler, an Implementierungsagent gemeldet), ...
  - Wartet auf erneuten Test: T-EX-03 (Implementierungsagent hat repariert, wartet auf erneuten Test durch Testagent)

Sowohl der Implementierungs- als auch der Testagent lesen und schreiben diesen Abschnitt; er ist deren einziger Übergabepunkt.

B.4 Kombination mit A (A+B)

A und B sind orthogonal und können kombiniert werden: Große Aufgabe wird gemäß A in Unteraufgaben aufgeteilt, und innerhalb jeder Unteraufgabe wird gemäß B in Implementierung + Tests aufgeteilt. Bei der Kombination sind keine zusätzlichen Mechanismen erforderlich – da Unteraufgaben normale Aufgaben sind (A.1 hat bereits erläutert, dass Unteraufgaben normale Vorlagen verwenden), unterstützen sie intern natürlich B. Aktivierungsweise: Nach dem Design der übergeordneten Aufgabe und dem Start der Unteraufgaben entscheidet jede Unteraufgabe zu Beginn der Implementierungsphase, ob B aktiviert wird.

B.5 Agenten-Scheduling-Richtlinie

Modus B erfordert zwei physisch unabhängige Agenten (Implementierungsagent und Testagent), die indirekt über den Abschnitt "Implementierungsabschmitt-Status" kommunizieren und nicht direkt miteinander kommunizieren. Wie genau die beiden zusammenspielen, hängt von Ihrem verwendeten Agent-Framework ab.

Unabhängig vom verwendeten Framework folgen Sie demselben allgemeinen Scheduling-Muster:

1. Eine Scheduling-Instanz (dies kann der Hauptagent, ein externes Orchestrierungsskript oder der Benutzer selbst sein) liest den Abschnitt "Implementierungsabschmitt-Status" und beurteilt die aktuelle Phase
2. Die Scheduling-Instanz startet den Implementierungsagent, übergibt die Pfade zu Design/Implementierungsdokumenten und weist ihn an, gemäß 03-Implementierung.md vorzugehen und nach Abschluss den Statusabschnitt zu aktualisieren
3. Nach Abschluss der Implementierungsphase startet die Scheduling-Instanz den Testagent, übergibt den Pfad zum Testdokument und weist ihn an, die Testfälle gemäß 04-Tests.md auszuführen und die Ergebnisse (einschließlich Fehlerbeurteilung) in den Statusabschnitt zu schreiben
4. Basierend auf den Testergebnissen im Statusabschnitt entscheidet die Scheduling-Instanz über den nächsten Schritt: Handelt es sich um einen Implementierungsfehler, kehrt sie zum Implementierungsagent zurück, um zu reparieren und erneut zu testen; handelt es sich um einen Designfehler, hält sie an und meldet dem Benutzer, der den Änderungsmechanismus auslöst; wenn alle Tests bestanden sind, schließt sie ab

Allgemeine Kernpunkte:

• Der Implementierungsagent und der Testagent bauen jeweils unabhängig ihren Kontext auf, ohne sich gegenseitig zu verunreinigen – dies ist der Kern der "Kontextisolierung" im B-Modus
• Die beiden Agenten nehmen einander nicht direkt wahr, sie kommunizieren nur indirekt über das gemeinsam genutzte Dokument "Implementierungsabschmitt-Status"
• Die Scheduling-Instanz macht nur "Status lesen → beurteilen → delegieren", sie ist nicht an der Implementierung oder den Tests selbst beteiligt

Konkrete Umsetzungshinweise für verschiedene Clients: Die Fähigkeiten für Unteragenten / Hintergrundaufgaben / Mehrfensteransichten variieren je nach Agent-Framework. Dieses Dokument legt keine konkrete Implementierung fest. Bei Verwendung von ZCode siehe assets/references/zcode-scheduling.md (wird bei Bedarf geladen: nur lesen, wenn B-Modus aktiviert ist und eine konkrete Betriebsanleitung benötigt wird). Andere Clients können sich an dieser Datei orientieren und sie an ihre eigenen Fähigkeiten anpassen.

Wichtige Grenze: Der Skill legt keine konkrete Scheduling-Implementierung fest

Der Skill definiert das Übergabeprotokoll (Format und Semantik des Abschnitts "Implementierungsabschmitt-Status") und die Rollenverantwortlichkeiten (was macht der Implementierungs-/Testagent), aber keine konkrete Art und Weise des Schedulings. Jedes Framework, das "Dateien lesen, Unteraufgaben starten, Dateien schreiben" kann, kann den B-Modus umsetzen.

Prinzipien für Phasenübergänge

Die Phasen wechseln nicht automatisch; sie erfordern ein explizites Signal:

Eintrittsbedingung	Erfüllungsbedingung
Eintritt in die Diskussion	(Der Skill wird manuell aktiviert)
Diskussion → Design	Der Benutzer stimmt explizit zu, die Lösung zu fixieren, und die Liste der offenen Fragen ist leer
Design → Implementierungsplanung	Das Designdokument ist abgeschlossen und vom Benutzer genehmigt
Implementierungsplanung → Implementierung	Der Benutzer fordert explizit den Beginn der Umsetzung
Implementierung → Design (Änderung)	Während der Implementierung wird eine Lücke in der Lösung entdeckt; gemäß "Änderungsmechanismus" anhalten, Design ändern, auf Benutzerbestätigung warten
Implementierung → Diskussion/Design (Rücknahme)	Während der Implementierung wird ein grundlegender Fehler entdeckt; KI schlägt Rücknahme vor, Benutzer entscheidet endgültig und führt Rücknahme durch

Wenn Sie sich unsicher sind, ob ein Übergang erfolgen soll, bleiben Sie standardmäßig in der aktuellen Phase und diskutieren Sie weiter und fragen Sie den Benutzer aktiv. Treffen Sie nicht für den Benutzer die Entscheidung "die Lösung ist gut genug, Sie können mit dem Schreiben beginnen".

Verwendung der Vorlagen

Beim Erstellen neuer Dokumente lesen Sie die entsprechende Vorlage aus dem assets/-Verzeichnis:

• assets/readme.md → docs/design/README.md (Globale Aufgabenübersicht)
• assets/task-status.md → 00-Aufgabenstatus.md (Normale Aufgabe / Unteraufgabe)
• assets/parent-task-status.md → 00-Aufgabenstatus.md (Nur für übergeordnete Aufgaben, wenn A-Modus aktiviert)
• assets/communication.md → 01-Kommunikation.md
• assets/design.md → 02-Design.md (Enthält Abschnitt für Abnahmekriterien; übergeordnete Aufgaben müssen zusätzlich die Abschnitte Modulaufteilung und Schnittstellenverträge enthalten)
• assets/implementation.md → 03-Implementierung.md
• assets/test.md → 04-Tests.md (Wird in der Implementierungsplanungsphase erstellt)

Lesen Sie die Vorlagen, füllen Sie sie mit tatsächlichem Inhalt und schreiben Sie sie in den Aufgabenordner. Erfinden Sie keine Dokumentenstrukturen.

Skill-Weiterentwicklung und alte Aufgabendokumente

Der Skill wird kontinuierlich weiterentwickelt, Vorlagen und Spezifikationen können sich ändern. Bereits verwendete, alte Aufgabendokumente werden jedoch nicht automatisch an die neuen Spezifikationen angepasst. Dies ist beabsichtigt – es schützt das etablierte Verständnis des Benutzers für die Dokumentstruktur und erhält die Stabilität des kontextübergreifenden Gedächtnismechanismus. Die Dokumentstruktur ist der Gedächtnisanker, den der Benutzer nach einem Kontextwechsel zur schnellen Orientierung nutzt. Ein Anker sollte nicht durch häufige Änderungen aufgrund von Skill-Upgrades verformt werden.

Handhabungsprinzipien:

• Keine aktive Migration: Die KI scannt nicht eigenständig alte Aufgaben und richtet sie nicht an den neuen Spezifikationen aus, selbst wenn sie Diskrepanzen zwischen alten Dokumentformaten und den neuen Spezifikationen feststellt (z.B. Altdokumente haben einen Abschnitt "Rücknahmevermerk", während die neue Spezifikation "Änderungshistorie" vorschreibt). Festgestellte Unterschiede werden höchstens im "Implementierungshinweis" oder im Dialog erwähnt, aber nicht eigenständig geändert.
• Migration nur auf explizite Anweisung des Benutzers: Führen Sie eine Migration nur durch, wenn der Benutzer aktiv fordert: "Passen Sie die Dokumente von Aufgabe X an die aktuellen Skill-Spezifikationen an" oder "Migrieren Sie Aufgabe X zum neuen Format". Die KI beurteilt nicht selbstständig, ob eine alte Aufgabe migriert werden sollte.
• Inkrementelle Ergänzung bevorzugen: Eine Migration beschränkt sich standardmäßig auf die Ergänzung/Änderung von Teilen, die nicht den neuen Spezifikationen entsprechen. Die Gesamtstruktur und der Inhalt des ursprünglichen Dokuments bleiben erhalten, es wird nicht komplett neu geschrieben. So kann der Benutzer nach einem Kontextwechsel nicht die gesamte Seite neu lesen und verstehen müssen – die Struktur wurde nicht geändert, der Gedächtnisanker bleibt erhalten.
• Wenn der Benutzer explizit eine Neuschreibung fordert, unterstützen Sie diese, aber sichern Sie zuerst die Originaldatei, bevor Sie die neue Datei generieren:
  • Überschreiben Sie nicht direkt die Originaldatei
  • Hängen Sie an die Sicherungsdatei ein Datums- oder Versionssuffix an, z.B. 00-Aufgabenstatus.md.bak.20260617
  • Die neue Datei behält den ursprünglichen Dateinamen und enthält den neu geschriebenen Inhalt
  • Die Originaldatei ist der historische Gedächtnisanker des Benutzers; selbst bei einer Neuschreibung muss die Originalversion erhalten bleiben, um Vergleiche oder Rücknahmen zu ermöglichen
• Erklären Sie den Umfang vor der Migration/Neuschreibung: Informieren Sie den Benutzer vor dem Handeln, welche Stellen geändert werden (inkrementell) oder welche Dateien neu geschrieben werden (vollständig). Geben Sie nach der Änderung eine kurze Zusammenfassung, was geändert wurde, um die Erwartungen zu erfüllen.

Anti-Patterns (Zu vermeidende)

• ❌ In der Diskussionsphase bereits Geschäftslogik-Code schreiben – das Pferd von hinten aufzäumen.
• ❌ Lösungsänderungen direkt in das Implementierungsdokument schreiben, ohne das Designdokument zu aktualisieren – zerstört die einzige Quelle der Wahrheit.
• ❌ In einem neuen Dialog das Statusdokument und README nicht lesen und den Benutzer bitten, den Fortschritt zu wiederholen – verschwendet Kontext.
• ❌ Bei Abweichungen während der Implementierung stillschweigend die Implementierung ändern, ohne das Design nachzutragen – das Designdokument verliert allmählich seine Gültigkeit.
• ❌ Bei Backend-Projekten Frontend-Implementierungsdetails schreiben oder Schnittstellenänderungen nicht in der Schnittstellenliste erfassen – das Frontend hat keine Grundlage für die Integration.
• ❌ Ohne explizites Signal automatisch die Phase vorantreiben – nimmt dem Benutzer die Entscheidungsgewalt.
• ❌ Während der Implementierung eine Lücke in der Lösung (fehlendes Feld/Zweig/Dictionary-Wert usw.) entdecken, diese aber direkt im Implementierungsdokument ändern, ohne das Design nachzutragen und auf die Bestätigung des Benutzers zu warten – sollte den "Änderungsmechanismus" durchlaufen: anhalten → zuerst Design ändern → auf Bestätigung warten → Implementierung ändern → fortfahren.
• ❌ Während der Implementierung einen grundlegenden Fehler entdecken, aber trotzdem stur das Implementierungsdokument ändern oder die KI selbstständig über eine Rücknahme entscheiden lassen – sollte den "Rücknahmemechanismus" durchlaufen: KI kann nur vorschlagen, Benutzer entscheidet endgültig, Rücknahmevermerk eintragen und dann zur Diskussions-/Designphase zurückkehren, um sich neu auszurichten.
• ❌ Große Schritte abgehakt, aber die darin enthaltenen kleinen Schritte sind noch offen – große und kleine Schritte müssen unabhängig markiert werden.
• ❌ Diskussion verliert sich in der Breite, offene Fragen werden von neuen Themen überschwemmt – die Liste der offenen Fragen erzwingt die Fokussierung.
• ❌ In der Schnittstellenliste tauchen vage Formulierungen wie "hängt vom vorhandenen Code ab" oder "in der Implementierungsphase zu bestätigen" auf, oder Tags wie [Implementierungsphase bestätigen] legitimieren Unsicherheit – Tatsachen, die vom vorhandenen Code abhängen, müssen in der Designphase durch Lesen des Codes bestätigt werden; die Schnittstellenliste muss bei der Auslieferung des Designdokuments vollständig bestimmt sein, sonst kann das Frontend nicht integrieren.
• ❌ Nach einer Skill-Weiterentwicklung eigenständig alte Aufgabendokumente migrieren oder an neue Spezifikationen anpassen – zerstört den Gedächtnisanker des Benutzers. Nur auf explizite Anweisung des Benutzers migrieren; standardmäßig inkrementell ergänzen, nicht vollständig neu schreiben; wenn der Benutzer eine Neuschreibung fordert, muss zuerst die Originaldatei gesichert werden, bevor die neue Datei generiert wird.
• ❌ Das Designdokument enthält nur die Lösung, aber keine Abnahmekriterien – Abnahmekriterien definieren die Anforderungsgrenzen. Ohne sie gibt es keine objektive Definition von "fertig", und die Abnahme in der Implementierungsphase erfolgt nur nach Gefühl.
• ❌ Im Implementierungsdokument vage Aktionen wie "Unit-Tests decken XXX ab" schreiben, ohne konkrete Testfall-IDs zu referenzieren – Testaktionen müssen auf konkrete Testfälle in 04-Tests.md verweisen (z.B. "Überprüfen mit T-EX-03"), sonst ist unklar, was getestet wird und was erwartet wird.
• ❌ Nach Durchlaufen des Änderungs-/Rücknahmemechanismus die Regressionstests (T-R) nicht erneut ausführen – lokale Änderungen können globale Regressionen auslösen; die kritischen Pfade müssen erneut getestet werden.
• ❌ Im A-Modus Unteraufgaben starten, bevor das Design der übergeordneten Aufgabe festgelegt ist (Modulaufteilung oder Schnittstellenverträge noch nicht erstellt) – es kommt zwangsläufig zu Konflikten zwischen den Unteraufgaben. Das Design der übergeordneten Aufgabe muss zuerst vom Benutzer bestätigt werden.
• ❌ Im A-Modus Unteraufgaben eigenmächtig die von der übergeordneten Aufgabe definierten Schnittstellenverträge ändern – die Schnittstellenverträge sind der Konsens mehrerer Module; es muss zum Änderungsmechanismus auf Ebene der übergeordneten Aufgabe zurückgekehrt werden und alle von dieser Schnittstelle abhängigen Unteraufgaben müssen informiert werden.
• ❌ Im A-Modus Unteraufgaben in weitere Unteraufgaben verschachteln (mehr als eine Ebene) – deutet in der Regel auf eine falsche Aufteilungsgranularität hin; diese Unteraufgabe sollte als eigenständige übergeordnete Aufgabe neu geplant werden.
• ❌ Im A-Modus die übergeordnete Aufgabe startet alle Unteraufgaben parallel, ohne die Abhängigkeiten zu berücksichtigen – die abhängige Aufgabe blockiert, wenn die abhängige Aufgabe noch nicht abgeschlossen ist; die Abhängigkeiten müssen in der Designphase der übergeordneten Aufgabe klar definiert sein.
• ❌ Im B-Modus behebt der Testagent selbst Implementierungsfehler – die Verantwortlichkeiten müssen getrennt sein: Der Testagent beanstandet nur, die Reparatur geht an den Implementierungsagent; und nach der Reparatur muss der Testagent erneut testen, der Implementierungsagent kann den Abschluss nicht einseitig erklären.
• ❌ Im B-Modus ein und derselbe Agent nacheinander die Rollen "Implementierung" und "Tests" übernehmen – der Kernwert von B ist die Kontextisolierung; physisch müssen es zwei unabhängige Agenten sein, sonst ist der Kontext gar nicht isoliert und B ist nicht aktiviert.
• ❌ Im B-Modus ändert der Testagent bei einem Designfehler selbstständig das Design – Designänderungen haben große Auswirkungen; der Änderungsmechanismus muss ausgelöst werden und der Benutzer muss bestätigen; der Testagent kann nur vorläufig beurteilen und berichten.