Du bist ein erfahrener [Sprache/Framework]-Ingenieur, der Code für [Projekt/Domäne] überprüft.
Ziel: [Fehlerbehebung | Leistung | Lesbarkeit | Sicherheit | DX | API-Konsistenz]
Einschränkungen: [Styleguide, unterstützte Versionen, Speicher-/Zeitlimits, Bibliotheksbeschränkungen]
Kontext:
- Laufzeit/Umgebung: [Node 20, JVM 17, Python 3.11, iOS 17, etc.]
- Wichtige Abhängigkeiten: [Liste]
- Architektur: [Monolith, Microservice, Serverless, hexagonal, etc.]
- Relevante Schnittstellen/Verträge: [Link oder Inline]
Aufgabe:
1) Überprüfe den folgenden Code auf [Ziele].
2) Identifiziere spezifische Probleme mit Beweisen (Zeilenreferenzen, Komplexitätsschätzungen, Edge Cases).
3) Schlage minimale, zielgerichtete Diffs vor.
4) Stelle eine endgültige, refaktorierte Version bereit.
5) Erkläre Trade-offs und Risiken.
Code:
```[Sprache]
// Code hier einfügen

Ziel: Reduzierung der Zeit- und Speicherkomplexität, ohne das öffentliche Verhalten zu ändern.
Bereitstellen: aktuelle Komplexität, vorgeschlagene Komplexität, Mikrooptimierungen vs. algorithmische Änderungen und auszuführende Benchmarks.

Refaktorieren für Klarheit: bessere Namensgebung, kleinere Funktionen, Single-Responsibility.
Docstrings/JSDoc hinzufügen, Kontrollfluss vereinfachen, toten Code entfernen. Öffentliche API stabil halten.

Bedrohungsmodell: nicht vertrauenswürdige Eingabe von [Quelle].
Prüfen: Injection, Deserialisierung, SSRF, XSS, CSRF, AuthZ/AuthN, Geheimnisbehandlung.
Vorschlagen: sichere Bibliotheken, Validierungsmuster und minimale Diffs.

Wir migrieren von [Lib A] zu [Lib B].
Liste Breaking Changes auf, schlage eine Adapterschicht vor und stelle einen inkrementellen Rollout-Plan mit Tests bereit.

Umgebung: Python 3.11, FastAPI, Pydantic v2.
Vertrag: Endpunkt muss 200 mit { data, meta } auch bei teilweisen Fehlern zurückgeben.
Einschränkung: muss asynchron bleiben; es dürfen keine neuen, umfangreichen Abhängigkeiten hinzugefügt werden.

1) Kritik: Liste konkrete Probleme mit Beweisen auf.
2) Diff: kleinste Änderungen zur Behebung.
3) Refactor: sauberer, idiomatischer finaler Code.
4) Tests: Unit-Tests, die den Happy Path + 3 Edge Cases abdecken.

Schlage 3 Refactoring-Optionen vor:
- Option A: minimale Änderung
- Option B: moderate Neugestaltung
- Option C: vollständige Neufassung
Für jede: Vor-/Nachteile, Komplexität, Risiko, Migrationsplan und wann man sie wählen sollte.

Einschränkungen: gleiche öffentliche API, <50ms p95, <10MB zusätzlicher Speicher, keine neuen Laufzeitabhängigkeiten.
Zeige, wie dein Refactoring jede Einschränkung mit Messungen oder Begründungen erfüllt.

Du bist ein erfahrener Python-Ingenieur. Ziel: Korrektheit + Leistung.
Umgebung: Python 3.11, FastAPI, httpx, Pydantic v2. Vertrag: niemals bei Teilausfall auslösen.
Aufgabe: überprüfen und refaktorieren. Stelle Kritik → minimale Diffs → finalen Refactor → Tests bereit.
Code:
```python
from fastapi import APIRouter
import httpx
router = APIRouter
@router.get("/users/{user_id}")
async def get_user(user_id: str):
async with httpx.AsyncClient as client:
profile = await client.get(f")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

Jeden Vorschlag annotieren mit: {severity, category, rationale}. Vorher/Nachher-Snippets und einen einstufigen Migrationsplan einfügen, wenn sich das Verhalten ändern könnte.

Gib die Ausgabe als Unified Diff mit korrekten Dateipfaden aus diesem Repo-Root zurück. Füge nur geänderte Hunks ein. Keine Kommentare im Diff. Füge dann einen separaten Abschnitt für Notizen ein.

Antworte mit genau zwei Blöcken:
1) ```diff
...Änderungen...

Erkläre jede Änderung in einem Satz mit einer zitierten Zeile oder einem Snippet. Wenn du dir unsicher bist, stelle eine Klärungsfrage, anstatt zu raten.

Wenn die Anforderungen mehrdeutig sind, stelle bis zu 3 Klärungsfragen, bevor du fortfährst.

Rolle: Erfahrener TypeScript-Ingenieur.
Ziel: Verbesserung der Lesbarkeit und Laufzeitsicherheit, ohne die öffentliche API zu ändern.
Umgebung: Node 20, TypeScript 5.4, Zod für Validierung, ESLint Airbnb, strictNullChecks.
Einschränkungen: keine neuen Laufzeitabhängigkeiten über Zod hinaus, keine Breaking Changes, Aufrechterhaltung der O(n)-Komplexität.
Aufgabe:
- Kritik → Diff → Refactor → Tests → Notizen.
- Kennzeichne Probleme mit {severity, category, rationale}.
- Füge ein Zod-Schema für die Eingabevalidierung und 4 Unit-Tests hinzu.
Code:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

Führe einen mentalen ESLint-Durchlauf durch und liste Verstöße auf, die du erwarten würdest, und behebe sie dann.

Nenne für jede Änderung das Refactoring-Muster (z. B. Extract Function, Introduce Parameter Object) und erkläre, wann es in dieser Codebasis angewendet werden sollte.

Verwende nur den Repo-Kontext. Überprüfe die in dieser PR geänderten Dateien auf [Ziel]. Annotiere die Ergebnisse Inline mit Schweregrad und Begründung. Schlage Diffs vor, die die öffentliche API und NFRs beibehalten. Füge Tests hinzu, die nur geänderte Pfade berühren.