# PARALLEL_EXECUTION — Parallelität und Branch-Safety

> **Geltungsbereich:** Red Queen Autonomous Engineering System v1
> **Status:** Verbindlicher Parallelitäts-Contract
> **Sprache:** Deutsch (verbindlich)

---

## 1. Grundregeln

- **Maximal 3 aktive Work Packages (WPs) gleichzeitig.**
- **Nur unabhängige WPs** dürfen parallel laufen. Bei Abhängigkeit (eine benötigt die andere)
  NICHT parallel ausführen.
- Red Queen überwacht Parallelität und erteilt Start-Freigabe (nicht der Sub-Agent).

## 2. Paralleles Coding — GIT WORKTREE (VERPFLICHTET)

- **Paralleles Coding ist VERPFLICHTET mit `git worktree` + eigenem branch.**
- **Kein paralleles Coding im selben Working Tree** — kein paralleler MAKER im selben
  Arbeitsverzeichnis/`main`.
- Jeder parallele Maker arbeitet in einem **eigenen, isolierten worktree** und **eigenem
  Branch**.

### 2.1 WORKTREE OWNERSHIP
| Feld | Regel |
|------|-------|
| Wer erstellt | Red Queen (Lead) legt worktree je parallel-WP an |
| Eigentümer | Genau EIN Sub-Agent pro worktree/Branch (Owner) |
| Zugriff | Kein anderer Sub-Agent schreibt in fremden worktree |
| Freigabe/Entfernung | Red Queen nach Integration; Owner darf nicht ungefragt löschen |

### 2.2 BRANCH NAMING
- Format: `rq/<TASK_ID>/<kurzbeschreibung>` (z. B. `rq/wp-042/fix-signal`).
- Ein Branch gehört genau **einem** worktree/Task.
- Kein Umbenennen/Übernehmen fremder Branches.

### 2.3 TASK OWNERSHIP
- **EIN TASK = EIN OWNER.** Kein paralleler Konflikt-Owner auf dieselbe Datei im selben Scope.
- Bevor paralleles Coding startet, wird der **FILE SCOPE** der Tasks geprüft: überlappende
  Dateien ⇒ Task-Nicht-unabhängig ⇒ nicht parallel.

### 2.4 FILE SCOPE & LOCKING
- Tasks, die **dieselben Dateien** berühren, dürfen **nicht** parallel laufen (Overlap ⇒ serialisieren).
- **Locking:** Red Queen führt Lock-Liste je Datei; Datei im Lock ⇒ anderer WP wartet.
- Der Owner erwirbt Lock vor Änderung und gibt es nach Merge/Beendigung frei.

### 2.5 RESULT COLLECTION
- Ergebnis je WP: Owner erstellt Commit auf eigenem Branch; Ergebnis/Test-Protokoll wird an
  Red Queen gemeldet (Maker→Checker→Tests→PASS, siehe §3).

### 2.6 CLEANUP
- Nach erfolgreichem Merge/Integration entfernt Red Queen den worktree und löscht den lokalen
  Branch (nur nach Ablage/Integration). Kein ungeordneter Abbruch von Active-Locks.
- Bei Abbruch: Branch/Worktree behalten + Red Queen-Check, worktree sauber räumen.

---

## 3. MAIN BRANCH SAFETY

- **Sub-Agenten arbeiten NIE direkt auf `main`.**
- Ablauf: `WP → Branch (worktree) → MAKER → Tests → CHECKER → PASS → Integration (durch Red Queen/Christian)`
- **Integration auf main** macht ausschließlich **Red Queen** (nicht der Sub-Agent), nur
  nach CHECKER-PASS und validiertem Test.

### 3.1 Verboten
| Aktion | Verbot |
|--------|--------|
| Force-Push | **Verbiet** überall (insb. auf main) |
| Blind-Merge | Kein Merge ohne Review/Checker-PASS |
| Blind-Rebase | kein Rebase ohne Verständnis/Abhängigkeit |
| History-Rewrite | keine Umschreibung der git-Historie |

### 3.2 Divergenz
- Falls Branch vs. main divergiert/konfligiert:
  - **STOPP** — kein erzwungenes Zusammenführen.
  - Red Queen meldet an Christian / Checker und klärt Konflikt.
  - Der Konflikt wird offengelegt gemeldet; kein blinder auto-merge.
  - Circuit Breaker bei unaufgelöster Divergenz/Regression (siehe SAFETY_CONTRACT).

---

## 4. Koordination

- Red Queen ist der **einzige** Scheduler; maximale Parallelität = 3, unabhängige WPs.
- Neues paralleles WP wird nur gestartet, wenn Limit nicht erreicht ist und keine Abhängigkeit/
  Datei-Überlappung besteht.
- Vor jedem parallelem Start validiert Red Queen via **State Validation** die WP-Transitions
  und FILE-Scope.
- Ergebnisse werden konsolidiert über Red Queen / Knowledge Agent (erst nach PASS).