techiejd/claude-skill-parallel-resource-isolation

Parallele Ressourcen-Isolation

Übersicht

Mehrere Claude-Instanzen, die am selben Projekt arbeiten, kollidieren bei Ports, Datenbanken und Browser-Instanzen. Diese Fähigkeit lehrt proaktive Erkennung und leise Anpassung – prüfe, was in Gebrauch ist, wähle etwas anderes, berichte, was du gewählt hast.

Kernprinzip: Beobachte den Systemzustand, passe dich leise an, berichte im Terminal. Keine Koordinationsdateien, keine Sperrdateien, kein gemeinsamer Zustand.

Wann verwenden

Führe vor jeder dieser Aktionen die Erkennungsprüfungen durch:

• Starten eines Dev-Servers (next dev, npm run dev)
• Ausführen von Playwright e2e-Tests
• Ausführen von Tests, die in die Datenbank schreiben oder gegen sie testen

Port-Isolation (Dev-Server)

Bevor du einen Dev-Server startest:

lsof -i :3000 -t 2>/dev/null

Wenn belegt, aufwärts scannen (3001, 3002, ...), bis ein freier Port gefunden wird. Starte mit:

PORT=<freier_port> next dev

Playwright mit webServer-Konfiguration:

• Überschreibe den Port per Umgebungsvariable, übergib denselben Port als baseURL
• Wenn das Überschreiben des Ports per Umgebungsvariable nicht unterstützt wird, weise den Benutzer darauf hin – ändere KEINE Konfigurationsdateien

Playwright ohne webServer (externer Server):

• Starte den Dev-Server auf dem freien Port
• Führe Playwright mit überschriebener baseURL aus:

BASE_URL=http://localhost:<freier_port> npx playwright test

Hartcodierte baseURL in der Playwright-Konfiguration (häufiger Fall): Die meisten Konfigurationen haben baseURL: 'http://localhost:3000' hartcodiert, anstatt sie aus der Umgebungsvariable zu lesen. Wenn das der Fall ist, funktioniert BASE_URL=... nicht. Weise den Benutzer mit dieser exakten Korrektur darauf hin:

Ihre playwright.config.ts hat eine hartcodierte baseURL. Bitte aktualisieren Sie sie zu: baseURL: process.env.BASE_URL || 'http://localhost:3000' Dadurch kann ich den Port per Umgebungsvariable überschreiben, ohne Konfigurationsdateien zu ändern.

Datenbank-Isolation (Supabase)

Bevor du Tests ausführst, die in die Datenbank schreiben oder gegen sie testen:

1. Stelle fest, ob Isolation erforderlich ist:
   • Nur lesen → Datenbank teilen, Isolation überspringen
   • Schreiben / Mutieren / Testen gegen DB-Zustand → isolieren
2. Generiere ein zeitstempelbasiertes Schema-Präfix: parallel_<Epoche>_ (z. B. parallel_1741234567_)
3. Erstelle das isolierte Schema und führe Migrationen aus:

psql "$DATABASE_URL" -c "CREATE SCHEMA parallel_1741234567_;"
PGOPTIONS="--search_path=parallel_1741234567_" npx supabase db push

4. Leite die App per Umgebungsvariable auf das isolierte Schema:

SUPABASE_SCHEMA=parallel_1741234567_ npx playwright test

5. Nach Abschluss der Tests: Schema löschen:

psql "$DATABASE_URL" -c "DROP SCHEMA parallel_1741234567_ CASCADE;"

Playwright-Browser-Isolation

Bevor du Playwright-Tests ausführst:

1. Überprüfe auf laufende Playwright-Browser-Prozesse, die kollidieren könnten
2. Isoliere den Browser-Status, um Sperrkonflikte zu vermeiden – verwende einen der folgenden Ansätze:

TMPDIR=/tmp/playwright_<Epoche> npx playwright test

Oder gezielter – nur den Browser-Pfad isolieren:

PLAYWRIGHT_BROWSERS_PATH=/tmp/pw_browsers_<Epoche> npx playwright install chromium
PLAYWRIGHT_BROWSERS_PATH=/tmp/pw_browsers_<Epoche> npx playwright test

3. Stelle sicher, dass die Playwright-Instanz denselben Port verwendet, der bei der Port-Isolation oben zugewiesen wurde

Berichterstattung

Nach der Anpassung einmal berichten und weitermachen:

⚡ Parallele Isolation:
  Dev-Server: Port 3005 (3000 war belegt)
  DB-Schema: parallel_1741234567_
  Playwright: /tmp/playwright_1741234567

Berichte nur über Ressourcen, die tatsächlich angepasst wurden. Wenn nichts in Konflikt geraten ist, sage nichts.

Kurzreferenz

Ressource	Erkennung	Anpassung	Bereinigung
Dev-Server-Port	lsof -i :<port>	PORT=<nächster_freier>	Keine erforderlich
Supabase-DB	Prüfen, ob Tests schreiben/testen	parallel_<Epoche>_ Schema	Schema nach Tests löschen
Playwright-Browser	Prüfen auf Sperrkonflikte	TMPDIR oder PLAYWRIGHT_BROWSERS_PATH	Temp-Verzeichnis wird automatisch gelöscht

Häufige Fehler

Den Prozess des anderen Claude töten

• Problem: Port 3000 ist belegt, also tötest du den Prozess, um ihn freizugeben
• Lösung: Töte niemals Prozesse, die du nicht gestartet hast. Wähle einen anderen Port.

Konfigurationsdateien für Port-Überschreibungen ändern

• Problem: Das Bearbeiten von playwright.config.ts oder next.config.js erzeugt Git-Konflikte
• Lösung: Verwende Umgebungsvariablen. Wenn Umgebungsvariablen nicht funktionieren, weise den Benutzer darauf hin.

Vergessen, den angepassten Port an Playwright zu übergeben

• Problem: Dev-Server auf 3005, Playwright trifft immer noch 3000
• Lösung: Koordiniere immer – der dem Dev-Server zugewiesene Port muss als BASE_URL an Playwright übergeben werden.

Datenbank isolieren, wenn nicht nötig

• Problem: Overhead der Schema-Erstellung für Read-Only-Tests
• Lösung: Nur isolieren, wenn Tests schreiben oder gegen den DB-Zustand testen.

Warnsignale

Nie:

• Einen anderen Prozess töten, um eine Ressource freizugeben
• Konfigurationsdateien ändern, um Ports zu ändern
• Port-Konflikte ignorieren und auf das Beste hoffen
• DB-Bereinigung nach Tests überspringen

Immer:

• Vor dem Start prüfen
• Leise per Umgebungsvariablen anpassen
• Berichten, was du gewählt hast
• DB-Schemata nach Tests bereinigen