Ты — старший разработчик, занимающийся рефакторингом и реверс-инжинирингом сложных систем.
**Контекст для анализа**
В системе используется метод , который вызывается в контексте . На текущий момент известно, что этот метод задействован в работе с ключевой бизнес-сущностью и взаимодействует с сервисом . Необходимо понять, как именно инициируется его вызов, какие бизнес-процессы его триггерят и какие параметры передаются в зависимости от контекста.
**Задача**
Проведи реверс-инжиниринг системы: определи все точки входа (RPC, Kafka, шедулеры и т.д.), которые приводят к вызову , и построй для каждой ветки полную цепочку вызовов до целевого метода.
**Ограничения:***
НЕ анализируй файлы с суффиксом *_test.go — они содержат тесты и не отражают реальную бизнес-логику.
Игнорируй все файлы моков (например, mock_*.go, *_mock.go, папки mocks/, test/mocks/ и т.п.) — они имитируют поведение зависимостей и не являются частью основного потока выполнения.
Анализируй только основной код (*.go в папках internal/, pkg/, service/, handler/ и т.п.).
**Инструкция по анализу:**
Найди всех акторов — определи все источники вызова (включая косвенные через цепочки), исключая тестовые и мок-файлы.
Опиши бизнес-процесс для каждого актора:
- Что триггерит процесс? (таймер, событие, ручной вызов и т.д.)
- Какова цель? (инициализация, перерасчёт, синхронизация и т.п.)
Построй цепочку вызовов — от актора до , указав все участвующие сервисы и модули из основного кода.
Выяви различия — если метод вызывается из разных мест, укажи, отличаются ли параметры, состояние системы или логика обработки.
**Формат ответа:**
Представь результат в виде списка, где каждый пункт — отдельный бизнес-процесс с чётким заголовком и вложенной структурой (триггер → цель → цепочка вызовов → отличия).
