orch-pipeline

Orchestrator-Pipeline (gemeinsame Engine)

Die orch-*-Skills sind dünne Hüllen. Sie implementieren keine Arbeit neu, sondern klassifizieren die Anfrage, wählen aus, welche Phasen dieser Pipeline ausgeführt werden, und delegieren jede Phase an einen vorhandenen ECC-Agenten oder -Befehl. Diese Datei ist diese Pipeline.

Rufen Sie einen Operationsskill (orch-add-feature, orch-fix-defect, …) auf, nicht direkt diese Engine. Diese Datei ist die Referenz, auf die sie verweisen.

Wann verwenden

• Indirekt geladen, sobald ein orch-*- Operationsskill ausgeführt wird.
• Nur direkt lesen, wenn eine neue Operation zur Familie hinzugefügt oder die gemeinsamen Phasen, Gates oder die Agentenzuordnung optimiert werden.

Die Operationsfamilie

Skill	Operation	Auslöser	Erster Schritt
orch-add-feature	Feature	Fähigkeit existiert noch nicht	recherchieren + neue Einheit planen
orch-change-feature	Anpassung	funktioniert, aber gewünschtes Verhalten weicht ab	vorhandenes Verhalten und dessen Tests ändern
orch-fix-defect	Fehlerbehebung	defekt; Verhalten ist falsch	als fehlschlagenden Test reproduzieren, dann beheben
orch-refine-code	Refactoring	Verhalten bleibt, Struktur verbessert sich	umstrukturieren, während Tests grün bleiben
orch-build-mvp	MVP	Bootstrap aus einem Design-/Spezifikationsdokument	Dokument einlesen → vertikale Einheiten erstellen

Diese Hüllen komponieren vorhandene ECC-Befehle, anstatt sie zu ersetzen: /feature-dev, /plan, /code-review, /build-fix, /refactor-clean und /gan-build, sowie den Skill tdd-workflow. Die orch-*-Familie fügt den gemeinsamen Größenklassifizierer und die beiden Gates hinzu, sodass ein Dach alle fünf Operationen konsistent abdeckt.

Schritt 0 – Größe klassifizieren (richtig dimensionieren)

Der Aufwand skaliert mit dem Änderungsumfang. Bewerten Sie die Anfrage anhand von drei Signalen, nehmen Sie die höchste Stufe, die ein Signal erreicht, und geben Sie das Ergebnis in einer Zeile aus, damit der Benutzer es überschreiben kann:

Stufe	Berührte Dateien	Neue Abhängigkeit / Vertrag	Designunsicherheit	Ausgeführte Phasen
trivial	1, einige Zeilen	keine	keine – die Änderung ist offensichtlich	4 → 5 → 6
klein	1 Datei / 1 Funktion	keine	klar, sobald man den Code liest	(1 light) → 4 → 5 → 6
normal	2–5 Dateien	vielleicht ein neues internes Modul	eine echte Entscheidung zu treffen	1 → 2 → 4 → 5 → 6
groß	viele / übergreifend	neue externe Abhängigkeit, öffentliche API oder ein Spezifikationsdokument	mehrere offene Fragen	1 → 2 → (3) → 4 → 5 → 6

Phase 0 (Intake) läuft immer und ist in der obigen Phasenmaske nicht aufgeführt. Der Tiebreaker: Alles, was einen Sicherheitsauslöser (unten) oder eine öffentliche API / einen öffentlichen Vertrag berührt, ist mindestens normal, unabhängig von der Dateianzahl.

Die Phasen

Jede Phase delegiert – sie führt die Arbeit nicht inline aus.

• 0. Intake – die Anfrage wiederholen. Bei orch-build-mvp das Spezifikations-/Design- Dokument lesen und Umfang, festgelegte Entscheidungen und eine Feature-Liste extrahieren.
• 1. Recherche & Wiederverwendung – gemäß rules/common/development-workflow.md: gh search repos / gh search code, dann Context7 / Anbieterdokumentation, dann Paketregistries, dann Exa. Bevorzugen Sie die Übernahme einer etablierten Implementierung gegenüber neuem Code.
• 2. Plan – an den Agenten planner delegieren (oder bei strukturellen Entscheidungen an architect / code-architect). Eine task_list als geordnete, dünne vertikale Einheiten ausgeben. → GATE 1.
• 3. Gerüst – nur orch-build-mvp: die erste End-to-End-Einheit aufbauen.
• 4. Implementieren (TDD) – jede Aufgabe durch den Agenten tdd-guide (oder den Skill tdd-workflow) treiben: rot → grün → refaktorisieren. Die Erstschritt-Regel der Operation einhalten.
• 5. Review – Agent code-reviewer / /code-review. security-reviewer immer dann hinzufügen, wenn der Diff einen Sicherheitsauslöser (unten) berührt.
• 6. Committen – Konventionelle Commits (feat: / fix: / refactor: / …), einer pro logischem Brocken. → GATE 2.

Die beiden Gates

Diese Familie ist gated, nicht autonom:

1. GATE 1 – nach dem Plan. Die task_list präsentieren; keinen Implementierungscode schreiben, bis der Benutzer zustimmt.
2. GATE 2 – vor dem Commit. Die Diff-Zusammenfassung und die vorgeschlagenen Nachrichten präsentieren; nicht committen, bis der Benutzer bestätigt.

Alles zwischen den Gates läuft ohne Unterbrechung.

Agenten-/Befehlszuordnung

Phase	Primär	Fallback / Eskalation
Intake / Verstehen	code-explorer	Vorhandene Pfade vor einer Anpassung, Fehlerbehebung oder einem Refactoring nachverfolgen
Plan	planner	architect, code-architect bei strukturellen Aufrufen
Implementieren	tdd-guide (oder Skill tdd-workflow)	build-error-resolver / /build-fix bei Build-Fehlern
Review	code-reviewer / /code-review	Sprachprüfer (python-reviewer, typescript-reviewer, …)
Sicherheit	security-reviewer	—
MVP interne Schleife	/gan-build "<Kurzbeschreibung>" --skip-planner	Treibt gan-generator → gan-evaluator an; --max-iterations / --pass-threshold anpassen

Den Sprachprüfer auf das Repository abstimmen (siehe die eigene CLAUDE.md des Repos).

Sicherheits-Review-Auslöser

security-reviewer einbeziehen, wenn der Diff Folgendes berührt: Authentifizierung oder Autorisierung, Benutzereingabe-Verarbeitung, Datenbankabfragen, Dateisystempfade, externe API-Aufrufe, Kryptografie oder Geheimnisse / Anmeldeinformationen. (Gemäß rules/common/security.md.)

Übergabeartefakte

Die Pipeline trägt keinen versteckten Zustand – die Planungsdokumente sind die Übergabe:

• task_list (vom Plan) treibt die Implementierungsschleife.
• Größere Arbeiten können auch PRD / Architektur / Systemdesign unter docs/ des Repos gemäß rules/common/development-workflow.md ausgeben.
• Review-Ergebnisse (CRITICAL / HIGH) müssen vor Gate 2 behoben werden.

Überprüfung

• Größenstufe wurde angegeben und entsprach der Arbeit
• Gate 1 (Plan) und Gate 2 (Commit) wurden beide eingehalten
• security-reviewer lief genau dann, wenn ein Sicherheitsauslöser berührt wurde
• Commits sind konventionell und auf eine logische Änderung beschränkt
• Neues / geändertes Verhalten hat Tests; Abdeckung ≥ 80 % gemäß rules/common/testing.md