DeepSeek Harness Plan Mode: план или выполнение

Главная ошибка при выборе режима — считать Plan Mode универсальным «безопасным переключателем». Он не заменяет резервную ветку, изоляцию секретов, тестовый контур или человеческое утверждение. В актуальной версии DeepSeek Harness наличие состояния планирования подтверждается кодом и событиями сохранения сессии, но конкретный вход в режим, ограничения записи и связь с политиками разрешений могут меняться вместе с developer preview. Их следует сверять с веткой master и исходным кодом проекта перед каждым внедрением в командный процесс.

Для независимого разработчика минимальный порог прямого выполнения выглядит так:

• изменение ограничено одним файлом или одним явно изолированным участком;
• результат легко отменить через diff или отдельный коммит;
• рабочая область уже знакома;
• команда проверки известна заранее и действительно проверяет изменённое поведение;
• в задаче нет секретов, production-конфигурации и миграции данных;
• цена ошибочной записи ниже цены дополнительного этапа планирования.

Если хотя бы два пункта не выполняются, разумнее начать с планирования. Особенно это касается кода, где изменение в одном модуле меняет контракты нескольких соседних модулей.

Такой порог полезнее фиксированного правила «всегда планировать сложный код». Например, исправление одной очевидной опечатки в конфигурации можно выполнить напрямую, а «небольшое» изменение схемы базы данных уже требует плана, даже если затрагивает формально один файл.

Когда разработчик впервые открывает рабочую область, задача DeepSeek Harness должна начинаться не с редактирования, а с восстановления карты проекта. Планирование в этом случае — не бюрократия, а способ отделить найденные факты от предположений агента.

До перехода к исполнению необходимо получить минимум следующие доказательства:

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

В официальном README указано, что проект запускается из исходного checkout через установку зависимостей, сборку и запуск Web UI; по умолчанию интерфейс обслуживается на 127.0.0.1:3080 (инструкция запуска из исходного кода). Этот параметр не следует воспринимать как гарантию одинакового запуска в любой удалённой среде: порт, процесс, права пользователя и способ публикации интерфейса нужно проверить на конкретном Mac.

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

Важно: текст плана — это результат исследования, а не доказательство того, что изменения уже безопасно применять. Перед записью нужно повторно сверить состояние рабочей области и подтвердить, что найденные предпосылки не изменились.

При чтении незнакомого репозитория удобно использовать следующий порядок:

1. Зафиксировать текущий каталог, ветку и базовый коммит.
2. Найти manifest-файлы, точку запуска и конфигурацию сборки.
3. Проследить вызовы от пользовательского сценария до изменяемого участка.
4. Найти тесты, которые подтверждают текущее поведение.
5. Сформулировать минимальный набор файлов для изменения.
6. Указать, какие файлы намеренно не затрагиваются и почему.
7. Сохранить команду проверки и ожидаемый результат.

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

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

Минимальный task contract должен содержать три решения:

1. Кто проверяет план. Этот человек отвечает за архитектурную полноту и отсутствие пропущенных зависимостей.
2. Кто разрешает запись. Это не обязательно автор плана; роль может принадлежать владельцу репозитория или ответственному за платформу.
3. Кто принимает результат. Он запускает тесты, проверяет diff и подтверждает возможность отката.

Такой подход соответствует стандартным механизмам контроля изменений: GitHub поддерживает обязательные ревью, проверки статуса, ограничения записи и правила для защищённых веток (документация GitHub о защищённых ветках). Для чувствительных каталогов можно дополнительно назначать владельцев кода, чтобы запрос на проверку автоматически направлялся ответственным участникам (документация GitHub о Code Owners и стандартизации pull request).

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

Переход к исполнению допустим, когда выполнены четыре условия:

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

Если одно из условий нарушено, план нужно пересмотреть, а не продолжать выполнение по инерции.

Для проектов с доступом к ключам, production-настройкам, клиентским данным или закрытым репозиториям планирование и исполнение должны происходить в разных контурах. Plan Mode не отменяет принцип минимальных прав: если процесс видит секретный файл, он уже получил доступ к чувствительным данным, даже если пока ничего не записывает.

На этапе планирования разумная конфигурация выглядит так:

• чтение только нужных каталогов;
• запрет записи вне файла самого плана или разрешённого временного каталога;
• отсутствие production-секретов в переменных окружения;
• отключённый доступ к внешней сети, если он не нужен для исследования;
• сохранение идентификатора сессии и исходного коммита.

На этапе исполнения права временно расширяются, но только под конкретную задачу. Не следует выдавать агенту доступ ко всему домашнему каталогу или ко всем рабочим проектам ради удобства. Официальный репозиторий отдельно предупреждает о быстром развитии проекта и возможных несовместимых изменениях (статус developer preview), поэтому политика разрешений должна проверяться после обновления, а не считаться неизменной.

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

Ниже приведён порядок, который подходит и независимому разработчику, и команде с ревью. Он не привязан к конкретной кнопке или команде интерфейса, поскольку такие детали могут меняться в developer preview.

Подготовьте исходное состояние

• [ ] Проверена текущая ветка.
• [ ] Записан базовый коммит.
• [ ] Зафиксированы незакоммиченные изменения или рабочая область очищена.
• [ ] Проверены зависимости и версия инструментов.
• [ ] Определён владелец решения по записи.

Сформируйте план

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

Проверьте права рабочей области

Сопоставьте фактически доступные инструменты и каталоги с задачей. Если агент может писать в более широкий диапазон, чем требуется, сначала ограничьте область. Если это невозможно, выполнение следует перенести в отдельную временную среду.

Утвердите переход

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

Выполните изменения малыми порциями

После каждого логического этапа проверяйте diff. Не следует ждать завершения всего рефакторинга, если первый изменённый модуль уже нарушил тест или расширил область записи.

Проведите независимую приёмку

Запустите тесты, линтер и сборку, указанные в плане. Затем проверьте фактически изменённые файлы, отсутствие секретов в diff и соответствие результата исходному контракту. Для команд, работающих через pull request, полезно сохранять ревью и результаты проверок отдельно от сообщения агента (документация GitHub о проверке изменений в pull request).

Зафиксируйте результат и откат

Сохраните коммит, результаты проверок, предупреждения и команду возврата. Если тесты не прошли, статус должен быть «не принято», даже если агент утверждает, что причина внешняя.

Удалённая работа добавляет риск рассинхронизации. SSH-соединение может оборваться, процесс может завершиться, Mac может перезапуститься, а рабочая область — измениться другим пользователем. При этом сохранённая история продолжит выглядеть убедительно и может создать ложное ощущение непрерывности.

Перед возобновлением задачи нужно выполнить пять проверок:

1. Подтвердить, что подключён именно нужный удалённый Mac.
2. Сверить путь рабочей области и пользователя процесса.
3. Проверить ветку, базовый коммит и незакоммиченные изменения.
4. Убедиться, что зависимости, виртуальные окружения и локальные сервисы доступны.
5. Сопоставить план с фактическим diff и заново запустить минимальную проверку.

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

Для удалённой эксплуатации полезны инструкции NUKCLOUD по помощи и рабочим сценариям, однако конкретные права, процесс восстановления и способ подключения должны быть проверены в выданной среде. При выборе постоянного удалённого рабочего места также стоит отдельно оценить условия аренды Mac в NUKCLOUD: временная среда удобна для исследования и приёмки, но не заменяет проектирование долгоживущего production-контура.

Ниже — условный алгоритм, который можно превратить в командную политику:

• Если изменение локальное, обратимое, тест уже существует, а рабочая область знакома, то выбирайте прямое выполнение.
• Если затронуты несколько каталогов, но владелец проекта один и откат понятен, то начинайте с краткого плана и переходите к исполнению после проверки списка файлов.
• Если репозиторий незнаком, то сначала собирайте только read-only сведения: входы, зависимости, тесты и ограничения.
• Если есть миграция, секреты, production-конфигурация или клиентские данные, то разделяйте планирующую и исполняющую среды.
• Если после обрыва удалённой сессии изменились ветка, коммит или зависимости, то возвращайтесь к планированию, даже если ранее план был утверждён.
• Если команда не определила, кто разрешает запись и кто принимает результат, то не переходите к широкому исполнению.
• Если план содержит только общие намерения без доказательств по коду и команды проверки, то возвращайте его на доработку.
• Если прямое выполнение уже начало менять файлы, но область задачи расширилась, то остановите работу, сохраните diff и переключитесь на двухэтапный процесс.

Для независимого разработчика прямое выполнение экономит время только там, где ошибка действительно быстро устраняется. Если удаление или изменение можно отменить одной операцией, тестовая команда известна, а рабочая область не содержит скрытых зависимостей, Plan Mode добавит лишнюю задержку.

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

Текущая схема без разделения режимов обычно имеет три недостатка: агент получает слишком широкий доступ до уточнения границ, план и фактический diff проверяются одним и тем же участником, а после разрыва удалённой сессии восстановленный контекст ошибочно принимают за восстановленное состояние среды. В таких задачах арендованный Mac через NUKCLOUD может быть удобнее собственного компьютера или случайной облачной машины: рабочую среду можно выделить под конкретную проверку, отделить от личных данных и затем закрыть после приёмки. Но для постоянной тяжёлой нагрузки, физического оборудования или строго закреплённых локальных интерфейсов аренда подходит не всегда — тогда оправдан собственный Mac и отдельная инфраструктурная политика.

После выбора режима рекомендуется сверить рабочую область, права и условия восстановления по материалам NUKCLOUD о доступной инфраструктуре, а затем принять решение: краткую задачу выполнять напрямую, незнакомую — сначала исследовать, а рискованную — проводить через формальный Plan Mode с отдельным утверждением и доказательствами приёмки.