Lernleitfaden: Teil 6. Die Verfassung schaffen

Lektion 2 von 5 im Modul «Teil 6. Die Verfassung schaffen»

Sie sehen die Lektion ohne Anmeldung an. Anmelden, um Ihren Fortschritt zu speichern und Tests zu absolvieren.

Thema: Teil 6. Erstellung einer Verfassung

Schwierigkeitsgrad: Mittelstufe

Geschätzte Lernzeit: 3-4 Stunden (einschließlich Übung mit Qwen Code)

Voraussetzungen: Grundlegendes Verständnis von Git und der Kommandozeile

Vertrautheit mit TypeScript und Node.js

Erfahrung mit Markdown-Dokumenten

Verständnis der Grundlagen von SDD (Specification-Driven Development) aus vorherigen Kursteilen

Zugang zu Qwen Code oder einem vergleichbaren KI-Assistenten für praktische Aufgaben

Lernziele: Eine Projektverfassung aus drei Pflichtdateien (mission.md, tech-stack.md, roadmap.md) vor Beginn der Entwicklung der ersten Funktion erstellen

Langfristige Architekturentscheidungen (tech-stack.md) und Entscheidungen auf Ebene einzelner Funktionen (requirements.md) anhand des Kriteriums „überlebt fünf Funktionen ohne Änderungen" unterscheiden

Ein strukturiertes Interview mit einem KI-Agenten zur gemeinsamen Erstellung einer Verfassung führen, wobei drei gruppierte Fragenblöcke gestellt werden

Implizite Teamregeln auf Basis einer Analyse von git diff nach der ersten Funktion in QWEN.md identifizieren und formalisieren

Die Verfassung auf Widersprüche, Unschärfen und zu große Phasen vor dem Commit prüfen

Überblick: Eine Verfassung ist ein Projektvertrag zwischen Mensch, KI-Agent und zukünftigen Projektbeteiligten, der verhindert, dass der Agent die Mission, den Technologie-Stack und die Arbeitsreihenfolge wiederholt „errät". In der SDD-Methodologie wird die Verfassung vor der ersten Produktfunktion erstellt und besteht aus drei Pflichtdateien im Verzeichnis specs/: mission.md (wofür und für wen), tech-stack.md (technische Projektentscheidungen) und roadmap.md (phasenweiser Implementierungsplan). Dieser Kursteil lehrt nicht einfach das manuelle Verfassen dieser Dokumente, sondern deren gemeinsame Erstellung mit dem Agenten durch ein strukturiertes Interview, die Prüfung auf Widersprüche und die Überführung impliziter Regeln in explizite Konventionen. Besondere Aufmerksamkeit gilt der Grenze zwischen verfassungsrechtlichen Entscheidungen und Funktionsspezifikationen sowie der Praxis, ungeschriebene Teamregeln in QWEN.md auf Basis realer Erfahrungen mit dem Agenten zu fixieren.

Schlüsselkonzepte: Projektverfassung: Eine Sammlung von drei Dateien (mission.md, tech-stack.md, roadmap.md) im Verzeichnis specs/, die vor der ersten Funktion erstellt wird. Funktioniert als Vertrag: Wenn sie übersprungen wird, wird der Agent jedes Mal neu die Mission, den Stack und die Arbeitsreihenfolge erraten, was zu architektonischer Degradation und Verlust von Integrität führt.

Mission.md: Beantwortet die Fragen „wofür" und „für wen". Enthält die Produktbestimmung, die Hauptzielgruppe und den Erfolgskriterium. Beispiel aus dem Kurs: AgentClinic — eine satirische Lernanwendung, in der KI-Agenten Patienten einer psychiatrischen Klinik sind und Menschen ihre Leiden verursachen. Der Code soll dabei ernsthaft und lehrreich bleiben.

Tech-stack.md: Fixiert langfristige technische Projektentscheidungen: Sprache, Laufzeitumgebung, Web-Framework, Datenbankmanagementsystem, Testbibliothek, Beschränkungen für Abhängigkeiten. Schlüsselprinzip: Entscheidungen hier müssen mindestens fünf Funktionen ohne Änderungen überleben. Jede Änderung erfordert eine Neubewertung (Teil 10 des Kurses).

Roadmap.md: Eine kurze Roadmap, unterteilt in kleine Phasen, von denen jede in einen fokussierten Branch passt. Phasen müssen so klein sein, dass sie ohne Heldentaten überprüft werden können. Beispiel: Phase 1 beweist nur die Funktionsfähigkeit der Grundverbindung, Phase 2 fügt Domänendaten hinzu.

Grenze tech-stack.md / requirements.md: Grundlegende Trennungsregel: In tech-stack.md leben projektbasierte Entscheidungen (überleben fünf Funktionen), in requirements.md für Funktionen leben entscheidungen auf Ebene einer einzelnen Funktion (Routen, Formularfelder, Validierungsregeln). Einfacher Test: Wenn eine Entscheidung nach dem Merge der Funktion vergessen wird — gehört sie in requirements.md. Beispiel: „Hono verwenden" — tech-stack.md; „Route GET /agents liefert HTML mit Liste von 10 Einträgen" — requirements.md der Funktion; „alle Listen liefern standardmäßig 10 Einträge" — tech-stack.md oder conventions.md.

Qwen.md und implizite Regeln: Dokument zur Fixierung ungeschriebener Teamregeln, die der Agent konsequent falsch errät. Typische Bereiche: Code-Stil und Benennung, verbotene Konstrukte (any, @ts-ignore), Liste erlaubter Abhängigkeiten, Format von Fehlermeldungen, Struktur der Fehlerbehandlung, Commit-Format, Rituale vor dem Merge. Die beste Methode zur Identifizierung — Analyse von git diff nach der ersten Funktion und Finden von Stil- oder Entscheidungskorrekturen, die für den Agenten vorgenommen wurden.

Interview via qwen code: Strukturierter Prozess der gemeinsamen Verfassungserstellung: Der Agent erhält Kontext, stellt genau drei gruppierte Fragen (Mission und Zielgruppe, Technologie-Stack, Roadmap), erhält konkrete Entscheidungen in der Antwort statt allgemeiner Wünsche, und erst dann werden die Dateien geschrieben. Wenn der Agent das Interview überspringt — muss er gestoppt und zur Protokollbefolgung aufgefordert werden.

Verfassungsprüfung: Obligatorischer Schritt vor dem Commit: Der Agent prüft eigene Dateien auf Widersprüche, unklare Formulierungen und zu große Phasen. Typische Probleme: Die Roadmap erfordert Heldentaten, der Stack enthält „für alle Fälle"-Abhängigkeiten, mission.md definiert nicht den Code-Leser, SQLite ist in der Roadmap erwähnt aber nicht im Stack, „moderne Benutzeroberfläche" ohne konkrete Einschränkungen.

Übungen: Titel: Übung 1: Klassifizierung von Entscheidungen — wohin schreiben?

Problem: Fünf technische Entscheidungen für das Projekt AgentClinic sind gegeben. Bestimmen Sie für jede, in welches Dokument sie gehört: tech-stack.md, requirements.md der Funktion, oder roadmap.md. Begründen Sie anhand des Kriteriums „überlebt fünf Funktionen".

Bibliothek Hono als Web-Framework verwenden
Route POST /appointments akzeptiert Felder agentId, ailmentId, date und gibt 201 mit ID zurück
ORM Prisma für Datenbankarbeit hinzufügen
Phase 2: Tabelle therapies und Seite /therapies hinzufügen
Alle Formulare auf der Website verwenden serverseitige Validierung mit Fehlerrückgabe in einem Format

Lösung: 1. tech-stack.md — die Wahl des Web-Frameworks bestimmt die Architektur des gesamten Projekts, überlebt viele Funktionen.

requirements.md der Funktion „Terminvereinbarung" — konkrete Route, Felder und Antwortcode gehören zu einer Funktion, werden nach Implementierung vergessen.
tech-stack.md — die Wahl des ORM ist eine langfristige architektonische Entscheidung, beeinflusst alle Datenzugriffsschichten.
roadmap.md — das ist eine Phase der Roadmap, keine technische Entscheidung und keine Funktionsdetails.
tech-stack.md (oder separates conventions.md) — Validierungsregel für alle Projektformulare, überlebt viele Funktionen. Wäre es nur um die Terminformulare gegangen — wäre es requirements.md.

Schwierigkeit: Anfänger

Titel: Übung 2: Erstellung von mission.md für ein neues Projekt

Problem: Sie beginnen das Projekt „DevGarden" — eine Plattform zur Visualisierung der Entwicklerfähigkeitsentwicklung in Form eines Pflanzengartens. Jeder Commit gießt eine Pflanze, ein verpasster Tag — Welken. Schreiben Sie die vollständige Datei mission.md, einschließlich: Bestimmung (satiristischer oder ernster Ton?), Hauptzielgruppe (mindestens 2 Gruppen), Erfolgskriterium. Folgen Sie der Struktur aus dem Kurs.

Lösung: Beispielantwort:

# Mission

DevGarden — eine Plattform, die die Commit-Historie eines Entwicklers in einen lebendigen Garten verwandelt: Regelmäßige Aktivität gießt Pflanzen, Pausen führen zum Welken.

## Bestimmung

Das Produkt ist ein Motivationsinstrument mit Gamification-Elementen. Der Ansatz wird in halb-ernstem Ton präsentiert: Pflanzen reagieren auf reale Aktivität in Repositories, und Welken ist eine anschauliche Metapher für „technische Schuld" im Aufmerksamkeitsreservoir.

## Hauptzielgruppe

- Entwickler, die SDD mit Agenten lernen, die Code schreiben.
- Teams, die Gamification von Entwicklungsmetriken einführen.
- Ingenieure, die Integration mit der GitHub API und Serveranwendungen in TypeScript lernen.

## Erfolg

Der Entwickler muss verstehen, wie SDD-Artefakte helfen, eine einheitliche Produktmetapher über viele Funktionen hinweg zu bewahren, und in der Lage sein, den Garten mit neuen Pflanzenarten zu erweitern, ohne architektonische Kohärenz zu verlieren.

Prüfen Sie: Gibt es eine Antwort auf „wofür" (Motivation durch Metapher), „für wen" (3 Gruppen), konkretes Erfolgskriterium (Verständnis der Rolle von SDD-Artefakten, nicht nur „die Anwendung funktioniert").

Schwierigkeit: Mittelstufe

Titel: Übung 3: Analyse von git diff zur Erstellung von QWEN.md

Problem: Nach der ersten Funktion mit dem Agenten entdecken Sie in git diff folgende manuell für den Agenten vorgenommene Korrekturen:

Der Agent verwendete console.log für Datenbankfehler → Sie ersetzten durch strukturierten Logger mit Ebenen
Der Agent benannte Variable usrData → Sie benannten um in userData
Der Agent setzte // @ts-ignore vor SQLite-Abfrage → Sie entfernten und fügten korrekte Typisierung hinzu
Der Agent schrieb Commit „some fixes" → Sie schrieben um zu „fix(db): handle connection timeout in agent repository"
Der Agent fügte Abhängigkeit lodash für eine debounce-Funktion hinzu → Sie ersetzten durch native Implementierung

Formulieren Sie 3-5 Regeln für QWEN.md auf Basis dieser Muster.

Lösung: Beispiel QWEN.md:

# QWEN.md — Projektkonventionen AgentClinic

## Logging
- Direkte `console.log` und `console.error` sind im Produktivcode verboten
- Einheitlichen strukturierten Logger mit Ebenen verwenden (info, warn, error, debug)
- Datenbankfehlermeldungen müssen Operationskontext enthalten, keine sensiblen Daten preisgeben

## Benennung
- Abkürzungen verboten: `usr`, `data`, `cnt` → `user`, `data`, `count` verwenden
- camelCase für Variablen und Funktionen, PascalCase für Klassen und Interfaces, snake_case für Datenbankfelder

## TypeScript
- `any` und `// @ts-ignore` sind im Produktivcode verboten
- Jede Datenbankabfrage muss explizite Ergebnistypisierung haben

## Commits
- Format: `<type>(<<scope>): <Verb in Gegenwart> + <Objekt>`
- Beispiele: `feat(agents): add list endpoint`, `fix(db): handle connection timeout`
- Commits wie „fix", „update", „some changes" sind verboten

## Abhängigkeiten
- Neue Abhängigkeit erfordert Diskussion und Aktualisierung von tech-stack.md
- Native Lösungen Bibliotheken vorziehen für einfache Aufgaben (debounce, throttle, deep clone einfacher Objekte)

Schlüsselkompetenz: Beobachtbare Fehlermuster in konkrete, überprüfbare Regeln verwandeln, nicht allgemeine Empfehlungen.

Schwierigkeit: Mittelstufe

Titel: Übung 4: Verfassungsprüfung auf Widersprüche

Problem: Eine Rohfassung einer Projektverfassung ist gegeben. Finden Sie mindestens 4 Probleme, die der Prüfschritt vor dem Commit aufdecken sollte.

# mission.md
AgentClinic — Klinik für KI-Agenten. Lernanwendung für alle.

# tech-stack.md
- TypeScript
- Hono
- SQLite (lokale Speicherung)
- ORM Prisma
- React für UI
- Vitest

# roadmap.md
## Phase 1
- Alle Abhängigkeiten installieren
- Datenbank mit Migrationen einrichten
- Alle Tabellen erstellen (agents, ailments, therapies, appointments)
- Alle Routen implementieren (GET, POST, PUT, DELETE)
- Administrator-Authentifizierung hinzufügen
- Tests für alles schreiben

Lösung: Identifizierte Probleme:

Unklare Mission: „für alle" — keine konkrete Zielgruppe, kein Erfolgskriterium, Ton unklar (satirisch/ernst).

Widerspruch im Stack: In tech-stack.md ist React für UI angegeben, aber im Kurs und im typischen AgentClinic-Ansatz wird serverseitiges Hono JSX-Rendering verwendet — muss geklärt werden, ob React eine bewusste Abweichung von der Lernmethodik ist.

SQLite in Roadmap aber nicht im Stack: SQLite ist in tech-stack.md erwähnt (OK), aber ORM Prisma ohne Begründung hinzugefügt — im Kurs wird explizit „direkte SQL-Migrationen bis zum Erscheinen eines ORM" angegeben, d.h. ORM erscheint später, nicht am Anfang.

Phase 1 erfordert Heldentaten: 6 Punkte, einschließlich „alles" — Routen aller Typen, Authentifizierung, Tests für alles. Das verletzt das Prinzip „jede Phase in einen Branch, überprüfbar ohne Heldentaten". Sollte in 3-4 Phasen aufgeteilt werden.

„Für alle Fälle"-Abhängigkeit: Administrator-Authentifizierung in der ersten Phase einer satirischen Lernanwendung — möglicherweise vorzeitige Komplexität, nicht durch Mission begründet.

Keine Einschränkungen im Stack: Fehlende Regeln für Abhängigkeiten, kein Verbot von „für alle Fälle".

Schwierigkeit: Fortgeschritten

Fallstudien: Titel: Fallstudie: Wie ein Team drei Iterationen durch fehlende mission.md verlor

Szenario: Ein Team von drei Entwicklern startete das Projekt „EcoTrack" — eine Anwendung zur CO2-Fußabdruckverfolgung. Der technische Leiter schrieb schnell tech-stack.md mit React Native und Firebase, und die Roadmap wurde in drei große Phasen à zwei Monate erstellt. Die Datei mission.md wurde als überflüssig erachtet — „alles ist klar, Umwelt und so".

Herausforderung: Nach der ersten Iteration stellte sich heraus, dass die Entwickler das Produkt unterschiedlich verstanden: einer machte eine B2C-Anwendung für umweltbewusstes Einkaufen, der zweite — ein Unternehmens-Dashboard für ESG-Berichterstattung, der dritte — einen gamifizierten Tracker für Schulkinder. Im tech-stack.md kamen widersprüchliche Ergänzungen: Mapbox für Ladenkarten, Tableau-Integration für Berichte, Unity für Spielmechaniken. Der Agent (Claude Code) fragte bei jeder neuen Funktion Grundlegendes nach und generierte Code für unterschiedliche Zielgruppen in verschiedenen Anwendungsteilen.

Lösung: Das Team stoppte die Entwicklung, führte eine gemeinsame Sitzung mit dem Agenten durch ein strukturiertes Interview. mission.md wurde mit klarer Definition erstellt: „EcoTrack — B2B SaaS für mittlere Unternehmen (50-500 Mitarbeiter), die Datensammlung für ESG-Berichterstattung nach GRI-Standard automatisieren müssen. Ton: geschäftlich, ohne Gamification". Der Technologie-Stack wurde von Mapbox und Unity bereinigt, Einschränkung hinzugefügt „neue Integration erfordert ROI-Begründung für Zielunternehmen". Die Roadmap wurde in Phasen von ein bis zwei Wochen aufgeteilt: Phase 1 — Prototyp für Excel-Import, Phase 2 — Berechnung grundlegender Metriken, Phase 3 — GRI-Berichtsgenerierung.

Ergebnis: Nach Einführung der Verfassung stieg die Entwicklungsgeschwindigkeit um 40% (gemessen an Story Points pro Sprint). Der Agent hörte auf zu „erraten" und begann, Lösungen im Rahmen der vorgegebenen Architektur vorzuschlagen. Code-Reviews reduzierten sich von 15 Kommentaren „wofür ist das?" auf 2-3 technische Anmerkungen. Nach 4 Monaten wurde das Produkt mit drei Pilotunternehmen gestartet.

Gelernte Lektionen: mission.md ist kein „Wasser", sondern ein Filter für alle folgenden Entscheidungen: ohne ihn wird selbst ein gutes tech-stack.md unter Unsicherheitsdruck verwässert

Das Interview mit dem Agenten wirkt als Katalysator für Teamkonvergenz: es zwingt zur expliziten Formulierung impliziter Vereinbarungen

Große Phasen verschleiern Unsicherheit: wenn eine Phase nicht in einer Woche überprüfbar ist, sind darin unbehandelte Risiken versteckt

Der Agent als „Spiegel" reflektiert Chaos im Projekt: wenn er ständig unterschiedlich „errät", liegt das Problem nicht am Agenten, sondern am Fehlen einer Verfassung

Verwandte Konzepte: mission.md

Interview via Qwen Code

Grenze tech-stack.md / requirements.md

Verfassungsprüfung

Titel: Fallstudie: Wie eine Entwicklerin nach der ersten Funktion QWEN.md erstellte und 20 Stunden sparte

Szenario: Die Indie-Entwicklerin Anna startete das Projekt „BookShelf" — einen Service für Buchtausch im Stadtteil. Sie nutzte Qwen Code zur Entwicklungsbeschleunigung. Nach der ersten Funktion (Registrierung und Profil) bemerkte sie, dass sie viel Zeit für die Korrektur des vom Agenten zurückgegebenen Code-Stils aufwendete.

Herausforderung: Die Analyse von git diff zeigte 47 manuelle Korrekturen in 12 Commits: Der Agent verwendete unterschiedliche Benennungsstile (snake_case vs camelCase), fügte any für „Einfachheit" hinzu, schrieb Commits auf Russisch und Englisch gemischt, nutzte console.log statt des konfigurierten Loggers pino. Jede neue Funktion erforderte die Wiederholung dieses Korrekturzyklus.

Lösung: Statt „manueller" Kontrolle fortzusetzen, investierte Anna 2 Stunden in die Erstellung von QWEN.md auf Basis der Muster aus git diff. Das Dokument umfasste: eine Tabelle der Kontext-Zuordnung und Benennungsstile (Datenbank — snake_case, Code — camelCase), Verbot von any mit alternativen Typisierungsmustern, Commit-Vorlage mit Beispielen, Anforderung pino mit Log-Level aus Config zu verwenden. Sie fügte auch einen Abschnitt „Ritual vor dem Merge" hinzu: Linter starten, Typ-Prüfung, und einen Test für den Happy Path.

Ergebnis: In der zweiten Funktion reduzierten sich manuelle Korrekturen von 47 auf 3 (alle logisch, nicht stilistisch). Die Zeit für Code-Review eigener PRs sank von 45 Minuten auf 5. Der Agent begann, Commits im korrekten Format selbstständig zu generieren. Nach drei Funktionen erweiterte Anna QWEN.md um die Regel „neue Abhängigkeit wird diskutiert" — der Agent schlug lodash vor, sie lehnte ab und ersetzte durch native Implementierung, was das Bundle um 12 KB reduzierte.

Gelernte Lektionen: git diff nach der ersten Funktion — ein kostenloses Audit impliziter Regeln: jede manuelle Korrektur ist ein Kandidat für QWEN.md

QWEN.md amortisiert sich in einer Funktion: 2 Stunden Schreiben vs 20+ Stunden Einsparung in nachfolgenden Iterationen

Konkrete Beispiele in QWEN.md sind wichtiger als abstrakte Regeln: „pino verwenden" ist schlechter als „pino mit Level aus config.logLevel verwenden, nicht console.log"

QWEN.md — lebendiges Dokument: es wächst mit dem Projekt, beginnt aber mit realen Schmerzen, nicht vermuteten

Verwandte Konzepte: QWEN.md und implizite Regeln

Verfassungsprüfung

Grenze tech-stack.md / requirements.md

Lerntipps: Arbeiten Sie das Material sequentiell durch: zuerst „wofür eine Verfassung" verstehen, dann die Struktur jeder Datei studieren, dann das Interview mit dem Agenten üben. Das Überspringen eines Schritts führt zur formalen Dokumentenerstellung ohne Verständnis ihrer Rolle.

Nutzen Sie die Methode des „parallelen Lesens": Öffnen Sie gleichzeitig das Kursursprungsdokument und die Beispiele aus practice_exercises, vergleichen Sie die Struktur. Dies stärkt die Mustererkennung für eigenständige Arbeit.

Führen Sie Übung 4 (Widerspruchsprüfung) unbedingt mit Timer durch: Beschränken Sie sich auf 10 Minuten wie bei einem echten Code-Review. Zeitdruck trainiert die Identifizierung kritischer Probleme statt „perfekter" Analyse.

Erstellen Sie Dateivorlagen für die Verfassung in Ihrem Editor mit Platzhaltern wie [BESTIMMUNG], [HAUPTZIELGRUPPE_1]. Verwenden Sie sie bei jedem neuen Projekt — das physische Ritual beschleunigt die innere Aneignung der Methodologie.

Führen Sie ein „Agenteninterview-Tagebuch": Notieren Sie, welche Fragen der Agent stellte, welche Antworten Sie gaben, was schiefging. Nach 3-4 Projekten bildet sich eine persönliche Bibliothek „klassischer Fallen" und effektiver Formulierungen.

Für Kinesthetiker: Drucken Sie eine physische Karte mit dem Kriterium „überlebt fünf Funktionen" und legen Sie sie neben den Monitor. Bei jeder Entscheidung bewegen Sie die Karte physisch: „das in den Stack?" — auf tech-stack.md legen, „das in die Funktion?" — auf requirements.md.

Für Auditive: Sprechen Sie die Verfassungsprüfschritte vor dem Commit laut aus: „SQLite im Stack? Phasen passen in Branches? Mission sagt, wer den Code liest?" — der Rhythmus der Sprache schafft mnemonische Stütze.

Für Visuelle: Zeichnen Sie ein Diagramm „Lebenszyklus einer Entscheidung" — von der Idee über den „fünf Funktionen"-Test bis zum endgültigen Platz in der Dokumentation. Farbcodierung (rot — tech-stack.md, blau — requirements.md, grün — roadmap.md) beschleunigt Entscheidungen in Echtzeit.

Zusätzliche Ressourcen: Ursprüngliches Kursdokument (Teil 6): Quellmaterial, auf dem dieser Leitfaden basiert — wenden Sie sich zur Klärung von Details und Code-Beispielen

Dokumentation hono: https://hono.dev — minimalistisches Web-Framework, im Kurs empfohlen für serverseitiges TypeScript

Conventional commits: https://www.conventionalcommits.org — Standard für Commit-Format, typisches Element von QWEN.md

Sqlite auf node.js: https://github.com/WiseLibs/better-sqlite3 — beliebter Treiber für SQLite-Arbeit ohne ORM, entspricht der Kursphilosophie

Vitest: https://vitest.dev — Testframework, erwähnt in tech-stack.md-Beispielen

Vorlage mission.md von gitlab: https://about.gitlab.com/handbook/engineering/ux/technical-writing/workflow/#documentation-templates — alternative Ansätze zur Strukturierung der Produktmission

Artikel „architecture decision records": https://adr.github.io — verwandte Praxis der Fixierung langfristiger Entscheidungen, erweitert das Verständnis der Rolle von tech-stack.md

Zusammenfassung: Die Verfassung ist das Herz des SDD-Projekts: drei Dateien (mission.md, tech-stack.md, roadmap.md), erstellt vor der ersten Funktion, verhindern chaotisches „Erraten" durch den Agenten und gewährleisten architektonische Integrität. Schlüsselkompetenzen dieses Teils: langfristige Entscheidungen (Stack) und Funktionsentscheidungen (requirements) am „fünf Funktionen"-Test unterscheiden; strukturiertes Interview mit dem Agenten statt manuellen Schreibens führen; implizite Regeln durch git-diff-Analyse identifizieren und in QWEN.md fixieren; Verfassung auf Widersprüche und Phasengröße vor dem Commit prüfen. Die Praxis zeigt: 2 Stunden für Verfassung und QWEN.md sparen 20+ Stunden in nachfolgenden Iterationen. Die Verfassung lebt — sie wächst mit dem Projekt, aber ihre Abwesenheit am Anfang garantiert architektonische Schuld.