3.8 KiB
3.8 KiB
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/wo manten + 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).