nocx

Откуда взялся nocx

Исходная идея была практической: собрать локальный терминал, в котором современные agent TUI, SSH и остальная работа с удалённой машиной не распадаются на несколько несвязанных приложений. Отдельно уже существовали хорошие терминалы, SSH-менеджеры, хранилища секретов и интерфейсы для ассистентов. Проблема была не в отсутствии каждой функции по отдельности, а в том, что их рабочий контекст оказывался разделён.

Поэтому nocx с самого начала строился как сочетание нескольких вещей в одном локальном приложении: терминала с качественным рендерингом, SSH-менеджера, vault, вкладок и рабочих пространств, передачи файлов, API-клиента и ассистента, который действует в той же прокрутке, что и человек. Без обязательного аккаунта, собственного облачного сервиса и продуктовой телеметрии.

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

Что уже выпущено

В v0.3.0 nocx — самостоятельный локальный терминал для macOS и Linux: GPU-рендеринг, SSH, вкладки и рабочие пространства, восстановление сессий, vault, передача файлов, API-клиент и ассистент в той же прокрутке. Это уже выпущенная версия, а не обещание из дорожной карты.

Почему следующая задача изменила архитектуру

Пока ассистент работал в рамках открытого окна, экран мог принадлежать браузерному terminal renderer. Но оркестрация добавила другой сценарий: ассистент запускает worker, читает его pane, отвечает на его меню и отправляет ему ввод, даже если конкретное окно сейчас не открыто.

Здесь прежняя модель стала давать неправильные гарантии. Backend видел поток байтов и мог хранить только ограниченное окно для replay. Если вывод превышал примерно 256 KB, восстановление превращалось в reset. Процесс при этом мог продолжать работать после того, как coordinator потерял окно вывода. Кроме того, скрытые frontend-renderer’ы могли отвечать программе на terminal queries, тогда как backend-копия эти ответы отбрасывала. У одной живой программы фактически оказывались два возможных ответчика.

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

Новая архитектурная ставка

В рабочей ветке feat/agent-orchestration принята модель: один VT-эмулятор живёт в backend session runtime и владеет состоянием сессии.

Backend теперь должен владеть экраном, режимами терминала, ответами на вопросы программы, геометрией и порядком допуска ввода. Клиент отвечает за отображение, layout, выделение, accessibility и IME. Действия пользователя и агента приходят не как сырые байты, а как намерения: клавиша, текст, option или paste. Runtime сам кодирует их с учётом реальных режимов терминала.

Это позволяет одному владельцу последовательно обработать вывод программы, ответы эмулятора, resize, ввод человека, ввод агента и завершение сессии. Координатор или desktop-клиент могут перезапуститься, не забирая с собой состояние живого процесса.

Именно поэтому из этой роли убирается xterm.js. Мы не просто меняем renderer и не оставляем два эмулятора «для надёжности»: xterm.js сам интерпретирует байты, хранит собственную сетку и отвечает программе. Если оставить его как «пассивную рисовалку», frontend всё равно продолжит выполнять cursor moves и erase поверх уже рассчитанного backend-состояния. Это снова создаст две расходящиеся версии терминала.

Подробное решение зафиксировано в ADR-0066. Отдельно проверен и выбран движок для backend-эмулятора — ADR-0065.

Что строится сейчас

Следующий слой — оркестрация рабочих процессов. Ассистент может запустить worker в отдельной вкладке, передать ему задачу, узнать, что осталось у его сессии, дождаться изменения состояния, отправить сообщение или ответить на вопрос worker и закрыть его. Backend хранит запись worker и продолжает наблюдать за ним, пока ассистент занят другой задачей или вообще не делает ход.

Здесь есть несколько проверяемых артефактов. workers.spawn возвращает идентификатор, состояние и признак, дошла ли первая задача до pane; если pane остановился на вопросе, ответ содержит waitingOn. workers.holdings показывает состояние каждого worker, исходную задачу, его отчёт и необходимость решения. Mailbox отдельно показывает сообщения, которые ещё не забраны worker или координатором. Завершение определяется отчётом самого worker вместе с выходом его процесса: один экран, молчание или красивое название вкладки готовностью не считаются.

Поверх этого runtime появляется единая поверхность для работы с descendant panes: прочитать экран, отправить один проверенный шаг ввода и передать сообщение worker’у. Это меняет и цену следующего шага. Нужны клиентский cell renderer, новый frame-протокол, backend-кодирование клавиш, восстановление эмулятора после потери части вывода и отдельная доставка эффектов, которые не являются изменением cells — например уведомлений или clipboard. Поэтому решение принято сейчас, но описывать его как готовую функцию ещё рано.

Границы готовности

v0.3.0 подтверждена тегом и собранными релизами. Архитектура backend-owned terminal и agent orchestration пока находятся в origin/feat/agent-orchestration: они не вошли в main, не имеют собственного релиза, а текущий клиентский переход ещё не завершён. В текущей работе проверяется механизм одного worker и его жизненный цикл; полноценные fan-out, восстановление после перезапуска backend и работа с закрытым окном остаются отдельными задачами.

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

Открытый вопрос теперь звучит так: как перейти от одного наблюдаемого worker к нескольким и закончить переход на единый живой экран, чтобы ассистент получил реальную помощь, а человек — не ещё один экран, за которым нужно следить вручную?