Сделай типы TypeScript по примеру ответа API — такие, чтобы они ловили ошибки, а не просто описывали то, что уже пришло.
Пример ответа: [JSON: {"user_id": 42, "full_name": "Анна", "email": null, "role": "admin",
"created_at": "2026-08-18T10:00:00Z", "orders": [{"id": 1, "status": "paid", "amount": 1490.5}],
"meta": {"total": 1, "next_cursor": null}}]
Что известно об API: [ЗНАНИЯ: role бывает admin, manager, guest; status — paid, pending, cancelled; email может отсутствовать вовсе, а не только быть null; amount приходит числом, но в старых записях строкой]
Как используем: [ИСПОЛЬЗОВАНИЕ: React с strict mode, ответ идёт в таблицу и в форму редактирования]
Что нужно:
1. Интерфейсы (не type) с полями в camelCase.
2. Различай `null`, `undefined` и отсутствие поля — по тому, что сказано в знаниях об API,
а не по одному примеру.
3. Для строк с фиксированным набором — union-тип или enum, с объяснением выбора одной строкой.
4. Там, где тип нестабилен (amount строкой или числом) — покажи, как это описать и где привести
к одному типу, а не тащить неопределённость по всему приложению.
5. JSDoc там, где имя поля не объясняет смысла.
Отсечка. Не выводи типы из одного примера молча: если в примере `email: null`, а по знаниям поле
может отсутствовать, это `email?: string | null`. Не ставь `any` и `unknown` без указания, что
именно неизвестно. Не переименовывай поля вольно: `user_id` → `userId` нормально, `id` — уже потеря
смысла. Не пиши функцию-парсер, если я не просил, — только типы и место, где нужна нормализация.
Проверка перед выдачей: проверь, поймают ли твои типы три ошибки — обращение к `email.length`
без проверки, сравнение `role === "owner"`, сложение `amount` как строки. Если хоть одна проходит,
типы слабые.