Обновление node-pty в DeepSeek Harness: что проверить

В заметках к релизу отдельно упомянуты исправление задержки persistent Bash в минимальном режиме и обновление node-pty 1.2 beta для более широкой совместимости PTY. Это два связанных, но не одинаковых сигнала.

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

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

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

Сам node-pty нужен для запуска процессов через псевдотерминал. В официальной документации среди типичных применений указаны эмуляторы терминала, передача управляющих последовательностей и запуск оболочек вроде Bash. Для вашего решения это означает: изменение библиотеки может проявиться не только в запуске команды, но и в обработке ввода, размеров терминала, выходных данных и завершения процесса. Документация node-pty и пример работы с Bash

Начинайте не со сборки и не с длинного агента. Сначала подтвердите, что интерактивная команда проходит полный цикл:

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

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

Минимальный набор команд должен проверять разные свойства, а не только факт запуска Bash:

printf 'start\n'
printf 'line-1\nline-2\nline-3\n'
pwd
printf 'exit-code-check\n'; false; printf 'status=%s\n' "$?"

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

На этом этапе нельзя писать в отчёте «совместимость улучшилась» только потому, что одна команда отработала. Запишите конкретно: какая команда, какая оболочка, какой Mac, какая дата, какой результат и какой код завершения.

Иногда — возможно, но утверждать это заранее нельзя. В rc.7 отдельно заявлено исправление задержки persistent Bash в минимальном режиме. Это более узкая формулировка, чем обещание исправить все задержки терминала. Официальные примечания к релизу

Разделите наблюдение на три цепочки:

• PTY и терминальная зависимость. Процесс может работать, но данные неправильно передаются или отображаются.
• Постоянная Bash-сессия. Сама оболочка может задерживать обработку или продолжение команды.
• Модель и интерфейс. Harness может ждать очередной ответ, обновление панели или результат инструмента, хотя терминальный процесс уже передал часть вывода.

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

Проверяйте не только финальный результат. Отмечайте:

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

Не используйте единичный успешный запуск как доказательство стабильности длинной операции. Долгие сборки чувствительны к накоплению вывода, переключению вкладок, разрыву сети и состоянию рабочего каталога.

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

Полезная последовательность выглядит так:

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

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

Не вводите универсальный порог «допустимого» объёма вывода без собственных данных. Для одной команды проблема проявится в передаче строк, для другой — в отмене, а для третьей — после переподключения.

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

Проверяйте только те границы, которые участвуют в вашей работе:

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

Изменение размера важно проверить отдельно. Программа может запускаться нормально, но продолжать работать со старым числом строк и столбцов. Тогда ошибка проявится не как сбой node-pty, а как неверная разметка интерфейса.

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

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

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

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

Поэтому проверяйте реконнект с двух сторон. Сначала намеренно разорвите подключение во время работающей команды. Затем снова откройте интерфейс и зафиксируйте, появляется ли новый вывод, доступна ли отправка ввода и совпадает ли статус с фактическим состоянием процесса на Mac.

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

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

Для такого сценария полезно связать результаты с проверкой фоновых задач DeepSeek Harness: терминальная регрессия показывает поведение канала, а отдельная приёмка фонового задания — что произошло с самой операцией. Если проблема начинается после переподключения Web UI, рассматривайте её как отдельную ветку диагностики доставки и доступа. При необходимости отдельный удалённый Mac можно использовать только как контрольную среду для повторения тех же команд и сравнения результатов. Перед таким сравнением зафиксируйте рабочий каталог, системное окружение и способ подключения в отдельном разделе для проверки удалённого доступа.

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

• одна интерактивная Bash-команда;
• одна длительная сборка;
• одна команда с постоянным выводом;
• одна задача, которую можно отменить.

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

Не называйте число параллельных задач допустимым лимитом без реального измерения на вашем Mac. Ресурсы зависят от версии macOS, окружения Node.js, характера вывода и самих процессов. Официальный репозиторий node-pty описывает поддержку macOS, но это не является обещанием одинакового поведения каждой сборки на каждом компьютере. Сведения о платформах node-pty

Выполняйте проверку в таком порядке:

• зафиксируйте версию DeepSeek Harness, версию macOS, архитектуру Mac, оболочку Bash и способ удалённого доступа;
• сохраните одну команду с коротким выводом и одну команду с промежуточными маркерами;
• проверьте эхо ввода, последовательность вывода и код завершения;
• запустите прежнюю сборку без изменения исходных параметров;
• остановите работающую задачу и проверьте процесс на удалённом Mac;
• выполните сценарий с намеренным разрывом подключения;
• восстановите сессию и отдельно проверьте вывод, ввод и состояние процесса;
• запустите небольшой набор параллельных задач с уникальными маркерами;
• повторите тот же набор на предыдущем выпуске;
• сохраните журналы и оформите решение: продолжать, ограничить или откатить.

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

Сравнивайте rc.7 и исходную версию на одинаковых задачах. Не сравнивайте новую сборку на одном Mac со старой на другом, если хотите сделать вывод именно о node-pty.

Откат нужен не потому, что обновление обязательно плохое. Он нужен, когда цена неопределённости выше пользы от новой зависимости. До расширения пилота зафиксируйте версию пакета, журнал установки и способ возврата к предыдущей сборке. Учитывайте, что rc.7 остаётся предварительным выпуском, а upstream-ветка node-pty 1.2 также развивается как beta-линейка. Список выпусков node-pty

Не меняйте одновременно версию Harness, Node.js, оболочку и настройки доставки. Иначе вы не поймёте, что именно изменило поведение терминала.

Напоминание: успешная проверка на одном Mac подтверждает только этот набор «версия — система — задача — дата». Она не заменяет матрицу окружений, если команда использует несколько удалённых машин.

После обновления node-pty вам обычно не требуется автоматически переписывать конфигурацию DeepSeek Harness. Сначала проверьте фактическое поведение существующей настройки. Новая зависимость может изменить совместимость бинарного модуля, обработку PTY или жизненный цикл процесса, но это не означает, что прежние параметры нужно менять без симптома.

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

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

Для удалённых задач это важнее самой строки в журнале зависимостей. Пользователь оценивает не факт установки node-pty, а возможность безопасно запустить Bash, увидеть прогресс, отменить работу и понять, что произошло после разрыва.

Поэтому первая волна действий после обновления node-pty в DeepSeek Harness должна быть ограниченной. Не расширяйте закупку, не переносите все долгие задания и не отменяйте резервный процесс только на основании текста release notes.

Если сейчас вы используете собственный Mac или нестабильную удалённую схему, у неё обычно есть три реальные слабости: физическая машина занята другими задачами, восстановление после разрыва зависит от вашей ручной диагностики, а повторяемость окружения ухудшается при смене пользователя или рабочего каталога. Для короткого теста CALMVPS может быть удобнее как отдельная удалённая Mac-среда: вы сначала проверяете конкретный сценарий, фиксируете результат доставки и только затем решаете, нужен ли постоянный ресурс. Для долгой неизменной нагрузки, физических интерфейсов и оборудования, привязанного к локальной сети, аренда подходит не всегда — там разумнее сохранить собственный Mac.

Начните с короткого набора регрессии: Bash, непрерывный вывод, отмена, реконнект и параллельная изоляция. Если эти проверки пройдены на вашей версии macOS и в вашей схеме удалённого доступа, rc.7 можно оставлять в ограниченном пилоте. Если нет — откат и сохранённая минимальная репродукция дадут больше пользы, чем раннее расширение.