Bitrix Analyst

---
name: bitrix-analyst
description: >
  Анализ и архитектура задач под 1С-Битрикс (сайт/интернет-магазин): разбор задачи, определение где искать
  функционал (какой модуль ядра — main/iblock/catalog/sale/highloadblock, старое ядро vs D7, компонент vs API),
  оценка влияния доработки (что затронет, где уже реализовано), подготовка ЧТЗ (ожидаемое поведение + модель данных +
  критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь/уточняешь задачу по Битрикс,
  определяешь модуль и слой (/local vs ядро), оцениваешь влияние изменения, готовишь/проверяешь ЧТЗ, формулируешь
  уточняющие вопросы или проектируешь на уровне архитектуры (не написания PHP). Срабатывай даже без слова «анализ»,
  если речь о понимании задачи, влиянии или подготовке требований. Правило: искать в ОБОИХ слоях (ядро + /local) и
  проверять по РЕАЛЬНОМУ коду, не по памяти. Написание кода — bitrix-dev; производительность — bitrix-performance.
---

# Анализ и архитектура под 1С-Битрикс

## Читать при проектировании (обязательно)
- **`references/design-method.md`** — конвейер: требования (поведение) → критерии приёмки Given/When/Then →
  **impact-чеклист под Битрикс** → **дерево выбора точки расширения** (result_modifier → событие → свой компонент →
  копия → модуль → НИКОГДА ядро) → ADR → план миграции с откатом.
- **`references/adr-template.md`** — формат архитектурного решения (контекст с замерами, альтернативы, последствия,
  план миграции, техдолг).
- Глубина решения (когда НЕ усложнять) и слои — `../bitrix-dev/references/architecture.md`.

## Правило: спроси инструмент, не угадывай
Прежде чем делать вывод об архитектуре/влиянии — проверь по реальному коду (Grep/Serena по ядру и `/local`) и справке
dev.1c-bitrix.ru. Не делай вывод об отсутствии функционала по непросмотренному слою.

## Где искать функционал (карта ядра)
- **main** — ядро D7: ORM, события, приложение, кэш, сервис-локатор, HTTP, работа с файлами.
- **iblock** — инфоблоки (контент, каталог-сущности), свойства, разделы.
- **catalog** — торговый каталог: цены, склады, торговые предложения (SKU), единицы измерения.
- **sale** — магазин: корзина, заказы, оплата, доставка, скидки, правила корзины.
- **highloadblock** — highload-справочники (большие объёмы, D7 ORM).
- **Компонент vs API:** UI-логика (вывод) — в компонентах/шаблонах; бизнес-логика — в своих сервисах/классах `/local` поверх API ядра.

## Слои — искать в ОБОИХ
Функционал может быть в ядре (`/bitrix/modules`) ИЛИ переопределён в `/local`. Приоритет `/local` → `/bitrix`.
Правки планируй только в `/local`; структуру инфоблоков/HL — миграциями.

## ЧТЗ = поведение, не реализация
Хорошее ЧТЗ: (1) ожидаемое поведение (сценарии: что видит пользователь/админ, крайние случаи), (2) модель данных
(какие инфоблоки/свойства/HL/сущности затронуты), (3) критерии приёмки (проверяемые условия готовности).
Реализацию (какие классы/компоненты) фиксируй отдельно — тех-решение.

## Оценка влияния доработки
- Какие модули/компоненты/шаблоны затронет; есть ли типовой компонент, который проще скопировать в `/local`, чем писать с нуля.
- Влияние на производительность (кэш, запросы, объёмы) — при сомнении подключай `bitrix-performance`.
- Обновляемость: не ломает ли правка обновление продукта (правки только в `/local`).
- Совместимость версий ядра: доступен ли нужный метод D7 в версии проекта (проверяй по реальному коду ядра).

## Уточняющие вопросы (/clarify)
Прежде чем проектировать — уточни неоднозначное: объём данных (влияет на архитектуру каталога), требования к
персонализации (влияет на кэш/композит), интеграции (1С, платёжки, CRM), нагрузку, сроки.