Вие сте старши [език/рамка] инженер, който преглежда код за [проект/домейн].
Цел: [Поправка на бъг | Производителност | Четимост | Сигурност | DX | Конзистентност на API]
Ограничения: [Стилов наръчник, поддържани версии, лимити на памет/време, ограничения на библиотеки]
Контекст:
- Изпълнителна среда: [Node 20, JVM 17, Python 3.11, iOS 17 и др.]
- Ключови зависимости: [списък]
- Архитектура: [монолит, микросървис, serverless, хексагонална и др.]
- Относими интерфейси/контракти: [линк или на място]
Задача:
1) Прегледайте следния код спрямо [цели].
2) Идентифицирайте конкретни проблеми с доказателства (редове, оценки на сложността, гранични случаи).
3) Предложете минимални, целенасочени диференции.
4) Предоставете финална рефакториранa версия.
5) Обяснете компромиси и рискове.
Код:
```[език]
// поставете кода тук

Цел: намаляване на времева и паметова сложност без промяна на публичното поведение.
Дайте: текуща и предложена сложност, микрооптимизации срещу алгоритмични промени, и бенчмаркове за изпълнение.

Рефакторинг за ясност: по-добри имена, по-малки функции, единствена отговорност.
Добавете docstrings/JSDoc, опростете контролния поток, премахнете мъртъв код. Запазете стабилността на публичния API.

Модел на заплахи: ненадежден вход от [източник].
Проверете: инжекции, десериализация, SSRF, XSS, CSRF, автентикация/авторизация, обработка на тайни.
Предложете: безопасни библиотеки, модели на валидиране и минимални дифове.

Мигрираме от [библиотека A] към [библиотека B].
Избройте счупващи промени, предложете адаптерен слой и план за постепенно въвеждане с тестове.

Среда: Python 3.11, FastAPI, Pydantic v2.
Контракт: ендпойнт връща 200 с { data, meta } дори при частични грешки.
Ограничение: трябва да остане асинхронен; без допълнителни тежки зависимости.

1) Критика: изброяване на конкретни проблеми с доказателства.
2) Диференции: най-малки промени за поправка.
3) Рефакторинг: чист, идиоматичен финален код.
4) Тестове: unit тестове, покриващи главния път и 3 гранични случая.

Предложете 3 опции за рефакторинг:
- Опция A: минимална промяна
- Опция B: умерен редизайн
- Опция C: пълно пренаписване
За всяка: плюсове/минуси, сложност, риск, план за миграция и кога да се избере.

Ограничения: същото публично API, p95 < 50ms, <10MB допълнителна памет, без нови зависимости по време на изпълнение.
Покажете как рефакторингът отговаря на всяко ограничение с измервания или обосновка.

Вие сте старши Python инженер. Цел: коректност + производителност.
Среда: 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"https://api.example.com/users/{user_id}/profile")
        posts = await client.get(f"https://api.example.com/users/{user_id}/posts")
    return {"data": {"profile": profile.json(), "posts": posts.json()}}

Отбележете всяко предложение с: {тежест, категория, обосновка}. Включете преди/след откъси и едностъпков план за миграция, ако поведението може да се промени.

Върнете изхода като обединен диф с правилни пътища към файлове от корена на репото. Включвайте само променени кучета. Без коментари в дифа. След това добавете отделна секция с бележки.

Отговаряйте с точно два блока:
1) ```diff
...промени...

Обяснете всяка промяна в едно изречение с препратка към ред или откъс. Ако не сте сигурни, задайте уточняващ въпрос вместо да гадаете.

Ако изискванията са неясни, задайте до 3 уточняващи въпроса преди да продължите.

Роля: старши TypeScript инженер.
Цел: подобряване на четимостта и изпълнителната безопасност без промяна на публичното API.
Среда: Node 20, TypeScript 5.4, Zod за валидиране, ESLint Airbnb, strictNullChecks.
Ограничения: без нови зависимости по време на изпълнение освен Zod, без счупвания, запазване на O(n) сложност.
Задача:
- Критика → Диференции → Рефактор → Тестове → Бележки.
- Отбелязвайте проблемите с {тежест, категория, обосновка}.
- Включете Zod схема за валидиране на вход и 4 unit теста.
Код:
```ts
export function parseUser(raw: any) {
  if (!raw) return null;
  return {
    id: raw.id || '0',
    name: raw.name || 'Unknown',
    age: parseInt(raw.age),
  };
}

Извършете ментален ESLint пас и избройте очакваните нарушения, след това ги поправете.

За всяка промяна посочете патърна на рефакторинг (напр. Extract Function, Introduce Parameter Object) и кога да се използва в този кодов базис.

Използвайте само контекста на репото. Прегледайте файловете, променени в този PR, спрямо [цел]. Ангажирайте откритията интерактивно с тежест и обосновка. Предложете дифове, запазващи публичното API и NFRs. Включете тестове само по пътищата с промени.