re_struct/.claude/commands/run-batch.md

Du bist der Batch-Orchestrator. Führe die folgenden Schritte der Reihe nach aus. Dieser Command ist eigenständig — er ersetzt den manuellen session-start/end-Zyklus. Ein vorheriges session-start ist nicht nötig; die Konsolidierung (Schritt 4) übernimmt session-end.

Beachte dabei strikt die Regeln aus @rules/batch-orchestration.md

Wichtig: Lies während des gesamten Batch-Laufs NIE die vollen Output-Dateien der Subagents. Arbeite ausschließlich mit den Subagent-Summaries. Die Output-Dateien sind für den User zur Review.

Schritt 1 — Phase und Tasks erkennen

1. Lies CLAUDE.md und bestimme die aktive Phase und das Arbeitsverzeichnis
2. Lies die task.md der aktiven Phase
3. Finde den Arbeitsabschnitt: den ersten Abschnitt mit ### Unterüberschriften und - Checkboxen
4. Ignoriere flache Checkbox-Listen ohne Unterüberschriften (das ist die Definition of Done)
5. Erstelle eine nummerierte Liste aller offenen Tasks (- ) mit:
   • Nummer
   • Task-Beschreibung
   • Gruppenname (### Überschrift)
   • Output-Pfad (falls im Text erkennbar)

Schritt 1.5 — Berechtigungen prüfen

Prüfe ob die folgenden Tools ohne Nachfrage verfügbar sind: Read, Write, Edit, Glob, Grep, Agent.

Falls Berechtigungen fehlen, zeige dem User:

Für den Batch-Modus werden folgende Berechtigungen benötigt: [Liste] Bitte konfiguriere sie in .claude/settings.json oder .claude/settings.local.json:

{ "permissions": { "allow": ["Read", "Write", "Edit", "Glob", "Grep", "Agent"] } }

Brich dann ab. Starte den Batch NICHT ohne bestätigte Berechtigungen.

Schritt 2 — Parameter abfragen

Falls der User beim Aufruf keine Parameter angegeben hat, oder Parameter fehlen, frage interaktiv:

Zeige die Task-Liste aus Schritt 1 und frage:

Ich sehe N offene Tasks in Phase X: [nummerierte Liste mit Gruppenname]

Welche Tasks? (alle / Nummern z.B. 1-3 / Gruppenname z.B. wave-3) Checkpoint-Modus? (after-each [Standard] / after-batch:N / at-end)

Falls der User keinen Checkpoint-Modus angibt, verwende after-each als Standard.

Warte auf die Antworten des Users.

Zeige dann eine Zusammenfassung des geplanten Batch-Laufs:

Batch-Plan:

• Tasks: [ausgewählte Tasks]
• Gruppen: [Gruppenreihenfolge, parallele Tasks markiert]
• Checkpoint: [gewählter Modus]
• Phase: [aktive Phase]

Soll ich starten?

Warte auf Bestätigung.

Schritt 3 — Gruppen abarbeiten

Arbeite die Gruppen in der Reihenfolge ihrer ### Überschriften ab.

Für jede Gruppe:

Context bestimmen:

• Basis: rules der aktiven Phase + status.md
• Phasen-spezifisch: falls Phase-Rules Context definieren (z.B. discovery-waves.md), folge diesen
• Task-spezifisch: falls der Task (context: datei1, datei2) deklariert, lade diese
• Fallback: alle existierenden Output-Dateien vorheriger Gruppen im aktuellen Batch
• Bevorzuge immer kondensierte Dokumente (structure-map.md, status.md) gegenüber Roh-Quellen. Raw Code nur wenn der Task es explizit erfordert.

Tasks dispatchen:

• Falls die Gruppe nur einen Task hat: dispatche einen Subagent
• Falls die Gruppe mehrere Tasks hat: dispatche alle als parallele Subagents

Für jeden Subagent verwende das Agent-Tool mit folgendem Prompt-Muster:

Du bist ein Subagent im re:struct Framework.

Dein Auftrag: [Task-Beschreibung aus task.md] Output-Datei: [Pfad] Context-Dateien zum Lesen: [Liste der Context-Dateien] Regeln: Beachte @rules/framework-constraints.md und @rules/language-conventions.md

Schreibe dein Ergebnis in die Output-Datei. Gib am Ende eine Zusammenfassung in 2-3 Sätzen zurück (NUR die Zusammenfassung als Return-Value, nicht in die Datei).

Auf Abschluss warten:

• Warte bis alle Subagents der Gruppe fertig sind
• Sammle die Summaries und eventuelle Fehler

Fehlerbehandlung:

• Falls ein Subagent fehlschlägt: notiere den Fehler, blockiere aber nicht andere parallele Tasks
• Fehlgeschlagene Tasks werden beim Checkpoint gemeldet

Checkpoint-Logik

Nach jeder abgeschlossenen Gruppe: prüfe ob ein Checkpoint fällig ist.

after-each: Immer Checkpoint nach jeder Gruppe. after-batch:N: Checkpoint nach jeder N-ten Gruppe. Zähler beginnt bei 1. at-end: Kein Checkpoint bis alle Gruppen fertig sind.

Bei einem Checkpoint:

Zeige dem User:

Checkpoint — Gruppe "[Gruppenname]" abgeschlossen

Task	Output	Status	Summary
[Name]	[Dateipfad]	✅ / ❌	[2-3 Sätze]

Befehle: weiter | stopp | zeig mir [datei]

• Bei weiter: nächste Gruppe starten
• Bei stopp: gehe zu Schritt 4 (Konsolidierung)
• Bei zeig mir [datei]: Datei lesen und anzeigen, dann erneut fragen

Phasen-Checkpoint (immer aktiv): Prüfe nach jeder Gruppe ob alle offenen Tasks der Phase erledigt sind (prüfe die DoD-Sektion). Falls ja: STOPP, unabhängig vom Checkpoint-Modus:

Alle Tasks dieser Phase sind abgeschlossen. Ein Phasenwechsel ist möglich. Nutze /project:phase-transition wenn du bereit bist.

Gehe dann zu Schritt 4.

Schritt 4 — Konsolidierung

Führe die folgenden Updates durch (nur der Orchestrator, nie Subagents):

1. task.md aktualisieren:

   • Markiere erfolgreich abgeschlossene Tasks mit
   • Fehlgeschlagene Tasks bleiben

2. status.md aktualisieren:

   • Aktuellen Stand in 2-3 Sätzen
   • Liste der abgeschlossenen Tasks
   • Falls Fehler auftraten: dokumentiere sie
   • Nächste Schritte (verbleibende offene Tasks)

3. decisions-log.md:

   • Falls während des Batch Entscheidungen relevant wurden: Einträge erstellen
   • Format: siehe docs/templates/decisions-log-entry.md

4. Phasen-spezifische Shared Artifacts:

   • Falls die Phase geteilte Dokumente hat (z.B. capabilities-inventory.md in Discovery): aktualisiere sie mit den konsolidierten Ergebnissen aus den Subagent-Summaries

Schritt 5 — Commit-Vorschlag

Zeige dem User:

Batch abgeschlossen. Zusammenfassung:

• [N] Tasks erfolgreich, [M] fehlgeschlagen
• Aktualisiert: task.md, status.md [, decisions-log.md] [, weitere]
• Output-Dateien: [Liste der neuen Dateien]

Soll ich einen Commit erstellen?

Falls ja: erstelle einen Commit mit einer Nachricht die den Batch beschreibt, z.B. feat: complete Wave 2 entry-points analysis