docs(skill): уточнено назначение README coordinator-loop

- Зачем:
  - README должен описывать границы скилла без ложных ожиданий от runtime-поведения.
- Что:
  - уточнена приёмка через агент другой модельной линии, если он доступен.
  - разделены проектная документация и документационные правки внутри issue.
  - проверяемость описана как свойство конечного результата цепочки.
- Проверка:
  - просмотрен staged diff README coordinator-loop.

agents/.agents/skills/coordinator-loop/README.md

@@ -32,8 +32,8 @@ coordinator-loop          каждый issue: worker по /tdd → саморе
   закладывается проверяемость результата (см. «Что получается»).
 - **Скилл — исполнение.** Берёт **готовые** issues по одной и проводит каждую через
   цикл worker → саморевью → классификация → ревью на риске → коммит.
-- **После скилла — приёмка.** Результат уходит на ревью другим агентом (обычно
-  Claude — это и есть взгляд другой родословной) и на ручную проверку.
+- **После скилла — приёмка.** Результат уходит на ревью агентом другой модельной
+  линии, если он доступен, и на ручную проверку.
 
 ## Что делает и чего не делает
 
@@ -42,7 +42,8 @@ coordinator-loop          каждый issue: worker по /tdd → саморе
 
 Не делает:
 
-- не проектирует и не пишет документацию — это upstream;
+- не создаёт проектную документацию и не принимает архитектурные решения — это
+  предыдущий этап;
 - не нарезает issues — это `/to-issues`;
 - не отвечает за проверяемость результата — она закладывается при проектировании;
 - не делает финальную приёмку — это ревью другим агентом плюс человек;
@@ -60,13 +61,13 @@ coordinator-loop          каждый issue: worker по /tdd → саморе
 Один issue = один проверяемый коммит плюс отчёт — так пост-цикловое ревью и ручная
 проверка остаются посильными.
 
-**Про проверяемость.** Прошлый прогон показал: если «готово» у issue — это «прочитай
-diff», проверить всю цепочку руками не выходит. Лекарство — на уровне
-проектирования: формулировать issue так, чтобы «готово» было **наблюдаемым** (запись
-в Kafka-топик, строки в конкретной таблице, панель дашборда, вывод команды). Это
-ответственность `/to-issues` и брейншторма, **не** этого скилла. Если issue пришла
-без наблюдаемого критерия, координатор отметит это как **риск** («проверять придётся
-чтением кода») и вернёт сигнал на уровень выше, но сам проверку не выдумывает.
+**Про проверяемость.** Прошлый прогон показал: если итог цепочки можно принять
+только чтением diff, ручная проверка становится слишком дорогой. Лекарство — на
+уровне проектирования: у всего набора issues должен быть **наблюдаемый конечный
+результат** для приёмки (запись в Kafka-топик, строки в конкретной таблице, панель
+дашборда, вывод команды). Это ответственность `/to-issues` и брейншторма, **не**
+этого скилла. Координатор может отметить слабую проверяемость как **риск** и вернуть
+сигнал на уровень выше, но сам критерий приёмки не выдумывает.
 
 ## Как вызвать