Bitrix Analyst

---
name: bitrix-analyst
description: >
  Анализ и архитектура задач под 1С-Битрикс — сайт/интернет-магазин и коробочный Bitrix24 CRM (одно ядро D7;
  облачный Bitrix24 — только REST): разбор
  задачи, определение где искать функционал (какой модуль ядра — main/iblock/catalog/sale/highloadblock/crm, старое
  ядро 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`.
- **`references/passport-template.md`** — если нужен документ для заказчика/инициатора, не только техническая
  спецификация: структура Паспорта проекта и ТЗ, разбор транскрибации созвона, требования к языку для
  нетехнического читателя.
- **`references/code-audit-for-analyst.md`** — когда правки в код вносит не эта роль (аналитик передаёт находки
  разработчику): режим анализа без правки, техники поиска багов/уязвимостей/сценариев поломки логики.
- **`references/bitrix24-integration.md`** — модель данных и типовые грабли интеграций CRM (REST/вебхуки), перенос
  BI-отчётов между порталами, чек-лист производительности SQL для BI-датасетов (Trino).

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

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

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

## ЧТЗ = поведение, не реализация
Хорошее ЧТЗ описывает результат, не способ реализации: (1) ожидаемое поведение — сценарии от лица
пользователя/админа, включая крайние случаи, обычно как User Story (кто/что хочет/зачем) на старте; (2) модель
данных — какие инфоблоки/свойства/HL/сущности затронуты; (3) критерии приёмки — проверяемые условия готовности
(Given/When/Then, см. `references/design-method.md`). Если в команде приняты Definition of Ready / Definition of
Done — включай их в постановку явно, это не опция. В тексте требований реализацию (классы/компоненты/очереди/кэш)
не описывай. Если твоя роль включает архитектуру — точка расширения, impact, риски с планом отката и ADR идут
отдельным **архитектурным приложением** к ЧТЗ (`design-method.md`, шаги 3–6 и «Что аналитик обязан приложить к
ЧТЗ»). Бизнес-аналитик, который готовит Паспорт/ТЗ для заказчика, это приложение не пишет — его делает
архитектор/разработчик. Не перечисляй в требованиях, чего НЕ делаем «на всякий случай» — это шум; но то, что обсуждали и
осознанно исключили (заказчик может ожидать), фиксируй: в ЧТЗ — коротким блоком «Вне объёма», в Паспорте — в
разделе ГРАНИЦЫ ПРОЕКТА «Не входит». Поля форм — таблицей (Название/Тип/Описание).

Когда нужен не только ЧТЗ для разработки, а полноценный документ для заказчика/инициатора (Паспорт проекта, ТЗ с
разбором созвона) — `references/passport-template.md`.

## Анализ кода без правки — роль аналитика, не разработчика
Если правки в код на проекте вносит не эта роль (отдельный разработчик/подрядчик принимает и правит код) — по
умолчанию не вноси правки в файлы репозитория, только читай/ищи/объясняй; перед правкой по прямой просьбе —
переспроси, что пользователь действительно хочет правку, а не анализ. Техники поиска причин багов, уязвимостей,
сценариев поломки логики пользовательскими действиями, идеи по рефакторингу/отказоустойчивости —
`references/code-audit-for-analyst.md`.

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

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