Открытая техническая документация

Редакция 0.3 · 7 октября 2026 · Архитектура и границы текущей реализации.

1. Начать здесь

Vantemio соединяет программную оркестрацию, AI-компоненты, производственные инструменты и проверку результата. Station — каноническое ядро. Studio — прикладной модуль видеопроизводства. Vantemio Market — развиваемая связь цифровых услуг с заказом и доставкой.

Документ описывает ответственность компонентов и правила интеграции. Он не является справочником действующего публичного API: внешний API ещё запланирован. Примеры ниже концептуальные; имена в них не следует копировать как реальные endpoint или поля внутренней базы.

2. Карта ответственности

Последовательность: запрос → Station → допуск → исполнитель → результат → проверка → принятая версия. Память и граф связывают этапы, а не заменяют их. Следующий исследуемый переход — принятая версия → тестовый коммерческий сценарий.

3. Идентичность задания

Интеграции должны сохранять устойчивую идентичность запроса, ссылку на исходную версию, полномочия исполнения, исполнителя и связь с результатом. Смена маршрута не создаёт нового исходного автора и не удаляет прежнюю историю.

Концептуальный пример: запрос A относится к версии материала B; допуск C разрешает исполнителю D выполнить ограниченную операцию; результат E связан с A–D и проверкой F. Повтор запроса A требует поиска уже существующего исполнения и результата. Он не должен автоматически создавать новую операцию.

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

4. Допуск и состояния

Перед исполнением проверяются допустимая схема, версия материалов, права выполнения, готовность выбранного исполнителя, бюджет ресурсов и незавершённые назначения. Установленная модель, зарегистрированный узел и готовый исполнитель — разные состояния.

Для читателя состояние задания удобно представлять как «получено», «проверяется», «допущено», «в работе», «результат получен», «проверяется качество», «принято», «требует исправления» или «нужно выяснить исход». Это отображаемые понятия, а не утверждение о существующем перечне enum.

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

5. Восстановление без повторного выполнения

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

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

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

6. Память и технический граф

Существующая память хранит наблюдения с защитой от изменения, версии и связи зависимостей. Повторный снимок не должен создавать фиктивную историю; возвращение состояния A после B при этом должно оставаться видимым изменением.

Граф помогает связывать использованный материал, этап и результат. Кандидат на урок связывается с наблюдениями-основаниями. До отдельной проверки он не становится правилом выпуска. Доступ к предыдущим результатам помогает следующему решению, но не является обучением весов модели.

Границы: снимок состояния не доказывает каждое фактическое исполнение; отсутствующая история не восстанавливается догадкой; технический статус готовности не доказывает художественное качество.

7. AI и инструменты

Локальные и облачные обращения координируются через Station. Модель должна возвращать результат, соответствующий контракту задачи. Схема, ссылки на медиа и применимость действия проверяются до исполнения. Ответ неверной структуры остаётся ошибкой, даже если его текст выглядит разумным.

Планирование Qwen класса 27B имеет зафиксированные примеры использования. Book Coder 7B — ограниченный помощник. Для остальных специалистов следует публиковать отдельный статус: «конфигурация существует», «готовность проверена» или «есть результат конкретной задачи». Не объединять эти статусы в общий ярлык «работает».

Remotion/JavaScript и Blender относятся к графике и композиции; монтажный тракт включает Vidra/MLT. Упоминание инструмента показывает его архитектурную роль. Конкретный поддерживаемый сценарий и качество должны подтверждаться примером. Внешние средства разработки не являются производственным ядром.

8. Расширение вычислительного пула

Количество исполнителей не ограничивается нынешними тремя машинами. Новый узел вводится через существующий реестр Station после проверки устойчивой идентичности, возможностей и ресурсов. Конфликт идентичности отклоняется; версии регистрации сохраняются.

При назначении учитываются текущая готовность и уже занятые ресурсы. Обзор большого реестра должен поддерживать страницы результатов. Наблюдение за узлом не запускает worker и не активирует очередь. Тест со множеством синтетических узлов показывает поведение механизма, но не подтверждает наличие такого количества оборудования.

9. Результат и качество

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

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

10. Base/Boson и границы данных

Тестовая коммерческая интеграция использует Base Sepolia. Принятая версия, её идентификаторы и условия должны согласованно проходить между производственным и коммерческим модулями. Повтор события, неизвестный исход транзакции и изменение состояния сети требуют сверки до следующей операции.

Хеш помогает сравнить версии, но не устанавливает права на материалы. Публичная цепочка не должна служить хранилищем приватного медиа, секретов или внутренних логов. Решение о коммерческом выпуске требует отдельных условий доступа, доставки и проверки.

11. Публичные материалы и обратная связь

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

Для сообщения о проблеме полезны версия, сценарий, ожидаемое поведение и обезличенный результат. Секреты и приватные материалы в публичные обсуждения не отправляются. Контакт: support@vantemio.com.

12. Расширение за пределы Studio

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

Контракт нового модуля

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

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

Практический пример будущего процесса

Бриф бренда → план кампании → материалы Studio → проверка → согласованная публикация → метрики → рекомендация следующего варианта → задача CRM. Каждый переход имеет версию данных и ответственного исполнителя. На текущем этапе это целевая схема расширения; она не представляется готовой сквозной интеграцией.