diff --git a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/02.md b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/02.md
index 488aaaa..5e29f05 100644
--- a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/02.md	
+++ b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/02.md	
@@ -14,9 +14,9 @@
 
   1. Необходимо организовать какой-то процесс безопасного получения токенов авторизации для пользователя-робота (например, через получение для него токенов реальным пользователем из веб-интерфейса), поскольку стандартная логин-парольная схема логина (тем более двухфакторная) слаба применима к клиенту API.
   2. Необходимо сделать для пользователей-роботов исключения из почти всех систем безопасности:
-    * роботы выполняют намного больше запросов, чем обычные люди, и могут делать это в параллель (в том числе с разных IP-адресов, расположенных в разных дата-центрах);
-    * роботы не принимают куки и не могут решить капчу;
-    * робота нельзя профилактически разлогинить и/или инвалидировать его токен (это чревато простоем бизнеса партнёра), поэтому для роботов часто приходится изобретать токены с большим временем жизни и/или процедуру «подновления» токена.
+      * роботы выполняют намного больше запросов, чем обычные люди, и могут делать это в параллель (в том числе с разных IP-адресов, расположенных в разных дата-центрах);
+      * роботы не принимают куки и не могут решить капчу;
+      * робота нельзя профилактически разлогинить и/или инвалидировать его токен (это чревато простоем бизнеса партнёра), поэтому для роботов часто приходится изобретать токены с большим временем жизни и/или процедуру «подновления» токена.
   3. Наконец, вы столкнётесь с очень большими проблемами, если вам всё-таки понадобится дать роботу возможность выполнять операцию от имени другого пользователя (поскольку такую возможность придётся тогда либо выдать и обычным пользователям, либо каким-то образом скрыть её и разрешить только роботам).
 
 Если же API не предоставляется как сервис для конечных пользователей, второй подход с авторизацией клиентов через API-ключи более прост в имплементации. Здесь можно добиться гранулярности уровня эндпойнта (т.е. партнёр может выставить для ключа набор эндпойнтов, которые можно с ним вызывать), но более гранулярные системы (когда ключу выставляются ещё и ограничения на уровне бизнес-сущностей) уже намного сложнее в разработке и применяются редко.
diff --git a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/03.md b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/03.md
index 5b59f7e..e0f021b 100644
--- a/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/03.md	
+++ b/src/ru/clean-copy/03-[В разработке] Раздел II. Паттерны дизайна API/03.md	
@@ -4,7 +4,7 @@
 
   1. Клиент отправляет запрос на создание нового заказа.
   2. Из-за сетевых проблем запрос идёт до сервера очень долго, а клиент получает таймаут:
-    * клиент, таким образом, не знает, был ли выполнен запрос или нет.
+      * клиент, таким образом, не знает, был ли выполнен запрос или нет.
   3. Клиент запрашивает текущее состояние системы и получает пустой ответ, поскольку таймаут случился раньше, чем запрос на создание заказа дошёл до сервера:
       ```
       const pendingOrders = await