Поверхности

Ядро одно, а окно в него можно открыть четыре раза: терминал, браузер, десктоп, Telegram. Различаются они тем, кто владеет процессом и какие инструменты доступны человеку на том конце.

Сводка

поверхность	команда запуска	что это	чего нет
TUI через поверхность	`snens tui`	терминальный клиент к работающему ядру по HTTP	пароль для `sudo` не спрашивает
локальный TUI	`snens tui-local`	прежний TUI: сам гоняет ход, без HTTP	нет общего списка сессий и веб-панелей
веб-клиент	`snens-web` (+ `snens serve`)	статика и прокси `/api` отдельным бинарём	токен ядра живёт только в прокси
десктоп	установщик приложения	окно Tauri с ядром-сайдкаром внутри	вторая копия данных не заводится
Telegram	процесс `snens-telegram`	бот, клиент ядра по HTTP/SSE	не работает без запущенного ядра

Метка поверхности уезжает в системный промпт (telegram, tui, web), поэтому модель знает, с кем говорит: в личном чате и в терминале поведение разное.

TUI через поверхность

snens serve                                  # ядро, отдельный терминал или сервис
snens tui                                    # клиент к нему
snens tui --session <ID> --endpoint <URL> --token-file <PATH>

Клиент читает токен из <каталог-данных>/api.token и адрес из --endpoint. Умеет: /new, /sessions, /resume <ID>, /stop, /reasoning, /memory on|off, /compact [инструкция], /model [slug], /help, /quit. Ctrl+C останавливает текущий ход.

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

Локальный TUI

snens tui-local
snens tui-local --session <ID> --config <PATH>

Полный цикл хода внутри одного процесса, без HTTP. Отсюда работает askpass: sudo спрашивает пароль у человека в том же терминале. Ещё умеет steer — строка, набранная во время хода, уходит агенту, а не в буфер. Без tty (пайп, скрипт) читает строки построчно, поэтому printf '…\n/quit\n' | snens tui-local остаётся проверяемым.

Это резервный путь: если ядро-поверхность не поднято, работать можно здесь.

Веб-клиент

Две части, обе — обычные бинарники:

snens serve --listen 127.0.0.1:7420          # ядро: API и SSE
snens-web --listen 127.0.0.1:5180 \
         --api http://127.0.0.1:7420 \
         --token-file ~/.local/share/snens/api.token

snens-web отдаёт собранный клиент из web/ рядом с собой и проксирует /api в ядро, подставляя Bearer из файла токена. Прокси нужен ровно затем, зачем раньше был нужен vite: браузер не должен знать токен инстанса. Ни node, ни npm в поставке не нужны.

флаг	дефолт / окружение	что задаёт
`--listen`	`127.0.0.1:5180`, `SNENS_WEB_LISTEN`	где слушать
`--api`	`http://127.0.0.1:7420`, `SNENS_API_BASE`	адрес ядра
`--token-file`	`<данные>/api.token`, `SNENS_API_TOKEN_FILE`	откуда брать токен
`--dist`	`web/` рядом с бинарём, `SNENS_WEB_DIST`	каталог клиента
`--no-proxy`	—	`/api` не проксируется: клиент подключается сам (пейринг)

Ассеты с хешем в имени кешируются навсегда, index.html — никогда: иначе обновление клиента не доедет до браузера.

Клиент скачивается готовым архивом (snens-web_<версия>_linux-x86_64.tar.gz): бинарь, web/, юнит systemd и README. Распаковал в каталог — работает.

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

Ядро тоже умеет отдавать статику (SNENS_WEB_DIR или web/ рядом с бинарём) — это путь установщика десктопа, где окно и ядро живут вместе. Для отдельного веб-сервиса он не нужен: прокси всё равно должен кто-то держать.

Десктоп

Установщик ставит окно Tauri, ядро-сайдкар, тулы и собранный клиент одним бандлом. Оболочка поднимает своё ядро на свободном порту и открывает окно на нём; при пейринге к чужому ядру своё не поднимает. Раскладка, трей и релиз — Десктоп.

Отдельный процесс на Go, снаружи ядра: он ходит в API как обычный клиент, держит SSE по курсору и хранит своё служебное состояние в SQLite. Отдельный репозиторий и отдельный релиз: snens-telegram, своя версия, обновляется независимо от ядра.

cp .env.example .env && chmod 600 .env   # TELEGRAM_TOKEN, ALLOWED_USER_IDS
go build -o bin/snens-telegram ./cmd/snens-telegram
bin/snens-telegram --env .env

Первое сообщение в разрешённом личном чате создаёт сессию с поверхностью telegram. Есть /new, /stop, /help, группировка пачки сообщений, стрим правкой сообщения, вложения и голосовые. Инструменты send_file, send_photo, send_voice доступны только сессиям этой поверхности. Пустой ALLOWED_USER_IDS запрещает запуск: доступ к боту = доступ к shell машины с ядром. Настройка через агента — в README репозитория, там же таблица переменных с дефолтами.

Что выбрать

нужен пароль от sudo и полный контроль из терминала — snens tui-local;
несколько окон, панели, дашборд, доступ с другого устройства — snens serve плюс клиент (браузер или десктоп);
работа с телефона — Telegram-бот.