# Точки входа для разработки Unica

Для исследования, изменения, тестирования и ревью самого Unica прочитайте
[unica-development](.agents/skills/unica-development/SKILL.md). Он задаёт
рабочий порядок и направляет в тестирование, редактуру и подготовку PR.
При запросе выпустить, продвинуть, завершить или проверить состояние релиза
прочитайте [unica-release](.agents/skills/unica-release/SKILL.md) до действий.

Проектные скиллы лежат в `.agents/skills/`. Если хост уже передал их имена,
описания и пути, используйте этот каталог. Иначе прочитайте только поля
`name` и `description` их `SKILL.md`, выберите нужные и откройте их тела.
Не загружайте все навыки целиком. Для Claude этот переход задаётся здесь;
нативное обнаружение `.agents/skills/` не предполагается.

`plugins/unica/skills/` — навыки работы с 1С через готовый продукт.
При разработке Unica они читаются по затронутой возможности.

## Источники и расхождения

Код и тесты показывают фактическое поведение. Согласованные правила продукта
в `arch/rules/` описывают, что должно сохраняться. Прочитайте применимые записи
до выбора решения: ищите по предмету задачи, исходникам и ссылкам `check`.
Правила в `arch/rules/` приняты владельцем; они не исчерпывают гарантий продукта.
Отсутствие записи не разрешает менять поведение или удалять содержательный тест.

Контракт пакета задают `plugins/unica/.mcp.json`, оба манифеста
`plugins/unica/.codex-plugin/plugin.json` и
`plugins/unica/.claude-plugin/plugin.json`, `plugins/unica/third-party/tools.lock.json`.
Спецификации XML 1С и JSON-DSL — в `plugins/unica/references/specs/`.
Расхождение с эмиттером разбирайте по содержательному тесту, фикстуре или
официальному дампу платформы. Происхождение адаптированных апстримов описано
в `docs/provenance/skill-upstreams.json` и `plugins/unica/ATTRIBUTIONS.md`.

## Противоречие принятому правилу

При расхождении правила и поведения установите причину: дефект реализации,
пробел проверки или необходимость изменить обязательство. Если соблюдение
правила мешает цели задачи, покажите человеку:

1. Запись и точную формулировку ограничения.
2. Цену соблюдения: что теряем, сохраняя правило.
3. Цену замены: какие гарантии и потребители затронуты.
4. Оба варианта решения.

До выбора человека не выполняйте зависимое изменение; независимая работа
может продолжаться. Не отбрасывайте подход молча, не заменяйте задачу удобным
для старого правила суррогатом и не ослабляйте обязательство под текущее
поведение. Уже согласованное в этой работе решение не требует нового одобрения.

## Гигиена поиска

Начинайте с `rg` и `git ls-files` в выбранной области. Не сканируйте при обычном
изучении `target/`, `.build/`, `dist/`, `docs-local/` и `.session-temp/`.
`docs-local/` — местные исследовательские материалы, не справка платформы.
Нужную справку запрашивайте через доступный инструмент документации Unica;
его имя и контракт сверяйте с используемой сборкой.

Исторические `docs/design/`, `docs/plans/`, `docs/provenance/reviews/`,
`docs/arch-v1/` и `docs/arch-v2/` не являются действующими инструкциями.
Открывайте их только для истории конкретного изменения или разбора перед
удалением. Новые планы и служебные меппинги туда не добавляются; их место и
порядок удаления старых материалов задаёт
[unica-development](.agents/skills/unica-development/SKILL.md#материалы-работы).
При упаковке предпочитайте отслеживаемые файлы и артефакты пакета обходу диска.