unica-rules git:20261016.9c6355cA

Immutable. This exact content never changes and is served at /api/v1/blob/41f7d36ed02e5d63.

---
name: unica-rules
description: Правила продукта Unica — предложение, добавление, изменение, отмена и разбор расхождений с кодом или тестами. Используй при работе с обязательствами arch/rules/; качество и запуск проверок остаются в unica-testing.
---

# Правила продукта Unica

Применяй навык при оценке и сопровождении самих правил. Обычное использование
применимой гарантии при исправлении кода не требует всего редакторского
маршрута. Формат записи задан в [arch/README.md](../../../arch/README.md),
полномочия при противоречии — в
[AGENTS.md](../../../AGENTS.md#противоречие-принятому-правилу).

При изменении текста используй общие приёмы
[unica-writing](../unica-writing/SKILL.md#общие-приёмы); при выборе, изменении
или запуске проверки — [unica-testing](../unica-testing/SKILL.md).
Класс задачи, скептика и reviewer-а выбирай по
[порядку разработки](../unica-development/SKILL.md#класс-задачи-и-независимая-проверка).
Не загружай эти процедуры повторно, если они уже прочитаны в этой работе.

## Назначение и атомарность

Правило закрепляет принятую устойчивую гарантию продукта: поведение,
совместимость, изоляцию данных, границу ответственности или зависимостей,
место обязательной проверки. Назови ситуацию применения, обязательный
результат, конкретное нарушение и способ его обнаружить. Структурная граница
тоже подходит; описание текущего устройства кода само по себе правилом
не становится.

Одна запись — одна самостоятельная гарантия. Её условия, исключения и
связанные последствия сохраняй вместе: восстановление исходников и кеша
после отказа — одна гарантия согласованности. Разделяй запись, когда её части
можно независимо принять, изменить или отменить как разные гарантии.
Количество тестов и assertions атомарность не определяет.

Новое правило нужно при принятии новой гарантии; изменение — при смене её
условий, границы или допустимого результата. Исправление реализации в рамках
гарантии, локальный рефакторинг и правка процесса сами по себе записи не
требуют. Частота случая сама по себе не определяет нужность правила:
учитывай последствия нарушения, включая редкие отказы с потерей данных.
Повторная ошибка агента — повод проверить инструкции, но не основание
самостоятельно вводить обязательство. Порядок работы агента остаётся
в навыках разработки.

## Общее и частное

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

Пример нужен, когда устраняет неоднозначность; он поясняет сформулированную
гарантию и не вводит собственных обязательств или исключений. Если при его
удалении теряется значимая граница, вырази её в самом обязательстве.
Регрессионный сценарий и его конкретные данные оставляй в тесте из `check`;
вместо копирования укажи ссылку и объясни, какую границу он показывает.

## Содержание и детализация

Формулируй гарантию понятным действием; заголовок передаёт, что сохраняется
или предотвращается. В тексте уместны условия, исключения, допустимый исход
отказа и краткая причина ограничения, когда они помогают отличить нарушение.
Пример точной границы —
[откат при обрабатываемом отказе](../../../arch/rules/workspace/retained-apply-rollback.md).
Не добавляй новое обязательство ради пояснения или шаблона.

История выбора, сравнение архитектурных альтернатив, план и прогресс остаются
в issue/PR; полный набор сценариев — в тестах, процедурные инструкции —
в навыках, текущее устройство — в коде и его документации. Архитектурное
ограничение уместно как самостоятельная гарантия; последовательность вызовов,
алгоритм и состав внутренних структур сами по себе обязательства не образуют.
Описание проверки нужно, когда объясняет границу доказанного: обработанный
отказ и авария процесса различаются. Не пересказывай assertions построчно.

Деталей должно хватать для выбора допустимого решения. Общие пожелания
вроде «обеспечить надёжность» этого не дают. Точные имена, числа, форматы
и механизмы закрепляй нормативно, когда они защищают принятую гарантию.
Навигационное упоминание текущего модуля допустимо без обещания сохранить
его устройство. Оставляй возможность заменить реализацию, если её конкретный
способ не является предметом обязательства. Ссылайся на канонический код,
схему или пример вместо копирования их содержимого. Механические требования
к оформлению проверяй принятым линтером или форматтером; не пересказывай
их конфигурацию и общие руководства в правиле. Автоматическая проверка
не заменяет формулировку продуктовой гарантии.

Редакторский ориентир — один–четыре коротких абзаца, обычно до 200 слов
основного текста без метаданных. Это не минимальный объём и не автоматический
лимит. Более длинная запись допустима для одной гарантии; при росте проверь
повторы, самостоятельные обязательства и пересказ тестов. Условия и исключения
ради краткости не удаляй; тест на число слов не нужен.

## Связи и размещение

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

У нормативной формулировки один владелец. Из других правил и документов
ссылайся на него без копирования. Объясняй связь: общее определение,
зависимость, исключение или соседняя гарантия. Собственное обязательство
должно быть понятно из записи; общие определения могут читаться по ссылке.
Взаимная навигация допустима, круговое обоснование ничего не доказывает.
Дата, расположение и число ссылок не устанавливают приоритет при конфликте.

## Предложение и изменение

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

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

После решения меняй правило вместе с необходимыми правками реализации и
содержательных проверок. Если существующий код и тесты уже подтверждают
гарантию, менять их ради записи не требуется. Исключение для отложенной
реализации требует явного согласования и описано ниже. Не меняй по ходу
чужое обязательство ради более удобной реализации.

При редактуре без смены смысла сохраняй `id`, `check`, условия и исключения.
Перенос и исправление адреса теста не являются новым продуктовым решением;
при переименовании проверки убедись, что её сценарий и сила сохранились.

## Отмена и перенос

Удаление файла не равно отмене гарантии. При устранении дубля сохрани всё
обязательство у одного владельца. При отмене установи, какое поведение теперь
разрешается, последствия для потребителей и зависимых правил; используй
имеющееся решение владельца или предложи отмену до зависимой правки.

При переносе сохраняй `id` и `check`, обновляй ссылки. При разделении или
объединении явно сопоставь сохраняемые обязательства и достаточные проверки
в diff и описании PR. `id` сохраняй за той же гарантией; новым самостоятельным
гарантиям назначай свои идентификаторы. Ссылки на удаляемую запись обнови.
История решения остаётся в Git и обсуждении; ADR, архив отменённых записей,
постоянный индекс и цепочка преемников для этого не нужны.

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

## Проверки и разрывы

Различай принятие гарантии, её выполнение реализацией и достаточность
доказательств. Зелёный тест может быть слабым, отсутствие теста не доказывает
дефект продукта, отсутствие `gap` не удостоверяет выполнение всего правила.
Текст записи не проверяй тестом на слова.

В `check` перечисляй существующие содержательные тесты, подтверждающие именно
эту гарантию, в том числе несколько проверок разных условий. Проверь реальное
исполнение, ОС, features и границы сценария по unica-testing; имя или наличие
функции не является подтверждением. Частичная проверка не доказывает всё
обязательство.

При явно согласованной отложенной реализации укажи `gap` на issue с текущим
разрывом и критериями приёмки. В самой записи кратко различи границу обещанного
и доказанного; подробный прогресс оставь в issue. В `check` сохраняй только
проверки новой гарантии; если их нет — `[]`. Тесты прежнего противоположного
поведения перечисли в issue как свидетельства разрыва. Пустой список не
позволяет самостоятельно объявить реализацию дефектной или отменить гарантию.
Установи, недостаёт реализации, проверки или обоих компонентов.

После реализации заполни `check` и убери `gap`, когда содержательные проверки
подтвердят всё обязательство. Закрытие issue само по себе для этого недостаточно.

## Расхождение с кодом или тестом

При падении сначала получи достоверные идентичность теста, ревизию, результат
и условия запуска по [unica-testing](../unica-testing/SKILL.md#после-падения-и-при-ревью).
Ищи через `rg -F` в `arch/rules/` адрес `путь::имя_теста` для Rust или
`путь::Класс.метод` для Python. `fullName` отчёта не равен адресу `check`.
Ноль или несколько правил допустимы; запись ради заполнения связи не создавай.
После потери контекста восстанови затронутые записи и проверки по файлам.

Сопоставь правило, тело теста и код; затем установи причину:

- Реализация нарушает однозначную действующую гарантию — воспроизведи и исправь
  дефект, усилив проверку при необходимости. Нового продуктового выбора нет.
- Тест ошибочен или недостаточен либо связь `check` неверна — исправь
  доказательство, сохранив обязательство и достаточное покрытие.
- Есть принятая целевая гарантия с разрывом — работай в рамках согласованного
  перехода и точно назови оставшуюся работу.
- Запись отстала от уже принятого решения — подтверди решение и обнови текст
  и ссылки без повторного согласования.
- Принятые обязательства конфликтуют или требуется новый выбор — примени
  [порядок AGENTS](../../../AGENTS.md#противоречие-принятому-правилу).

Сам факт поведения кода и падение теста не разрешают ослабить ожидание или
переписать правило под результат. Если обещано больше, чем доказано, покажи
границу проверки. Проверяемый спор разрешай свидетельствами; зависимое
изменение обязательства требует решения, а независимая работа может продолжаться.