Teil 13. Unterstützung eines bestehenden Projekts

SDD ist nicht nur für neue Projekte nützlich. In einem bestehenden Projekt können Spezifikationen aus Code, README, TODO, Aufgaben-Tracker, Änderungsprotokoll, Tests und Architekturdokumenten wiederhergestellt werden. Das ist kein „Umschreiben des alten Codes“. Das ist das Hinzufügen einer Absichtsschicht, die zuvor gefehlt hat.

Im Lernszenario kann man einen fertigen AgentClinic-MVP nehmen, specs/ löschen und so tun, als ob es ein bestehendes Projekt ist. Die Aufgabe von Qwen Code besteht darin, die Projektverfassung wiederherzustellen und dann den normalen SDD-Zyklus fortzusetzen.

Prozess für ein bestehendes Projekt

Bestehendes Projekt
  README.md
  TODO.md
  Quellcode
  Tests
  package.json

Wiederherstellung
  specs/mission.md
  specs/tech-stack.md
  specs/roadmap.md

Fortsetzung
  Feature-Spezifikation
  Implementierung
  Überprüfung
  Neuplanung

Anfrage zur Wiederherstellung der Projektverfassung

/clear
Wir fügen die spezifikationsbasierte Entwicklung in ein bestehendes Projekt ein.

Lies @README.md, @TODO.md, @package.json und schau dir den Quellcode-Baum an.
Schreibe die Anwendung nicht um.

Bereite die Projektverfassung vor:
- specs/mission.md
- specs/tech-stack.md
- specs/roadmap.md

Stelle mir vor dem Schreiben der Dateien genau drei Gruppen von Fragen:
1. Lücken in der Mission und der Zielgruppe.
2. Annahmen und unbekannte Stellen im Technologie-Stack.
3. Prioritäten der Roadmap nach TODO.md und aktuellem Code.

Wenn Qwen Code das Projekt ungenau beschreibt, korrigieren Sie die Verfassung vor dem nächsten Feature.

Was in einem bestehenden Projekt zu suchen ist

Bitten Sie den Agenten, Fakten zu sammeln, keine Vermutungen:

Analysiere das Projekt und erstelle eine Liste nur mit Fakten:
- gefundene Laufzeitumgebung und Framework;
- package.json-Skripte;
- Datenbank oder Speicherschicht;
- Routen und Seiten;
- Tests;
- TODO-Punkte;
- riskante Bereiche.

Trenne Fakten von Vermutungen.
Ändere keine Dateien.

Das schützt vor erfundener Architektur.

Beispiel tech-stack.md für ein bestehendes Projekt

# Technologie-Stack

## Erkannt

- TypeScript.
- Hono-Routen.
- JSX wird serverseitig gerendert.
- SQLite über better-sqlite3.
- Tests mit Vitest.

## Gefundene Konventionen

- Routen liegen in src/routes.
- Komponenten liegen in src/components.
- Datenbank-Migrationen liegen in src/db/migrations.
- Tests liegen in tests.

## Unbekannt

- Bereitstellungsziel ist nicht dokumentiert.
- CI-Konfiguration nicht gefunden.

- Linting- und Formatierungsrichtlinie nicht gefunden.

## Einschränkungen

- Kein neues Framework während des SDD-Anschlusses an ein bestehendes Projekt hinzufügen.
- Verhalten bestehender Routen beibehalten, wenn die Feature-Spezifikation nichts anderes erfordert.

Roadmap aus TODO

Wenn vorhanden:

# TODO

- Feedback-Formular hinzufügen.
- Über-uns-Seite hinzufügen.
- Kundenbewertungen hinzufügen.
- Karte zur Über-uns-Seite hinzufügen.

In kleine Phasen umwandeln:

## Phase 1: Feedback-Formular

- [ ] Tabelle feedback hinzufügen.
- [ ] Route /feedback hinzufügen.
- [ ] Formular und Liste hinzufügen.
- [ ] Validierungstests hinzufügen.

## Phase 2: Inhalt der Über-uns-Seite

- [ ] Statische Über-uns-Seite hinzufügen.
- [ ] Klinikgeschichte und kurze Mitarbeiterbiografien hinzufügen.
- [ ] Link in die Navigation hinzufügen.

## Phase 3: Karte auf der Über-uns-Seite

- [ ] Karten-Einbettungsmethode auswählen.
- [ ] Adresse hinzufügen.
- [ ] Ordentliches Verhalten bei nicht verfügbarer Karte sicherstellen.

Feature-Spezifikation für ein bestehendes Projekt

Nach der Verfassung den normalen Zyklus fortsetzen:

Finde die nächste unvollständige Phase in @specs/roadmap.md.
Erstelle eine Feature-Spezifikation dafür.

Verwende bestehende Code-Konventionen; füge keine neue Architektur hinzu.
Frage mich vor dem Schreiben der Dateien nach Grenzen, Entscheidungen und Kontext.

Besondere Risiken von SDD in einem bestehenden Projekt

• Der Agent kann zufälligen alten Code als architektonische Regel ansehen.
• README kann veraltet sein.
• TODO kann die aktuelle Priorität nicht widerspiegeln.
• Tests können Fehler festigen.
• Man darf das Projekt in einem Feature-Branch nicht „aufräumen“ ohne ausdrückliche Erlaubnis.

Deshalb müssen Spezifikationen eines bestehenden Projekts zwischen „beobachtet“, „entschieden“ und „unbekannt“ unterscheiden.

Praxis

1. Nehmen Sie ein bestehendes kleines Projekt.
2. Bitten Sie Qwen Code, eine Liste nur mit Fakten zu sammeln.
3. Erstellen Sie die Verfassung durch ein Interview.
4. Formen Sie eine Roadmap aus TODO und Lücken.
5. Implementieren Sie ein kleines Feature eines bestehenden Projekts über eine Feature-Spezifikation.

Kontrollfragen

1. Warum muss die wiederhergestellte Verfassung Fakten von Vermutungen trennen?
2. Welche Quellen kann man für die Roadmap eines bestehenden Projekts verwenden?
3. Warum darf man alten Code nicht „nebenbei“ refactoren, wenn es nicht in der Spezifikation steht?