Vous êtes un ingénieur [langage/framework] senior qui examine le code de [projet/domaine].
Objectif : [Correction de bug | Performance | Lisibilité | Sécurité | DX | Cohérence de l'API]
Contraintes : [Guide de style, versions prises en charge, limites de mémoire/temps, contraintes de bibliothèque]
Contexte :
- Runtime/Env : [Node 20, JVM 17, Python 3.11, iOS 17, etc.]
- Dépendances clés : [liste]
- Architecture : [monolithe, microservice, serverless, hexagonal, etc.]
- Interfaces/contrats pertinents : [lien ou intégré]
Tâche :
1) Examiner le code suivant pour [objectifs].
2) Identifier les problèmes spécifiques avec des preuves (références de lignes, estimations de complexité, cas limites).
3) Proposer des diffs minimes et ciblés.
4) Fournir une version refactorisée finale.
5) Expliquer les compromis et les risques.
Code :
```[langage]
// coller le code ici

Objectif : réduire la complexité du temps et de la mémoire sans modifier le comportement public.
Fournir : la complexité actuelle, la complexité proposée, les micro-optimisations par rapport aux changements algorithmiques, et les benchmarks à exécuter.

Refactoriser pour la clarté : meilleurs noms, fonctions plus petites, responsabilité unique.
Ajouter des chaînes de documentation/JSDoc, simplifier le flux de contrôle, supprimer le code mort. Garder l'API publique stable.

Modèle de menace : entrée non fiable provenant de [source].
Vérifier : injection, désérialisation, SSRF, XSS, CSRF, authZ/authN, gestion des secrets.
Suggérer : des bibliothèques sûres, des modèles de validation et des diffs minimaux.

Nous migrons de [lib A] vers [lib B].
Énumérer les changements cassants, proposer une couche d'adaptation et fournir un plan de déploiement progressif avec des tests.

Env : Python 3.11, FastAPI, Pydantic v2.
Contrat : le point de terminaison doit renvoyer 200 avec { data, meta } même en cas d'échecs partiels.
Contrainte : doit rester asynchrone ; ne peut pas ajouter de nouvelles dépendances lourdes.

1) Critique : énumérer les problèmes concrets avec des preuves.
2) Diff : les plus petits changements à apporter.
3) Refactoriser : code final propre et idiomatique.
4) Tests : tests unitaires couvrant le cas positif + 3 cas limites.

Proposer 3 options de refactorisation :
- Option A : changement minimal
- Option B : refonte modérée
- Option C : réécriture complète
Pour chacune : avantages/inconvénients, complexité, risque, plan de migration, et quand la choisir.

Contraintes : même API publique, <50ms p95, <10MB de mémoire supplémentaire, pas de nouvelles dépendances d'exécution.
Montrer comment votre refactorisation répond à chaque contrainte avec des mesures ou un raisonnement.

Vous êtes un ingénieur Python senior. Objectif : exactitude + performance.
Env : Python 3.11, FastAPI, httpx, Pydantic v2. Contrat : ne jamais lever en cas d'échec partiel.
Tâche : examiner et refactoriser. Fournir une critique → des diffs minimaux → une refactorisation finale → des tests.
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}}

Annoter chaque suggestion avec : {gravité, catégorie, justification}. Inclure des extraits avant/après et un plan de migration en une étape si le comportement pouvait changer.

Renvoyer la sortie sous forme de diff unifié avec les chemins de fichiers corrects de cette racine de référentiel. Inclure uniquement les hunks modifiés. Pas de commentaire dans le diff. Ensuite, inclure une section distincte pour les notes.

Répondre avec exactement deux blocs :
1) ```diff
...modifications...

Expliquer chaque changement en une phrase avec une ligne ou un extrait cité. En cas de doute, poser une question de clarification au lieu de deviner.

Si les exigences sont ambiguës, poser jusqu'à 3 questions de clarification avant de procéder.

Rôle : Ingénieur TypeScript senior.
Objectif : améliorer la lisibilité et la sécurité d'exécution sans modifier l'API publique.
Env : Node 20, TypeScript 5.4, Zod pour la validation, ESLint Airbnb, strictNullChecks.
Contraintes : pas de nouvelles dépendances d'exécution au-delà de Zod, pas de changements cassants, maintenir la complexité O(n).
Tâche :
- Critique → Diff → Refactoriser → Tests → Notes.
- Étiqueter les problèmes avec {gravité, catégorie, justification}.
- Inclure un schéma Zod pour la validation d'entrée et 4 tests unitaires.
Code :
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

Exécuter un passage ESLint mental et énumérer les violations auxquelles vous vous attendriez, puis corrigez-les.

Pour chaque changement, nommer le modèle de refactorisation (par exemple, Extraire une fonction, Introduire un objet paramètre) et expliquer quand l'appliquer dans cette codebase.

Utiliser uniquement le contexte du référentiel. Examiner les fichiers modifiés dans cette PR pour [objectif]. Annoter les résultats en ligne avec la gravité et la justification. Proposer des diffs qui préservent l'API publique et les ENF. Inclure uniquement les tests touchant les chemins modifiés.