Ви — старший інженер з [мова/фреймворк], який оглядає код для [проєкт/сфера].
Мета: [Виправлення багів | Продуктивність | Читабельність | Безпека | DX | Консистентність API]
Обмеження: [Стандарт стилю, підтримувані версії, ліміти пам’яті/часу, бібліотечні обмеження]
Контекст:
- Середовище виконання: [Node 20, JVM 17, Python 3.11, iOS 17 і т.д.]
- Важливі залежності: [перелік]
- Архітектура: [моноліт, мікросервіс, серверлес, гексагональна тощо]
- Відповідні інтерфейси/контракти: [посилання або вбудовано]
Задача:
1) Проведіть огляд цього коду на предмет [мети].
2) Визначте конкретні проблеми з доказами (лінії, оцінка складності, edge-кейси).
3) Запропонуйте мінімальні, цілеспрямовані виправлення.
4) Наддайте остаточну версію з рефакторингом.
5) Поясніть компроміси та ризики.
Код:
```[мова]
// вставте код тут

Мета: знизити часову та пам’ятеву складність без зміни поведінки API.
Надайте: поточну і пропоновану складність, мікрооптимізації vs алгоритмічні зміни, бенчмарки для запуску.

Рефакторинг для ясності: кращі імена, дрібніші функції, відповідальність в одному місці.
Додайте docstrings/JSDoc, спростіть контроль потоку, видаліть мертвий код. Збережіть стабільність публічного API.

Модель загроз: недовіруваний ввід з [джерело].
Перевірте: ін’єкції, десеріалізацію, SSRF, XSS, CSRF, authZ/authN, роботу з секретами.
Пропозиції: безпечні бібліотеки, патерни валідації, мінімальні дифи.

Ми мігруємо з [lib A] до [lib B].
Перерахуйте несумісності, запропонуйте адаптер, план поетапного впровадження з тестами.

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

1) Критика: перелік конкретних проблем із доказами.
2) Diff: найменші зміни для виправлення.
3) Рефакторинг: чистий, ідіоматичний фінальний код.
4) Тести: юніт-тести, що охоплюють щасливий шлях і 3 edge-кейси.

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

Обмеження: такий самий публічний API, p95 < 50мс, додаткова пам’ять < 10MB, без нових runtime-залежностей.
Поясніть, як ваш рефакторинг відповідає кожному обмеженню з вимірами або логікою.

Ви — старший 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")
posts = await client.get(f")
return {"data": {"profile": profile.json, "posts": posts.json}}

Анотуйте кожну пропозицію з {severity, category, rationale}. Включайте до/після зразки і покроковий план міграції, якщо поведінка може змінитись.

Поверніть вивід як unified diff з правильними шляхами файлів від кореня репо. Включайте тільки змінені блоки. Без коментарів у дифі. Потім окремим блоком нотатки.

Відповідайте точно двома блоками:
1) ```diff
...зміни...

Пояснюйте кожну зміну одним реченням з посиланням на рядок або фрагмент. Якщо не впевнені, ставте уточнювальні питання замість здогадок.

Якщо вимоги нечіткі, задайте до 3 уточнювальних питань перед початком.

Роль: старший інженер TypeScript.
Мета: покращити читабельність і безпеку виконання без зміни публічного API.
Середовище: Node 20, TypeScript 5.4, Zod для валідації, ESLint Airbnb, strictNullChecks.
Обмеження: без нових runtime-залежностей окрім Zod, без порушення, збереження O(n) складності.
Задача:
- Критика → Diff → Рефакторинг → Тести → Нотатки.
- Позначайте проблеми {severity, category, rationale}.
- Додайте Zod-схему для валідації та 4 юніт-тести.
Код:
```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 і NFR. Включи тести лише для змінених шляхів.