Фиксирую состояние

_process/doc_rules_v3/common-elements/api-contract.md

@@ -1,5 +1,7 @@
 # API Contract Rules
 
+Этот rule описывает только тело секции `### Контракт`.
+
 ## Обязательные части
 - request parameters (`header/query/path`)
 - request body (если применимо)
@@ -9,6 +11,11 @@
 - timeout
 - retry/idempotency (если применимо)
 
+## Правила заголовков внутри тела секции
+- Не повторять заголовок `Контракт`.
+- Запрещено выводить `## Контракт` и `### Контракт` внутри тела секции.
+- Если нужны подзаголовки, использовать только уровень ниже родительской секции: `#### Запрос`, `#### Ответ`, `#### Ошибки`, `#### Auth`, `#### Timeout`, `#### Retry/Idempotency`.
+
 ## Табличный формат
 Для request/response таблицы должны содержать:
 - название

_process/doc_rules_v3/common-elements/fr.md

@@ -1,5 +1,7 @@
 # Functional Requirements Rules
 
+Этот rule описывает только тело секции `### Функциональные требования`.
+
 ## Формат
 - `FR.<номер>. <Название>`
 - Нумерация инкрементальная внутри документа.
@@ -9,6 +11,7 @@
 - FR не копируют шаги сценария без добавления новой информации.
 - Для интеграционных шагов FR обязательны.
 - Если в сценарии есть вызов внешнего API / сервиса / БД, нужен отдельный FR на интеграцию.
+- Запрещено повторять заголовок `### Функциональные требования` внутри тела секции.
 
 ## FR для интеграционных шагов
 Для интеграционного FR обязательно раскрывать:

_process/doc_rules_v3/common-elements/tech-use-case.md

@@ -1,5 +1,7 @@
 # Tech Use Case Rules
 
+Этот rule описывает только тело секции `### Технический use case`.
+
 ## Обязательные части
 - название
 - предусловия
@@ -14,3 +16,4 @@
 - Формат шага: смысловое действие + техническая реализация (endpoint/топик/операция).
 - Длинные технические детали выносить в FR и ссылаться на FR из шага.
 - Для интеграционных шагов описание обработки ошибок обязательно.
+- Запрещено повторять заголовок `### Технический use case` внутри тела секции.