1c Analyst

Анализ и архитектура 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 вне своего режима совместимости.