Аудит capability после пачки lifecycle-задач вскрыл две пред-существующие находки (вне scope самих задач) — заведены в беклог: - catched-source-type-namer-okno (средний): addReq не пересобирается из свежего source_type в окне namer'а; самоисцеляется через magnet_timeout→Retry. - dismiss-cancel-user-dismiss-marker (низкий): веб-UI зовёт Cancel вместо Dismiss на не-терминальных, теряется маркер user_dismiss. Инлайн: finishRecognition — комментарий врал про «Ф3, авто-раскладки нет»; фактически авто-раскладка идёт при Decision.Auto. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Документация jellybit
Три раздела с разной ролью — не путать:
-
specs/ — спецификации. Описывают целевое и текущее устройство системы. Живые и изменяемые: правим по мере развития, держим в соответствии с кодом. Отвечают на вопрос «как устроено».
-
adr/ — Architecture Decision Records. Неизменяемый журнал значимых решений, пишется постфактум. Хранит главное — почему так сделано. Передумали → не правим старую запись, заводим новую. Процесс — в adr/README.md.
-
drafts/ — черновики: заметки, мысли, планы на будущее, ещё не принятые решения. Не источник истины и ни к чему не обязывают. Когда черновик становится реальностью — его место в specs (как устроено) и/или adr (почему решили).