diff --git a/docs/clustering.md b/docs/clustering.md
index 326f005782799fd8865ce8b18d633f3c8cefd585..84e45cca6442628f1a32c7b32d29ef7ac61daab6 100644
--- a/docs/clustering.md
+++ b/docs/clustering.md
@@ -114,14 +114,14 @@ struct Peer {
 - `JoinRequest` отправляет всегда неинициализированный инстанс.
 - В зависимости от того, содержится ли в запросе `instance_id`, проводится анализ его корректности (уникальности).
 - В процессе обработки запроса в Raft-журнал добавляется запись `op::PersistPeer{ peer }`, который помимо всевозможных айдишников содержит поле `health: Loading`, которое играет важную роль в обеспечении надежности кластера. [TODO](## "Сейчас в коде Online вместо Loading, но это надо исправить.")
-- Обработка запроса также включает в себя добавление инстанса в Raft-группу в роли `Learner` (процедура также известная как `raft::ConfChangeV2`). Raft не позволяет изменять топологию, пока предыдущее изменение не было применено. Поэтому в целях оптимизации обработка идет в отдельном потоке (т.н. `conf_change_loop`) и выполняется группами.
+- Обработка запроса также включает в себя добавление инстанса в Raft-группу в роли `Learner` (процедура также известная как `raft::ConfChangeV2`). Raft не позволяет изменять топологию, пока предыдущее изменение не было применено. Поэтому в целях оптимизации обработка идет в отдельном потоке (т.н. `raft_conf_change_loop`) и выполняется группами.
 - Прежде чем отвечать на запрос, инстанс дожидается применения изменений конфигурации. Это произойдет после того как он выйдет из состояния `joint state` ([подробнее](https://web.stanford.edu/~ouster/cgi-bin/papers/OngaroPhD.pdf), §4.3). [TODO](## "этот тезис в коде пока не реализован")
 - В ответ выдаётся всегда новый `raft_id`, никому другому ранее не принадлежавший.
 - Генерировать значение `raft_id` может только лидер Raft-группы. Ожидание `ConfChangeV2` лидерства не требует.
 - Помимо всевозможных идентификаторов, ответ содержит список голосующих членов Raft-группы. Они понадобятся новому инстансу чтобы знать адреса соседей и нормально с ними общаться.
 - Также ответ содержит параметр `box_replication`, который требуется для правильной настройки репликации.
 
-# Логика conf_change_loop
+# Логика raft_conf_change_loop
 
 Все узлы Raft в кластере делятся на два типа: голосующие (`voter`) и неголосующие (`learner`). На каждом инстансе кластера присутствует поток, управляющий конфигурацией Raft-группы (составом `voters` / `learners`). Реальные изменения тем не менее может генерировать только лидер, на остальных инстансах этот поток спит и ничего не делает.
 
@@ -163,4 +163,4 @@ struct Peer {
 - Инстанс не должен оставаться воутером, пока есть другие онлайн кандидаты.
 - Инстанс не должен оставаться лидером.
 
-Чтобы этого добиться, каждый инстанс на `on_shutdown` триггер отправляет лидеру запрос `UpdatePeerRequest{ health: Offline }`. Непосредственно изменением роли `voter` -> `learner` занимается отдеьный поток на лидере (тот самый `conf_change_loop`), инстанс только дожидается его применения.
+Чтобы этого добиться, каждый инстанс на `on_shutdown` триггер отправляет лидеру запрос `UpdatePeerRequest{ health: Offline }`. Непосредственно изменением роли `voter` -> `learner` занимается отдеьный поток на лидере (тот самый `raft_conf_change_loop`), инстанс только дожидается его применения.