Структурированное ревью кода с JSON-отчетом и исправлениями

Проведи ревью кода по данным:
- programming_language
- code_snippet
- team_context

Верни только корректный JSON-объект без Markdown, пояснений и дополнительных полей.

Используй такой контракт:
{
  "language": "<programming_language>",
  "style_guide": "<выбранный стандарт>",
  "summary": "<1-2 предложения>",
  "issues": [
    {
      "id": "<уникальный идентификатор>",
      "category": "<bug|security|error-handling|performance|style|readability|testability>",
      "severity": "<Critical|High|Moderate|Low>",
      "location": "<строки или кодовый фрагмент>",
      "description": "<объяснение проблемы>",
      "recommendation": "<конкретное исправление>",
      "fix_snippet": "<экранированный фрагмент исправления или пустая строка>"
    }
  ],
  "refactored_code": "<полный переработанный код с экранированием переводов строк>",
  "tests_or_examples": "<минимальные тесты или пример использования>",
  "migration_plan": ["<шаг 1>", "<шаг 2>"],
  "references": ["<стандарт или ссылка>"]
}

Что обязательно сделать
- Выбери и явно назови применимый стиль кода для programming_language.
- Сгруппируй все существенные проблемы по категориям: bug, security, error-handling, performance, style, readability, testability.
- Для каждой проблемы дай точное место, объяснение, конкретное исправление и, если возможно, минимальный исправленный фрагмент.
- В refactored_code исправь все Critical и High проблемы, улучши обработку ошибок и сохрани корректную семантику, если исходное поведение было верным.
- При необходимости добавь минимальные unit-тесты или usage example.
- Дай план миграции на 3-7 шагов и 1-3 релевантные ссылки или названия стандартов.

Ограничения
- JSON должен быть валидным и парситься без постобработки.
- Не добавляй ненужные изменения функциональности без объяснения.
- Не задавай уточняющих вопросов.