schema: spec-driven

context: |
  Language: Russian
  Пиши на русском, но:
  - Структурные заголовки оставляй на английском:
    ## ADDED/MODIFIED/REMOVED Requirements, ### Requirement:, #### Scenario:
  - Ключевые слова GIVEN/WHEN/THEN и RFC 2119 (SHALL/MUST/SHOULD) — на английском
  - Технические термины (API, REST, JSON, MCP), пути и код — на английском

  Имена capabilities:
  - Capability — это ПОВЕДЕНИЕ/домен системы, а не пакет кода (совпадение с
    именем пакета допустимо, но не критерий).
  - Существительное, понятное без знания кода: ingest, parsing, storage,
    read-api, self-description. НЕ store/httpapi (это реализация).
  - Гранулярность по принципу «требования меняются вместе». Дробить, когда в
    одной спеке смешиваются разные заботы. Переименовать дёшево (RENAMED
    Requirements) — не дроби преждевременно в маленьком проекте.

  RFC 2119 — это требование валидатора, не стиль:
  - Каждое ### Requirement ОБЯЗАНО содержать литерал SHALL или MUST, иначе
    `openspec validate` падает (проверено). Поэтому эти слова и WHEN/THEN не
    русифицируем — они несут точную нормативную/структурную семантику.

  Ревью (процесс, не артефакт):
  - Правило выбора профиля и состав проходов здесь не пересказываем: их дом —
    скилл av-dev-pipeline:review-pipeline, проектная настройка — docs/review.md.

  Конвенции кода (соблюдать при apply):
  - Механизируемое проверяет `task gate`, прозой остаётся
    docs/conventions/README.md. Ни состав шагов гейта, ни перечень конвенций
    здесь не пересказываем: и то и другое растёт по ходу задач, а источник
    скажет точнее и всегда актуальнее.

  Что это за проект — читай перед предложением, а не отсюда:
  - docs/passport.md — цель, её граница (чем проект НЕ является), потребители,
    типовые сценарии, референсы;
  - CLAUDE.md — инварианты с severity и семантика гейта;
  - docs/architecture.md — устройство; docs/database.md — схема;
    docs/security.md — периметр и модель угроз; docs/adr/ — почему решено так.
  Пересказа этих документов здесь нет намеренно: второй дом факта расходится с
  первым молча, и заметно это становится в предложении, которое уже написано.

  Развилка или блокер — сперва prior art. Проект не уникален: готовые решения
  смотрим в референсах паспорта, отвергаем — с названной причиной, и причина
  идёт в design.md этого же изменения (оттуда её промоутит в docs/adr/ скилл
  av-dev-pm:docs).

  Разведка уже проведена, догадки о формате не нужны:
  - docs/research/apple-health.md — находки на живом потоке, во многом расходящиеся с
    документацией Health Auto Export. ПРОВЕРЬ ТАМ, прежде чем строить
    предположение о формате входа: скорее всего вопрос закрыт измерением.
  - Тесты на разбор формата держим на реальных пакетах (testdata), а не на
    выдуманных: документация формата тонкая и местами врёт.

# Per-artifact rules (optional)
rules:
  proposal:
    - Capabilities называй по поведению/домену системы, не по пакету кода
  specs:
    # Кавычки обязательны: без них YAML обрежет строку на первом '#'.
    - "Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)"
    - "Сценарий — ровно #### (четыре решётки); три или список молча теряются"
    - "SHALL/MUST должно стоять в ПЕРВОМ абзаце требования: валидатор смотрит только его, обоснование ниже он не видит (проверено)"
    - "Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском"