Правило, которое проверяет машина, не должно оставаться прозой: файл конвенций на сотни строк размазывает внимание по тривиальному — модель добросовестно проверит именование полей лога и не дойдёт до формы решения. Включены sloglint (константный msg, стиль ключ-значение), forbidigo (fmt.Print*, os.Getenv, time.Now мимо store.Now), errorlint (сравнение ошибок), depguard (сторонние пакеты ошибок). internal/archrules — сканеры на то, что линтером не выражается: направление зависимостей ядро↔транспорты, AUTOINCREMENT и серверное время в новых миграциях, матчинг ошибки по тексту. Код приведён к правилам: logging.StartCall как единая точка отсчёта длительности внешних вызовов, store.Now вместо time.Now в httpapi и часах воркера, slog.DiscardHandler в тестах. Перенесённое вычеркнуто из docs/conventions/* и openspec/config.yaml — прозой осталось только то, что правилом не выражается. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
59 lines
3.9 KiB
YAML
59 lines
3.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).
|
|
- Тривиальная задача — достаточно одного прохода (код).
|
|
|
|
Конвенции кода (соблюдать при apply):
|
|
- Механизируемое проверяет конвейер сборки (.golangci.yml + internal/archrules),
|
|
пересказывать его здесь не нужно: `task lint` и `task test` скажут точнее.
|
|
- Прозой остаётся то, что правилом не выражается, и это читаем в источнике:
|
|
docs/conventions/{logging,errors,config,database,web-ui}.md — уровень лога
|
|
по адресату, единственный логирующий чокпоинт на доменной границе,
|
|
трансляция доменной ошибки на внешней границе, самодокументируемый
|
|
config.example.toml, htmx-партиалы.
|
|
- Безопасность: никаких секретов в полях логов и в диагностике состояния
|
|
(пароли qBittorrent, API-ключи LLM/метабаз, auth-заголовки).
|
|
|
|
# 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 — на английском, остальной текст на русском
|