Дополнил правила

openspec/config.yaml

@@ -8,6 +8,26 @@ context: |
   - Ключевые слова GIVEN/WHEN/THEN и RFC 2119 (SHALL/MUST/SHOULD) — на английском
   - Технические термины (API, REST, JWT), пути и код — на английском
 
+  Имена capabilities:
+  - Capability — это ПОВЕДЕНИЕ/домен системы, а не пакет кода (совпадение с
+    именем пакета допустимо, но не критерий).
+  - Существительное, понятное без знания кода: ingest, recognition,
+    file-layout, review, notifications. НЕ qbt/worker (это реализация).
+  - Гранулярность по принципу «требования меняются вместе». Дробить, когда в
+    одной спеке смешиваются разные заботы. Переименовать дёшево (RENAMED
+    Requirements) — не дроби преждевременно в маленьком проекте.
+
+  RFC 2119 — это требование валидатора, не стиль:
+  - Каждое ### Requirement ОБЯЗАНО содержать литерал SHALL или MUST, иначе
+    `openspec validate` падает (проверено). Поэтому эти слова и WHEN/THEN не
+    русифицируем — они несут точную нормативную/структурную семантику.
+
+  Ревью (процесс, не артефакт):
+  - Нетривиальная/архитектурная задача — два чекпоинта: ревью дизайна (после
+    design/specs, ДО кода — дешевле чинить направление) и ревью кода (после
+    apply, до archive).
+  - Тривиальная задача — достаточно одного прохода (код).
+
 # Project context (optional)
 # This is shown to AI when creating artifacts.
 # Add your tech stack, conventions, style guides, domain knowledge, etc.
@@ -19,10 +39,9 @@ context: |
 
 # Per-artifact rules (optional)
 # Add custom rules for specific artifacts.
-# Example:
-#   rules:
-#     proposal:
-#       - Keep proposals under 500 words
-#       - Always include a "Non-goals" section
-#     tasks:
-#       - Break tasks into chunks of max 2 hours
+rules:
+  proposal:
+    - Capabilities называй по поведению/домену системы, не по пакету кода
+  specs:
+    - Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)
+    - Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском