Локальное развёртывание

Развёртывание ThreadCells продвигает проверенный неизменяемый кандидат в локальный runtime. Оно не подразумевает публикацию, Git push/tag, выпуск пакета или открытие доступа к публичной сети.

Дисциплина кандидатов

Соберите из одного точного чистого commit исходного кода, затем проверьте кандидат до staging:

python3 scripts/build_local_candidate.py --output "$PWD/threadcells-candidate"
python3 scripts/verify_local_candidate.py \
  --candidate "$PWD/threadcells-candidate/threadcells-0.3.4a0-local"

Кандидат должен содержать Python-код, упакованные Web-ресурсы, Docs bundle из allowlist, идентичность сборки, контрольные суммы и метаданные релиза из одной ревизии.

Staging на хосте использует отдельную группу обслуживания релизов, поэтому работающий control plane может читать, но не заменять неизменяемый кандидат, а службы обслуживания могут удалить явно незащищённый релиз. Создайте эту системную группу один раз до первого staging на хосте:

sudo groupadd --system threadcells-release-admin

Установленные units control plane и обслуживания отключают запись Python bytecode. Благодаря этому обычные импорты не меняют владельца или содержимое внутри неизменяемого релиза, в том числе когда активна узко ограниченная группа обслуживания релизов.

Команда staging закрыто отказывает, если эта группа недоступна. Она хранит кандидаты релизов, атомарный активный указатель, блокировку staging и метаданные защиты релизов под корневой точкой /var/lib/threadcells, принадлежащей root и находящейся вне состояния, принадлежащего runtime. Production-службы выполняются через /var/lib/threadcells/active, а не через доступную на запись runtime ссылку на команду. Пути кандидатов должны быть непосредственными дочерними элементами /var/lib/threadcells/releases; символьные ссылки и альтернативные цели блокировки/метаданных отклоняются.

Последовательность безопасного продвижения

1. Запишите текущий активный runtime и его состояние health.
2. Сохраните его как проверенную цель восстановления.
3. Создайте резервную копию базы данных и проверьте её целостность.
4. Подготовьте точный проверенный кандидат с помощью канонического механизма развёртывания репозитория.
5. Проверьте подготовленный кандидат снова.
6. Атомарно продвиньте подготовленную идентичность.
7. Перезапустите только необходимые службы ThreadCells.
8. Выполните production-приёмку на loopback или через существующий защищённый путь доступа.

Не перезаписывайте активный каталог на месте. Указатель/символьная ссылка релиза или эквивалентный канонический механизм должен однозначно обозначать активный кандидат, кандидат восстановления и подготовленный кандидат.

После того как staging записал точный кандидат, продвиньте его через каноническую операцию под блокировкой:

sudo python3 deployment/promote-ops-p1.py \
  --system-root / \
  --candidate-root /var/lib/threadcells/releases/RELEASE_ID \
  --expected-commit EXACT_PUBLIC_SHA

Используйте --rollback-root, когда уже есть проверенный канонический релиз восстановления. Операция идемпотентна: повтор завершает прерванный переход указателя/метаданных, не создавая новую идентичность релиза.

Приёмка

Проверьте как минимум:

• health и идентичность сборки в Settings → About;
• Home, Agents, Flows, Statistics, Settings, Docs и Spawn Agent;
• инвентарь провайдеров и один безопасный preflight;
• состояние оператора configured/locked/unlock/защищённое изменение;
• безопасное состояние конфигурации глобального Telegram и, только когда нативные учётные данные уже настроены, явное поведение подключения/теста;
• подключение терминала и переподключение;
• продолжение рабочего процесса/результата;
• целостность базы данных и отсутствие дублирования воспроизведения использования;
• регистрацию манифеста/иконок/service worker PWA без динамического кэширования.

Восстановление

Восстановление переключает на сохранённый предыдущий кандидат и перезапускает только необходимые службы. Восстанавливайте базу данных только если новая версия выполнила несовместимую или повредившую данные миграцию; ненужное восстановление базы данных может отбросить действительную работу, завершённую после продвижения.

После восстановления проверьте идентичность сборки, health, совместимость schema, активные рабочие процессы и терминалы. Сохраняйте неудачный кандидат и журналы, пока не будет понятна первопричина.

Границы

Полномочия локального развёртывания не дают разрешения публиковать пакеты, отправлять изменения в remote, создавать тег/релиз или открывать доступ к необработанному порту службы. Это по-прежнему отдельные решения владельца.