ADR фиксирует «почему»: recall чек-листа равен его длине, ценность верификатора определяется оракулом и декорреляцией с автором (а не числом ролей), отчёт без границ покрытия хуже отсутствия отчёта. В беклоге закрыт открытый вопрос «дробить ли review-code на узкие оптики» — не дробим; осталась калибровка проходов и ревьювер наименований. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Документация jellybit
Три раздела с разной ролью — не путать:
-
specs/ — спецификации. Описывают целевое и текущее устройство системы. Живые и изменяемые: правим по мере развития, держим в соответствии с кодом. Отвечают на вопрос «как устроено».
-
adr/ — Architecture Decision Records. Неизменяемый журнал значимых решений, пишется постфактум. Хранит главное — почему так сделано. Передумали → не правим старую запись, заводим новую. Процесс — в adr/README.md.
-
drafts/ — черновики: заметки, мысли, планы на будущее, ещё не принятые решения. Не источник истины и ни к чему не обязывают. Когда черновик становится реальностью — его место в specs (как устроено) и/или adr (почему решили).
Рядом лежат ещё два прикладных раздела: conventions/ — как мы пишем код (то, что не выражается правилом линтера), и review/ — журнал дефектов, проскочивших ревью: эвал-сет для калибровки конвейера review-pipeline.