Teil 12. MVP

Die MVP-Phase unterscheidet sich von der normalen Feature-Phase. Hier bitten Sie den Agenten, nicht ein kleines Stück zu implementieren, sondern den verbleibenden Teil des minimal lebensfähigen Produkts. Das ist riskant. So etwas sollten Sie nur tun, wenn die Projektregeln, Spezifikationen, Tests und Überprüfungen bereits ausreichend ausgereift sind.

MVP ist nützlich als Stresstest Ihrer eigenen Spezifikationen: Wenn der Agent, nachdem er die Konstitution und Feature-Spezifikationen gelesen hat, nicht das baut, was Sie erwarten, liegt das Problem nicht nur am Agenten. Höchstwahrscheinlich gaben die Spezifikationen zu viel Freiheit oder die Roadmap war unverständlich.

Wann man MVP versuchen kann

Günstiger Moment:

• mindestens zwei Features haben den vollständigen Zyklus durchlaufen;
• mission.md, tech-stack.md, roadmap.md sind aktuell;
• es gibt eine Testpolitik;
• es gibt ein Änderungsprotokoll;
• Sie sind bereit, eine große Menge an Änderungen zu überprüfen;
• die Roadmap enthält klare MVP-Grenzen.

Ungünstiger Moment:

• die allererste Phase des Projekts;
• keine Tests vorhanden;
• die Roadmap ist vage;
• der Agent verstößt bereits häufig gegen Grenzen;
• Sie können keine Zeit für die Überprüfung aufbringen.

MVP-Anfrage für Qwen Code

/clear
Lies @QWEN.md, @specs/mission.md, @specs/tech-stack.md, @specs/roadmap.md
und alle bestehenden Feature-Spezifikationen in @specs/.

Wir betrachten den MVP-Zweig.
Implementiere noch nichts.

Zuerst:
1. finde den minimalen Satz verbleibender Roadmap-Punkte, die für das MVP nötig sind;
2. liste die Risiken ihrer gemeinsamen Implementierung auf;
3. stelle mir drei Gruppen von Fragen zu MVP-Grenzen, Entscheidungen und Überprüfung.

Nach den Antworten:

Erstelle specs/YYYY-MM-DD-mvp/requirements.md, plan.md und validation.md.
Der Plan sollte in Gruppen aufgeteilt sein, damit ich die Implementierung in Teilen anfordern kann.
Schreibe noch keinen Implementierungscode.

Beispiel für MVP-Grenzen

# Anforderungen — MVP

## Grenzen

MVP soll AgentClinic zu einer zusammenhängenden kleinen Demonstration machen:
- Startseite;
- Agenten und Beschwerden;
- Therapien;
- Formular für Terminanfragen;
- Dashboard-Zusammenfassung;
- adaptive Stile;
- Tests kritischer Routen.

## Außerhalb der Grenzen

- Authentifizierung.
- Zahlung.
- E-Mail-Versand.
- Admin-Oberfläche für Bearbeitung.
- Externes Deployment.

## Entscheidungen

- SQLite-Tabellen und Anfangsdaten verwenden.
- Gesendete Formulare lokal speichern.
- Alles serverseitig rendern.
- Bestehendes Layout und CSS-Konventionen verwenden.

MVP-Überprüfung

Für das MVP muss die Überprüfung strenger sein als für ein kleines Feature:

## Automatische Überprüfungen

- npm run typecheck läuft erfolgreich.
- npm test läuft erfolgreich.
- Routentests decken /, /agents, /ailments, /therapies und /appointments ab.
- Datenbanktests decken Migrationen und Anfangsdaten ab.

## Manuelle Überprüfungen

- In einem frischen Klon können npm install, npm run seed und npm run dev ausgeführt werden.
- Die Hauptnavigation führt zu allen MVP-Seiten.
- Das Anmeldeformular verarbeitet korrekte und falsche Eingaben.
- Bei mobiler Breite 375px bricht das Layout nicht.
- Das Änderungsprotokoll beschreibt den MVP-Zweig.

## Abweichungsüberprüfung

- Authentifizierung wurde nicht hinzugefügt.
- Client-Framework wurde nicht hinzugefügt.
- Externe Dienste sind nicht erforderlich.

MVP-Implementierung in Gruppen

Auch wenn die MVP-Spezifikation eine einzige ist, muss die Implementierung nicht unbedingt in einem einzigen Befehl erfolgen.

Implementiere nur Gruppe 1 aus @specs/2026-05-05-mvp/plan.md.
Führe die nötigen Überprüfungen aus.
Stoppe und liste die geänderten Dateien auf.

Dann:

Implementiere Gruppe 2.
Bearbeite keine Dateien aus Gruppe 1, es sei denn, die Überprüfung erfordert es.

So behalten Sie Kontrollpunkte bei, die sich bequem überprüfen lassen.

Wann man aufhört: Timeboxing und Rollback zum letzten grünen Punkt

Der MVP-Zweig neigt dazu, auszuufern. Der Agent implementiert Gruppe 1, dann Gruppe 2, dann beginnt er „nebenbei" Gruppe 1 für Gruppe 3 anzupassen — und nach einer Stunde ist unklar, in welchem Zustand sich das Repository befindet.

Legen Sie im Voraus zwei Dinge fest: Zeitbudget und Rollback-Punkt.

Zeitbudget. Einigen Sie sich mit sich selbst (oder dem Team) auf ein Timebox für die Sitzung. Für ein Lern-MVP sind das 2–4 Stunden. Wenn die Timebox abgelaufen ist, nicht „noch eine Gruppe" — Stopp, Bewertung, Entscheidung.

Rollback-Punkt. Machen Sie vor jeder Gruppe von Aufgaben einen Commit, auch wenn er vorläufig ist. Nach dem Commit führen Sie npm run typecheck aus und dokumentieren, dass dieser Punkt grün ist:

git commit -m "MVP group 1: agents page"
npm run typecheck
git tag mvp-green-1

Wenn die nächste Gruppe alles zerbricht und Sie innerhalb einer angemessenen Zeit nicht verstehen, wie man es repariert — rollen Sie zum letzten grünen Zustand zurück:

git reset --hard mvp-green-1

Das ist keine Niederlage. Das ist ein Signal, dass die MVP-Spezifikation für die konkrete Gruppe nicht detailliert genug war — sie muss durch ein separates kleines Feature nachpräzisiert werden, anstatt in der MVP-Zweige weiterzumachen.

Anzeichen, dass man vor Ablauf der Timebox anhalten sollte:

• der Agent kehrt zweimal hintereinander zur gleichen Gruppe zurück und schließt sie nicht ab;

• git diff --stat zeigt Änderungen in Dateien, die in keiner Gruppe des Plans enthalten sind;
• nach einer weiteren Implementierung schlagen Tests fehl, die zuvor bestanden;
• der Agent beginnt zu fragen „kann ich nebenbei auch…" — das bedeutet, die MVP-Grenze behindert ihn, und die Spezifikationen müssen korrigiert werden, nicht die Grenze verschoben.

Nach dem MVP nach Spezifikationslücken fragen

Eine der besten Fragen:

Sag mir bezüglich der MVP-Implementierung, was du selbst ableiten musstest, weil es nicht explizit vorgegeben war.
Liste Lücken in den Spezifikationen auf und schlage Aktualisierungen für mission, tech-stack, roadmap oder die MVP-Spezifikation vor.
Ändere keine Dateien.

Wenn der Agent ehrlich antwortet „ich habe X selbst entschieden", ist das ein Geschenk. Notieren Sie X in den Spezifikationen, wenn die Entscheidung wichtig ist.

Praxis

• [ ] Beginnen Sie kein MVP, bevor zwei kleine Phasen nicht abgeschlossen sind.
• [ ] Bitten Sie Qwen Code, die Bereitschaft einzuschätzen.
• [ ] Erstellen Sie die MVP-Spezifikation.
• [ ] Legen Sie Timebox der Sitzung und Rollback-Punkt fest.
• [ ] Implementieren Sie MVP-Aufgabengruppen in Teilen und taggen Sie grüne Punkte.
• [ ] Führen Sie die Abweichungsüberprüfung durch.
• [ ] Aktualisieren Sie die Projektregeln und das Änderungsprotokoll.

Kontrollfragen

1. Warum ist MVP ein Stresstest für Spezifikationen?

1. Welche Bedingungen müssen vor einer großen Agenten-Implementierung erfüllt sein?
2. Warum muss man den Agenten nach dem MVP nach impliziten Ableitungen fragen?