Эксплуатация

Повседневная эксплуатация ThreadCells в основном сводится к сохранению четырёх видов достоверности: идентичности запущенной сборки, владения рабочими процессами, доступной ёмкости и восстанавливаемого состояния.

Ежедневные проверки

Используйте Home, Agents, Settings → General и Settings → Обслуживание, чтобы ответить на вопросы:

• Исправен ли сервер и запущена ли ожидаемая сборка?
• Зелёные, жёлтые или красные показатели диска и ёмкости — GREEN, YELLOW или RED?
• Какие supervisor и исполнители действительно активны?
• Есть ли доставленные, но не включённые результаты?
• Ожидает ли какой-либо рабочий процесс решения владельца?
• Если Telegram включён, показывает ли Settings → Telegram ожидаемое безопасное состояние подключения/теста?

Представление ёмкости в командной строке:

threadcells-resource-status

Для мониторинга сервиса используйте локальный endpoint health:

curl -fsS http://127.0.0.1:9889/health

Запуск и остановка

Запустите threadcells-server на loopback или используйте каноническую установленную службу. Отключение браузера не останавливает агентов на основе tmux. Поддерживаемый перезапуск сервера сохраняет легитимно активные runtime терминалов, а затем восстанавливает устойчивое состояние открытых рабочих процессов и доставки Inbox. Закрытые runtime выводятся из эксплуатации по точной идентичности терминала/процесса; исторические записи сессий и результатов не зависят от того, остаётся ли живой панель tmux.

Перед плановым перезапуском:

1. проверьте активную работу провайдера и тяжёлую работу;
2. по возможности не прерывайте изменение;
3. запишите текущие идентичности активной сборки и сборки восстановления;
4. для обновления создайте резервную копию базы данных и проверьте её целостность;
5. перезапустите только необходимые службы ThreadCells;
6. переподключитесь и проверьте рабочие процессы/результаты, прежде чем что-либо повторять.

Используйте Graceful Exit для жизненного цикла провайдера. Принудительное завершение tmux или ручное удаление строк базы данных может рассогласовать состояние терминала и устойчивое состояние рабочего процесса.

Гигиена сессий и рабочих процессов

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

Add Agent действует на стабильный жизненный цикл выбранной сессии. Удаление исторической сессии и удаление завершённого терминала действуют на точные устойчивые идентичности и отклоняются, пока существует активный runtime, открытый рабочий процесс или рабочий процесс восстановления, lease writer, ожидающий результат либо другая реальная зависимость жизненного цикла. Сохранённые журналы, защищённые worktree очистки и post-exit cleanup claims сами по себе не препятствуют логическому удалению: ThreadCells сохраняет полномочия над ресурсом, помечает точную сессию удалённой и делает повторы идемпотентными. При блокировке удаления возвращается конкретный конфликт жизненного цикла, а не общая ошибка отсутствия ресурса/сервера.

В пределах одной сессии Home и Agents сохраняют долговременную последовательность создания агентов в представлениях List и Grid. Статус, провайдер, профиль, активность, polling, reconnect и restart не меняют порядок агентов; новый агент добавляется после предыдущих.

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

Изменения ёмкости

Settings → Orchestration Capacity применяет изменения без перезапуска сервера. Снижение лимита осушает ёмкость; активные сессии не завершаются. Меняйте по одному ограничению за раз и следите, улучшается ли нужная очередь.

Изменения ёмкости требуют разблокированной сессии оператора и аудируются. См. Модель ёмкости и ресурсов.

Журналы и свидетельства

Храните достаточно журналов и истории результатов, чтобы диагностировать неудачный запуск, но не считайте журналы единственной устойчивой истиной. База данных, результат рабочего процесса, commit/diff Git, манифест кандидата и свидетельства тестов отвечают на разные вопросы.

Избегайте записи в журнал prompts или значений, содержащих учётные данные. Публичные/API ошибки ThreadCells должны оставаться безопасными для отображения.

Обслуживание

Обслуживание всегда начинается с плана. Проверьте список кандидатов dry-run и идентичность плана, затем явно выполните именно этот план. Исполнитель заново формирует текущий защищённый набор и повторно проверяет каждого кандидата перед изменением. Он может вывести из эксплуатации доказанно закрытые runtime терминалов и подтверждённые worktree, ожидающие очистки, не стирая устойчивую историю.

Резервные копии — только инвентарь и никогда не удаляются автоматически. Неизвестные или активные ресурсы остаются защищёнными. Full Cleanup — отдельно подтверждаемое действие оператора, которое выполняется только в простое всех агентов, сохраняет полномочия продолжения для агентов в состоянии «Готов» и намеренно удаляет каждый доказанно неактивный локальный релиз, после чего локальный откат становится недоступен. См. Обслуживание.

Дисциплина изменения production

Для обновления:

1. соберите и проверьте неизменяемый кандидат из точного commit;
2. сохраните текущую установку как вариант восстановления;
3. создайте резервную копию базы данных и проверьте её целостность;
4. подготовьте через канонический механизм развёртывания;
5. продвиньте точный подготовленный кандидат;
6. перезапустите только необходимые службы;
7. проведите smoke-тест health, UI, preflight провайдера, авторизации оператора, рабочих процессов, терминалов и настроенных глобальных уведомлений Telegram.

Не публикуйте, не отправляйте изменения в remote, не создавайте тег и не меняйте публичную экспозицию как побочный эффект локального развёртывания. См. Обновление и Развёртывание.

Если что-то выглядит неправильно

Сохраните свидетельства до очистки или повтора. Запишите идентичность сборки, ID сессии, терминала или рабочего процесса, безопасное сообщение об ошибке, относящееся к делу окно журнала, статус Git и текущую ёмкость. Затем используйте руководство Устранение неполадок, организованное по симптомам.