# Подробный паспорт Двигателя Редакция 2026-09-15 Статус: Редакция 15 сентября 2026 года; состояние функций уточняется документом готовности ## Область применения источника Двигатель — серверная часть Core, существующие каналы, история, задания, полномочия и инструменты. Описанные далее обязанности задают архитектуру; фактическая включённость функций зависит от версии экземпляра. Свежий код не считается автоматически развёрнутым на публичном сервере. Управляемый Context в проверенном срезе является выключенным по умолчанию лабораторным режимом владельца. Общая корпоративная история всех интерфейсов и файловая изоляция многопользовательских исполнителей не считаются завершёнными. ## 1. Цель и смысл Превратить запрос человека в управляемое выполнение: сохранить задачу и контекст, подключить разрешённую модель и инструменты, довести действие до наблюдаемого результата. Пользователь должен продолжить ту же работу после переключения между Штатом, Шлюзом и подключённым каналом. Оператор должен видеть, что действительно произошло, в том числе когда результат внешнего действия неизвестен. Двигатель — владелец агентной работы. Core управляет состоянием и полномочиями; OpenCode исполняет модельный цикл. Наличие OpenCode не означает, что вся бизнес- логика переносится в него или что собственная языковая модель входит в продукт. ## 2. Пользователи и ценность Сотрудник получает результат и историю; оператор — управляемые операции и диагностику; администратор — обслуживаемый экземпляр с понятным состоянием. Разработчик интеграции получает проверяемые контракты вместо доступа к БД. Критерии ценности: задача завершается результатом, история восстанавливается, отмена работает, повтор не создаёт лишний внешний эффект, чужие данные недоступны. Процент успешных задач и задержки измеряются на стенде; целевые числа ещё не заданы. ## 3. Системная карта ```mermaid flowchart LR Inputs[Штат / Штурвал / Штрих / Шлюз / каналы] --> API[Проверка actor и входного контракта] API --> Core[Core: задача и состояние] Core --> Queue[Очередь и жизненный цикл] Queue --> Executor[OpenCode] Executor --> Model[Разрешённая модель] Executor --> Tools[Инструменты и коннекторы] Tools --> Result[Результат и квитанция] Result --> Core Core --> Store[История / context / файлы] Core --> Events[События и чтение состояния] ``` Это целевая корпоративная карта. Разные текущие входы имеют разные механизмы identity; единый scoped web-вход ещё требуется реализовать. ## 4. Ответственность и данные Core владеет пользователем/ролью в своём runtime, агентом, диалогом, состоянием задания, назначенным контекстом, расписаниями и receipt. SQLite и рабочие области составляют operational state. Web-клиенты читают разрешённые представления и подают команды, а не изменяют таблицы напрямую. Один логический writer выполняет составные изменения; исторические пути требуют сверки с ADR-016. OpenCode владеет исполнением модельного turn и техническими данными своей сессии; Core сохраняет связь с бизнес-задачей и её состоянием. Шлюз владеет локальным исполнением device command. Нельзя объявлять локальное действие успешным по факту его постановки в серверную очередь. ## 5. Архитектурные блоки и код | Блок | Источник | Роль | |---|---|---| | Runtime и маршрутизация | src/main.ts, provider-dispatch.ts, agent-opencode.ts | Выбранный исполнитель и агентный цикл | | Сериализация и жизненный цикл | session-turn-queue.ts, runtime-turn-context.ts, turn-receipt.ts | Продолжение, порядок, результаты | | Данные | db.ts, reminder-store.ts | История, события, напоминания | | Команды управления | core-command.ts, operator-runtime.ts | Typed commands и Core authority | | Устройства и каналы | edge-store.ts, channel-edge.ts, bridge-compat.ts | Pairing, actor/agent binding, delivery | | Вложения и речь | bridge-attachments.ts, bridge-voice.ts, audio-chunks.ts | Рабочая область, лимиты, обработка медиа | | Диагностика | main-dashboard.ts, monitor.ts | Существующая техническая поверхность | Пути относительно src/ в этом репозитории. Это карта проверенных точек интеграции, не утверждение, что каждая ветка старого runtime уже соответствует целевому профилю. ## 6. Контракты и жизненный цикл Вход должен связывать authenticated actor, agent, разговор/рабочую область, request ID, текст/вложения и разрешённые действия. Идентификаторы не выводятся из display name. Конкретные существующие schemas берутся из модулей Core; не добавляем несовместимые поля без новой версии контракта. Целевой переход: принято → выполняется → ожидает данных/подтверждения → завершено, ошибка либо отменено. Неизвестный внешний эффект требует status/reconcile. Доставка события может повторяться, но повтор command ID не должен повторять бизнес-действие. Переключение провайдера после возможного эффекта не означает безопасного повторного запуска. Подтверждение изменения связано с digest/revision. ## 7. Полномочия и границы доверия Контекст модели и содержимое файла не являются разрешением. Сервер определяет actor и область доступа, повторно проверяет их при исполнении после очереди. Отдельно контролируются агентные shell/file/network инструменты: фильтрация UI не ограничивает процесс исполнителя. Ключ модели не должен становиться доступным произвольным child tools; способ доставки credentials требует испытания. Существующий company-scope Operator не является корпоративным RBAC. Требуются проектные/пользовательские scopes, привязка IdP и отзыв действующих полномочий. Пути, файлы и секреты защищаются независимо от роли owner. ## 8. Ошибки и наблюдаемость Модель недоступна: явная ошибка readiness; запрещён незаявленный внешний fallback. Инструмент завершился неизвестно: сохраняем исходное намерение и выясняем эффект. Занята рабочая область: последовательная обработка или явный конфликт. Диск заполнен: контролируемая ошибка без ложного «файл создан». Отмена: проверяется остановка текущей работы и дальнейших побочных действий. Наблюдаемость: request/run/receipt IDs, очередь, длительность этапов, provider readiness, ошибка и безопасный контекст для поддержки. Не журналируем raw secrets, а содержание разговоров защищаем политикой доступа/хранения. ## 9. Развёртывание и сопровождение Core/OpenCode на сервере заказчика или тестовой VM; технические порты закрыты от браузера. Версии, native dependencies и модель закреплены. Данные отделены от immutable release. Backup охватывает согласованный набор БД/файлов/настроек; миграция и rollback проверяются совместно. Single-node не равен HA. ## 10. Что есть и что предстоит Есть исходный Core 0.18.1, локальные unit/build и технический smoke, OpenCode startup, операторские команды и bridge. Не приняты: Linux-поставка, российская модель с tools, реальная STT, полный web identity/RBAC, новая UI/клиентская связка. Локальный synthetic recording test не является измерением качества речи. ## 11. Приёмка ENT-02/03/04/08/15/16/18/19/20/21/36/38. Минимум: чистая установка; task с tools и файлом; restart и resume; дубль/отмена/неизвестный эффект; отказ чужому actor; backup/restore. DEMO-01/02/03/07/08. В отчёте — точные версии и реальные результаты. ## 12. Открытые решения Выбранная модель/STT, схема делегированной web identity, Linux/BOM, лимиты, лицензирование и egress. Их отсутствие явно блокирует соответствующий ENT, но не переносит ответственность на пользовательский интерфейс. Общий контекст: системная карта (см. оглавление документации), критерии приёмки (см. оглавление документации), план демо (см. оглавление документации). ## Текущий слой контекста Встроенный TeamON MCP предоставляет логические области компании, агента и пользователя. Контекстные документы, подтверждённая память и состояние работы имеют разных владельцев. Поиск публичной документации сайта является отдельным сервисным корпусом и не заменяет эти функции. Управляемый Context описывает объекты и коллекции с проверками областей доступа. Включение допускается в лабораторном профиле владельца; выдавать этот режим за готовую общекорпоративную базу знаний нельзя. До выпуска необходимо подтвердить изоляцию процессов, чтение исходников и версий, отзыв прав и обходные файловые пути.