आप [परियोजना/डोमेन] के लिए कोड की समीक्षा करने वाले एक वरिष्ठ [भाषा/ढांचा] इंजीनियर हैं।
लक्ष्य: [बग फिक्स | प्रदर्शन | पठनीयता | सुरक्षा | DX | API स्थिरता]
बाधाएँ: [शैली गाइड, समर्थित संस्करण, मेमोरी/समय सीमा, लाइब्रेरी बाधाएँ]
संदर्भ:
- रनटाइम/Env: [Node 20, JVM 17, Python 3.11, iOS 17, आदि।]
- मुख्य निर्भरताएँ: [सूची]
- आर्किटेक्चर: [मोनोलिथ, माइक्रोसर्विस, सर्वरलेस, हेक्सागोनल, आदि।]
- प्रासंगिक इंटरफेस/अनुबंध: [लिंक या इनलाइन]
कार्य:
1) [लक्ष्यों] के लिए निम्नलिखित कोड की समीक्षा करें।
2) सबूतों के साथ विशिष्ट मुद्दों की पहचान करें (लाइन रेफ्स, जटिलता अनुमान, एज केस)।
3) न्यूनतम, लक्षित अंतर प्रस्तावित करें।
4) एक अंतिम रिफैक्टर किया गया संस्करण प्रदान करें।
5) ट्रेड-ऑफ और जोखिमों की व्याख्या करें।
कोड:
```[भाषा]
// कोड यहाँ पेस्ट करें

लक्ष्य: सार्वजनिक व्यवहार को बदले बिना समय और मेमोरी जटिलता को कम करना।
प्रदान करें: वर्तमान जटिलता, प्रस्तावित जटिलता, माइक्रो-अनुकूलन बनाम एल्गोरिथम परिवर्तन, और चलाने के लिए बेंचमार्क।

स्पष्टता के लिए रिफैक्टर: बेहतर नामकरण, छोटे कार्य, एकल-जिम्मेदारी।
डॉक्सस्ट्रिंग/JSDoc जोड़ें, नियंत्रण प्रवाह को सरल बनाएं, मृत कोड को हटा दें। सार्वजनिक API को स्थिर रखें।

खतरा मॉडल: [स्रोत] से अविश्वसनीय इनपुट।
जांच करें: इंजेक्शन, डिसेरिएलाइजेशन, SSRF, XSS, CSRF, authZ/authN, रहस्य हैंडलिंग।
सुझाव दें: सुरक्षित लाइब्रेरी, सत्यापन पैटर्न और न्यूनतम अंतर।

हम [lib A] से [lib B] में माइग्रेट कर रहे हैं।
ब्रेकिंग परिवर्तनों की सूची बनाएं, एक एडेप्टर परत प्रस्तावित करें, और परीक्षणों के साथ एक वृद्धिशील रोलआउट योजना प्रदान करें।

Env: Python 3.11, FastAPI, Pydantic v2।
अनुबंध: आंशिक विफलता पर भी एंडपॉइंट को { डेटा, मेटा } के साथ 200 वापस करना होगा।
बाधा: एसिंक रहना चाहिए; नई भारी deps नहीं जोड़ सकते।

1) आलोचना: सबूतों के साथ ठोस मुद्दों की सूची बनाएं।
2) अंतर: ठीक करने के लिए सबसे छोटे परिवर्तन।
3) रिफैक्टर: स्वच्छ, मुहावरेदार अंतिम कोड।
4) परीक्षण: हैप्पी पाथ + 3 एज केस को कवर करने वाले यूनिट परीक्षण।

3 रिफैक्टर विकल्प प्रस्तावित करें:
- विकल्प A: न्यूनतम परिवर्तन
- विकल्प B: मध्यम रीडिज़ाइन
- विकल्प C: पूर्ण रीराइट
प्रत्येक के लिए: फायदे/नुकसान, जटिलता, जोखिम, माइग्रेशन योजना, और इसे कब चुनना है।

बाधाएँ: समान सार्वजनिक API, <50ms p95, <10MB अतिरिक्त मेमोरी, कोई नई रनटाइम deps नहीं।
दिखाएं कि आपका रिफैक्टर माप या तर्क के साथ प्रत्येक बाधा को कैसे पूरा करता है।

आप एक वरिष्ठ पायथन इंजीनियर हैं। लक्ष्य: शुद्धता + प्रदर्शन।
Env: Python 3.11, FastAPI, httpx, Pydantic v2। अनुबंध: आंशिक विफलता पर कभी न उठाएँ।
कार्य: समीक्षा करें और रिफैक्टर करें। आलोचना → न्यूनतम अंतर → अंतिम रिफैक्टर → परीक्षण प्रदान करें।
कोड:
```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}}

प्रत्येक सुझाव को एनोटेट करें: {गंभीरता, श्रेणी, तर्क}। व्यवहार बदल सकता है या नहीं, पहले/बाद के स्निपेट और एक-चरणीय माइग्रेशन योजना शामिल करें।

इस रेपो रूट से सही फ़ाइल पथ के साथ आउटपुट को एकीकृत अंतर के रूप में लौटाएँ। केवल बदले हुए हंक शामिल करें। अंतर में कोई टिप्पणी नहीं। फिर नोट्स के लिए एक अलग अनुभाग शामिल करें।

ठीक दो ब्लॉक के साथ उत्तर दें:
1) ```diff
...परिवर्तन...

उद्धृत पंक्ति या स्निपेट के साथ प्रत्येक परिवर्तन को एक वाक्य में समझाएँ। यदि अनिश्चित हैं, तो अनुमान लगाने के बजाय एक स्पष्टीकरण प्रश्न पूछें।

यदि आवश्यकताएँ अस्पष्ट हैं, तो आगे बढ़ने से पहले 3 स्पष्टीकरण प्रश्न पूछें।

भूमिका: वरिष्ठ TypeScript इंजीनियर।
लक्ष्य: सार्वजनिक API को बदले बिना पठनीयता और रनटाइम सुरक्षा में सुधार करना।
Env: Node 20, TypeScript 5.4, सत्यापन के लिए Zod, ESLint Airbnb, strictNullChecks।
बाधाएँ: Zod से परे कोई नई रनटाइम deps नहीं, कोई ब्रेकिंग परिवर्तन नहीं, O(n) जटिलता बनाए रखें।
कार्य:
- आलोचना → अंतर → रिफैक्टर → परीक्षण → नोट्स।
- {गंभीरता, श्रेणी, तर्क} के साथ मुद्दों को टैग करें।
- इनपुट सत्यापन और 4 यूनिट परीक्षणों के लिए एक Zod स्कीमा शामिल करें।
कोड:
```ts
export function parseUser(raw: any) {
if (!raw) return null
return {
id: raw.id || '0',
name: raw.name || 'Unknown',
age: parseInt(raw.age),
}
}

एक मानसिक ESLint पास चलाएं और उन उल्लंघनों की सूची बनाएं जिनकी आप अपेक्षा करेंगे, फिर उन्हें ठीक करें।

प्रत्येक परिवर्तन के लिए, रिफैक्टरिंग पैटर्न का नाम दें (उदाहरण के लिए, फ़ंक्शन निकालें, पैरामीटर ऑब्जेक्ट पेश करें) और बताएं कि इसे इस कोडबेस में कब लागू करना है।

केवल रेपो संदर्भ का उपयोग करें। [लक्ष्य] के लिए इस PR में बदली गई फ़ाइलों की समीक्षा करें। गंभीरता और तर्क के साथ इनलाइन निष्कर्षों को एनोटेट करें। सार्वजनिक API और NFR को संरक्षित करने वाले अंतर प्रस्तावित करें। केवल बदले हुए पथों को छूने वाले परीक्षण शामिल करें।