Системная карта и ответственность компонентов
Область применения источника
Актуальная продуктовая модель содержит Двигатель, Штат, Штурвал, Штрих и Шлюз. Этот справочник задаёт ответственность компонентов; состояние конкретных соединений приведено в документе готовности. Старые схемы из каталога артефактов сохраняются как материалы истории проекта.
Состав и назначение
Двигатель управляет серверными агентами и состоянием работы. Штат — веб-поверхность сотрудника. Штурвал — интерфейс оператора компании. Штрих — личное приложение с контекстом и чатом. Шлюз — расширение браузера с чатом сайта и разрешёнными действиями.
Node, Native Messaging host, OpenCode и выбранная модель — поддерживающие части исполнения и транспорта. Они не добавляют пользовательские компоненты к указанным пяти. Operator MCP и встроенный TeamON MCP имеют свои границы полномочий.
Общая карта целевого экземпляра
Текстовая схема или контракт
flowchart TB Employee[Сотрудник] --> Staff[Сайт Штат] Operator[Оператор] --> Helm[Отдельный сайт Штурвал] IdP[Служба входа заказчика] --> Web[Web backend: сессии и область доступа] Staff --> Web Helm --> Web Web --> Core[Двигатель: Core] Channels[Разрешённые мессенджеры] --> Core Core --> Executor[OpenCode] Executor --> LLM[Модель заказчика или российский API] Executor --> Tools[Разрешённые инструменты] Tools --> Systems[Системы заказчика] Core --> State[История, задания, файлы, квитанции] Core --> STT[Распознавание речи по выбранному профилю] Core <--> Node[Node: транспорт и Native host] Node <--> Extension[Шлюз: расширение браузера] Node <--> Personal[Штрих: личное приложение] Node --> Device[Разрешённые ресурсы компьютера] Personal -. корпоративное подключение требует реализации .-> Core
Стрелка обозначает взаимодействие, а не разрешение на неограниченный доступ. Точный протокол, порт и политика задаются контрактом и профилем развёртывания. Веб-пилот с локальными индивидуальными сессиями и серверными привязками существует. Корпоративный IdP, произвольные проектные роли и полный интерфейс Штурвала остаются отдельными этапами. Показанная карта является целевой, а готовность каждого соединения описана ниже.
Владение состоянием
| Данные | Ответственный компонент | Правило взаимодействия |
|---|---|---|
| Учётная запись организации | IdP заказчика | Backend проверяет вход и связывает личность с разрешениями |
| Сессия сайта и её отзыв | Web backend | Браузер не назначает себе роль или проект |
| Агент, диалог, задание, история | Core | UI отправляет команды и читает разрешённое представление |
| Техническая сессия исполнения | OpenCode | Связана с заданием Core, не подменяет его бизнес-состояние |
| Результат внешнего действия | Исполнитель и квитанция Core | Отправка команды не равна успешному выполнению |
| Локальное устройство и разрешения ОС | Штрих, Node и Шлюз в своих границах | Серверное поручение ограничено pairing и локальными разрешениями |
| Файлы и знания | Рабочая область Core или разрешённый источник | Назначение агенту и доступ пользователя проверяются отдельно |
| Ключи провайдеров | Серверный профиль секретов | Не попадают в UI, общую поставку и журнал |
| Черновик интерфейса | Штат/Штурвал | До принятия сервером не является выполненной операцией |
Это целевое распределение ответственности. Миграция старых путей и конкретная схема делегирования полномочий проходят отдельную реализацию и испытания.
Сквозной сценарий сотрудника
Текстовая схема или контракт
sequenceDiagram
actor User as Сотрудник
participant UI as Штат
participant Web as Web backend
participant Core as Двигатель
participant Model as Модель и инструменты
participant Node as Node и разрешённый Шлюз
User->>UI: Задача и выбранные материалы
UI->>Web: Команда в авторизованной сессии
Web->>Core: Проверенный actor и область доступа
Core-->>UI: Задание принято, идентификатор
Core->>Model: Выполнение в разрешённых пределах
opt Нужно действие на компьютере
Core->>Node: Команда для связанного устройства
Node-->>Core: Результат или отказ/неизвестное состояние
end
Model-->>Core: Результат выполнения
Core-->>UI: Состояние и доступные артефакты
UI-->>User: Проверяемый результатПри разрыве связи интерфейс перечитывает состояние по идентификатору. Он не создаёт второе задание автоматически. Неизвестный эффект выясняется до повтора. Изменение оператором проходит подготовку, просмотр, подтверждение и проверку ревизии; подробный сценарий описан в паспорте Штурвала.
Границы и зависимости
Браузер, сервер, компьютер сотрудника и внешние API — разные зоны доверия. Текст модели, документ и страница браузера не предоставляют полномочий. Контроль выполняется на сервере и повторно перед чувствительным действием. Корпоративный контур может использовать внутреннюю модель; внешний API требует явно выбранной политики передачи данных. Локальная установка сама по себе не означает отсутствия сетевых обращений или готового автономного режима.
Двигатель нужен всем сценариям. Штат и Штурвал используют его контракты через авторизованный backend. Шлюз нужен сценариям устройства. STT нужен обработке реального аудио; тестовый текст не подтверждает работу распознавания. Недоступность опционального подключения должна давать понятный статус конкретной функции.
Как читать документацию
- Состав и границы продукта (см. оглавление документации).
- Паспорта пяти компонентов: цели, пользователи, карты, данные, архитектура, сценарии, безопасность, отказы, эксплуатация, источники и открытые решения.
- Экраны и роли (см. оглавление документации) и технический проект (см. оглавление документации).
- Реестр наработок (см. оглавление документации) и состав артефактов (см. оглавление документации).
- Этапы реализации (см. оглавление документации), план демо (см. оглавление документации), приёмка ENT (см. оглавление документации).
Готовность и поддержание документов
«Есть исходник», «собирается», «проверено локально» и «принято в корпоративном профиле» — разные статусы. Наличие описания не закрывает ENT. Для приёмки нужны версия артефакта, среда, шаги, фактический результат и файл доказательства. Паспорта фиксируют проверенные исходные точки и целевое поведение отдельно.
При изменении компонента обновляются его паспорт, общий контракт при затрагивании соседей, состав артефактов и связанные ENT. Новая поддерживаемая ОС, модель или интеграция появляется в эксплуатационных обещаниях после испытания. Нерешённые вопросы сохраняются в разделе открытых решений до получения фактов.
Текущая связность
Штат и веб-Штурвал обращаются к своему backend и разрешённым API Core. Публичный консультант использует отдельный gateway и отдельный профиль OpenCode с запрещёнными инструментами. Он не подключён к корпоративным полномочиям сотрудника.
Личная связанная беседа Штрих — Шлюз реализована в согласованном кандидате через Node. Корпоративный маршрут расширения проходит через Node к Core. Нативное корпоративное подключение самого Штриха, общая личность работы между всеми каналами и перенос фонового Node остаются отдельными задачами.
Штрих сейчас предоставляется для macOS 15 и новее; Windows запланирована. Состояние каждого пути проверяется независимо, включая полномочия, модель, историю, локальные действия и отзыв.