docs(spec): мониторинг перенесён из хвоста в параллельный трек

- Зачем:
  - дашборды нужны точками наблюдения на приёмке этапов 4-8, а зависимость
    у них формально только от этапа 1: «в хвосте» было выбором, не
    необходимостью.
- Что:
  - раздел 9: дашборды строятся параллельно этапам 4-8, состав не меняется.
  - назван хвост этапа: runbook keeper/DDL, system.text_log, правила
    оповещения, урок «посмотрели - сломали - вернули».
  - записано правило: панели порогов и цветовых вердиктов не несут, красное
    и зелёное живёт в проверках.
- Проверка:
  - тикеты этапа нарезаны по этому раскрою: #114-#117 под #11.

docs/specs/2026-07-30-stand-v2-realism.md

@@ -587,7 +587,23 @@ v2 стартует пустым, поэтому объём ниже — это
    на amd64 и arm64.
 8. Superset-дашборд v2.
 9. Мониторинг и runbook «keeper упал / DDL повис в очереди». Состав дашбордов
-   и границы — ADR 0002.
+   и границы — ADR 0002. Этап идёт не подряд, см. ниже.
+
+**Мониторинг не ждёт своего номера.** Зависимость у дашбордов формально только
+от этапа 1, а «в хвосте» было выбором, не необходимостью. Довод за переезд
+пришёл со второй стороны: дашборд — точка наблюдения не только для менти, но и
+для владельца на приёмке этапов 4–8, а шесть вопросов дашборда «Данные» из
+ADR 0002 с приёмочными совпадают почти целиком. Поэтому дашборды строятся
+параллельно этапам 4–8. Состав от переезда не меняется, меняется срок.
+
+В хвосте остаётся то, чему нужен прожитый опыт или дозревший мир: runbook
+«keeper упал / DDL повис в очереди», `system.text_log` (ADR 0002 привязал его
+к runbook), правила оповещения и урок «посмотрели → сломали → увидели →
+вернули» (раздел 10).
+
+Порогов панели не несут вовсе, и это правило, а не срок: на дашборд смотрят
+глазами; красное и зелёное живёт в проверках — у целей `make` про стенд и у
+дагов качества данных про данные.
 
 Что гонять на приёмке этапа — строка в [карте
 проверок](../architecture/testing.md), раздел «Какую проверку когда