Уточнить язык, выбор контекста и пересмотр процессов Kit

hub/ARCHITECTURE.md

@@ -16,6 +16,8 @@ AGENTS.md целевого проекта
 
 Хаб остаётся источником шаблонов и обновлений. Подключённый проект владеет локальными правилами, а выбранная копия переносимых правил обновляется явной локальной синхронизацией.
 
+Установленный состав не равен контексту задачи: `CORE → выбранный профиль → релевантные темы → нужный рабочий процесс → локальные разделы`. Полная карта проекта служит пониманию системы человеком; агент выбирает разделы по области и зависимостям. Карта решений ведёт к релевантным основаниям по [правилу документации](../rules/DOCUMENTATION.md#карта-значимых-решений).
+
 ## Слои
 
 ### `rules/CORE.md`
@@ -28,7 +30,7 @@ AGENTS.md целевого проекта
 
 Подробные нормы для продукта, архитектуры и данных, реализации, качества, эксплуатации, безопасности, документации, Git, совместной работы с AI и исследований. Каталог включает их в итоговый набор, но агент читает только темы текущей задачи.
 
-Рабочие процессы конкретных задач находятся в `workflows/` и не считаются постоянными нормативными правилами. Идентификатор `project-study` пока сохраняется для совместимости `.ai-rules/manifest.json`, но создаёт `workflows/PROJECT_STUDY.md`. Идентификатор `project-audit` подключает `workflows/PROJECT_DEEP_AUDIT.md` для отдельной задачи глубокого аудита. Идентификатор `parallel-delivery` подключает `workflows/PARALLEL_DELIVERY.md` для явно выбранной параллельной задачи; `prompt parallel` только печатает стартовый запрос и не меняет проект. Ни один из этих процессов не входит в профиль и не подключается автоматически.
+Рабочие процессы находятся в `workflows/` и выбираются явно; профили не подключают их автоматически. Совместимые идентификаторы и пути задаёт `sync/catalog.json`, маршрут запуска — [README](../README.md). Команда `prompt` только печатает запрос и не меняет проект.
 
 ### `profiles/`
 
@@ -123,16 +125,9 @@ hub checkout + project manifest
 
 ## Жизненный цикл правила
 
-```text
-наблюдение или повторяющийся риск
-→ проверяемые примеры и подтверждения
-→ кандидат и проверка переносимости
-→ профиль или тематическое правило
-→ при подтверждении широкой применимости — `CORE.md`
-→ уточнение, замена или удаление с migration note
-```
+Наблюдение → проверка переносимости → профиль или тема → при широкой применимости `CORE` → пересмотр, замена или удаление с описанием перехода. Временный аудит не становится правилом: нужны подтверждения во втором контексте либо фундаментальный риск.
 
-Временный аудит не переносится напрямую в `CORE.md`. Сначала из него извлекается устойчивое решение, затем оно проверяется минимум на втором контексте или на фундаментальном риске вроде потери данных.
+Основание, доказательства, область, цена и условия пересмотра/удаления значимых правил, профилей и процессов хранятся в [существующем описании решения](../rules/DOCUMENTATION.md#пересмотр-средств-организации-работы-агента). Новая модель может сделать прежнюю меру лишней; подтверждённое упрощение предпочтительнее накопления. Это не вводит автоматическое удаление управляемых файлов.
 
 ## Что пока не строится
 

hub/CONTRIBUTING.md

@@ -23,7 +23,7 @@ Agent Engineering Kit развивается под управлением вл
 3. выявить конфликты, сравнить специфичность и актуальность правил и выбрать один канонический текст;
 4. оценить стоимость обязательного контекста: должно ли правило загружаться всегда или только для соответствующей задачи;
 5. проверить подтверждение минимум в двух контекстах либо фундаментальным риском;
-6. назначить одно действие: `add`, `merge`, `replace`, `move`, `reject` или `candidate` до появления достаточных оснований.
+6. назначить действие: добавить, объединить, заменить, перенести, удалить, отклонить или оставить кандидатом до появления оснований.
 
 До интеграции выдать краткий отчёт с выбранными действиями, конфликтами и ожидаемым влиянием на структуру. Если пользователь запросил предварительную ревизию или согласование, файлы не изменяются до его подтверждения.
 
@@ -49,6 +49,8 @@ Agent Engineering Kit развивается под управлением вл
 
 ## Список проверки
 
+После изменения проведи отдельный проход на упрощение: убери дубли и покрытые новым принципом инструкции, пересмотри абсолютные требования и длинные объяснения. Сравни объём постоянно читаемого контекста и всего затронутого набора; рост должен иметь наблюдаемую причину.
+
 - Не стала ли основа длиннее из-за профильного случая?
 - Есть ли один источник истины для нового правила?
 - Удалены ли точные и смысловые дубли?

hub/PROJECT_RULES.md

@@ -18,6 +18,8 @@
 6. правильный слой: core, тема, профиль, шаблон, пример или локальное правило проекта;
 7. путь применения: как правило попадёт к агенту до решения или действия, которое должно изменить.
 
+Для значимой меры также зафиксируй цену и условия пересмотра и удаления по [существующей модели решений](../rules/DOCUMENTATION.md#пересмотр-средств-организации-работы-агента). Неизвестные подтверждения не заменяются предполагаемой историей.
+
 Если правило подтверждено одним доменом и несёт его терминологию, оно остаётся профилем либо проектным примером. Базовый набор не растёт из единичного предпочтения.
 
 ## Нормативная граница

profiles/standard-product.md

@@ -12,4 +12,4 @@
 
 ## Рекомендуемые локальные документы
 
-Короткий product overview, system map и roadmap — только если каждый имеет отдельную поддерживаемую роль.
+Короткие обзор продукта, карта системы и план развития — только если каждый имеет отдельную поддерживаемую роль.