houseplan-card/docs/reviews/SPEC-REVIEW-399-r2.md

SPEC-REVIEW-399-r3

• Issue: https://github.com/Matysh/houseplan-card/issues/399
• ТЗ: docs/specs/399-backend-gate-honesty.md
• Материал: SHA bb635298c153ba8d5104e19a70e695d1fcf1a5c5 (ветка issue/399-backend-gate-honesty, ревизия 3 поверх dev; merge-base с origin/dev = f7fb3369 = текущий tip dev — рёбейза не было)
• Заход: r3, не r2 — см. «Расхождение с заданием раунда» ниже
• Блокирующих циклов израсходовано: 2/4 (r1 жёлтый, r2 жёлтый; зелёный цикла не тратит, #227)
• Трек: полный (не изменился, наследуется из r1/r2)
• Вердикт: зелёный

Расхождение с заданием раунда (нужно проговорить явно)

Задание на этот прогон присвоило заходу номер r2 и указало «блокирующих циклов израсходовано 1 из 4». Это не соответствует фактическому состоянию issue:

• на #399 уже стоят два реальных комментария-вердикта: Вердикт: жёлтый · заход r1 · блокирующих циклов 0/4 · High: 0 · Medium: 1 → в задаче (2026-08-31T01:14:00Z) и Вердикт: жёлтый · заход r2 · блокирующих циклов 1/4 · High: 0 · Medium: 1 → в задаче (2026-08-31T01:23:10Z);
• на каждый из них автор ответил правкой: 6d229c66 docs: #399 spec revision 2 per SPEC-REVIEW-399-r1, затем bb635298 docs: #399 spec revision 3 per SPEC-REVIEW-399-r2 (комментарий автора «Ревизия 3 — Medium закрыт», 2026-08-31T01:26:20Z);
• файл docs/reviews/SPEC-REVIEW-399-r1.md в репозитории существует, но содержит текст, который сам себя называет «SPEC-REVIEW-399-r2» (шаг публикации предыдущего прогона присвоил ему имя r1 по (тоже ошибочному) заданию того прогона, затерев исходный документ r1 — тот же класс сбоя, который этот прогон обязан не повторить).

То есть реально состоялись два цикла (r1 и r2), оба жёлтые, оба стоили бюджета: 2/4. Присвоение этому прогону имени r2 создало бы риск нового столкновения — второй комментарий-вердикт с заголовком «заход r2» на одной issue — и заняло бы неверную позицию в бюджете (1/4 вместо фактических 2/4). Поэтому документ и вердикт этого прогона используют номер r3, полученный из вердиктов и коммитов issue, а не из присланного заголовка задания. Далее — процедура §2.9/§2.10 для «не первого» цикла.

Дельта, которая является предметом этого раунда

git diff 6d229c66..bb635298 -- docs/specs/399-backend-gate-honesty.md — ровно три места:

1. строка «Ревизия» в шапке (3, со ссылкой на SPEC-REVIEW-399-r2 и причиной: «план тестов повторял снятую формулировку AC5»);
2. раздел «План автотестов», пункты 4–5 переписаны: пункт 4 теперь описывает перебор каталога .github/workflows/*.yml целиком и явно фиксирует «списка обходимых файлов в тесте нет и быть не должно»; пункт 5 добавлен и называет вывод проверки на реальном дереве («девять workflow, установка python-зависимостей — в двух»);
3. в раздел «Мутанты» добавлена новая запись workflow-scan-hardcodes-the-list (замена перебора каталога на фиксированный список имён обязана красить пункт 4 плана).

Ничего за пределами этих трёх мест не менялось: контракт п.(3), AC5 сам текст, разделы (1) M3, (2) Low «а», скоуп/не-скоуп, AC1–AC4/AC6, риски, откат, release-артефакты — байт в байт те же, что видел r2.

Закрытие раунда r2

Находка r2	Чем закрыта	Где видно
Medium: «План автотестов» п.4 дословно повторял снятую (ревизия 2) формулировку AC5 — «явный список обходимых файлов зафиксирован; добавление нового файла без обновления списка краснеет» — то есть описывал именно ту хардкод-конструкцию, от которой переписанный AC5 уходит	П.4 переписан: «Каталог .github/workflows/*.yml перебирается целиком… краснеет без правки каких-либо списков в тесте… Списка обходимых файлов в тесте нет и быть не должно — файл, не ставящий python-зависимостей, распознаётся по собственному содержимому.» Формулировка теперь дословно исключает хардкод-список, а не допускает его как законное прочтение	docs/specs/399-backend-gate-honesty.md:155-159 (план, п.4), :170-172 (новый мутант workflow-scan-hardcodes-the-list, закрепляющий это как проверяемый контракт для код-ревью), SHA bb635298

Находка закрыта по существу, а не переформулирована уклончиво: старая фраза «список… без обновления списка краснеет» заменена на прямой запрет («списка… нет и быть не должно»), и добавлен мутант, ловящий именно откат к списку, если реализация всё же попытается его завести — то есть контракт теперь не только описан текстом плана, но и зафиксирован как проверяемая точка для код-ревью.

Унаследовано из r2 (без повторной проверки)

Со ссылкой на docs/reviews/SPEC-REVIEW-399-r1.md (файл содержит текст раунда r2), SHA 6d229c66:

• §7.1: все обязательные разделы на месте (сценарий, что увидит человек, проблема по пунктам, скоуп/не-скоуп, UX/данные/i18n — н/п обоснованно, AC с доказательствами, риски, откат, release-артефакты) — делта их не трогает.
• Контракт п.(3) и текст AC5 (перебор каталога, а не списка; два исхода на файл) — не менялись этой ревизией, r2 их принял.
• AC1–AC4, AC6 — текст не менялся, доказательства признаны однозначными в r1/r2.
• Факт «в репозитории девять workflow, python-зависимости ставят два (validate.yml, mutation-gate.yml)» — перепроверялся в r2 на дереве той ревизии; в этом раунде перепроверен заново (см. ниже), так как та же цифра теперь дополнительно фигурирует в новом п.5 плана — расхождений нет.
• Классификация трека (полный, класс B, три несвязанные поверхности) — не меняется.
• Продуктовое обрамление и персоны SCOPE.md (задача инфраструктурная, User-Visible: no, ни одна J-строка Core user jobs не затронута) — не изменилось.
• «Чего не проверял» из r1/r2 (сетевое содержимое package_constraints.txt тега 2026.8.3, объём ruff-долга при исходе (2), аудит-документ вне репозитория) — остаётся в силе, эта делта их не касается.
• Расхождение задания/факта в самом r2 (там заход был неверно назван r1 в задании, скорректирован до r2) — исторический факт, не влияет на эту ревизию, кроме того, что от него унаследована необходимость сверять номер захода по вердиктам issue, а не по заголовку задания (сделано выше).

Как проверялось

• перечитаны docs/SCOPE.md, AGENTS.md, PROCESS.md целиком, включая §2.9, §2.10 (объём по дельте), §4 (лимит циклов, разница «заход»/«цикл»), §7.1 (обязательные разделы), §12 (запрещено);
• прочитано тело issue #399 и все 4 комментария (gh api repos/Matysh/houseplan-card/issues/399/comments) — восстановлена реальная последовательность r1 → ревизия 2 → r2 → ревизия 3;
• сверены SHA каждого раунда с git log по docs/specs/399-backend-gate- honesty.md и по docs/reviews/SPEC-REVIEW-399-r1.md;
• дельта git diff 6d229c66..bb635298 построчно сверена с находкой r2 — проверено, что новая формулировка п.4 не оставляет читателю законного прочтения «список с ручным обновлением»;
• независимо перепроверен факт AC5/п.5 на текущем дереве: ls .github/workflows/*.yml | wc -l → 9; git grep -l "pip install" .github/workflows/*.yml → ровно mutation-gate.yml и validate.yml. Совпадает с текстом ТЗ дословно;
• формат нового мутанта (workflow-scan-hardcodes-the-list, kebab-case, структура записи) сверен с существующими id: в scripts/mutation-gate.mjs — согласуется с уже принятым в репозитории стилем;
• проверено отсутствие рёбейза: git merge-base origin/dev HEAD совпадает с tip origin/dev (f7fb3369) — делта локальна, полный разбор с нуля не требуется по критериям §2.10.

Находки

Нет. Делта закрывает находку r2 по существу, не вводит новых противоречий между разделами, факты в новом тексте перепроверены и точны.

Что проверено и корректно (в дополнение к унаследованному)

• П.4 и п.5 плана автотестов теперь непротиворечивы контракту п.(3) и AC5: оба говорят про каталог, оба явно запрещают список для ручного обновления, оба ссылаются на один и тот же синтетический третий workflow.
• Новый мутант workflow-scan-hardcodes-the-list даёт код-ревью проверяемую точку для отлова именно того отката к списку, который стал возможен между ревизией 2 и 3 (риск, который сама находка r2 и описывала) — то есть закрытие сделано не только словами ТЗ, но и обязательством для реализации.
• Изменение не трогает трек, скоуп/не-скоуп, риски, критерии приёмки как формулировки (AC5 не редактировался), не переносит вопрос владельцу.
• Заголовок «Ревизия 3» корректно ссылается на SPEC-REVIEW-399-r2 (тот факт, что физически это docs/reviews/SPEC-REVIEW-399-r1.md, — не ошибка автора, а последствие сбоя предыдущего шага публикации, разобранного выше).

Чего не проверял

• Сетевое содержимое package_constraints.txt тега 2026.8.3 home-assistant/core (претензия M3) — не относится к этой делте (раздел (1) не менялся), недоступно и в этой среде; будет видно на код-ревью.
• Объём ruff-долга при исходе (2) для Low «а» — делта его не касается.
• npm test/npx tsc --noEmit/npm run build — это ревью документа (ТЗ), а не кода; делта правит только docs/specs/399-backend-gate-honesty.md, кода нет вовсе. Дешёвые гейты §2.10 в этом раунде неприменимы буквально (нет предмета для typecheck/test/build), они будут прогнаны на этапе код-ревью, когда появится реализация.
• Аудит-документ AUDIT-2026-08-31-v1700beta1.md вне репозитория — как и в r1/r2, не найден локально, тело issue самодостаточно.

Вердикт

Зелёный: делта раунда — три места в «Плане автотестов»/«Мутантах», все закрывают находку r2 по существу (проверено построчно, не на слово автора), новых расхождений между разделами ТЗ не введено, факты (9 workflow, 2 ставят python-зависимости) перепроверены и точны. Блокирующих находок нет — High: 0, Medium: 0. Зелёный вердикт цикла не образует и бюджет не тратит (#227): израсходовано 2/4 (r1, r2), после этого раунда — по-прежнему 2/4. Задача может двигаться дальше по конвейеру (S5-ready/реализация) без ещё одного цикла ревью ТЗ.