docs: input manifest and exact-candidate merge in TESTING.md and PROCESS.md

Issue: #492
User-Visible: no

PROCESS.md

@@ -933,6 +933,28 @@ S7-code-review → код-ревью → слияние в dev → S8-merged л
 ветки и пушем автор мог запушить коммит, и слепой `--force` потерял бы его молча.
 Расхождение lease — падение прогона, а не предупреждение.
 
+**В `dev` уезжает точный кандидат, и только проверенный** (#492,
+`scripts/merge-candidate.mjs`). Ревью длится десятки минут, `dev` за это время
+двигается; ребейз после вердикта даёт дерево, которого никто не видел, — а чистый
+ребейз ничего не доказывает: соседняя правка в `dev` меняет поведение без единого
+конфликта. Шаг слияния поэтому:
+
+- сверяет вершину ветки с материалом ревью (#312) — иначе `S6-in-progress`;
+- если `dev` не двигался — push с `--force-with-lease` на текущую вершину;
+- если двигался — ребейз (конфликт — `S6-in-progress`, как раньше), сравнение
+  patch-id проверенного и получившегося диффа (различие — `S7-code-review`: вердикт
+  к другому диффу не применим, §7.2), публикация кандидата в ветку задачи, ожидание
+  зелёного Validate **на этом SHA** и только затем push в `dev` с lease на ту
+  вершину, поверх которой кандидат собран. Отклонённый lease — `dev` двинулся снова
+  — новая попытка; после третьей — `S6-in-progress` с комментарием;
+- красный Validate на кандидате или прогон, не появившийся за три минуты, —
+  `S6-in-progress` с ссылкой; `S8-merged` ставится только после push.
+
+Проверка кандидата — обычный Validate ветки: лёгкий набор плюс диффозависимые
+гейты. Тяжёлые гейты остаются за кандидатом релиза (#479): слияние не превращает
+каждое движение `dev` в двадцатиминутный прогон, а проверяет ровно то, что
+проверил бы пуш той же дельты.
+
 Поэтому зелёное код-ревью с неудавшимся слиянием ведёт не в `S8-merged`, а в
 `S6-in-progress`: работа действительно вернулась к автору, только осталась не
 правка кода, а ребейз. Вердикт при этом в силе, переделывать нечего. После ребейза