reverse-process

**Роль:** Ты — бизнес-аналитик и технический архитектор. Твоя задача — прочитать код как историю (story), понять бизнес-процесс, а затем создать детальную архитектурную карту.

**Задача:** Проанализируй код метода `Handle` в файле `fileName` и всю связанную с ним логику. Сначала **пойми бизнес-сценарий**, а затем **построй карту выполнения**.

**Ограничения:**
- НЕ анализируй файлы с суффиксом `*_test.go` — они содержат тесты и не отражают реальную бизнес-логику.
- Игнорируй все файлы моков (например, `mock_*.go`, `*_mock.go`, папки `mocks/`, `test/mocks/` и т.п.).
- Анализируй только основной код (`*.go` в папках `internal/`, `pkg/`, `service/`, `handler/`, `api/` и т.п.).

### **ШАГ 1: АНАЛИЗ БИЗНЕС-СЦЕНАРИЯ (Человеческим языком)**

Прочитай код и ответь:

1. **Кто является пользователем этой системы?** (Другие сервисы, администраторы, cron-задание?)
2. **Какой бизнес-проблему решает этот код?** 
   - Что было ДО запуска этого процесса?
   - Что происходит ВО ВРЕМЯ выполнения?
   - Что изменится ПОСЛЕ успешного выполнения?
3. **Какие бизнес-объекты участвуют?** (Пользователи, скидки, сегменты, программы лояльности?)
4. **Каковы ключевые бизнес-правила?**
   - Когда нужно обновлять данные?
   - Какие данные считаются "разными"?
   - Что делать с устаревшими данными?

**Формат ответа на ШАГ 1:**
```
БИЗНЕС-СЦЕНАРИЙ:

1. Пользователь: [описание]
2. Проблема: [что решает]
3. Объекты: 
   - [Объект 1]: [роль в процессе]
   - [Объект 2]: [роль в процессе]
4. Бизнес-правила:
   - Правило 1: [описание + где в коде]
   - Правило 2: [описание + где в коде]
```

### **ШАГ 2: ВЫЯВЛЕНИЕ ПОТОКА ДАННЫХ (Data Flow Analysis)**

Теперь проанализируй код технически:

1. **Откуда берутся данные?** Найди все источники данных:
   - Базы данных (DWH, PostgreSQL, Redis)
   - API других сервисов
   - Входные параметры
   - Конфигурационные файлы

2. **Куда данные попадают?** Найди все приемники данных:
   - Внешние API
   - Базы данных
   - Логи
   - Очереди сообщений

3. **Как данные трансформируются?** Найди ключевые преобразования:
   - Фильтрация
   - Группировка
   - Сравнение
   - Агрегация

### **ШАГ 3: ПОСТРОЕНИЕ КАРТЫ ВЫПОЛНЕНИЯ (Execution Mapping)**

Создай детальную карту по следующему шаблону:

**A. ПОЛНАЯ ЦЕПОЧКА ВЫЗОВОВ (от начала до конца):**
```
1. [Точка входа] → [Первый вызов]
   ├── [Что проверяется/решается]
   └── [Условия перехода к следующему шагу]

2. [Второй шаг] → [Вызов метода]
   ├── [Источник данных]
   ├── [Логика обработки]
   └── [Результат]

... и так далее до завершения
```

**B. ТАБЛИЦА СЕРВИСОВ И ОТВЕТСТВЕННОСТЕЙ:**

| # | Сервис/Пакет | Метод | Бизнес-ответственность | Техническая ответственность | Вход → Выход |
|---|--------------|-------|------------------------|-----------------------------|--------------|
| 1 | `[путь]` | `[метод]` | [Что делает для бизнеса] | [Как делает технически] | `[типы входа]` → `[типы выхода]` |

**C. КЛЮЧЕВЫЕ СТРУКТУРЫ ДАННЫХ И ИХ ЖИЗНЕННЫЙ ЦИКЛ:**
```
Структура: [Имя структуры]
- Где создается: [пакет/файл]
- Как заполняется: [методы]
- Где используется: [список мест]
- Когда уничтожается: [конец процесса/сохранение]
```

**D. ОБРАБОТКА ОШИБОК И ГРАНИЧНЫХ СЛУЧАЕВ:**
- Какие ошибки обрабатываются явно?
- Что происходит при падении внешнего сервиса?
- Как обрабатываются пустые данные?
- Есть ли retry-логика?

### **ШАГ 4: АРХИТЕКТУРНЫЕ ВЫВОДЫ И РЕКОМЕНДАЦИИ**

1. **Точки расширения:** Где проще всего добавить новую логику?
2. **Точки изменения:** Если нужно поменять X, идти в Y
3. **Потенциальные проблемы:** Где могут быть узкие места?
4. **Тестовое покрытие:** Какие сценарии критично покрыть тестами?

---

### **КРИТИЧЕСКИЕ ВОПРОСЫ ДЛЯ АНАЛИЗА КОДА:**

Когда смотришь на код, задавай себе:

1. **"Почему?"** — Почему эта проверка здесь? Почему именно такой алгоритм сравнения?
2. **"Что если?"** — Что если данных будет в 100 раз больше? Что если внешний сервис не ответит?
3. **"Где еще?"** — Где еще в коде используется эта логика? Есть ли дублирование?
4. **"Как узнать?"** — Как система узнает, что процесс завершился успешно?

### **ПРИМЕР ТОГО, ЧТО Я ОЖИДАЮ В ОТВЕТЕ:**

```markdown
## БИЗНЕС-СЦЕНАРИЙ

1. **Пользователь:** Cron-задание, которое запускается каждый час
2. **Проблема:** Скидки пользователей устаревают, нужно синхронизировать с системой лояльности
3. **Объекты:**
   - Пользователь: имеет текущую скидку и сегмент
   - Скидка: процент, который меняется при изменении статуса лояльности
   - Сегмент: группа пользователей с одинаковой скидкой
4. **Бизнес-правила:**
   - Правило 1: Обновлять только если изменилась скидка (compare_dealer_programs.go:89)
   - Правило 2: Пользователи без скидки в DWH удаляются из всех сегментов (comparator.go:112)

## ТАБЛИЦА СЕРВИСОВ

| # | Сервис | Метод | Бизнес-ответственность | Техническая ответственность | Вход → Выход |
|---|--------|-------|------------------------|-----------------------------|--------------|
| 1 | `update_runner` | `Handle()` | Оркестрация процесса синхронизации | Маршрутизация вызовов, обработка ошибок | `RunDataUpdaterIn` → `error` |
| 2 | `clients/dwh` | `ExportDealerLoyaltyProgram()` | Получение актуальных статусов лояльности | HTTP-запрос к DWH, парсинг ответа | `context` → `[]DealerLoyaltyProgram` |
```

---

## **ДОПОЛНИТЕЛЬНЫЕ ИНСТРУКЦИИ ДЛЯ LLM:**

```
ВАЖНО: Не просто пересказывай код построчно. Анализируй:

1. СНАЧАЛА ПОНЯТЬ:
   - Какие комментарии в коде? Они могут раскрывать бизнес-логику
   - Имена переменных: `userDiscount`, `segmentID`, `loyaltyTier`
   - Названия методов: `compare`, `sync`, `update`, `notify`

2. ЗАТЕМ СТРУКТУРИРОВАТЬ:
   - Группируй связанные методы
   - Выделяй паттерны (паттерн Компаратор, паттерн Репозиторий)
   - Определяй слои (transport, service, repository, client)

3. НАКОНЕЦ, ОБЪЯСНИТЬ:
   - Если бы ты был новым разработчиком, что бы тебе показали в первую очередь?
   - Где "живет" основная бизнес-логика?
   - Какие файлы меняются чаще всего?
```

Ты — старший разработчик, специализирующийся на реверс-инжиниринге и анализе кода. Твоя задача — восстановить полную картину того, как формируется конкретное поле в ответе API.

**Контекст для анализа**
- Эндпоинт: endpoint_method endpoint_path
- Целевое поле в ответе: target_field_path
- Дополнительный контекст: additional_context

**Задача**
Проведи реверс-инжиниринг кодовой базы и опиши полный путь данных для поля `target_field_path` в ответе эндпоинта `endpoint_method endpoint_path`. Определи все возможные источники данных, бизнес-логику и условия, влияющие на итоговое значение.

**Ограничения:**
- НЕ анализируй файлы с суффиксом `*_test.go` — они содержат тесты и не отражают реальную бизнес-логику.
- Игнорируй все файлы моков (например, `mock_*.go`, `*_mock.go`, папки `mocks/`, `test/mocks/` и т.п.).
- Анализируй только основной код (`*.go` в папках `internal/`, `pkg/`, `service/`, `handler/`, `api/` и т.п.).

**Инструкция по анализу:**
1.  **Найди обработчик:** Определи, какой именно хендлер (функция-обработчик) в коде отвечает за эндпоинт `endpoint_method endpoint_path`. Начни с поиска маршрутов (роутов) в `cmd/`, `internal/api/` или `internal/handlers/`.
2.  **Точка формирования ответа:** Найди место в этом хендлере, где создается и наполняется структура ответа, содержащая `target_field_path`.
3.  **Проследи источник данных:** Определи, откуда берется значение для `target_field_path`:
    - Это прямой запрос в базу данных? (найди соответствующий репозиторий/DAO и SQL-запрос).
    - Это вызов метода какого-то сервиса (например, `SomeService.GetData(...)`)? Если да, углубись в этот сервис.
    - Это результат агрегации или вычисления на основе других данных?
    - Это данные из кеша?
    - Это данные, полученные из контекста запроса (например, от аутентификации)?
4.  **Построй цепочку вызовов:** Опиши полный путь от хендлера до источника данных (БД, внешний API, кеш). Укажи все промежуточные функции, сервисы, репозитории и пакеты.
5.  **Выяви бизнес-логику и отличия:**
    - Существуют ли какие-либо условия, влияющие на значение `target_field_path`? (например, тип пользователя, параметры запроса, A/B-тесты, статус платежа).
    - Зависит ли значение от того, откуда пришел запрос (разные версии API, разные клиенты)? Учти дополнительный контекст: additional_context.

**Формат ответа:**
Представь результат в виде структурированного описания пути данных:

*   **Эндпоинт и Хендлер:** Укажи точный путь и имя функции-обработчика (например, `internal/handler/some_handler.go: (h *SomeHandler) HandlerFunc`).
*   **Структура ответа:** Покажи (или опиши), в какой структуре находится поле `target_field_path` (например, `type ResponseStruct struct { Field NestedStruct }` и `type NestedStruct struct { TargetField type }`).
*   **Путь данных (Снизу вверх):**
    1.  **Источник (БД/Внешний источник):** Откуда в итоге читаются данные? (например, таблица `some_table`, колонка `some_column`, с дополнительным условием `WHERE condition = ?`).
    2.  **Слой репозитория:** Какая функция и в каком репозитории выполняет запрос к этому источнику?
    3.  **Слой сервиса (бизнес-логика):** Какая функция сервиса вызывает этот репозиторий и применяет ли какую-либо логику перед возвратом данных? (например, конвертация, округление, проверка прав).
    4.  **Слой хендлера:** Как сервис вызывается из хендлера и как его результат помещается в итоговую структуру ответа.
*   **Бизнес-процесс и особенности:** Кратко опиши, с какой целью отображается это поле, учитывая дополнительный контекст: additional_context. Укажи все выявленные условия и особенности.

Ты — старший разработчик, занимающийся рефакторингом и реверс-инжинирингом сложных систем.

**Контекст для анализа**
В системе используется метод methodName, который вызывается в контексте context. На текущий момент известно, что этот метод задействован в работе с ключевой бизнес-сущностью и взаимодействует с сервисом serviceName. Необходимо понять, как именно инициируется его вызов, какие бизнес-процессы его триггерят и какие параметры передаются в зависимости от контекста.

**Задача**
Проведи реверс-инжиниринг системы: определи все точки входа (RPC, Kafka, шедулеры и т.д.), которые приводят к вызову methodName, и построй для каждой ветки полную цепочку вызовов до целевого метода.

**Ограничения:***
НЕ анализируй файлы с суффиксом *_test.go — они содержат тесты и не отражают реальную бизнес-логику.
Игнорируй все файлы моков (например, mock_*.go, *_mock.go, папки mocks/, test/mocks/ и т.п.) — они имитируют поведение зависимостей и не являются частью основного потока выполнения.
Анализируй только основной код (*.go в папках internal/, pkg/, service/, handler/ и т.п.).

**Инструкция по анализу:**
1.  **Найди всех акторов (точки входа):** Определи все публичные точки доступа (RPC API handlers, Kafka consumers, методы команд, шедулеры, quass), которые прямо или косвенно (через цепочку вызовов) ведут к целевому методу.
2.  **Опиши бизнес-процесс для каждой ветки:** Для каждого найденного актора составь описание бизнес-процесса.
    *   *Что триггерит процесс?* (Вызов handler, приход сообщения из внешней системы, таймер).
    *   *Какова цель процесса?* (Начислить бонусы, списать деньги, отправить уведомление, инициализировать калибровку).
3.  **Построй цепочку вызовов:** Для каждого процесса покажи трассировку стека вызовов от актора до целевого метода. Укажи ключевые сервисы, которые участвуют в этом пути (например: `OrderController -> OrderFacade -> PaymentService -> TransactionManager`).
4.  **Выяви различия:** Если один и тот же метод вызывается из разных мест, укажи, отличается ли набор передаваемых параметров или состояние системы на момент вызова (например, в одном случае транзакция уже подтверждена, в другом — еще в обработке).

**Формат ответа:**
Представь результат в виде списка, где каждый пункт — отдельный бизнес-процесс с чётким заголовком и вложенной структурой (триггер → цель → цепочка вызовов → отличия).