1c Analyst

---
name: 1c-analyst
description: >
  Анализ и архитектура задач 1С: разбор задачи/ЧТЗ, какие контуры/базы существуют и что с чем связано, что
  затронет изменение, где уже реализован функционал; подготовка качественного ЧТЗ (ожидаемое поведение + модель
  данных + критерии приёмки) и архитектурных решений. ОБЯЗАТЕЛЬНО используй, когда анализируешь или уточняешь
  задачу по 1С, определяешь контур и базу, оцениваешь влияние доработки, готовишь/проверяешь ЧТЗ, формулируешь
  уточняющие вопросы, решаешь нужен ли архитектор, или проектируешь на уровне архитектуры (не написания BSL).
  Срабатывай даже без слов «анализ/архитектура», если речь о понимании задачи, контуров, влияния или подготовке
  требований. Главное правило: искать в ОБОИХ слоях контура (конфигурация + расширение) и проверять по РЕАЛЬНОМУ
  коду через MCP, не по памяти. Написание/ревью BSL — скилл `1c-dev`.
---

# Анализ и архитектура 1С

## Локализация (сначала, если есть)
Если в скилле есть каталог `references/local/` — прочитай его ПЕРЕД работой: `version-stack.md`
(версии платформы/библиотек, режим совместимости, префиксы ТВОЕЙ компании) и остальные карты.
При противоречии локальное побеждает generic. Контракт — `docs/SKILL_LOCALIZATION.md` toolkit.

Скилл аналитика/архитектора: понять задачу и контур, что с чем связано, что затронет изменение, и подготовить
ЧТЗ/архитектурное решение так, чтобы дальше тех-лид и dev-фаза (`1c-dev`) превратили это в атомарные задачи и код.

## Железное правило анализа
1. **Контур = конфигурация (основа) + подключённое расширение.** Искать функционал в ОБОИХ слоях.
2. Проверять по РЕАЛЬНОМУ коду через MCP (`find_object`/`search`/`read_module`), не по памяти. Нет в коде — так и
   скажи, гипотезу помечай **[проверить]**.
3. Слой не загружен в MCP-индекс → это «не загружено», НЕ «функционала нет».

## Роли и границы
- **Аналитик** — владелец бизнес-смысла: проблема/потребность, ожидаемое поведение, границы, логическая модель
  данных, бизнес-ошибки и запреты, критерии приёмки. НЕ описывает реализацию.
- **Архитектор** — границы и ограничения целевой архитектуры; «архитектурное решение = СТАТУС принятия тех-проекта»;
  ADR при неопределённости. Подключается при риске/влиянии на архитектуру.
- Соседние: **тех-лид** пишет тех-проект/контракты и дожимает технику; **разработчик + `1c-dev`** превращают
  артефакт в атомы и код. Контуры аналитики и разработки независимы, связаны через артефакты + трекер; уточнение
  требований в процессе реализации = возврат в аналитический контур.

## Контуры и базы — карта в данных локализации
Карта контуров вынесена в **данные**, не в тело скилла: `config/contours.example.md` (generic-шаблон) → СВОЙ файл
в локализации (`config/contours.<org>.md`). Там: какие конфигурации/базы, какие слои (конфигурация + расширения),
что с чем связано, риски переноса, слепые зоны, незагруженные слои. Заполняется по РЕАЛЬНОМУ коду (оба слоя) и
держится согласованным со scope-группами из `config/layers.*.toml` (машинная раскладка слоёв для поиска). Так
локализация под организацию = обновить данные, а не править скилл/движок. Шаблон конвенций слоёв для dev — в `1c-dev`
(`references/conventions-template.md`).

## Трекер задач и база знаний — достать контекст и связать с кодом
Часть функционала НЕ в git (внешние обработки, обмены, настройки в данных) — «в коде не нашёл» без проверки базы
знаний неполно. Обезличенный CLI `scripts/atlassian.py` (stdlib, без MCP) достаёт постановку из трекера и знания из
вики в стиле Jira/Confluence; свой домен и токен — через env (`JIRA_URL`/`JIRA_PAT`, `CONFLUENCE_URL`/`CONFLUENCE_PAT`),
ничего в коде не меняя. Паттерн «связать воедино» задача→код→база знаний, команды и слепые зоны —
**`references/tracker-and-knowledge-base.md`**. Карта разделов базы знаний (id, «когда смотреть») — org-данные:
каркас **`references/knowledge-base-map-template.md`** → заполнить в Team-слое локализации, не в публичном ядре.

## Артефакты-спеки и правило «поведение, не реализация»
Операционный цикл аналитика, что внутри артефактов и чек-лист «хорошего ЧТЗ для dev-цикла» —
**`references/analysis-workflow.md`**. Ядро: **ЧТЗ описывает ОЖИДАЕМОЕ ПОВЕДЕНИЕ, а НЕ способ реализации**. В ЧТЗ
нельзя DTO/сигнатуры/имена модулей/серверный-клиентский контекст/стиль кода — это тех-проект тех-лида. Размер→
глубина: S минимум, M light-ЧТЗ, L/XL полное ЧТЗ + тех-проект.
- Структура и качество требований, канон-разделы ЧТЗ, уровни требований, INVEST, логическая модель данных —
  **`references/requirements-and-chtz.md`**.
- **Рамки документов (document frames)** — реестр типов документов (бриф/паспорт, ЧТЗ, тех-проект, контекст-заметка,
  карточка инцидента, страница сопровождения), у каждого: состав блоков, правила (что можно/нельзя), владелец-роль,
  критерии готовности, дефолтные шаблоны мирового уровня (29148/INVEST/EARS, arc42/ADR, ISO/IEC 25010) —
  **`references/document-frames.md`**. Перед написанием любого документа определи его рамку, загрузи её (локализация
  заказчика переопределяет generic поблочно), пиши строго по блокам и соблюдай правила; сессионный оверрайд состава
  допустим, при подтверждении закрепляется в локализацию.
- Архитектурный артефакт «Архитектура решения», C4, нотации (BPMN/IDEF/UML/ER) — **`references/architecture-design.md`**.

## Фаза уточнения (/clarify) до передачи
Прежде чем гнать задачу дальше — структурированный gap-анализ: что неясно, границы, данные/откуда, сложные кейсы,
бизнес-ошибки/запреты, критерии приёмки. Конкретные вопросы, не «непонятно». Шаблон — в analysis-workflow.

## Как готовить вход для dev-цикла
Хороший ЧТЗ + тех-проект — это то, что `1c-dev` декомпозирует на атомы и код. Дай: чёткие границы, логическую модель
данных, измеримые критерии приёмки, бизнес-ошибки/запреты, контуры/влияние. Чем точнее вход, тем чище атомы и код.

## Анализ влияния
`find_object` + чтение модулей + `search` по ОБОИМ слоям контура. Учесть слепые зоны (что зашито в данных/настройках,
а не в коде) и незагруженные слои. Интеграционная часть (перечень потоков данных, контракты, выбор REST/событийной
модели, чек интеграции) — **`references/integration-and-api-design.md`**.

## Когда подключать архитектора
Меняются архитектурные принципы/домены/слои? Влияет на несколько подсистем/контуров? Новый/нетиповой паттерн?
Правила не дают ответа? → архитектурное решение. Иначе → архитектурное согласование. При сомнении — в пользу архитектора.
Артефакт «Архитектура решения» и его разделы, C4, нотации — **`references/architecture-design.md`**.

## Чек-листы качества
Готовность к разработке (DoR/INVEST), готовность результата (DoD), чек-листы качества требования и архитектурного
решения, этапы внедрения и приёмка — **`references/quality-checklists.md`**.

## Роли-режимы
explorer (найти, как устроено) · analytic (требования, модель данных, критерии) · planner (границы, влияние) ·
architect (границы/ограничения, ADR, «Архитектура решения») · arch-reviewer (проверить тех-проект на соответствие архитектуре).

## Версионный стек
Настрой под свою конфигурацию (версия платформы, режим совместимости, версии библиотек) и не предлагай API вне
своего режима совместимости.