Files
jellybit/openspec/config.yaml
T
2026-06-28 12:39:41 +03:00

48 lines
2.9 KiB
YAML

schema: spec-driven
context: |
Language: Russian
Пиши на русском, но:
- Структурные заголовки оставляй на английском:
## ADDED/MODIFIED/REMOVED Requirements, ### Requirement:, #### Scenario:
- Ключевые слова 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.
# Example:
# context: |
# Tech stack: TypeScript, React, Node.js
# We use conventional commits
# Domain: e-commerce platform
# Per-artifact rules (optional)
# Add custom rules for specific artifacts.
rules:
proposal:
- Capabilities называй по поведению/домену системы, не по пакету кода
specs:
- Каждое ### Requirement обязано содержать SHALL или MUST (иначе валидация падает)
- Заголовки и WHEN/THEN/GIVEN — на английском, остальной текст на русском