Коротко
- Native activation — это дизайн без разрешения на деплой: слайс 1 в OpenClaw 2026.10.1 записывает adoption и готовит поколения, а слайс 2 добавляет саму native activation и recovery, которые включаются только явным
--enable-activation. - Адаптер установки фиксирует поколения и пакует stable launcher. Оркестрация обновления, recovery и миграции Doctor остаются у их владельцев.
- Перед сменой поколения нужен bridge-релиз Gateway с поддержкой committed suspension handoff, иначе старый Gateway не передаст управление.
- Проверяют через
openclaw update --dry-run,openclaw update status --jsonиopenclaw update recover --root <installation-root>— последний сверяет генерацию без её перезапуска.
Сверено с документацией OpenClaw 2026.10.1, 11 октября 2026.
В OpenClaw 2026.10.1 появилась страница Team immutable update design. Это implementation design без разрешения на деплой. Слайсы 1–2 покрывают подготовку и явно включаемую native activation. Обычные npm- и git-установки это не затрагивает: адаптер работает только после явного adoption. Дальше — что уходит в immutable-адаптер установки, что остаётся у текущих владельцев, и какие команды запускать, прежде чем решиться на --enable-activation.
Что выносится в immutable-адаптер установки
Сейчас развёртывание команды Team собирает закреплённую ревизию main в стороне, публикует запечатанный релиз, дренирует Gateway, переключает симлинк current и перезапускает systemd-сервис. Свой приватный контроллер оркестрирует ещё и Doctor, бэкапы, проверку, восстановление и хранение. Дизайн добавляет immutable installation adapter к openclaw update. Обязанности оркестрации, восстановления при активации, миграций Doctor и жизненного цикла сервиса остаются существующим владельцам.
В адаптер уезжают: durable-дескриптор поколения, хранение текущего, предыдущего и поколений по ссылке из журнала, packaged stable launcher, показ immutable-установок через статус и dry run. Команды adoption под openclaw update фиксируют и подготавливают поколения.
Сам адаптер не публикует current, не меняет определение сервиса, не рестартует Gateway, не мигрирует живой state, не собирает поколения, не импортирует историю приватного контроллера и не выводит его из эксплуатации. Это явно сказано в дизайне за слайс 1.
Слайсы 1–2: подготовка и явно включаемая native activation
Slice 1, ревью #163799, делает две вещи: распознаёт immutable-установку и принимает её, а ещё готовит всё возможное, пока прежний Gateway ещё обслуживает запросы. Он записывает adoption и подготовленные поколения, пакует стабильный лаунчер и начинает показывать immutable-установки через статус и dry run.
Slice 2 добавляет версионируемую, явно включаемую запись adoption и владельца native activation и recovery. Он переиспользует владельцев suspension drain, native systemd lifecycle, restart health и config audit. Активация журналирует намерение до публикации, проверяет выбранное физическое поколение и стабильное определение сервиса, принимает только аддитивные правки конфига от кандидата с совпадающими аудит-доказательствами и неизменной политикой. Успешная проверка выводит запись, безопасный откат её сохраняет. Команда openclaw update recover --root <installation-root> сверяет эффекты и проверяет уже здорового кандидата или предшественника без его перезапуска.
Что остаётся у текущих владельцев
Дизайн прямо оставляет обновление и activation/recovery существующим владельцам: оркестрацию обновления, восстановление при активации, миграции Doctor и жизненный цикл сервиса. Приватный контроллер развёртывания в ядро (core) не портируется.
Bridge-релиз должен сначала включить committed suspension handoff на существующем Gateway. Дизайн прямо говорит: CLI на стороне кандидата не в состоянии дооснастить ею уже работающий старый Gateway. После того как bridge-релиз здоров, включают adoption и проверяют native cutover на другое проверенное поколение, прежде чем старый контроллер уйдёт на покой.
Сбор поколений, доказательство развёртывания, импорт истории приватного контроллера и вывод его из эксплуатации остаются отдельной работой. В этом дизайне они не закрыты.
Команды для проверки
Adoption выполняет openclaw update adopt-immutable --root <installation-root>: сначала без активации, потом повторно с --enable-activation. После сомнительных эффектов recover сверяет генерацию без перезапуска. Проверки состояния запускаются отдельно.
openclaw update --dry-run
openclaw update status --json
openclaw update cleanup --dry-run
openclaw update recover --root <installation-root>
openclaw health
openclaw gateway status --deep --json
openclaw doctor --lint --jsonDry run и команды, отклонённые внешним супервизором, проверкой владения хранилища состояния, идентичности handoff или immutable-config, не собирают диагностику и не запускают агента. Это описано в разделе про repair and recovery.
Как это собрать на OpenClaw
Включается в два захода. Сначала зафиксируйте, что immutable-установка распознаётся. В дизайне перечислены текущие значения update-install-kind.ts: git, package, unknown, host. Там же сказано, что каталог releases/<sha> сам по себе не равен владению. Проведите adoption в режиме slice 1 и проверьте через update status --json и --dry-run, что подготовка поколений и упаковка stable launcher отображаются.
Затем поднимите bridge-релиз Gateway с поддержкой committed suspension handoff. После этого повторите adoption с --enable-activation. Флаг --drain-timeout отделён от --timeout: drain задаётся явно, например 30 секунд, и не используется при здоровом восстановлении. Условие: cgroup v2 и совпадающие schema-contracts, иначе включение откажется до drain.
Когда это не подойдёт
Без bridge-релиза Gateway с поддержкой committed suspension handoff дизайн прямо запрещает ретрофит через candidate-side CLI. Для неподдерживаемых install-surface документация по openclaw update описывает собственное поведение: запись skipped, следующее действие для пользователя и выход без ошибки.