nexo312/trading-system-docs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
trading-system-docs/red-queen-architecture/PARALLEL_EXECUTION.md
Red Queen 581253cda9 docs(a1): fix typo 'wo manten' -> 'Worktree behalten' + A2 status note 
Kosmetische A1-Fixes (A2 §20), getrennt vom A2-Feature-Commit.
- PARALLEL_EXECUTION.md: Tippfehler korrigiert.
- README.md: Implementierungsstatus (A2 abgeschlossen) ergänzt.
2026-08-24 20:18:36 +00:00

3.8 KiB
Raw Blame History

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).