Ультра-ревью: сходятся ли план, код и реальность

Контрольная точка · 13.07.2026, 10:30 Бангкок · независимый прогон: 6 ревьюеров по осям, адверсарная перепроверка каждой серьёзной находки, 31 агент, всё - только чтением

Вопрос ревью: «В плане написано, что сделано X. Сделано ли X на самом деле, и работает ли оно?» Проверялись все заявления фаз 1-4 по коду (репозитории ely-os и ely-core), по живому серверу и по опубликованным страницам. Ничего не чинилось - только факты.

Вердикт одной строкой

Есть критические проблемы - но это мины на будущее, а не пожар. Система жива, агенты работают, цифры готовности честные.

Боевые агенты отвечают, данные клиентов не текут, деньги не текут, проценты в плане совпали с пересчётом. Но найдены три вещи, каждая из которых в плохой день превращается в аварию: откат Элли по написанной инструкции приведёт к драке двух ботов, восстановление из бэкапа не проверяется с 8 июля, и часть машинных контролёров подтверждает прошлое, а не настоящее. Ехать по плану дальше можно - после починки пунктов 1-4 из списка в конце.

1Критическое: три мины

Мина 1 · откат боевой Элли

Если Элли на новом моторе сломается, откат по написанной инструкции устроит драку двух ботов - как в ночь переезда

Старого движка (OpenClaw) караулят недобитые «няньки»: сторож archivist прямо сейчас, каждую минуту, пытается его поднять - его останавливает только блок-файл. Инструкция отката велит первым шагом снять этот блок-файл. В ту же минуту нянька поднимет старый движок, а новый мотор ещё работает - два бота на одном телефоне, сообщения теряются. Плюс у портального сервиса есть два места в коде, которые сами умеют перезапускать старый движок, и остался старый крон синхронизации. В плане написано «обе няньки обезврежены» - это не так: обезврежена одна, вторая жива и долбится в дверь.

Техническое

journalctl 13.07 05:58: [ARCH] Service openclaw is inactive, restarting... -> Operation refused (RefuseManualStart). 30 попыток за 30 минут. Блок: /etc/systemd/system/openclaw.service.d/cutover-block.conf (RefuseManualStart=yes + ConditionPathExists=/opt/ely-os/.allow-openclaw). CUTOVER_ROLLBACK.txt: «убрать этот файл, daemon-reload, start openclaw (и stop hermes-gateway)» - порядок опасен: снятие блока до остановки hermes-gateway = гонка getUpdates. Плюс /opt/brain-api/openclaw_client.py: safe_restart_openclaw(), вызывается из brain_api.py:2598, 2629. Плюс cron: sync_openclaw.py каждые N минут. Починка: остановить archivist (или научить его читать реестр), выпилить safe_restart_openclaw, переписать порядок отката (стоп gateway -> стоп нянек -> снять блок -> старт openclaw), отрепетировать на копии.

Мина 2 · восстановление памяти

Проверка восстановления из бэкапа сделана один раз 8 июля - и с тех пор не запускалась, хотя заявлена ежедневной

Бэкапы делаются честно каждый день и улетают в облако. Но проверка «а восстановится ли из этого бэкапа память» прогонялась один раз, вручную, пять дней назад. Расписания нет ни в кроне, ни в таймерах. Контролёр фазы 1 при этом каждый раз рапортует «восстановление проверено» - он смотрит только на слово PASS в старом файле и не смотрит на дату. Если завтра бэкапы начнут писаться битыми, узнаем об этом в день катастрофы.

Техническое

drill-result.txt: Modify 2026-07-08 19:21. crontab и systemd timers: drill.sh отсутствует (есть ely-backup.timer 20:30 ежедневно - работает, лог подтверждён 09-12.07). verify-1a.sh:15: grep -q PASS /opt/ely-os/health/drill-result.txt - без проверки возраста. Внутри файла ещё и старые цифры (prod=1460717 - до чистки памяти). Починка: ely-drill.timer после бэкапа + проверка свежести маркера <26h в verify-1a.sh.

Мина 3 · слепые контролёры

Контролёр фазы 3 подтверждает историю от 12 июля, а не сегодняшнее состояние: его «PASS 17/0» нельзя перегнать и получить правду

Три проверки внутри пришиты к конкретным прогонам от 12.07: даже если сегодняшние тесты упадут, контролёр продолжит печатать PASS, потому что смотрит на старые номера прогонов. Ещё одна проверка (про тень) устроена так, что оба исхода - «тень работает» и «тень остановлена» - засчитываются как PASS: она физически не может дать FAIL. Контролёр фазы 2 при этом написан правильно (всегда берёт последний прогон) - то есть команда умеет делать честно, просто в фазе 3 срезала угол. Доверять цифре «17/0» как текущему состоянию нельзя - это снимок дня переезда.

Техническое

verify-phase3.sh:12 run_id='20260712-145756', :23 run_id='20260712-153718'; verify-motor.sh:16 тот же hardcoded id. Тень: crontab | grep shadow_feed && ok ... || ok «остановлена после cutover» - обе ветки ok. Эталон правильного паттерна: verify-phase2.sh:14-17 (ORDER BY max(created_at) DESC LIMIT 1). Проверено сегодня: последний полный прогон Ады 20260713-053118 = 14/14 (контролёр фазы 2 это видит), последний полный прогон Элли 20260712-220354 = 13/14 - контролёр фазы 3 этого не видит.

2Что проверили и что оказалось честным

Ревью искало обман - поэтому важно сказать, где обмана нет. Это проверено по коду и по живому серверу, не со слов плана:

Подтверждено фактами

Бэкапы идут каждый день, шифруются, улетают в Dropbox - логи за 4 дня подряд. Секреты закрыты правами 600, в юнитах открытых токенов нет. Память вычищена честно: 1.46 миллиона строк мусора превратились в 99 тысяч живых. Здоровье снимается каждые 15 минут (таймер жив, свод свежий). Утренний светофор сегодня пришёл. Боевые агенты (Элли, Ада, Марк) работают без единого рестарта за сутки. Тесты агентов настоящие: 14 кейсов у каждого, включая деньги, инъекцию в сообщении, изоляцию клиентов и отправку без подтверждения; судья строгий и его нельзя пройти красивым отказом. Роутер моделей написан правильно: переключение на запасную модель реально срабатывало, учёт платных вызовов атомарный. Тень физически не может отправить сообщение наружу - у её мозга нет инструментов. Аудит записи задач в доску работает (таблица и триггер живы, записи пишутся). Портальный API только читает. Десктопное приложение в форке мотора действительно существует (Electron, профили, модели по ролям). Пирамида доверия и стандарт восстановления реально вшиты в карточки Ады и Элли.

Отдельно: паника отменяется

Ревьюеры-агенты сначала решили, что боевая Элли «мертва 26 часов» - драка двух ботов в ночь переезда выглядела в логах страшно. Перепроверка руками показала: конфликт шёл 9 минут (23:07-23:16 по Бангкоку) во время переезда, погас, как только добили старый движок, и с тех пор не возвращался. Последнее сообщение Элли обработала в 23:58 в ночь переезда, сегодня ей просто никто не писал. Это отражено честно: бот жив, но именно эта драка вернётся при откате по нынешней инструкции (мина 1).

3Расхождения: план говорит одно, система - другое

План заявляет	На самом деле	Насколько важно
«Проверка восстановления - ежедневная»	Один ручной прогон 08.07, расписания нет	важно
«Обе няньки OpenClaw обезврежены»	Обезврежена одна; archivist жив и каждую минуту пытается поднять старый движок	важно
«Тень копит отчёт ~неделю»	Тень остановлена в ночь переезда (11 пар в журнале, последняя 12.07 23:58 Бангкок). Решение «стоп после переезда» логично - боевая теперь на том же моторе - но план и витрина продолжают говорить «копится»	средне
«Роутер с лестницами - мозги агентов»	Роутер написан и работает, но боевая Элли ходит к модели напрямую, мимо лестницы. Роутером пользуются пилот, сторож и тесты. Упадёт основная модель - боевая Элли сама на запасную не переедет	важно
«Golden Set Элли 14/14»	Это снимок 12.07. Ночной прогон упал на техническом баге песочницы (max-turns), баг починили утром 13.07, Аду перегнали целиком (14/14), а полный перегон Элли не сделали - последняя полная картина у Элли 13/14	средне
«Фаза 4 частично работает» (автопрогоны, светофор, журнал сбоев)	Работает, подтверждено. Но контролёра фазы 4 нет вообще - закрыть её официально нечем; SOURCE_MAP и «повторный сбой становится тестом» не начаты (план это признаёт)	средне
Реестр REGISTRY.md - «нет записи = нет сервиса»	Реестр не обновлён после переезда: статусы юнитов и роль OpenClaw устарели. Лина при этом работает на старом юните lina.service (это в реестре признано), lina-hermes выключена сознательно	мелко

4Имитации: где «работает» - это витрина

Прямого обмана в коде не нашлось - тесты настоящие, судья настоящий, проверки в основном честные. Но три вещи создают ложное чувство контроля:

Контролёр фазы 3 - см. мину 3: цифра «17/0» воспроизводится всегда, независимо от сегодняшнего состояния системы.
Маркер восстановления - см. мину 2: «восстановление проверено» рапортуется по файлу пятидневной давности.
Вкладка «Доказательства» на этой же странице - написана руками и уже разошлась с реальностью: там «тень на конвейере» (остановлена), «Элли 14/14» (последний полный - 13/14 из-за бага песочницы), «17/0» без даты снимка. Чертёж требует: витрина генерится из фактов и несёт штамп свежести - как страница /os/, которая пересобирается каждые 15 минут. Эта вкладка - нет.

Отдельно про песочницу - это признанная граница, не обман: тесты проверяют, что агент говорит и решает, но инструменты в песочнице не исполняются. Агент теоретически может сказать «записала» и пройти кейс. Это ограничение написано прямо в коде раннера, закрывается тенью и mock-инструментами фазы 4 - но пока кейса «сказала, но не сделала» нет ни в одном наборе.

5Потери из чертежа, которые план не признаёт

План честно признаёт пять потерь (цех, блок «Истина», матрица скиллов, единая доска, карта источников). Сверка с чертежом нашла ещё три, которые нигде не записаны:

Конвейер актуальности для витрин стройки

Правило чертежа «каждая витрина - со штампом свежести, пересобирается из фактов» выполнено для /os/ и светофора, но не для главной страницы проекта: вкладка «Доказательства» - ручная статика без даты. Именно поэтому она уже врёт (см. выше).

Зомби-сторожа старой эры как класс риска

Стратегия «чистой ячейки» учла старые сервисы, но не учла их сторожей: archivist, старый крон синхронизации OpenClaw, программные рестарты в портальном сервисе. Они не в реестре, не в плане сноса, и один из них - причина мины 1. Нужен пункт реестра: «кто имеет право поднимать/ронять юниты».

Контролёр как живой инструмент, а не акт приёмки

По чертежу контролёр фазы - многоразовая машинная проверка состояния. По факту контролёры фаз 3 и 4 выродились: у фазы 3 - снимок истории, у фазы 4 контролёра нет. Если это не вернуть, вся конструкция «фаза закрыта = PASS контролёра» перестаёт что-либо гарантировать.

6Ошибки в коде

Тяжесть	Где	Что сломается	Как чинить
P1	bin/verify-phase3.sh, verify-motor.sh	Контролёры не видят сегодняшние прогоны (пришиты к номерам от 12.07); проверка тени не может дать FAIL	Взять паттерн из verify-phase2.sh: всегда последний полный прогон; тень - одна честная ветка
P1	brain-api + archivist + крон	Три независимых механизма умеют поднять OpenClaw; при откате - гонка двух ботов	Выпилить safe_restart_openclaw, остановить archivist или научить его реестру, убрать крон синхронизации
P2	sandbox/*/runner.py, функция judge	Вызов судьи не обёрнут в try/except: если судья-модель недоступна, падает весь прогон на середине, в журнале остаётся огрызок	Обернуть вызов; недоступный судья = FAIL кейса с пометкой, прогон продолжается
P2	песочница, была: max-turns=1	Ночной прогон 12.07 из-за этого дал ложные FAIL (13/14 у обоих агентов)	Уже починено утром 13.07 (max-turns=3). Ада перегнана - 14/14. Осталось перегнать Элли целиком
P2	archivist	Долбится в заблокированный юнит раз в минуту, засоряет журнал (30 попыток за 30 минут) - на этом фоне легко проглядеть настоящую ошибку	Часть починки мины 1
P3	router.py, драйвер Gemini	Ключ передаётся в адресе запроса - может осесть в логах прокси	Перенести в заголовок x-goog-api-key
P3	shadow: проверка «наружу не пишет»	Контролёр ищет слово sendMessage в выводе тени - слабый признак. Сама изоляция при этом настоящая (у мозга тени нет инструментов)	Проверять конструкцию (пустой allowlist), не текст

7Честность цифр: пересчёт

Цифры в плане честные. Пересчёт по формуле плана (10 гнёзд на агента, доказательство на каждое гнездо) сошёлся с заявленным почти точно:

Что	План заявляет	Пересчёт ревью	Вердикт
Элли	8/10 (80%)	8/10 - подтверждено погнездно	честно
Ада	7/10 (70%)	7/10 - мотор старый и мозг мимо роутера, как план и признаёт	честно
Лина	2/10 (20%)	2/10 - канал и скиллы; карточки, тестов, стоп-правил нет	честно
Флоу	1/10 (10%)	1/10 - как агент ОС не существует	честно
Платформа (8 блоков)	62%	~69% - по факту чуть лучше заявленного (в плане себя недооценили)	честно
Вся ОС	45%	46-47%	честно

Единственная поправка к самооценке: гнездо «мозги» у Элли считается закрытым с оговоркой - модель работает через официальный мозг, но без лестницы запасных в бою (см. расхождение про роутер). Если считать строго, у Элли 7.5/10 - на общую картину не влияет.

8Что исправить перед фазой 5A

Обезвредить нянек и переписать откат. Остановить archivist (или научить реестру), выпилить программные рестарты OpenClaw из портального сервиса, убрать старый крон. Новый порядок отката: остановить новый мотор - остановить нянек - снять блок - поднять старый движок. Отрепетировать на копии, записать результат репетиции.
Вернуть ежедневную проверку восстановления. Таймер для drill.sh после ночного бэкапа + контролёр проверяет свежесть результата, а не слово в старом файле.
Вылечить контролёр фазы 3 и завести контролёр фазы 4. Все проверки - по последнему полному прогону; убрать ветку, которая не может дать FAIL. Фаза 4 без контролёра не закрывается.
Перегнать полный Golden Set Элли после утренней починки песочницы - чтобы «14/14» снова было фактом, а не воспоминанием.
Подключить боевую Элли к лестнице моделей (или честно записать в план: «лестница в бою - фаза N»). Сейчас алерт «еду на запасном» боевого агента не касается.
Вкладку «Доказательства» перевести на факты. Генерить из журнала прогонов и контролёров со штампом даты - как страница /os/. Ручные цифры оттуда убрать.
Закрыть судьбу тени. Либо конвейер возобновляется с новой целью, либо этап официально закрыт - и из плана уходит «копится неделя».
Обновить REGISTRY.md после переезда и добавить раздел «кто имеет право поднимать/ронять юниты».
Отдельное ревью Марка. Это деньги, и в этом ревью он проверен только поверхностно (жив, не рестартился). Глубокая проверка - его тесты, его стоп-правила, его изоляция - не делалась ни разу.
Кейс «сказала, но не сделала» в Golden Set обоих агентов - с mock-инструментом, как и задумано фазой 4.

9Итог: можно ли ехать дальше

Можно - после пунктов 1-4. Они закрывают обе мины и возвращают доверие контролёрам; это дни, не недели. Фаза 5A (портал) реалистична, её главные известные препятствия план уже назвал сам: нет реестра агентов (agent_id - подтверждено: в коде ноль упоминаний), нет read-only пользователя базы для копии портала (проверено - не создан), нет baseline-скриншотов. Это всё - первые задачи самой фазы 5A, а не сюрпризы.

Общая оценка честности проекта: план не врёт в цифрах и признаёт большинство своих долгов сам - это редкость. Врут детали витрины: «проверено», «копится», «14/14» - там, где надо писать «проверялось 8 июля», «остановлена», «13/14, чиним». Если починить сам механизм самопроверки (мина 3), эта разница исчезнет системно.

Как делалось: 6 независимых ревьюеров по осям (контролёры, тесты, мотор-роутер-тень, живой сервер, цифры, чертёж) + адверсарный проверяющий на каждую серьёзную находку + критик полноты; 31 агент, ~2.7 млн токенов, сервер - только чтением. Три находки ревьюеров опровергнуты перепроверкой и в отчёт не вошли как проблемы: «Элли мертва 26 часов» (конфликт шёл 9 минут при переезде), «аудит доски не работает» (таблица и триггер живы в базе sell - ревьюер искал не в той базе), «старый контейнер дерётся за токен Элли» (дрался старый движок, добит 12.07; контейнер - чужой бот). Не покрыто этим ревью: глубокая проверка Марка (SIP, деньги), реальная репетиция восстановления из бэкапа, нагрузочное поведение. Исходные материалы: план-ревизия 2 от 13.07, пакет Ely_OS_сборка, репозитории ely-os / ely-core, живой сервер.