av
2c12376262
- ссылки на tasks/ROADMAP.md переведены на BACKLOG.md и на openspec/specs, упоминания целей — на задачи, которые эту работу делают; - судьи документации нашли восемь расхождений: Purpose спеки pipeline объявлял неописанным то, что уже нормирован пятью требованиями, вид времени в конвенции спорил со схемой, а квоты, шесть часов и отказ от Web Push жили сразу в двух документах без ссылки друг на друга; - два числа получили провенанс: 259 200 запросов в сутки и потолок в шесть часов теперь ведут к записке разведки, а не читаются как замер.
68 lines
5.6 KiB
YAML
68 lines
5.6 KiB
YAML
schema: spec-driven
|
|
|
|
context: |
|
|
Language: Russian
|
|
Пиши на русском, но:
|
|
- Структурные заголовки оставляй на английском:
|
|
## ADDED/MODIFIED/REMOVED Requirements, ### Requirement:, #### Scenario:
|
|
- Ключевые слова GIVEN/WHEN/THEN и RFC 2119 (SHALL/MUST/SHOULD) — на английском
|
|
- Технические термины, пути и код — на английском
|
|
|
|
Имена capabilities:
|
|
- Capability — это ПОВЕДЕНИЕ или домен системы, а не пакет кода (совпадение с
|
|
именем пакета допустимо, но не критерий).
|
|
- Существительное, понятное без знания кода: intake, recognition, delivery —
|
|
это примеры формы, а не список проекта. НЕ service/httpapi/tg: это
|
|
реализация.
|
|
- Гранулярность по принципу «требования меняются вместе». Дробить, когда в
|
|
одной спеке смешиваются разные заботы. Переименовать дёшево (RENAMED
|
|
Requirements) — не дроби преждевременно в маленьком проекте.
|
|
|
|
RFC 2119 — требование валидатора, не стиль:
|
|
- Каждое ### Requirement ОБЯЗАНО содержать литерал SHALL или MUST, иначе
|
|
`openspec validate` падает. Поэтому эти слова и WHEN/THEN не русифицируем.
|
|
|
|
Состояние спек и правило «первая задача, трогающая поведение, заводит спеку
|
|
своей capability» — docs/architecture.md, преамбула.
|
|
|
|
Что это за проект — читай перед предложением, а не отсюда:
|
|
- docs/passport.md — цель, её граница (чем проект НЕ является), потребители,
|
|
типовые сценарии, референсы;
|
|
- CLAUDE.md — инварианты с severity и семантика гейта;
|
|
- docs/architecture.md — устройство; docs/security.md — периметр;
|
|
docs/database.md — схема и настройки с числами; docs/adr/ — почему решено
|
|
так; docs/research/ — что уже измерено;
|
|
- openspec/specs/ — что приложение уже умеет; tasks/BACKLOG.md — что осталось
|
|
и в каком порядке это берут.
|
|
Пересказа этих документов здесь нет намеренно: второй дом факта расходится с
|
|
первым молча, и заметно это становится в предложении, которое уже написано.
|
|
|
|
Ревью: правило выбора метки и состав проходов здесь не пересказываем — их дом
|
|
скилл av-dev:code-review, проектная настройка — docs/review.md.
|
|
|
|
Конвенции кода: механизированное проверяет гейт, прозой остаётся
|
|
docs/conventions/. Ни состав шагов гейта, ни перечень конвенций здесь не
|
|
пересказываем: и то и другое растёт по ходу задач.
|
|
|
|
Развилка или блокер — сперва prior art. Готовые решения смотрим в референсах
|
|
паспорта, отвергаем — с названной причиной, и причина идёт в design.md этого
|
|
же изменения.
|
|
|
|
rules:
|
|
proposal:
|
|
- Capabilities называй по поведению или домену системы, не по пакету кода
|
|
- "Why и What Changes — языком домена из docs/passport.md: без SHALL, без имён модулей и функций там, где вещь называется по-русски"
|
|
design:
|
|
- "Назови рассмотренные варианты и причину отказа от каждого — из них потом пишется ADR"
|
|
- "Решение объясняется через то, что человек увидит иначе, а не через устройство кода"
|
|
specs:
|
|
# Кавычки обязательны: без них YAML обрежет строку на первом '#'.
|
|
- "Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)"
|
|
- "Сценарий — ровно #### (четыре решётки); три или список молча теряются"
|
|
- "SHALL/MUST должно стоять в ПЕРВОМ абзаце требования: валидатор смотрит только его"
|
|
- "Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском"
|
|
tasks:
|
|
- "Критерии приёмки задачи — отдельным блоком и дословно: файл задачи закрытие удалит, критерии обязаны его пережить"
|
|
- "Рубрика ревью дизайна, если оно её дало, идёт в тот же блок: приёмка судится по одному списку, а не по двум"
|
|
- "Шаг плана формулируется проверяемо — по нему видно «сделано / не сделано» без суждения"
|