diff --git a/docs/reviews/SPEC-REVIEW-331-r3.md b/docs/reviews/SPEC-REVIEW-331-r3.md
new file mode 100644
index 00000000..b9f48d8a
--- /dev/null
+++ b/docs/reviews/SPEC-REVIEW-331-r3.md
@@ -0,0 +1,127 @@
+# 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`