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

Обслуживание освобождает runtime-артефакты только тогда, когда ThreadCells может доказать их соответствие условиям очистки. Оно намеренно консервативно: неизвестный, нечитаемый, активный, связанный ссылкой или изменённый ресурс защищается, а не считается безопасным для удаления наугад.

Click to expand

Что можно очистить

В зависимости от возраста и свидетельств владения план может включать:

• истёкшие временные пути с маркерами владения ThreadCells;
• старые вложения терминала, на которые не ссылается активный терминал;
• журналы, пригодные для сжатия или очистки по сроку хранения;
• осиротевшие группы процессов браузера, определённые по точной идентичности процесса;
• ревизии браузера и кэши, на которые не ссылаются активные метаданные;
• контейнеры и тома с меткой ThreadCells, чей владелец завершён и на которые нет ссылок;
• доверенные кэши пакетов с измеримым действием по высвобождению места;
• неактивные кандидаты/релизы, представленные каноническими метаданными staging.
• точные панели runtime закрытых терминалов и дочерние процессы, чей устойчивый терминал уже закрыт и чья идентичность процесса всё ещё совпадает;
• управляемые дочерние worktree, ожидающие очистки, после подтверждения и повторной проверки границы их устойчивого результата/вывода из эксплуатации.
• чистые неактивные связанные worktree, чей HEAD уже содержится в явно настроенной устойчивой Git-ссылке;
• помеченные воспроизводимые кэши/сгенерированные свидетельства, расположенные непосредственно под одобренным корнем кэша, после завершения владельца и истечения срока хранения.

Обслуживание не удаляет вслепую исходные репозитории, активные или неизвестные worktree, работающие терминалы, открытые файлы, текущие релизы/релизы восстановления, подготовленные кандидаты или резервные копии. Связанные worktree выводятся из эксплуатации через git worktree remove и git worktree prune, а не универсальным рекурсивным удалением. Вывод из эксплуатации runtime закрытого терминала не удаляет его устойчивую историю сессии, агента, Inbox, результата или рабочего процесса.

Воспроизводимый каталог должен быть непосредственным дочерним элементом настроенного корня и содержать .threadcells-reproducible.json:

{"schema_version":1,"owner":"threadcells","kind":"cache","created_at":1790000000,"owner_pid":12345}

Поддерживаемые типы: cache, generated, test_evidence и candidate. Отсутствующие или недопустимые маркеры, символьные ссылки, выходы за пределы пути, живые владельцы и пути в пределах срока хранения остаются защищёнными.

Развёртывания также могут называть точные принадлежащие ThreadCells префиксы кэша для обратно совместимых CI-кэшей. Такие записи по-прежнему ограничены непосредственными дочерними элементами одобренного runtime-корня и требуют истечения срока хранения, а также тех же проверок активного процесса и идентичности во время выполнения. Неперечисленные префиксы, включая неоднозначные артефакты кандидата релиза, остаются защищёнными.

Сначала план, затем выполнение

План dry-run доступен только для чтения. Каждый кандидат включает категорию, каноническую идентичность/fingerprint, предлагаемое действие, общий объём байт, оценку высвобождаемого места, когда она известна, причину хранения и причину защиты. В сводках классов отдельно приводятся доступные для действия/высвобождаемые и сохранённые/защищённые объёмы, поэтому большой защищённый класс не скрывается как ноль байт.

Inspect current state
      ↓
Build immutable plan and plan_id
      ↓ operator reviews
Execute exact plan_id
      ↓
Rebuild protected set under lock
      ↓
Revalidate each candidate immediately before action
      ↓
Report reclaimed, skipped, changed, and failed items

Если набор кандидатов изменился между планированием и выполнением, ручное выполнение отклоняет устаревший план, не изменяя ресурсы. Каждый оставшийся кандидат проверяется снова непосредственно перед изменением.

Full Cleanup

Последнее действие в опасной зоне Settings → Обслуживание — Delete all system files — Full Cleanup. Оно использует те же канонический инвентарь, защищённый набор, неизменяемую идентичность плана и проверки идентичности при выполнении, что и обычное обслуживание, но применяет максимальное доказанно безопасное хранение: подходящими могут стать воспроизводимые кэши, старые журналы, артефакты build/candidate/temp, безопасно выводимые из эксплуатации worktree и каждый неактивный локальный релиз. Неизвестное владение или неоднозначные полномочия остаются защищёнными и объясняются в плане и отчёте.

Full Cleanup доступен только тогда, когда долговременное состояние жизненного цикла на backend доказывает, что каждый значимый агент находится в состоянии «Готов», «Завершён» или явно эквивалентном невыполняющемся состоянии. Working, Processing, Starting, поставленное в очередь изменение файловой системы, выполнение провайдера, тяжёлая операция, runtime-операции и неизвестная идентичность жизненного цикла блокируют выполнение. Сервер получает канонические admission fences и повторно проверяет этот idle gate непосредственно перед изменением; если агент становится активным после preview, запуск прерывается без удаления чего-либо.

Предварительный просмотр доступен только для чтения. Для допуска выполнения нужны существующая кратковременная разблокировка оператора и существующее модальное окно подтверждения необратимого действия; отдельного пароля Full Cleanup или секрета в клиентском хранилище нет. При допуске создаётся один непрозрачный ID операции, связанный с точным 64-символьным plan_id; произвольный путь не передаётся. После допуска долговременные прогресс и итоговый отчёт операции сохраняются при отключении браузера, истечении разблокировки и перезапуске control plane. Повторный запрос той же операции наблюдает её состояние, а не запускает второй разрушающий проход; другой план требует новой авторизации.

Каждый кандидат Full Cleanup, заданный путём, обрабатывается узкоспециализированным root helper, активируемым через сокет, после того как он однократно использует серверное полномочие, перестроит точный план, докажет соблюдение idle gate и проверит, что control plane по-прежнему удерживает все admission fences. Необработанные учётные данные оператора никогда не передаются helper. Helper перемещает каждого кандидата в root-exclusive quarantine в той же файловой системе, блокирует захваченное дерево каталогов от изменений со стороны runtime-пользователя, а затем удаляет через дескрипторы каталогов только проверенные идентичности. Ограниченный итоговый отчёт сохраняется до ответа; сверка при перезапуске и опросе сохраняет точного ещё живого helper либо правдиво сообщает о неудачном/неопределённом исходе без повторения разрушающего прохода. Ресурс с изменившейся идентичностью сохраняется и отражается в отчёте, а ресурсы жизненного цикла вне файловой системы продолжают обрабатываться своими каноническими транзакционными исполнителями.

После успешного Full Cleanup остаётся только активный неизменяемый локальный релиз ThreadCells. Все доказанно неактивные релизы отката/восстановления удаляются, метаданные релиза атомарно согласуются, а локальный откат отмечается как недоступный. Активный релиз и активный указатель никогда не могут стать кандидатами. Агенты в состоянии «Готов» остаются пригодными к работе: их worktree, полномочия writer, текущий контекст, текущий вывод и другое состояние продолжения защищаются. История агентов в состоянии «Завершён» может остаться в SQLite после очистки их безопасного файлового вывода; тогда Full Output сообщает, что долговременный вывод недоступен, вместо сбоя или вымышленного текста.

Резервные копии, текущие полномочия над исходниками/инструментами, credentials/state провайдера, база SQLite и любой недоказанный ресурс остаются защищёнными. Второй Full Cleanup безопасно создаёт план с почти нулевым числом доступных действий, кроме недавно ставших подходящими или ранее защищённых элементов.

Безопасный ручной пример

Из установленной среды сначала запросите вывод JSON:

threadcells-housekeeping --dry-run --json

Просмотрите каждого кандидата и скопируйте возвращённый plan_id. Выполняйте только проверенный план:

threadcells-housekeeping --plan-id PLAN_ID_FROM_DRY_RUN

Не автоматизируйте извлечение plan_id и немедленное выполнение, пока не разберётесь в плане. Dry-run никогда не означает разрешение на удаление.

Философия защищённого набора

Защищённый набор объединяет активные терминалы и worktree, владение writer/рабочим процессом, текущую линию исходников/runtime, активные релизы и релизы восстановления, подготовленные кандидаты, упомянутые ревизии браузера, открытые файлы, идентичность запуска живого процесса и идентичность терминала, метаданные ссылок контейнеров, резервные копии и общие блокировки.

Детали важны для реализации, но правило оператора простое: отсутствие свидетельств не является свидетельством, что ресурс завершён. Если защиту невозможно установить точно, Обслуживание пропускает ресурс и сообщает причину.

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

Расписания

Settings → Обслуживание разделяет политику, расписание, планирование, выполнение и отчёты. Поддерживаемые формы расписания включают:

• частый интервал от 15 минут до 365 дней, например 6h;
• еженедельное расписание UTC, например Sun 04:00 UTC;
• очистку при давлении на диск через on_red.

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

Изменения настроек обслуживания и ручное выполнение защищены Авторизацией оператора.

Поведение при давлении на диск

При YELLOW проверьте рост и выполните dry plan. При RED ThreadCells может допустить lease тяжёлой операции для восстановительного запуска обслуживания, хотя обычная тяжёлая работа может быть отклонена. Планы при давлении ставят крупнейшие доказанно безопасные кандидаты первыми и показывают доминирующие защищённые классы, но очистка по-прежнему считается одним тяжёлым выполнением и не обходит защиту кандидатов.

YELLOW — состояние проверки, а не разрешение создавать высвобождаемые байты. Когда все оставшиеся большие классы защищены, добавьте внешнюю ёмкость или задокументируйте защищённый объём вместо ослабления предикатов.

Высвобождение кэша пакетов сообщается как unknown/zero, когда команда не может доказать количество байт; ThreadCells не заявляет предполагаемое восстановление.

Отчёты и частичный сбой

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

После запуска проверьте давление на диск и просмотрите пропущенные/неудачные записи. Перед следующим выполнением создайте новый план; не используйте старый план после изменения состояния.

Резервные копии и релизы

Резервные копии — только инвентарь. Решения о сроке хранения носителей резервных копий относятся к политике резервного копирования оператора, а не к автоматическому обслуживанию.

Очистка релизов и кандидатов использует общую каноническую блокировку staging и требует доверенных метаданных ссылок. Обычное обслуживание защищает активный runtime и runtime отката. Full Cleanup защищает только активный релиз и после явного подтверждения оператора намеренно удаляет каждый доказанно неактивный локальный релиз отката. См. Обновление.

Установленные запланированные службы обслуживания получают узкую группу обслуживания релизов, необходимую для освобождения подходящего неизменяемого релиза. Основной control plane и обычные процессы агентов её не получают. Ручной/API запуск без этого полномочия пропускает удаление релиза с RELEASE_ADMIN_GROUP_REQUIRED, продолжает независимую безопасную очистку и оставляет запланированной службе возможность освободить релиз позже через тот же движок планирования/выполнения.

Защита открытых путей учитывает каждый процесс, принадлежащий настроенной runtime-учётной записи ThreadCells, независимо от того, какая авторизованная учётная запись вызывает ручной план. Другие учётные записи хоста находятся за пределами границы владения одноразовым состоянием ThreadCells; нечитаемые приватные записи /proc из-под этих учётных записей не отключают очистку для всего хоста. Неизвестная runtime-идентичность или любая неопределённость при проверке процесса runtime-учётной записи по-прежнему закрыто отказывает.

Распространённые ошибки

• Удалять каталог worktree напрямую, чтобы освободить место.
• Считать оценку объёма байт гарантированно высвобождаемым местом.
• Выполнять непроверенный план.
• Полагать, что остановленного PID достаточно для доказательства, что группа браузера/процесса — старая.
• Ожидать, что Обслуживание удалит резервные копии.
• Повышать пороги диска вместо устранения устойчивого роста.