analysis

**Роль:** Ты — бизнес-аналитик и технический архитектор. Твоя задача — прочитать код как историю (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.  **Выяви различия:** Если один и тот же метод вызывается из разных мест, укажи, отличается ли набор передаваемых параметров или состояние системы на момент вызова (например, в одном случае транзакция уже подтверждена, в другом — еще в обработке).

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

Role & Goal
You are an experienced agency growth consultant. Build a single, cohesive “Growth Bottleneck Identifier” diagnostic framework tailored to my agency that pinpoints what’s blocking growth and tells me what to fix first.

Agency Snapshot (use these exact inputs)
- Agency type/niche: [YOUR AGENCY TYPE + NICHE]
- Primary offer(s): [SERVICE PACKAGES]
- Average delivery model: [DONE-FOR-YOU / COACHING / HYBRID]
- Current client count (active accounts): [ACTIVE ACCOUNTS]
- Team size (employees/contractors) + roles: [EMPLOYEES/CONTRACTORS + ROLES]
- Monthly revenue (MRR): [CURRENT MRR]
- Avg revenue per client (if known): [ARPC]
- Gross margin estimate (if known): [MARGIN %]
- Growth goal (90 days + 12 months): [TARGET CLIENTS/REVENUE + TIMEFRAME]
- Main complaint (what’s not working): [WHAT'S NOT WORKING]
- Biggest time drains (where hours go): [WHERE HOURS GO]
- Lead sources today: [REFERRALS / ADS / OUTBOUND / CONTENT / PARTNERS]
- Sales cycle + close rate (if known): [DAYS + %]
- Retention/churn (if known): [AVG MONTHS / %]

Output Requirements
Create ONE diagnostic system with:
1) A short overview: what the framework is and how to use it monthly (≤10 minutes/week).
2) A Scorecard (0–5 scoring) that covers all areas below, with clear scoring anchors for 0, 3, and 5.
3) A Calculation Section with formulas + worked examples using my inputs.
4) A Decision Tree that identifies the primary bottleneck (capacity, delivery/process, pricing, or lead flow).
5) A “Fix This First” prioritization engine that ranks issues by Impact × Effort × Risk, and outputs the top 3 actions for the next 14 days.
6) A simple dashboard summary at the end: Bottleneck → Evidence → First Fix → Expected Result.

Must-Include Diagnostic Modules (in this order)
A) Capacity Constraint Analysis (max client load)
- Determine current delivery capacity and maximum sustainable client load.
- Include a utilization formula based on hours available vs hours required per client.
- Output: current utilization %, max clients at current staffing, and “over/under capacity” flag.

B) Process Inefficiency Detector (wasted time)
- Identify top 5 recurring wastes mapped to: meetings, reporting, revisions, approvals, context switching, QA, comms, onboarding.
- Output: estimated hours/month recoverable + the specific process change(s) to reclaim them.

C) Hiring Need Calculator (when to add people)
- Translate growth goal into role-hours needed.
- Recommend the next hire(s) by role (e.g., account manager, specialist, ops, sales) with triggers:
  - “Hire when X happens” (utilization threshold, backlog threshold, SLA breaches, revenue threshold).
- Output: hiring timeline (Now / 30 days / 90 days) + expected capacity gained.

D) Tool/Automation Gap Identifier (what to automate)
- List the highest ROI automations for my time drains (e.g., intake forms, client comms templates, reporting, task routing, QA checklists).
- Output: automation shortlist with estimated hours saved/month and suggested tool category (not brand-dependent).

E) Pricing Problem Revealer (revenue per client)
- Compute revenue per client, delivery cost proxy, and “effective hourly rate.”
- Diagnose underpricing vs scope creep vs wrong packaging.
- Output: pricing moves (raise, repackage, tier, add performance fees, reduce inclusions) with clear criteria.

F) Lead Flow Bottleneck Finder (pipeline issues)
- Map pipeline stages: Lead → Qualified → Sales Call → Proposal → Close → Onboard.
- Identify the constraint stage using conversion math.
- Output: the single leakiest stage + 3 fixes (messaging, targeting, offer, follow-up, proof, outbound cadence).

G) “Fix This First” Prioritization (biggest impact)
- Use an Impact × Effort × Risk scoring table.
- Provide the top 3 fixes with:
  - exact steps,
  - owner (role),
  - time required,
  - success metric,
  - expected leading indicator in 7–14 days.

Quality Bar
- Keep it practical and numbers-driven.
- Use my inputs to produce real calculations (not placeholders) where possible; if an input is missing, state the assumption clearly and show how to replace it with the real number.
- Avoid generic advice; every recommendation must tie back to a scorecard result or calculation.
- Use plain language. No fluff.

Formatting
- Use clear headings for Modules A–G.
- Include tables for the Scorecard and the Prioritization engine.
- End with a 14-day action plan checklist.

Now generate the full diagnostic framework using the inputs provided above.