Scheduled task повторяет prompt по расписанию или по automation-триггеру, и это уже не разовый запуск, а production-workflow со своими требованиями. Три из них ключевые: задача должна быть идемпотентной, ограниченной по правам и оставлять evidence, понятное после вашего отсутствия. Идемпотентность - чтобы повторный прогон не ломал то, что уже сделано; узкие права - чтобы автоматическое действие не выходило за рамки; понятное evidence - чтобы вы разобрались в результате, не наблюдая прогон вживую.

Требование evidence отличает запланированную задачу от интерактивной сильнее всего. В интерактиве вы видите ход работы и можете вмешаться; запланированная задача отрабатывает без свидетелей. Поэтому она должна оставлять после себя понятный след - отчёт, лог, артефакт, - по которому вы восстановите, что произошло и всё ли в порядке. Задача, которая "что-то сделала" и не оставила понятного evidence, в production бесполезна: вы не сможете ни довериться ей, ни разобрать её сбой.

Частые запланированные задачи создают операционную нагрузку, о которой легко забыть. Они могут порождать много worktrees, и без уборки это накапливается. Поэтому завершённые прогоны архивируют, а закрепляют только те, что действительно должны сохранять рабочее состояние. Это та же дисциплина, что и с сессиями: не растить бесконечно, а осознанно решать, что сохранить, а что убрать. Автоматизация без уборки за собой превращается в свалку worktrees, в которой потом трудно разобраться.

Recurring mutation - самый рискованный класс запланированных задач, и к нему подходят поэтапно. Задача, которая каждую ночь "сама чинит код", требует куда более строгой изоляции и ревью, чем разовый интерактивный turn: у неё нет человека рядом, а последствия накапливаются каждую ночь. Разумный путь - сначала автоматизировать read-only отчёт, убедиться, что он полезен и надёжен, и лишь затем, отдельно и осознанно, переходить к автоматической мутации. Сразу доверять ночную правку кода - значит рисковать вслепую.

Remote control - экспериментальная команда для локального app-server-демона и короткоживущего pairing. Полезно один раз увидеть её команды: start, pair с выводом в JSON и stop. Экспериментальный статус здесь важен так же, как у App Server: на команду не строят критичный процесс, не проверив её текущее поведение. Remote control удобен для быстрого связывания, но это не тот фундамент, на котором стоит возводить production-интеграцию.