houseplan-card/docs/reviews/SPEC-REVIEW-331-r3.md

# SPEC-REVIEW-331-r3

Issue: #331 — «Ограничения стыков (#329): пограничная точность даёт ложные
отказы и невидимые дубли»
ТЗ: `docs/specs/331-junction-limit-precision.md`
Материал раунда: ревизия 3, SHA `4423d285` (issue-комментарий автора
называет этот SHA явно: «Ревизия 3 (`4423d285`)»).
Предыдущий раунд: r2, вердикт «жёлтый», документ
`docs/reviews/SPEC-REVIEW-331-r2.md`, материал на SHA `2d703543`.
Трек: полный (не `small`) — issue не помечен `small` (метки: `bug`, `P1`,
`S4-spec-review`), ТЗ по-прежнему живёт в `docs/specs/331-*.md`; дифф
r2→r3 трек не меняет.
Заход: r3 · блокирующих циклов израсходовано 2 из 4 (r2 жёлтый цикл
израсходовал 2-й; зелёный вердикт бюджет не тратит и цикла не образует —
см. системную инструкцию по #227).

## Скоуп разбора (дельта, не заново)

Дельта раунда — `git diff 2d703543..4423d285 -- docs/specs/331-junction-limit-precision.md`.
Затронуто три места: статус-строка (сводка ревизии), AC6 (`§4`), формулировка
риска (2) в `§6`. Обе находки r2 (M-r2-1, L2) — предмет этой правки, других
разделов дифф не касается. Это ровно тот случай, когда объём разбора
сокращается до дельты: изменение локально (два абзаца), не меняет трек,
не задевает новую подсистему, не является ребейзом. Полный повторный разбор
не требуется; но каждая из двух правок проверена по существу — совпадает ли
новый текст с тем, что r2 явно потребовал, и не рвёт ли он согласованность
с остальным документом (§2.5, §2.6, AC5).

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

1. `git diff 2d703543..4423d285 -- docs/specs/331-junction-limit-precision.md`
   — построчно.
2. Текст находки M-r2-1 (`docs/reviews/SPEC-REVIEW-331-r2.md:78-108`) —
   сверен пункт за пунктом с новым текстом AC6 (`docs/specs/331-junction-limit-precision.md:144-150`):
   ожидались два явных случая по образцу AC5, требование выполнено дословно.
3. Текст находки L2 (`SPEC-REVIEW-331-r2.md:112-125`) — сверен с новой
   формулировкой риска (2) (`:170-171`): «максимальная ветвь» → «сумма
   коллинеарной компоненты», совпадает буквально с текстом §2.3 (`:76-78`,
   не тронут этим диффом).
4. Перечитан §2.5 (`:88-94`) и §2.6 (`:96-105`) — не тронуты диффом r2→r3 —
   чтобы убедиться, что новый текст AC6 не противоречит нормативному
   тексту, который он тестирует: candidate → «честная ошибка WS,
   fail-closed, как §2.5»; previous → «прежний широкий фолбэк "нет базы
   для наследования"». Формулировка AC6 (а)/(б) слово в слово повторяет
   эту асимметрию.
5. Перечитан AC5 (`:141-143`, не тронут) — «по образцу AC5» из статус-строки
   и текста AC6 действительно означает структурное подобие: два явных
   случая по сторонам с разным исходом, как у AC5 (кандидат/baseline).
6. Прочитан полный файл `docs/specs/331-junction-limit-precision.md`
   целиком (не только дельту) — на предмет новых внутренних противоречий,
   которые правка могла случайно внести в соседние разделы (§3, §5, §6
   целиком). Противоречий не найдено.
7. Issue #331 — комментарии перечитаны (`gh issue view 331 --json comments`):
   вердикт r2 (жёлтый, M-r2-1 + L2) и хендофф автора о ревизии 3 — оба
   совпадают с тем, что видно в диффе; SHA назван автором явно.

Гейты `typecheck`/`test`/`build`/`check-docs`/инварианты модели/смоки/
golden/backend-pytest/perf — не гонялись и не нужны: дифф раунда —
исключительно `docs/specs/331-*.md` (класс C, стадия `spec`), исполняемого
кода нет ни в этом диффе, ни накопительно с r1 (весь путь #331 пока —
только спецификация).

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

| Находка r2 | Чем закрыта в r3 | Где это видно |
|---|---|---|
| **M-r2-1** — AC6 не различал сторону (`previous`/`candidate`); реализация с перепутанной или отсутствующей асимметрией §2.6 формально проходила байт-в-байт тот же текст, что был до правки §2.6 | AC6 переписан на два явных случая по образцу AC5: (а) TypeError кандидата → честная ошибка WS; (б) TypeError previous → запись проходит фолбэком «нет базы для наследования»; отдельно оговорено, что перепутанные стороны или отсутствие асимметрии красят хотя бы один из двух юнитов | `docs/specs/331-junction-limit-precision.md:144-150`. Текст (а)/(б) сверен слово в слово с нормативным §2.6 (`:100-105`, не тронут этим диффом) — не расходится и не изобретает нового поведения. Критерий теперь однозначно различает две реализации, которые старый AC6 не различал. **Закрыто.** |
| **L2** — §6 «Риски» (2) описывал механизм «максимальная ветвь», которого §2.3 в редакции r2 уже не содержит (там — «сумма компоненты связности») | Формулировка риска (2) заменена на «сумма коллинеарной компоненты» | `:170-171`. Совпадает буквально с текстом §2.3 (`:76-78`). Рассинхрон между разделами устранён. **Закрыто.** |

Обе находки r2 закрыты содержательными правками текста, а не декларацией
в статус-строке (хотя статус-строка тоже обновлена корректно — `:3`
перечисляет обе находки r2 и подтверждается фактическим диффом).

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

Ниже — то, что r2 (`docs/reviews/SPEC-REVIEW-331-r2.md`, материал @
`2d703543`) проверил и признал корректным, и что дельта r2→r3 не
затрагивает (ни один символ в этих разделах не изменился между
`2d703543` и `4423d285`):

- H1 (квантование ключа, формула канонизации) — сверено побайтово с
  `coordinate-canonicalization.ts/.py` в r2; §2.1/AC1 не тронуты этим
  диффом.
- M1 (порог инцидентности 2e-7, арифметика примера) — §2.1/AC1 не тронуты.
- M3 (обход по рёбрам вместо DFS, O(E), развилка и П1) — §2.3/AC3 не
  тронуты; вывод r2, что любая «развилка» и так нарушает П1 по углу
  независимо от версии §2.3, наследуется без повторной проверки кода.
- M4 (USER-GUIDE в Release) — §6/Release не тронут этим диффом (правка
  риска (2) — другая строка того же раздела, не пересекается с абзацем
  Release).
- Нормативный текст §2.6 (сама асимметрия candidate/previous) — введён и
  проверен в r2, этим диффом не тронут; проверялся сейчас только для
  сверки с новым AC6 (см. «Как проверялось», п.4), не как повторный аудит
  §2.6 с нуля.
- Скоуп/не-скоуп, структура «один AC на пункт», i18n, touch, обязательство
  по `docs/specs/329-*.md` — унаследовано ещё из r1 через r2, дельтой r3
  не задето.

## Что проверено и признано корректным (эта ревизия)

- AC6 в новой редакции действительно способен различить две реализации,
  которые старая редакция не различала: пропущена или перепутана
  асимметрия candidate/previous — хотя бы один из двух явно описанных
  юнитов красный.
- Новый текст AC6 не вводит поведения, которого нет в нормативном §2.6 —
  сверено дословно.
- Формулировка риска (2) в §6 синхронизирована с текущим текстом §2.3.
- Полный документ (не только дельта) перечитан на предмет новых
  противоречий — не найдено.

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

- Всё, что унаследовано из r2/r1 (список выше) — не перепроверялось
  повторно.
- Исполняемого кода по-прежнему нет — гейты typecheck/test/build/
  check-docs/инварианты/смоки/golden/backend-pytest/perf не применимы
  к этой стадии (`spec`) и не гонялись.
- Фактическая реализация AC6 — она ещё не написана; проверялась только
  формулировка критерия, а не код, который по нему будет писаться.

## Вердикт

Обе находки r2 (M-r2-1, L2) закрыты содержательными правками, сверенными
построчно с текстом находок и с остальным документом. Новых находок в
дельте r2→r3 нет. High нет, Medium нет.

`Вердикт: зелёный · заход r3 · блокирующих циклов 2/4 · High: 0 · Medium: 0`