impl-next

name	impl-next
description	Aktuellen Fortschritt ermitteln und den nächsten Implementierungsschritt durchführen. Erstellt Feature-Branch, implementiert, testet und erstellt PR.
disable-model-invocation	true

Nächsten Schritt implementieren

Dieser Befehl ermittelt den aktuellen Fortschritt und implementiert den nächsten Schritt.

Anweisungen

1. Fortschritt ermitteln

Lies docs/implementation/README.md und erstelle eine Übersicht:

• Für jedes Epic: Wie viele Phasen sind offen / in Arbeit / abgeschlossen?
• Für jede Phase mit Status "In Arbeit" oder erste offene Phase: Wie viele Schritte sind abgehakt (- [x]) vs. offen (- [ ])?
• Welche Phasen sind aktuell auf einem Integration-Branch in Arbeit?

Prüfe zusätzlich den aktuellen Git-Branch:

git branch --show-current

2. Aktive Phase bestimmen

Fall A: Auf einem Feature-Branch (z.B. feat/cc-appearance-model)

• Prüfe welcher Integration-Branch die Basis ist
• Die Phase ergibt sich aus dem Integration-Branch
• Weiter mit Schritt 3

Fall B: Auf einem Integration-Branch (z.B. integration/phase-10-cc-data-model)

• Die Phase ergibt sich aus dem Branch-Namen
• Es wird ein neuer Feature-Branch für den nächsten Schritt erstellt
• Weiter mit Schritt 3

Fall C: Auf main, keine Phase in Arbeit

• Zeige dem User die Übersicht aller Epics mit Fortschritt
• Zeige Phasen die als nächstes implementiert werden können (ausgearbeitet + Abhängigkeiten erfüllt)
• Frage den User welche Phase gestartet werden soll
• Erstelle den Integration-Branch

Fall D: Auf main, aber Integration-Branch(es) existieren

• Prüfe existierende Integration-Branches:

  git branch -r --list "origin/integration/*"
  

• Zeige welche Phasen in Arbeit sind
• Frage ob der User eine davon fortsetzen oder eine neue starten möchte

3. Phase-Dokumentation prüfen

Prüfe ob die aktuelle Phase vollständig ausgearbeitet ist:

docs/implementation/phase-X-*/
├── README.md
├── X.1-...md
├── X.2-...md
└── ...

STOPP falls Phase nicht ausgearbeitet ist:

• Informiere den User
• Empfehle /plan-phase auszuführen
• Fahre NICHT mit Implementierung fort

4. Spezifikationen lesen (PFLICHT)

Lies ZUERST die verlinkten Spezifikationen:

• Spezifikationen des Epics (im Master-Plan beim Epic-Abschnitt verlinkt)
• Haupt-Spezifikation des Epics (falls vorhanden, z.B. Character Creator Spec)
• Spezifikationen der Phase (in der Phase-README verlinkt)
• Verstehe die Architektur-Entscheidungen und Konzepte

WICHTIG: Die Spezifikationen sind bindend. Implementierungen müssen den Spezifikationen entsprechen.

5. Schritt-Dokumentation lesen

Lies die Dokumentation für den nächsten offenen Schritt:

• docs/implementation/phase-X-*/X.Y-step-name.md
• Verstehe Ziel, Anforderungen, erwartetes Ergebnis

5a. Schritt-spezifische Spezifikationen lesen (PFLICHT)

Prüfe ob die Schritt-Dokumentation einen ## Relevante Spezifikationen Abschnitt enthält.

Falls vorhanden:

1. Lies ALLE dort verlinkten Spezifikationen vollständig
2. Achte besonders auf die genannten Sektionen/Kapitel
3. Verstehe die Hintergründe, Architektur-Entscheidungen und Begründungen
4. Diese Spezifikationen sind bindend für die Implementierung dieses Schritts

Warum dieser Schritt existiert: Manche Phasen (z.B. Netzwerk, Character Platform) haben umfangreiche Spezifikations-Dokumente die kritisches Detailwissen enthalten. Die Schritt-Dokumentation allein reicht nicht — die Specs liefern den Kontext für warum etwas so gebaut wird und welche Fallstricke zu vermeiden sind.

Falls kein ## Relevante Spezifikationen Abschnitt vorhanden: Weiter mit Schritt 5b.

5b. Impact Notes prüfen

Prüfe ob die Phase-README einen ## Impact Notes Abschnitt enthält.

Falls Impact Notes vorhanden:

1. Lies alle Impact Notes vollständig
2. Prüfe ob der aktuelle Schritt von einer Impact Note betroffen ist
3. Falls ja → User warnen:

   ⚠ Impact Note gefunden:
     Phase Y (Name) benötigt Änderungen an [Datei/Interface].
     Wird in Phase Y, Schritt Y.Z adressiert.
   
     Optionen:
     → Schritt normal implementieren (Änderung kommt in Phase Y)
     → Änderung jetzt vorziehen (Interface schon jetzt erweitern)
     → Schritt überspringen und erst Impact klären
   

4. User entscheiden lassen, dann entsprechend fortfahren

Falls keine Impact Notes oder Schritt nicht betroffen: Weiter mit Schritt 6.

6. Architektur-Review

Bevor implementiert wird:

• Lies relevante bestehende Dateien
• Verstehe Abhängigkeiten und Schnittstellen
• Prüfe ob Voraussetzungen erfüllt sind

7. Branch-Management

Neuen Feature-Branch vom Integration-Branch erstellen:

git checkout integration/phase-X-beschreibung
git pull origin integration/phase-X-beschreibung
git checkout -b <type>/fachliche-beschreibung

Branch-Typ passend zum Inhalt wählen:

• feat/ — Neue Funktionalität
• fix/ — Bugfix
• refactor/ — Code-Umbau
• test/ — Tests
• docs/ — Dokumentation
• chore/ — Setup, Config

Falls bereits auf richtigem Feature-Branch:

• Weiter mit Implementierung

8. Implementierung durchführen

Führe die Schritte aus der Dokumentation durch:

• Befolge die Anweisungen exakt
• Erstelle/modifiziere Dateien wie beschrieben
• Schreibe Tests für neue Funktionalität

9. Tests schreiben

Für jede neue Klasse/Modul:

• Unit Tests erstellen
• Pfad: Packages/.../Tests/Runtime/ oder Tests/Editor/
• Test-Klasse mit [TestFixture] Attribut
• Mindestens: Konstruktion, Hauptfunktionalität

10. Kompilierung prüfen

powershell -Command "Get-Content 'C:\Users\marcu\AppData\Local\Unity\Editor\Editor.log' -Tail 100 | Select-String -Pattern 'error|CS\d{4}'"

Bei Fehlern: Beheben bevor Commit erstellt wird.

11. Commit erstellen

git add <geänderte-dateien>
git commit -m "feat(phase-X): X.Y Beschreibung"

WICHTIG:

• Kein Claude-Footer (kein "Co-Authored-By")
• Commit-Message exakt wie in Schritt-Dokumentation angegeben

12. Feature-Branch in Integration-Branch mergen

Feature-Branches werden direkt in den Integration-Branch gemerged (kein PR nötig):

git checkout integration/phase-X-beschreibung
git merge <type>/fachliche-beschreibung
git push origin integration/phase-X-beschreibung

Danach Feature-Branch aufräumen:

git branch -d <type>/fachliche-beschreibung

Hinweis: PRs werden nur für Integration → main erstellt, nicht für Feature → Integration.

13. Dokumentation aktualisieren

In docs/implementation/README.md:

• Checkbox abhaken: - [ ] → - [x]

In docs/implementation/phase-X-*/README.md:

• Checkbox abhaken
• Status aktualisieren

git add docs/implementation/
git commit -m "docs: Markiere Schritt X.Y als abgeschlossen"

14. Nächsten Schritt anzeigen

Informiere den User:

• Epic und Phase in der wir arbeiten
• Was wurde implementiert
• Welcher Schritt ist als nächstes dran
• Fortschritt der Phase (z.B. "3/6 Schritte abgeschlossen")
• Ob die Phase abgeschlossen ist (dann Phase-PR → main erstellen)

Beispiel-Ausgabe

Aktueller Fortschritt:

Epic "Lebendige Charaktere — Animation Pipeline":
  Phase 1: 4/4 ✅ | Phase 2: 0/5 | Phase 3: nicht ausgearbeitet

Epic "Character Creator & Ausrüstung":
  Phase 10: 2/6 (in Arbeit) | Phase 11–16: nicht ausgearbeitet

Aktueller Branch: integration/phase-10-cc-data-model
Nächster Schritt: 10.3 EquipmentSlot Enum und Grundtypen

Erstelle Feature-Branch: feat/cc-equipment-types
Basis: integration/phase-10-cc-data-model

Implementiere Schritt 10.3...
[Implementierung]

Commit: feat(phase-10): 10.3 EquipmentSlot Enum und Grundtypen
Merge: feat/cc-equipment-types → integration/phase-10-cc-data-model (direkt)

Fortschritt Phase 10: 3/6 Schritte abgeschlossen
Nächster Schritt: 10.4 ScriptableObject-Kataloge

Bei Phase-Abschluss

Wenn der letzte Schritt einer Phase abgeschlossen wurde:

1. Letzten Feature-Branch mergen in Integration-Branch (direkt, kein PR)
2. Phase-PR erstellen (Integration → main):

gh pr create --base main --title "feat: Phase X - Beschreibung" --body "..."

PR-Body Format:

## Summary
**Epic:** [Epic-Name]

- Schritt X.1: ...
- Schritt X.2: ...
- ...

## Test plan
- [ ] Test 1
- [ ] Test 2

3. Nach Merge: Integration-Branch aufräumen

git checkout main && git pull origin main
git branch -d integration/phase-X-beschreibung
git push origin --delete integration/phase-X-beschreibung

4. Master-Plan aktualisieren: Phase-Status → Abgeschlossen

WICHTIG: Keine Claude-Attribution in PRs!