Lernleitfaden: Teil 10. Projektumplanung

Thema: Teil 10. Projektneuplanung

Schwierigkeitsgrad: Mittelstufe

Geschätzte Lernzeit: 3-4 Stunden (Theorie + Praxis)

Voraussetzungen: Grundlagen der Arbeit mit Git (Branching, Merging, Commits)

Verständnis der Struktur der Projektdokumentation SDD (mission.md, tech-stack.md, roadmap.md)

Basiserfahrung mit dem Framework Hono

Verständnis des Konzepts der Feature-Spezifikationen (feature specs)

Grundkenntnisse in TypeScript und Testen

Lernziele: Selbstständig die Neuplanungsphase zwischen Features durchführen, einen separaten Git-Branch erstellen und die Projektdokumente aktualisieren

Bestimmen, welche Beobachtungen aus der Feature-Implementierung in Regeln (QWEN.md), technische Entscheidungen (tech-stack.md), Prüfvorlagen (validation.md) oder Agentenfähigkeiten kodiert werden sollen

Anfragen an den KI-Agenten formulieren, um Spezifikationen, Änderungsprotokoll und Roadmap ohne Implementierung neuer Produktfeatures zu aktualisieren

Die Größe von Roadmap-Phasen nach Kriterien der Überprüfbarkeit und des Werts bewerten, zu breite oder zu kleine Iterationen vermeiden

Überblick: Die Projektneuplanung ist eine Schlüsselphase in der SDD-Methodik (Specification-Driven Development), die zwischen der Implementierung von Features stattfindet, nicht innerhalb dieser. Es ist der Moment bewusster Pause, wenn das Team das erworbene Wissen festhält, die Projektdokumente aktualisiert und einmalige Beobachtungen in dauerhafte Regeln verwandelt. Je schneller der KI-Agent Code generiert, desto wichtiger ist es, regelmäßig zur Projektverfassung zurückzukehren und den Kurs zu korrigieren, solange die Abweichung noch gering ist. Die Neuplanung beantwortet fünf kritische Fragen: Was haben wir gelernt, muss der Technologie-Stack aktualisiert werden, ist die Roadmap aktuell, welche Prüfungen sollen verpflichtend werden, und welche Prozesse lohnen sich zu automatisieren. Erfolgreiche Neuplanung schafft einen Rückkopplungskreislauf: Jede Beobachtung aus dem vorherigen Feature löst eine Regelaktualisierung aus, die die Wahrscheinlichkeit verringert, dass dasselbe Problem in der nächsten Iteration wiederholt wird.

Schlüsselkonzepte: Neuplanungsphase: Ein separater Git-Branch, der nach Abschluss eines Features erstellt wird und ausschließlich der Aktualisierung der Projektdokumente ohne Implementierung neuer Produktfunktionen dient. Unterscheidet sich von der regulären Entwicklung durch das Verbot, Code für neue Features zu schreiben – Fokus auf Reflexion und Kodifizierung.

Kodifizierung von Beobachtungen: Der Prozess der Umwandlung einmaliger Beobachtungen aus der Feature-Implementierung in dauerhafte Projektartefakte. Vier Arten von Artefakten: Agentenverhaltensregeln (QWEN.md), technische Entscheidungen (tech-stack.md), Prüfvorlagen (validation.md), automatisierbare Fähigkeiten und Hooks (.qwen/skills/).

Änderungsprotokoll changelog.md: Ein dokumentiertes Protokoll mit Datumsangaben, das als komprimierte Projektgeschichte für Menschen und als Kontext für den KI-Agenten dient. Wird auf Basis der Git-Historie und der Änderungen des aktuellen Branches erstellt, nicht manuell von Grund auf.

Testpolitik: Eine formalisierte Anforderung in tech-stack.md, die das Werkzeug (Vitest), den Ausführungsbefehl (npm test) und die Verpflichtung zur Angabe automatischer Prüfungen in Feature-Spezifikationen festlegt.

Adaptives Design als Projektregel: Eine Anforderung auf Projektebene, nicht auf Feature-Ebene: Seiten müssen auf mobiler Breite 375px und Desktop-Breite 1280px funktionieren. Nach der Kodifizierung wird es retrospektiv auf alle bestehenden Spezifikationen angewendet.

Größe einer Roadmap-Phase: Überprüfbarkeitskriterium: Eine Phase sollte weder zu breit ('alle Features bauen') noch zu klein ('einen CSS-Abstand hinzufügen') sein. Eine optimale Phase hat ein konkretes Domänenziel und 3-5 überprüfbare Aufgaben.

Rückkopplungskreislauf: Ein Modell kontinuierlicher Verbesserung, bei dem jedes Signal aus der Feature-Implementierung (wiederholter Agentenfehler, nicht gefundene Datei, falscher Test) einen vordefinierten Ort für die Aufzeichnung der Reaktion hat. Wenn kein Ort gefunden wird – Signal für einen fehlenden Abschnitt in der Projektstruktur.

Aktualisierung alter Spezifikationen: Der Prozess der Anpassung abgeschlossener Feature-Spezifikationen an neue Projektregeln ohne Änderung der Implementierung, sofern dies nicht durch die aktualisierte Prüfung erforderlich ist. Bewahrt historische Genauigkeit: Die Spezifikation erklärt, welche Regeln zum Zeitpunkt der Implementierung galten.

Neuplanungsbranch: Eine isolierte Entwicklungslinie (z.B. replanning-after-hello-hono), die von main abzweigt, nur Dokumentänderungen enthält und nach Prüfung von Tests und Typen über Merge zurückgeführt wird.

Übungsaufgaben: Titel: Erstellen eines Neuplanungsbranches und Formulieren einer Anfrage

Problem: Sie haben das erste Feature 'Hello Hono' in einem Hono + TypeScript-Projekt abgeschlossen. Beobachtungen: Der Agent vergaß zweimal, Tests vor dem Commit auszuführen; das Layout sieht auf dem Telefon schlecht aus; in der Spezifikation gab es keinen Abschnitt 'Prüfung'; Sie haben den Agenten dreimal gebeten, mission.md vor der Arbeit zu lesen. Erstellen Sie einen Neuplanungsbranch und formulieren Sie eine Anfrage an den Agenten, die die Projektdokumente ohne Implementierung neuer Features aktualisiert.

Lösung: 1. Branch erstellen: git checkout -b replanning-after-hello-hono

1. Anfrage mit klaren Einschränkungen formulieren:

/clear Lies @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md und die abgeschlossene Feature-Spezifikation Hello Hono. Wir führen eine Neuplanungsphase durch. Implementiere keine neuen Produktfeatures. Schlage Änderungen vor für:

1. Testpolitik mit verpflichtendem Ausführen vor dem Commit;
2. Adaptives Design als allgemeine Anforderung (375px/1280px);
3. Prüfvorlage in Feature-Spezifikationen;
4. Automatisierung des Lesens von mission.md durch eine Fähigkeit.

Liste vor der Bearbeitung die vorgeschlagenen Dateiänderungen auf.

1. Prüfen, dass die Anfrage ein explizites Verbot neuer Features enthält und eine vorläufige Liste der Änderungen verlangt.

Schwierigkeitsgrad: Anfänger

Titel: Kodifizierung von Beobachtungen in die richtigen Artefakte

Problem: Nach dem Feature 'Hello Hono' haben Sie 6 Beobachtungen festgehalten. Verteilen Sie diese auf die Artefakttypen und erklären Sie die Wahl: (a) Der Agent änderte tsconfig.json ohne Erlaubnis und brach den Build (b) Vitest erwies sich als praktischer als manuelles Testen (c) Für die Datenbankmigration wurde die Idempotenz wiederholter Ausführung nicht geprüft (d) Die Anfrage 'generiere Spezifikation für Feature X nach Vorlage Y' wurde 5 Mal verwendet (e) Der Agent fand die Datei mit Konstanten nicht, obwohl sie im Projekt war (f) Die Implementierung fügte ein Feld 'status' hinzu, das nicht in requirements.md stand

Lösung: 1. (a) → QWEN.md (Agentenverhaltensregel): 'Ändere tsconfig.json niemals ohne Bestätigung durch einen Menschen'

1. (b) → tech-stack.md (technische Entscheidung): 'Wir verwenden Vitest für alle Tests, npm test führt vitest run aus'
2. (c) → validation.md (Prüfvorlage): 'Für Migrationen Idempotenz durch wiederholtes Ausführen prüfen'
3. (d) → .qwen/skills/spec-generation/SKILL.md (Fähigkeit): Anfrage mit Feature-Parametern automatisieren
4. (e) → QWEN.md (Liste 'Was am Anfang lesen' erweitern): Datei mit Konstanten hinzufügen
5. (f) → requirements.md über Neuplanungsbranch (Rückverfolgbarkeit): Entscheidung nachträglich festhalten
6. Begründung: Die Wahl bestimmt sich aus der Natur der Beobachtung – Agentenverhalten, technische Wahl, Prüfform, mechanische Wiederholung, Projektstruktur, Anforderungen.

Schwierigkeitsgrad: Mittelstufe

Titel: Bewertung und Korrektur der Roadmap

Problem: Analysieren Sie drei Varianten der Phase 2 der Roadmap und bestimmen Sie, welche den Kriterien einer guten Phase entspricht. Schlagen Sie Korrekturen für die nicht korrekten Varianten vor:

Variante A:

Phase 2: Die gesamte Anwendung bauen

• [ ] Datenbank hinzufügen
• [ ] Alle Seiten erstellen
• [ ] Tests schreiben

Variante B:

Phase 2: padding-top in der Hello-Hono-Überschrift hinzufügen

• [ ] CSS ändern

Variante C:

Phase 2: Agenten und Krankheiten

Ziel: Basis-Domänenmodell und Nur-Lesen-Seiten hinzufügen.

• [ ] SQLite-Schema für Agenten und Krankheiten hinzufügen.
• [ ] Initiale fiktive Daten hinzufügen.
• [ ] Seiten /agents und /ailments hinzufügen.
• [ ] Routen- und Komponententests hinzufügen.

Lösung: 1. Variante A – zu breit. Probleme: 'gesamte Anwendung' ist nicht überprüfbar; 'alle Seiten' nicht konkret; das Änderungsvolumen erschwert die menschliche Prüfung. Korrektur: In 2-3 Phasen mit Domänengrenzen aufteilen (z.B. 'Agenten und Krankheiten', 'Anträge und Zuweisungen', 'Verwaltung').

1. Variante B – zu klein. Probleme: Der Overhead für Branch, Code-Review, Merge übersteigt den Wert; kein Domänensinn. Korrektur: Mit anderen CSS-Aufgaben in eine Phase 'Basislayout und Navigation' zusammenfassen oder als Unteraufgabe in eine größere Phase einbinden.
2. Variante C – korrekt. Prüfung: Konkretes Domänenziel ('Basis-Domänenmodell'); 4 überprüfbare Aufgaben; Klare Grenzen ('nur für Lesen'); messbares Ergebnis (4 Checkboxen).
3. Allgemeines Prinzip: Eine Phase sollte 'an einem Abend überprüfbar' sein und Domänenwert tragen.

Schwierigkeitsgrad: Mittelstufe

Titel: Erstellen von CHANGELOG.md und Aktualisierung durch den Agenten

Problem: Nach Abschluss des Neuplanungsbranches mit Änderungen in tech-stack.md, validation.md und roadmap.md formulieren Sie eine Anfrage an den Agenten zur Erstellung oder Aktualisierung von CHANGELOG.md. Ausgangsdaten: Branch erstellt am 2026-05-01, Commits enthalten Hinzufügen von Vitest, Regel für adaptives Design, Präzisierung der Phasen 2-3 der Roadmap.

Lösung: 1. Anfrage an den Agenten: /clear Erstelle oder aktualisiere @CHANGELOG.md. Verwende Überschriften mit Datumsangaben im Format YYYY-MM-DD. Stütze dich auf die Git-Historie des Branches replanning-after-hello-hono und die Änderungen des aktuellen Branches. Schreibe kurz und verständlich für Beteiligte. Jeder Punkt sollte eine Zeile sein, die mit einem Verb beginnt.

1. Erwartetes Ergebnis:

# Änderungsprotokoll ## 2026-05-01

• Testpolitik mit Vitest hinzugefügt (npm test → vitest run).
• Anforderung für adaptives Design eingeführt (375px/1280px).
• Grenzen der Phasen 2 und 3 der Roadmap nach Domänenbereichen präzisiert.
• Feature-Spezifikationsvorlage um Abschnitt 'Verpflichtende Prüfungen' erweitert.

1. Prüfung: Daten entsprechen den Commits, Punkte sind atomar, Sprache ist für Menschen, aber strukturiert für das Parsen durch den Agenten.

Schwierigkeitsgrad: Anfänger

Titel: Anwendung des Rückkopplungskreislaufs

Problem: Während der Implementierung des Features 'Agenten und Krankheiten' traten folgende Ereignisse auf. Bestimmen Sie für jedes, welches Artefakt aktualisiert werden soll, oder halten Sie fest, dass in der Projektstruktur ein Abschnitt fehlt:

1. Der Agent generierte eine Migration, die bei wiederholter Anwendung auf derselben Datenbank fehlschlägt
2. Der Agent konnte die Datei mit Domänenmodelltypen nicht finden, obwohl sie in /src/types/ lag
3. Ein Mensch bemerkte, dass die Seite /agents auf dem iPhone SE nicht korrekt angezeigt wird, obwohl die Tests bestanden
4. Der Agent fragte dreimal, welches API-Antwortformat verwendet werden soll
5. In die Feature-Spezifikation gelangte versehentlich ein Beispiel mit einem echten Kundennamen

Lösung: 1. Migration schlägt wiederholt fehl → validation.md: Neue Vorlage 'Für Migrationen Idempotenz durch wiederholtes Ausführen prüfen' (Prüfebene wird erhöht).

1. Datei in /src/types/ nicht gefunden → QWEN.md: Liste 'Was am Anfang lesen' um Verzeichnisstruktur erweitern; möglicherweise Regel hinzufügen 'Vor Erstellen eines Typs prüfe vorhandene in /src/types/'
2. Tests bestanden, aber reales Verhalten falsch → validation.md: Fakt hinzufügen 'Für Seiten mit Daten Rendering auf Breite 375px zusätzlich zu Funktionstests prüfen'; möglicherweise visuelle Prüfebene einführen (siehe Teil 9).
3. Dreimal nach API-Format gefragt → .qwen/skills/api-response-format/SKILL.md: Standard für Antworten kodifizieren (JSON, Felder, Fehlercodes).
4. Echter Name in Spezifikation → QWEN.md: Regel 'Verwende niemals echte Kundendaten in Beispielen' + validation.md: Prüfszenario zur Suche nach PII (siehe Teil 18).
5. Prüfung: Für alle 5 Fälle wurde ein Platz in der bestehenden Struktur gefunden – die Struktur ist angemessen. Wäre für eine Beobachtung kein Platz gefunden worden, wäre dies das Signal, einen neuen Abschnitt zu erstellen.

Schwierigkeitsgrad: Fortgeschritten

Fallstudien: Titel: Neuplanung nach dem ersten Feature in einem medizinischen Plattformprojekt

Szenario: Ein Team aus zwei Entwicklern und einem Product Manager führt SDD für eine interne Patientenverwaltungsplattform ein. Das erste Feature 'Hello Hono' – eine Basis-Willkommensseite mit serverseitigem JSX-Rendering – wurde mit Hilfe des KI-Agenten Qwen Code in 2 Tagen implementiert. Das Team will sofort mit dem Feature 'Patientenregistrierung' beginnen.

Herausforderung: Der Product Manager bemerkt, dass die Willkommensseite auf seinem iPhone 12 mini (Breite 375px) nicht korrekt angezeigt wird, obwohl auf dem Desktop alles in Ordnung ist. Entwickler A stellt fest, dass der Agent vergaß, Tests vor dem finalen Commit auszuführen, und ein TypeScript-Fehler manuell korrigiert werden musste. Entwickler B gab dem Agenten dreimal dieselbe Anfrage: 'Lies mission.md, dann generiere eine Spezifikation für Feature X nach der Vorlage aus specs/templates/'. Die Roadmap enthält Phase 2: 'Den gesamten Patientenmodul implementieren' ohne Detaillierung. Das Team erkennt, dass ohne Pause zur Reflexion das nächste Feature dieselben Probleme wiederholen wird.

Lösung: Das Team erstellt den Branch replanning-after-hello-hono und führt eine Neuplanungsphase von 4 Stunden durch. Die Anfrage an den Agenten enthält ein klares Verbot der Implementierung neuer Features. Abfolge der Schritte: (1) Der Agent analysiert die abgeschlossene Hello-Hono-Spezifikation und schlägt Änderungen vor; (2) In tech-stack.md wird eine Testpolitik mit Vitest mit verpflichtendem npm test und die Anforderung für adaptives Design (375px/1280px) hinzugefügt; (3) In validation.md wird die Vorlage 'Für Seiten Rendering auf mobiler Breite prüfen' eingeführt; (4) CHANGELOG.md mit Projektgeschichte wird erstellt; (5) Phase 2 wird aufgeteilt in 'Patienten: Lesen' (Schema, Seiten, Tests) und 'Patienten: Schreiben' (Formulare, Validierung, Sicherheit); (6) Die wiederholte Anfrage wird in die Fähigkeit .qwen/skills/spec-generation/SKILL.md kodiert. Alte Spezifikationen werden an neue Regeln angepasst, ohne die Implementierung zu ändern.

Ergebnis: Die Zeit für manuelle Korrekturen bei der Implementierung des Features 'Patienten: Lesen' reduziert sich um 60%. Der Agent führt Tests automatisch aus und prüft die Adaptivität. Die Spezifikation wird mit einem Fähigkeitsaufruf statt drei Anfrageiterationen generiert. Die menschliche Prüfung der Phase dauert 2 Stunden statt der erwarteten 6 Stunden für eine monolithische Phase. CHANGELOG.md ermöglicht einem neuen Entwickler, der nach einem Monat hinzukommt, die Projektgeschichte in 15 Minuten zu verstehen.

Gelernte Lektionen: Neuplanung zwischen Features spart mehr Zeit, als sie kostet, durch die Vermeidung wiederholter Fehler

Die Kodifizierung wiederholter Anfragen in Agentenfähigkeiten hat einen Multiplikatoreffekt bei jedem weiteren Feature

Die Anforderung für adaptives Design auf Projektebene ist kostengünstiger als die Korrektur jeder Seite einzeln

Die Aufteilung monolithischer Phasen in überprüfbare Iterationen reduziert die kognitive Belastung des menschlichen Reviewers

Das Änderungsprotokoll ist nicht nur für Menschen nützlich, sondern auch als Kontext für zukünftige Anfragen an den Agenten

Verwandte Konzepte: Neuplanungsphase

Kodifizierung von Beobachtungen

Rückkopplungskreislauf

Größe einer Roadmap-Phase

Änderungsprotokoll CHANGELOG.md

Titel: Fehlgeschlagene Neuplanung: Folgen des Auslassens der Phase

Szenario: Ein Startup für die Entwicklung eines SaaS-Tools für Anwälte nutzt SDD mit dem Agenten Qwen Code. Nach dem ersten Feature 'Hello Hono' wechselt das Team sofort zum Feature 'Dokumente: Upload' und lässt die Neuplanung aus 'Deadline für die Investor-Demo' aus.

Herausforderung: Im Feature 'Dokumente' wiederholt der Agent drei Fehler aus Hello Hono: Führt keine Tests aus (am letzten Tag entdeckt), generiert eine Seite ohne mobile Version (der Anwalt zeigt die Demo vom Telefon – Fehlschlag), verwendet ein anderes API-Antwortformat als im ersten Feature (Frontend bricht bei Integration zusammen). Das Team verbringt 3 Tage mit Korrekturen statt der geplanten 2 Tage für die Implementierung. Die Roadmap bleibt unverändert: Phase 3 – 'Alle anderen Funktionen' – macht die Planung sinnlos.

Lösung: Nach dem Demo-Fehlschlag führt das Team eine erzwungene Neuplanung im Krisenmodus durch. Die Analyse zeigt, dass 70% der Probleme aus Beobachtungen des ersten Features vorhersehbar waren. In tech-stack.md werden die Regeln retrospektiv eingeführt, aber erst nach doppelter Arbeit. Alte Spezifikationen müssen mit Änderung der Implementierung aktualisiert werden, da die Integration gebrochen ist. Die Fähigkeit zur Spezifikationsgenerierung wird erstellt, verliert aber durch den Druck einen Teil des Kontexts.

Ergebnis: Das Projekt liegt 2 Wochen hinter dem Plan. Das Team führt eine verpflichtende Neuplanungsphase von 1 Tag zwischen allen Features als harte Regel ein. Es entsteht eine interne Regel: 'Keine Neuplanung – kein Branch für das nächste Feature'. Positiver Nebeneffekt: Eine Kodifizierungskultur bildet sich, das Team beginnt CHANGELOG.md zu führen und den Rückkopplungskreislauf regelmäßig zu aktualisieren.

Gelernte Lektionen: Das Auslassen der Neuplanung zugunsten der Geschwindigkeit schafft eine Illusion von Zeitersparnis

Wiederholte Agentenfehler sind kein Zufall, sondern ein Signal für ein fehlendes Regel

Krisenhafte Neuplanung ist teurer als geplante: Sie erfordert Änderung der Implementierung, nicht nur der Dokumente

Eine harte Regel 'Neuplanung ist verpflichtend' schützt vor Optimierung unter kurzfristigem Druck

Verwandte Konzepte: Rückkopplungskreislauf

Kodifizierung von Beobachtungen

Neuplanungsphase

Aktualisierung alter Spezifikationen

Lerntipps: Üben Sie das physische Erstellen von Neuplanungsbranches: Öffnen Sie ein Terminal, führen Sie git checkout -b replanning-after-... aus, schreiben Sie einen sinnvollen Commit. Muskelgedächtnis ist für diesen Prozess wichtiger als theoretisches Verständnis.

Führen Sie einen persönlichen 'Rückkopplungskreislauf' als Tabelle: Linke Spalte – Beobachtung aus Ihren Projekten, rechte – wohin sie aufgenommen wird. Ergänzen Sie nach jedem Feature.

Üben Sie die Formulierung von Anfragen an den Agenten mit explizitem Verbot der Implementierung. Das ist kontraintuitiv: Normalerweise bitten wir 'mach', hier – 'mach nicht, schlage nur vor'.

Erstellen Sie Vorlagen für die vier Artefakttypen der Kodifizierung in Ihrem Editor (Snippets oder Fragmente). Das beschleunigt den Übergang von Beobachtung zur Aufzeichnung.

Prüfen Sie die Größe einer Roadmap-Phase nach der Regel 'an einem Abend überprüfbar': Wenn Sie sich nicht vorstellen können, wie Sie an einem Abend sicherstellen, dass alles funktioniert – ist die Phase zu groß.

Lesen Sie CHANGELOG.md vor jedem neuen Feature als Kontext – so verstehen Sie seinen Wert für den Agenten und für sich selbst.

Üben Sie die Unterscheidung zwischen 'Regel auf Projektebene' und 'Entscheidung auf Feature-Ebene': Adaptives Design – Projekt, konkreter padding – Feature. Ein Fehler hier führt zu inkonsistenten Spezifikationen.

Verwenden Sie die Technik '5 Warum' für jede Beobachtung: Warum hat der Agent sich geirrt? Warum die Datei nicht gefunden? Warum die Anfrage wiederholt? Wurzelursachen weisen auf das richtige Kodifizierungsartefakt hin.

Zusätzliche Ressourcen: Originalkurs SDD (Teile 1-18): Vollständiger Kontext der Methodik Specification-Driven Development mit Fokus auf die Arbeit mit KI-Agenten

Teil 9 des Kurses (Prüfebenen): Detaillierte Betrachtung der validation.md-Vorlagen und der Erhöhung von Prüfebenen bei Fehlerentdeckung

Teil 14 des Kurses (Hooks und Fähigkeiten): Mechanik der Erstellung von .qwen/skills/ und Automatisierung wiederholter Anfragen

Teil 17 des Kurses (Schutz-Hooks): Verhinderung gefährlicher Befehle durch Automatisierung

Teil 18 des Kurses (Sicherheit und Geheimnisse): Regeln zur Verhinderung von PII- und vertraulichen Datenlecks in Spezifikationen

Vitest-Dokumentation: https://vitest.dev – für tiefes Verständnis der Einrichtung der Testpolitik

Conventional-Commits-Leitfaden: Standardisierung von Commit-Nachrichten, nützlich für automatisches CHANGELOG.md

Keep a changelog: https://keepachangelog.com – internationale Praxis der Änderungsprotokollführung (an Kursformat anpassen)

Zusammenfassung: Die Projektneuplanung ist eine strategische Pause zwischen Features in SDD, die chaotische Beobachtungen in systematische Regeln verwandelt. Ihr Ziel ist nicht die Beschleunigung der Entwicklung, sondern die Verhinderung wiederholter Fehler durch Kodifizierung: Regeln in QWEN.md, technische Entscheidungen in tech-stack.md, Vorlagen in validation.md, Fähigkeiten in .qwen/skills/. Schlüsselpraktiken: separater Git-Branch mit Verbot neuer Features, Aktualisierung alter Spezifikationen ohne Implementierungsänderung, Führung von CHANGELOG.md als Kommunikation für Menschen und Kontext für den Agenten, richtige Größe von Roadmap-Phasen (an einem Abend überprüfbar), Rückkopplungskreislauf mit vordefinierten Reaktionen auf Signale. Das Auslassen der Neuplanung schafft eine Geschwindigkeitsillusion und verdoppelt die technische Schuld. Die regelmäßige Kodifizierung der 2-3 häufigsten Beobachtungen pro Iteration bildet ein sich selbst verstärkendes Qualitätssystem.