textmachine/docs/BACKEND_CONSISTENCY_SESSION_PROMPT.md

Промт: бэкенд-сессия «КОНСИСТЕНТНОСТЬ КАК ЗАКОН» — приоритет владельца №1

Ты — бэкенд-сессия TextMachine. Зона записи: backend/. Сессия НЕ коммитит — готовое дерево передаёшь оркестратору на лендинг. Чужие зоны (platform/, frontend/, eval/, docs/) не трогать; расхождения — пингом в секцию «Бэкенд» файла docs/PROGRESS.md. .env не читать.

Карта чтения — ЗАКОН, дальше только по её ссылкам

1. CLAUDE.md — цели и нормы. Особо: комментарий не доказывает поведение, источник утверждения о смысле — тест · тесты и гейты не подгонять под зелень · мутация засчитывается по ТЕКСТУ сообщения, а не по факту красноты · отрицательный замер печатает контрольную величину.
2. Строки бэклога 295, 267, 318, 320, 322 (docs/PROGRESS.md, греп ^| N |) — предмет пака целиком.
3. docs/architecture/03-implementation-notes.md — через баннер.
4. backend/README.md — механика движка.
5. docs/architecture/12-go-style-notes.md — норматив стиля, только больные места.

Зачем этот пак

Приоритет владельца №1 — консистентность терминов и голосов на всю книгу. Сегодня она держится на банке, а банк на проводе — закон для всех ролей. Пак закрывает четыре места, где этот закон либо не доезжает, либо описан неверно, и одно место, где принятая работа может быть потеряна.

⚠ Ни одна из этих строк не предлагает ослабить закон банка (D39.104). Он ратифицирован, и доказательств против него нет ни у одного голоса. Предмет — исполнение и честность описания.

Состав — пять предметов, порядок мой, отступления объявляй

1. Подать подписанный канон в прогон (половина строки 295) — ПЕРВЫМ

Без этого полигон не может мерить приоритет №1 вообще: точность чекера меряется на прогоне, в котором подписанный канон участвовал. Это разблокирует чужую зону, поэтому идёт первым.

Приёмка: прогон, где подписанный канон реально участвовал, предъявлен исполнением; что именно поехало на провод — видно из артефакта, а не из отчёта.

2. Гард перекрытия окон при слиянии (строка 267)

Один термин в одном смысле может нести две конкурирующие формы, и обе доезжают на оба провода — дыра в проверке схлопывания. Решение владельца 05.09 состоялось; строка несёт разбор.

⚠ Смежное, проверь заодно: совет оператору «пометь одну строку статусом» (строка 320а) гвард полисемии не исполняет — он статус НЕ СМОТРИТ вовсе. Либо совет приводится к тому, что код делает, либо гвард учится смотреть статус. Выбор объяви и обоснуй, молча не решай.

3. Комментарий постчека — привести к поведению (строка 318)

Комментарий обещает, что промах ловит и случай «мы вложили неверный dst, и модель его исполнила (страх владельца)». Код при найденной форме делает continue: исполненная неверная строка промаха не даёт. ⇒ метрика «нет промахов» означает «банк ИСПОЛНЕН», а читается как «исполнен ВЕРНО».

⛔ Заказ здесь узкий: честный комментарий плюс пин. Детектор правильности ЗНАЧЕНИЯ — не этот пак, он живёт строкой 286 и упирается в замер точности, а не в код. Не строй его тут.

4. Не уничтожать и адресовать принятую редактуру (строка 322, части «а» и «б»)

Ре-проход пере-делывает затронутую единицу целиком тем же редакторским промптом; прежний текст остаётся в чекпойнтах, но без адреса — ни одна строка статуса на него не указывает, экспорт не видит, отката нет. И один путь уничтожает его физически: ре-проход флагнулся → redrive → сброс сносит чекпойнты флагнутой стадии по всем снапшотам, прежняя хорошая редактура в их числе.

Заказ: (а) история финальных хешей при перезаписи финальной строки + ограда, чтобы сброс не удалял чекпойнт, на который ссылается история; (б) адресация выгрузки «по состоянию на».

⭐ Всё это ВНЕ снапшота и хеша запроса ⇒ перепокупки нет, ключ манифеста и версия встроенных данных не двигаются. Проверь это исполнением, не поверь на слово.

5. Два ложных комментария — снять (строки 320 и 322)

chunkstatus.go утверждает, что обычный резюм перезаписывает строку статуса — не перезаписывает, он выходит раньше; пишет только ре-пин. И оправдание nil-переноса в редакторской волне (строка 321) ложно — но саму передачу переноса в этом паке НЕ СТРОИТЬ: там сначала замер (см. ниже).

Чего в этом паке НЕТ и почему

• Строка 321 (перенос sticky) — не строить. Экспозиция замерена (49 строк, 4 из них уже в черновике), а дрейф — нет, инцидентов ноль. Сначала замер на следующем платном прогоне, потом решение. В этом паке — только правка ложного оправдания в комментарии.
• Строка 324 (вход рендера) — не долг, а контракт входа; расцеплена от 321, строить не надо.
• Детектор верности значения — строка 286, упирается в замер.
• Перекрой структуры глав (161/283) — отдельный дизайн-пак с мандатом качества.

Самопроверка — обязательна, и вот чем ЭТОТ пак уязвим

Не отчёт «проверено», а исполнение. Направление задаю, глубину и веер выбираешь сам:

1. Ты правишь ОПИСАНИЯ поведения. Соблазн подогнать текст под то, что «должно быть», максимален. После каждой правки комментария спроси: это описание того, что код ДЕЛАЕТ, или того, что я хотел бы? Сегодня проект нашёл пять таких мест за смену, все — прозой.
2. Мутации засчитывай по ТЕКСТУ. Правый вердикт по неправой причине — дыра, а не поимка: сегодня мутация покраснила гейт сообщением о рецепте, который делал ровно обратное сказанному.
3. Не двигает ли твоя правка деньги. Для каждой правки скажи прямо: двигает ли она снапшот, хеш запроса, ключ манифеста, версию встроенных данных. Если да — это перепокупка, и её надо объявить.
4. Числа с деревом и популяцией. Приводишь счёт — назови коммит и что посчитано.
5. ⭐ И отдельный проход, заказанный владельцем: ЛОГИЧЕСКИЕ баги, а не исполнительские. Пока ты в этих файлах — ищи места, где код работает как написано, но написанное не то, что задумывалось: гейт, отвечающий на свой вопрос вместо заказанного; метрика, чьё имя шире её смысла; ветка, которая по построению не исполняется. Найденное — не чинить молча, а вынести списком в отчёт: это заказ владельца, и он идёт в отдельный разбор.

Отчёт

Секция «Бэкенд» в docs/PROGRESS.md + сообщение оркестратору: что построено · чем предъявлено (команда и её вывод) · какие правки двигают деньги · список логических расхождений «задумано против сделано» · что осталось открытым · что ты сам считаешь слабым местом своей работы.

⚠ Числа батареи снимай после последней правки, не до. Пере-съём голдена, если понадобится, объявляй явно с причиной (D39.183).