Teil 8. Implementierung des Features

Die Implementierung beginnt erst nach der Überprüfung und dem Commit der Feature-Spezifikation. In dieser Phase wechseln Sie den Arbeitsmodus des Agenten: Er ist nicht mehr Interviewer oder Produktteditor, sondern Ausführer eines konkreten Plans.

Die wichtigste Regel: Bitten Sie nicht um „mach das Feature“ ohne Verweis auf die Spezifikation. Bitten Sie um die Implementierung konkreter Aufgabengruppen.

Sitzungsvorbereitung

Überprüfen Sie den Branch:

git branch --show-current
git status --short

Starten Sie Qwen Code:

qwen

Löschen Sie den Kontext:

/clear

Geben Sie dann eine präzise Eingabe:

Lies @QWEN.md, @specs/mission.md, @specs/tech-stack.md,
@specs/2026-05-01-hello-hono/requirements.md,
@specs/2026-05-01-hello-hono/plan.md,
und @specs/2026-05-01-hello-hono/validation.md.

Implementiere die verbleibenden Aufgabengruppen aus dem Plan.
Halte die Implementierung minimal.
Füge keine Features außerhalb der Grenzen hinzu.
Nach Änderungen nenne die geänderten Dateien und die Überprüfungsbefehle.

Wann die Implementierung aufgeteilt werden sollte

Wenn Aufgabengruppen Datenbank, Authentifizierung, Zahlungen, Migrationen oder Sicherheit betreffen, implementieren Sie sie einzeln:

Implementiere nur Gruppe 1 aus @specs/2026-05-01-hello-hono/plan.md.
Stoppe nach der Liste der geänderten Dateien.

Gehe nicht zu Gruppe 2 über.

Für eine einfache Hello-Hono-Phase können alle Gruppen auf einmal implementiert werden. Für komplexe Phasen — nur in kleinen Blöcken.

Was während der Agentenarbeit zu beobachten ist

Warten Sie nicht passiv auf das Ende. Achten Sie auf Abweichungsanzeichen:

• der Agent fügt eine neue Abhängigkeit hinzu, die nicht in tech-stack.md angegeben ist;
• der Agent ändert Dateien außerhalb der Aufgabengrenzen;
• der Agent implementiert eine zukünftige Phase der Roadmap;
• der Agent schreibt README oder Styles ohne Grund um;
• der Agent überspringt Überprüfungsbefehle.

Wenn dies geschieht, stoppen Sie:

Stoppe. Diese Änderung liegt außerhalb der Feature-Spezifikation.
Lies @specs/2026-05-01-hello-hono/requirements.md erneut.
Erkläre vor Korrekturen, warum die zusätzliche Änderung nötig ist.

Typische Agentenfehler, auf die man sich vorbereiten sollte

Nicht jede Implementierungssitzung verläuft reibungslos. Hier sind häufig wiederkehrende Fehler, die bei Studierenden am häufigsten auftreten:

1. Dateihalluzination. Der Agent schreibt „korrigierte src/utils/format.ts“, obwohl es diese Datei im Repository nicht gibt. Gegenmittel: Vor dem Commit führen Sie git diff --stat aus und vergleichen jede Datei aus der Agentenantwort mit der Realität.

1. Falsche Bibliotheksversion. Der Agent verwendet eine API, die in einer späteren Hono-Version als in package.json enthalten ist. Gegenmittel: Beim ersten Fehler von tsc oder zur Laufzeit prüfen Sie npm list <package> und bitten den Agenten, die Version zu überprüfen.
2. **Stille Änderung von tsconfig.json.** Um „Typfehler zu beheben“, lockert der Agent strict oder fügt // @ts-ignore hinzu. Gegenmittel: In der Praxis aus Teil 5 ist der strenge Modus fixiert — betrachten Sie jede Änderung von tsconfig.json als Grenzverletzung.
3. Übergang zur nächsten Phase. Bei der Implementierung von Phase 1 fügt der Agent aus Gewohnheit eine Tabelle aus Phase 2 hinzu. Gegenmittel: Fordern Sie nach der Implementierung sofort an: „Liste die implementierten Dateien auf und vergleiche sie mit der Aufgabengruppe“.
4. Ersetzen von Überprüfungen. Der Agent schreibt „alles funktioniert, überprüft mit curl“, hat aber curl nicht ausgeführt. Gegenmittel: Überprüfen Sie die Befehle aus validation.md selbst; wenn es in der Sitzung kein Ausführungswerkzeug gibt, konnte der Agent nicht überprüfen.

Diese Fehler sind kein Grund, den Agenten abzulehnen, aber ein Grund, ihm nicht blind zu vertrauen und die Faktenbefehle aus validation.md und git diff griffbereit zu halten.

Beispiel einer minimalen Implementierung

Erwartete Änderungen für Hello Hono:

package.json
package-lock.json
src/index.tsx
src/pages/Home.tsx

src/components/Layout.tsx
static/style.css
tsconfig.json

Wenn der Agent eine Datenbank, Authentifizierung, mehrere Seiten oder ein Testframework hinzufügt, ist dies eine Grenzverletzung der Aufgabe.

Überprüfung nach der Implementierung

Führen Sie die Befehle selbst aus, vertrauen Sie nicht nur dem Agenten:

npm run typecheck
npm run dev

In einem anderen Terminal:

curl -s http://localhost:3000 | head
curl -s http://localhost:3000 | rg "AgentClinic"

Wenn der Server startet, aber die Typüberprüfung fehlschlägt, ist das Feature nicht fertig. Wenn die Typüberprüfung besteht, aber das HTML nicht mit der Überprüfung aus validation.md übereinstimmt, ist das Feature nicht fertig.

Commit der Implementierung

Vor dem Commit:

git diff --stat
git diff

Bitten Sie Qwen Code, die Änderungen kurz zu erklären:

Erkläre kurz die Unterschiede des aktuellen Branches zu main.
Gruppiere die Änderungen nach Aufgabengruppen aus der Spezifikation.
Ändere keine Dateien.

Dann:

git add .
git commit -m "Implement Hello Hono baseline"

Praxis

• [ ] Löschen Sie den Qwen-Kontext.
• [ ] Geben Sie dem Agenten nur die benötigten Spezifikationen.
• [ ] Implementieren Sie die Aufgabengruppen.
• [ ] Überprüfen Sie die Typen und führen Sie manuelles curl aus.
• [ ] Überprüfen Sie die Änderungen.
• [ ] Machen Sie einen Commit.

Kontrollfragen

1. Warum sollte die Implementierung besser nach /clear beginnen?
2. Wann können alle Aufgabengruppen auf einmal implementiert werden, und wann muss man sie einzeln durchführen?
3. Wie erkennt man, dass der Agent begonnen hat, eine zukünftige Phase zu implementieren?