Erweiterte Funktionen

Diese Funktionen ermöglichen kollaborative, groß angelegte und parallele SDD-Workflows. Sie bauen auf dem grundlegenden Lebenszyklus auf — stellen Sie sicher, dass Sie mit dem SDD-Workflow vertraut sind, bevor Sie sie verwenden.

1. Spec-Verzweigung

Werkzeuge: branch_spec, merge_spec_branch

Stellen Sie sich Spec-Branches wie Git-Branches vor — aber für Ihre Pläne. Erstellen Sie eine A/B-Variante, um einen anderen Implementierungsansatz zu erkunden, bevor Sie sich festlegen.

Wann verwenden:

• Architekturentscheidungen mit mehreren gültigen Ansätzen
• UI-Experimente (Redesign-Spec A vs. inkrementelle Spec B)
• Wenn ein Stakeholder eine alternative Schätzung anfordert

Wann NICHT verwenden

Erstellen Sie keine Spec-Branches für geringfügige Wortänderungen oder Tippfehler. Branches sind für grundlegend unterschiedliche Implementierungsstrategien — wenn beide Ansätze dieselben Dateien berühren, treffen Sie die Entscheidung zuerst und implementieren Sie dann.

So funktioniert es:

1. Verzweigen Sie eine bestehende Spec, um eine Variante zu erstellen:

"Verzweige Spec SPEC-042 als variant-B mit Microservices-Ansatz"
→ branch_spec(specId: "SPEC-042", branchName: "variant-b", description: "...")

2. Entwickeln Sie beide Varianten unabhängig voneinander. Jeder Branch hat eigene Akzeptanzkriterien und eine eigene PLAN.md.

3. Vergleichen Sie die Schätzungen und wählen Sie die bessere. Dann führen Sie zusammen:

"Führe Branch variant-b in Spec SPEC-042 zusammen"
→ merge_spec_branch(specId: "SPEC-042", branchName: "variant-b")

Planu erkennt Konflikte zwischen Varianten und kennzeichnet widersprüchliche Kriterien vor dem Merge.

---

2. Spec-Federation

Werkzeuge: federate_specs, federation_status

Teilen und synchronisieren Sie Specs über mehrere Repositories hinweg. Unverzichtbar für Monorepos, Microservices und Plattform-Teams.

Wann verwenden:

• Das Plattform-Team besitzt gemeinsame Specs (Authentifizierung, Zahlungen, Logging)
• Monorepo mit mehreren Services, die Anforderungen teilen
• API-Vertrags-Specs, die zwischen Frontend- und Backend-Repos geteilt werden

Wann NICHT verwenden

Federieren Sie keine Specs, die eng an die internen Details eines einzelnen Services gekoppelt sind. Federation ist für geteilte Verträge — nicht zum Replizieren von Implementierungsdetails zwischen Repos.

So funktioniert es:

1. Im Quell-Repository veröffentlichen Sie eine Spec an ein nachgelagertes Ziel:

"Federiere Spec SPEC-010 nach team/payments-service"
→ federate_specs(...)

2. Im Ziel-Repository erscheint die Spec schreibgeschützt mit einem Link zur Quelle. Nachgelagerte Teams können sie referenzieren, aber nicht direkt bearbeiten.

3. Änderungen werden automatisch oder auf Anfrage synchronisiert. Prüfen Sie den Synchronisierungsstatus jederzeit:

"Prüfe Federation-Status"
→ federation_status()

Der Statusbericht zeigt, welche Specs gegenüber ihrer Quelle voraus, zurück oder in Konflikt sind.

---

3. Agenten-Team-Orchestrierung

Werkzeuge: plan_team_distribution, orchestrate_runtime, orchestrate_agents

Verteilen Sie eine große Spec auf mehrere parallele KI-Agenten, jeder mit exklusivem Besitz über bestimmte Dateien.

Wann verwenden:

• Specs, die 5+ unabhängige Module berühren
• Große Refaktorierungen mit klar definierten Dateigrenzen
• Zeitkritische Funktionen, die parallelisiert werden können

Wann NICHT verwenden

Orchestrieren Sie keine kleinen Specs (weniger als 3 Dateien). Der Koordinierungsaufwand überwiegt die eingesparte Zeit. Vermeiden Sie auch die Orchestrierung, wenn Module eng gekoppelt sind — Agenten können dateiübergreifende Konflikte nicht während der Ausführung lösen.

So funktioniert es:

1. Planung der Verteilung — Planu analysiert die Spec und schlägt Agentenzuweisungen vor:

"Plane Team-Verteilung für SPEC-099"
→ plan_team_distribution(specId: "SPEC-099")
→ Ergebnis: 3 Agenten, Dateizuweisungen, geschätzte Zeit

2. Starten Sie die Orchestrierung — Agenten arbeiten parallel, jeder mit seinen zugewiesenen Dateien:

"Orchestriere SPEC-099 mit 3 Agenten"
→ orchestrate_runtime(specId: "SPEC-099", agentCount: 3)
→ Agenten arbeiten parallel, Planu überwacht den Fortschritt

3. Überwachen und abschließen:

"Prüfe Orchestrierungsstatus"
→ orchestrate_agents(action: "status")

Von Planu durchgesetzte Regeln:

• Jeder Agent besitzt exklusive Dateien — keine gleichzeitigen Bearbeitungen
• Integrationstests werden nach Abschluss aller Agenten ausgeführt
• Konflikte werden markiert, nicht automatisch aufgelöst

---

Nächste Schritte

• Siehe die Werkzeug-Referenz für vollständige Parameterdokumentation
• Zurück zum SDD-Workflow für den grundlegenden Lebenszyklus